#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 [EMAIL PROTECTED] (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)
pgp00000.pgp
Description: PGP signature
