#include <hallo.h>
* Stephan Seitz [Thu, Mar 13 2003, 05:55:44PM]:
> > Folgendes: Du bringst 2 Sachen zusammen die nicht zusammen gehören.
> > Einmal gibts da die Kodierung der Dateinamen im Dateisystem - bei Redhat
> > 8 wird offensichtlich die Standard NLS auf UTF-8 gesetzt und damit
> > werden dann alle Dateinamen in UTF-8 kodiert. Das andere ist die Anzeige
> > von UTF-8 kodierten Dingen. Das eine hat mit dem anderen nahezu nichts
IMO ja. Dann werden die Dateinamen direkt in UTF-8 geschrieben.
> Sagt mal, ist es bei Dateisystemen wie ext2/3 oder reiser nicht so,
> daß die Kodierung von der locale abhängig ist? Also ich habe hier ein
> Verzeichnis angelegt unter einer UTF-8-Umgebung (locale: de_DE.UTF-8)
> und die Namen sind falsch in de_DE@euro (also iso-8859-15) und
> natürlich umgekehrt. Ich dachte immer, diese NLS-Module bräuchte man
> nur für Samba, CD-ROM oder FAT, zumindest lädt der Kernel diese Module
> nur in diesem Zusammenhang.
Folgendes behaupte ich ohne Anspruch auf Richtigkeit:
Dateisysteme unter Linux und ihre Kodierungen sind eine komplizierte
Angelegenheit. Allgemein ist Internationalisierung nur mit langfristiger
und grundlegender Plannung elegant realisierbar. 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]. Unter Linux dagegen hat man lange Zeit geschlafen:
grundsätzlich wurde alles auf der Annahme: Zeichen=Byte aufgebaut, kein
Dateisystem unterstützt Unicode, es gibt nicht mal eine interne
Zeichensatzdeklaration, die den Zeichensatz angibt. Alphabete mit
nicht-lateinischen Zeichen wurden nach bestimmten Tabellen
(NLS-Zeichensätzen) in dem erweiterten (8-bit) ASCII verteilt. Während
Probleme mit Zeichensätzen den Windows-Usern spaetestens seit Win2k
fremd sind, müssen sich Linux-Benutzer noch lange Zeit damit plagen. 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 Gtk
vereinheitlich ist), wenn man mit anderen Welten Kontakt aufnehmen will.
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.
Immerhin kann man bei deutschen Texten auch mit 7-bit ASCII auskommen,
das Umschreiben von wenigen Umlauten ist erträglich. Bei anderen, z.B.
kyrillischen Zeichensätzen, sieht es dagegen düster aus.
Als Lösung aus der Misere wurde UTF-8 auserkoren. Dies ist eine echte
Unicode-Variante: Mischung aus dem herkömmlichen ASCII und
Unicode-Zeichen, die in die Byte-Zeichen eingebettet werden. Der Vorteil
von UTF-8 ist die vollständige Kompatibilität zu ASCII (7-bit, keine
Probleme mit englischer Sprache) und somit die platzsparende
Datenlagerung im Vergleich zu UCS-2 oder UCS-4 bei wissenschaftlichen
Daten u.Ae. Aber nichts geht ohne Nachteile:
- 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)
- 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.
- Daraus resultiert auch das nächste Problem: UTF-8 soll die nativen
Zeichensätze irgendwann mal ersetzen. Unter ungünstigen Umständen,
und diese sind immer zu erwarten, wenn man den Übergang nicht
sorgfältig plannt, ensteht ein Gemisch aus UTF-8 und Zeichen in der
alten NLS-Kodierung (z.B. latin1). Mir fällt nur eine vernünftige
Lösung, um mit diesem Schlamassel aufzuräumen:
- für Korrektur vorher: Perl-Skript, das das Dateisystem durchgeht
und die Dateinamen NLS->UTF-8 ändern
- für Korrektur nach der Panne: Perl-Skript, das das Dateisystem
durchgeht und nur typische Spezialzeichen (hier: Umlaute) erkennt
und ins UTF-8 umwandelt.
[1] Es ist also möglich, beliebige Zeichen auf von MS-stammenden
Dateisystemen zu speichern. Mit der Mount-Option
iocharset=8-bit-zeichensatz wandelt der Kernel die Zeichen zwischen
einer best. NLS-Kodierung für die Anwendungen und den gespeicherten
Unicode-Dateinamen im Dateisytem.
Mit der Option utf-8 kodiert der Kernel das Dateisystem-interne
Unicode-Format ins UTF-8-Unicode, das für die Anwendungen sichtbar wird.
Dies erfordet natürlich Programe, die damit auch umgehen können,
siehe oben.
Mir ist leider keine Option bekannt, mit der man eine einseitig
beschränkte Konvertierung Unicode(UTF-8) <-> NLS (hier: latin1)
im Dateisystem durchführen könnte. Viele Benutzer möchten gar nicht den
vollen Unicode-Umfang ausnutzen und können sich bei den Dateinamen
durchaus auf ihren alten Zeichensatz beschränken - dafür aber keine
Probleme mit Namenslängen und ggf. Zeichensatz-Gemisch bekommen.
Gruss/Regards,
Eduard.
--
Windows is great, I used it to download Linux.
-- Seen on Slashdot (14.01.2000)
Attachment:
pgp10EujYLTDP.pgp
Description: PGP signature