[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: auf UTF-8 umsteigen, Folgen?



On 11.07.06 20:58:41, Steffen Schulz wrote:
> Mail ist nen bissl doof. Entweder weil ich noch immer was falsch mache,
> oder viele Clients nicht mit utf8 klar kommen. (?,?,?,?,?,?,?, anyone?)

Hae? Mutt kann wunderbar UTF-8, sofern das korrekt in der Shell gesetzt
ist. Aber das ist noch lange kein Grund seine latin1/latin9 Mails als
UTF-8 zu verschicken, dafuer gibts sowas:

set send_charset = "us-ascii:iso-8859-1:iso-8859-15:utf-8"

Damit nimmt mutt das "kleinstmoegliche" Charset beim verschicken. Also
hier meistens iso-8859-1.

> Ein Problem stellen auch zB Dateinamen dar. Die sind ja auch irgendwie
> kodiert, verfuegbare Codings sind im Kernel zu konfigurieren.

Also damit habe ich eigentlich auch keinerlei Probleme. Wenn ein User
mit de_DE locale eine Datei mit Umlauten auf einem *nix-Dateisystem
ablegt kann ich die auch korrekt in UTF-8 locale sehen. Und
Default-Kodierung fuer FS im Kernel ist hier latin1. Solange der Kernel
weiss welche Kodierung das Dateisystem nutzt ist das alles kein Problem.
Problematisch wirds bei FAT/NTFS und evtl. SMB/CIFS, aber dort gibts
Optionen um dem Kernel auf die Spruenge zu helfen. 

> Mit convmv kann man die Codierungen aendern.

Wie gesagt hier unnoetig.

> Aber ich hab noch immer Probleme, wenn zB der p2p-Client gegenueber
> anderen Clients Dateien fehlerhaft anzeigt(UTF wird nicht beachtet)
> oder beim runterladen die Datei zwar "f?b?r" heist und korrekt
> angezeigt wird, aber irgendwie trotzdem anders/falsch codiert ist.

Dann ist irgendwas bei dir kaputt, evtl. auch einfach nur der Client.

> Meines Wissens hat man bei Unicode wohl schon darauf geachtet, dass
> viele Zeichen gleich codiert sind wie in anderen Zeichensaetzen,

Da ist schon dein 1. Denkfehler: Unicode != UTF-8. Unicode ist etwas
sehr abstraktes, IIRC einfach nur ein Mapping von sog. Codepoints auf
Glyphen. UTF-8 ist eine Zeichenkodierung fuer Byte-Streams die alle
Unicode-Zeichen darstellen kann. Dadurch das UTF-8 variable Lange
Byte-Folgen fuer 1 Zeichen nutzt kann es den ASCII-Zeichensatz direkt
nutzen. Also alle UTF-8 1-Byte-Zeichenfolgen sind mit demselben
Integerwert im ASCII-Zeichensatz zu finden. Umlaute liegen aber oberhalb
von 127 und werden deswegen mit 2 Bytes kodiert. 

Daneben gibts noch UTF-16 oder UTF-32 die jeweils die entsprechende
Mindestanzahl an Bytes fuer 1 Zeichen nutzen. Dadurch sind damit
kodierte Dateien wirklich nur mit einem Editor/Viewer zu betrachten der
UTF-16/32 auch beherrscht.

> Nerviges Problem ist, dass man fuer unicode modifizierte terminals
> benutzt, die dann auch anders heissen. z.B. rxvt-unicode oder uxterm.

Bloedsinn, deine Howtos sind hoffnungslos veraltet. Solange LANG korrekt
gesetzt ist, funktionieren xterm, gnome-terminal, konsole und
xfce4-terminal wunderbar. Ich vermute aber das bei dir einfach LANG
falsch gesetzt ist.

> Zusammenfassend werd ich wohl wieder iso-8859-15 nehmen, wenn ich mal
> dazu komme, das Gentoo hier durch Debian zu ersetzen. So tolle
> Sonderzeichen eingeben koennen ist nett, aber wenn die dann nicht
> ankommen und man sich diverse andere Probleme einhandelt, ist das dann
> nicht mehr so toll...

Also ich habe 0 Probleme. Hoechstens mal wenn eine Mail anders kodiert
ist, als im Header angegeben, aber das liegt dann meistens am OP und
seinem Mailclient...

Andreas

-- 
You are always busy.



Reply to: