Re: Dateisysteme, Unicode, UTF-8 und Konvertierungsprobleme

["Martin v. Löwis" <martin@v.loewis.de>]

Eduard Bloch wrote:
> Folgendes behaupte ich ohne Anspruch auf Richtigkeit:

Ist ziemlich richtig. Ich versuche mal, die Fehler zu finden:

> Dateisysteme unter Linux und ihre Kodierungen sind eine komplizierte
> Angelegenheit. Allgemein ist Internationalisierung nur mit langfristiger
> und grundlegender Plannung elegant realisierbar. 
                    (Planung)

> Microsoft erkannte dies
> schon vor zehn Jahren und ihre neuere Dateisysteme verwenden allesamt
> Unicode (VFAT, VFAT32, Joliet, NTFS, interne Kodierung ist AFAIK UCS-2
> mit BOM, d.h. immer zwei-bytig mit einer Endianes-Markierung am
> Stringanfang) [1]. 

Ist ohne BOM, und ist zunehmend auch UTF-16.

> Unter Linux dagegen hat man lange Zeit geschlafen:
> grundsätzlich wurde alles auf der Annahme: Zeichen=Byte aufgebaut

Ich bin hier nicht so sicher. Es ist eher die Annahme:
Dateinamen=Bytefolgen; Zeichen sind uninteressant und Aufgabe der Anwendung.

>, kein
> Dateisystem unterstützt Unicode, es gibt nicht mal eine interne
> Zeichensatzdeklaration, die den Zeichensatz angibt. 

Falsch. Man kann gut UTF-8 in Dateinamen verwenden. In NFSv4 ist
sogar festgelegt, dass Dateinamen in UTF-8 kodiert sind.

> Alphabete mit
> nicht-lateinischen Zeichen wurden nach bestimmten Tabellen
> (NLS-Zeichensätzen) in dem erweiterten (8-bit) ASCII verteilt. 

Falsch. Man kann sehr gut Multi-Byte-Zeichensätze in Dateisystemen 
benutzen; davon wird auch intensive gebrauch gemacht.

> Während
> Probleme mit Zeichensätzen den Windows-Usern spaetestens seit Win2k
> fremd sind, müssen sich Linux-Benutzer noch lange Zeit damit plagen. 

Ich bin nicht sicher. Redhat 8 geht in die richtige Richtigung:
Alle locales verwenden UTF-8, und das Problem ist gelöst.

> Man
> ist in der Regel auf ein Zeichensatz beschränkt und muss die gesammte
> Umgebung auf eine andere Locale umstellen (und ausserdem überall
> händisch Fonts ändern, sofern das nicht durch Toolkits wie Gt
> vereinheitlich ist), wenn man mit anderen Welten Kontakt aufnehmen will.

Falsch. Das hängt von der anderen Welt ab: In der Regel ist die Windows,
und man kann für Dateisystemnamen die Mount-Optionen verwenden.

> Es gibt nähmlich keinen Mechanismus für Abwährtskompatiblität (wie in
> Windows-XP), mit dem das System die Soll-Sprache einer Anwendung erkennt
> und aus dem System-Internen Unicode automatisch mit der Soll-Sprache der
> Anwendung kommuniziert.

Falsch. Es gibt verschiedene solcher Mechanismen, etwa das X-Clipboard.

[UTF-8]
>  - Bei nicht-lateinischen Zeichensätzen benötigen die Zeichen mehr
>    Platz, somit schrumpft die maximale Stringlänge beim gleichbleibenden
>    reelen Speicherplatz (z.B. in Dateinamen). Womit wir früher oder
>    später auf ein anderes Problem zusteuern, Beschränkungen, die man
>    z.B. von Joliet kennt (64Zeichen)

Falsch: Das hängt von den nicht-lateinischen Zeichen ab. Kyrillisch,
Armenisch, Hebräisch usw. brauchen in UTF-8 geringfügig weniger Platz 
als UCS-2 (wenn im Text Leerzeichen vorkommen).

>  - Es ist nicht kompatibel zu vorhanden 8bit-Zeichensaetzen; somit sind
>    alle Sprachen wieder "gleichberechtigt" und betroffene Benutzer
>    gleichermassen von Umstellungsproblemen betroffen. Diese sind
>    gewaltig, zu viele Programme sind einfach kurzsichtig entstanden und
>    müssen geändert werden. Siehe Unicode-on-Linux-Howto für Details.

Richtig. Das gilt natürlich auch für UCS-2.

>     - für Korrektur vorher: Perl-Skript, das das Dateisystem durchgeht
>       und die Dateinamen NLS->UTF-8 ändern

Richtig; Python tut's auch.

Ciao,
Martin