asiatische Zeichen als Ordnername bei NTFS

lockdoc

Well-Known Member
Hallo,

ich habe ein NTFS Laufwerk unter FreeBSD gemounted. In diesem Laufwerk haben die meisten Ordner chinesische Schriftzeichen als Name. Leider stellt mein FreeBSD diese nicht da. Jedes einzelne Zeichen wird durch ein _ ersetzt dargestellt. Besteht also ein Ordnername aus 2 Zeichen, sieht BSD das (sowohl auf der shell mit /usr/local/bin/terminal als auch im /usr/local/bin/nautilus Browser) als __.

Ich dachte mir erst, dass ich damit leben kann, allerdings sind jetzt mehrere Ordner in einem Verzeichnis die 2 Character haben, dann werden die alle mit __ dargestellt und ich komme nur immer in ein und den selben Ordner rein, auch wenn ich mit Nautilus auf einen anderen __ klicke lande ich immer in ein und dem selben.

Auf der BSD Partition selber (UFS) ist das kein Problem, da wird alles korrekt dargestellt, auch im Terminal.

Wie kriege ich denn jetzt die korrekte Darstellung fuer die NTFS Platte hin oder wenigstens wie kann ich in verschiedene Ordner navigieren, die alle den selben Namen haben?
 
Also ich mounte das jetzt wie folgt:

Code:
mount_ntfs -C <charset> /dev/ad0s1 /mnt/win/

Die Charsets hab ich von der Seite hier: http://a4esl.org/c/charset.htm und habe mal 6 verschiedene ausprobiert. Das Ergebnis ist ernuechternd.

Hier werden die Ordner gar nicht angezeigt
hz-gb-2312
utf-8

Hier sehen die Ordner so aus: �ҵ���Ƶ (invalid encoding)
EUC-CN
gb2312

Laesst sich gar nicht mounten mit
x-mac-chinesesimp
unicode

Es geht um "chinese simplified". Gibt es da noch andere Charsets
 
ja, weißt du denn nicht, wie die Dateinamen geschrieben sind?

ich habe letztlich versucht, meinen ee mit UTF-8 zu verheiraten und dabei etwas gelesen, dass Mac und Microsoft UTF-16 benutzen würden. FreeBSD kann wohl kein UTF-16.

Das ganze Thema ist mir noch immer suspekt und ich verstehe das nicht ganz. UTF-8 sollte eine Untermenge von UTF-16 sein und da würde ich mir denken, dass wenigstens die gemeinsamen Zeichen korrekt darstellbar sein sollten, aber scheinbar ist das nicht so, weil nicht auf Zeichensätze an irgendeiner Stelle einfach zugegriffen wird, sondern die Programme den passenden Code noch verstehen lernen müssen.
Da hat jemand sich wohl was ausgedacht, was in der Praxis echt schlecht ist.

Vielleicht kannst du was mit convmv (converters/convmv) etwas anfangen, jedenfalls listet das auch UTF-16 als Möglichkeit und vielleicht ist es möglich, die Namen einfach zu konvertieren?
Ich meine, wenn sonst nichts hilft...
 
Konzeptionell ist UTF-8, oder UTF-16 ziemlich genial, leider scheitern meistens da einige Programme. Eigentlich ist aber UTF-8 das Mittel der Wahl im europaeischen Raum. Die Texte bleiben bei typischen mitteleuropaeischen Sprachen immernoch klein, da sie ueberwiegen ASCII Code enthalten und wenn dann mal, wie im deutschen ein Umlaut auftaucht, belgen sie halt 2 Byte. *shrug*

Das Konzept ist wie gesagt eigentlich recht simpel, aber irgendwie wird das oft durcheinander geworfen: Jedes Unicode Zeichen ist immer 21 Bit breit, in der Codierung wird es dann aufgeblasen zu 32 Bit. Warum sieht man spaeter.
Dann haetten wir UTF-32, da belegt also jedes Zeichen exakt 4 Byte. Das waere fuer die Englaender natuerlich sehr schlecht, also hat man sich ueberlegt wie man das ganze geschickter verpacken kann, um zumindest die Zeichen aus der BMP klein zu halten. Rausgekommen ist dann erstmal UTF-16, das fuer Zeichen aus der BMP nur 2 Byte belegt. Ist natuerlich immernoch nicht toll, und deshalb hat man dann UTF-8 entworfen, was in 7 Bit identisch mit den ASCII Zeichen ist. Also ein ASCII Zeichen belegt auch nur 1 Byte in utf-8. Der Nachteil ist, und das sieht man recht gut, wenn man sich die codierung genau ansieht, das um die vollstaendige BMP abzubilden anstatt 2 Byte, 3 Byte benoetigt. Das ist meistens Pech fuer asiatische Sprachen, deshalb nehmen die lieber UTF-16.
Was das ganze eklig macht ist die Codierung. In der Codierung muss enthalten sein, ob das naechste Byte immernoch zum ein und dem selben Zeichen gehoert, oder nicht. Deshalb musste man die 21Bit aufblasen. Die Anzahl der einsen am Anfang jedes Byte gibt an wieviele Bytes noch fuer dieses Zeichen folgen. Wenn Programme das nicht verstehen, geben sie Kauderwelsch aus. Dann muss man noch gucken, ob das ganze little, oder big endian ist. Deshalb fuegen gute Editoren am Anfang eines Mehrbytezeichentextes ein s.g. "BOM" ein. Wenn man kein UTF-8 benutzt sieht man in ISO-8859-1 immer dieses "". Mit solchen Sachen gibt es Bibliotheken, die versuchen den Zeichensatz zu erraten.

FreeBSD kann sehr wohl mit UTF-8 umgehen, nur der terminal emulator kann es noch nicht, obwohl es dafuer ja einen rewrite gibt, der aber soweit ich weiss noch nicht drin ist. Mit anderen Worte du kannst halt keine Mehrbytezeichensaetze auf der Konsole lesen. In einer Konsole in xorg aber sehr wohl. Da muss man halt nur seine locale richtig anpassen. Vllt ist das schon das Problen des Threaderstellers? ;)

Jetzt duerfen mich hier diese ISO-8859 Liebhaber zusammenfauchen. Trotzdem finde ich Unicode eigentlich eine gute Sache. :)
 
@ s-tlk
also, ich falte mal nicht, sondern bedanke mich für diese Darstellung, die mal wieder erhellend für mich ist.

Heute abend will ich nicht darauf eingehen, dass ich mal die ASCI-Codes in E-PROMS gebrannt habe und daraus dann einen Zeichen-Generator betrieb, der kleine grüne Leuchtpunkte auf einen Bildschirm zauberte, in denen ich dann Buchstaben oder andere Zeichen erkennen konnte. Aber ohne Zweifel bin ich von dieser zeit durchaus beeinflusst und hatte es mir auch so mit den Zeichensätzen vorgestellt.
Nunja, so ähnlich halt.
Für mich war klar, dass es irgendwo einen Klick auf meiner Tastatur gibt, der einem bestimmten Wert entspricht und dass eine SW diesem Wert dann ein Zeichen gemäß einer bestimmten Tabelle zuordnet. Wie dieses Zeichen auf meinem Bildschirm dargestellt wird, entscheidet dann eine andere SW, die Zugriff auf die verschiedenen Zeichensätze hat.
Kommt der Wert nicht von meiner Tastatur, sondern aus einem Text, sollte trotzdem die Zuordnung zu den Zeichensätzen über einen SW-Zeichengenerator passieren.
Diesen "Zeichengenerator" stellte ich mir einheitlich vor und deshalb zwischen den Betriebssystemen grundsätzlich austauschbar.
Jedes Programm würde alle Zeichen(Werte, Bytes, Codes) einfach dem Generator übergeben und dieser wiederum würde sein Ergebnis an die Darstellungsprogramme abliefern.
So einfach hatte ich mir das vorgestellt.
So einfach geht es aber nicht und du erklärst das auch, warum es doch ein wenig komplizierter ist.

Trotzdem weiß ich nicht, ob da ausreichend Hirnschmalz in dieses Problem geflossen ist und es nicht grundsätzlich mit externen (also nicht in jedem Programm eigens eingebauten) Mechanismen zu lösen wäre. Das könnte ich mir jedenfalls vorteilhaft vorstellen.

Nebenbei: ISO-Anhänger war ich nur aus alter Gewohnheit, habe auch inzwischen (jedenfalls auf diesem Rechner) nach UTF-8 umgestellt und bin davon dem Grundsatz nach genau wie du überzeugt. Ich möchte nicht an ISO festhalten, aber ich sehe, dass unerwarteter Weise nicht alles mit UTF-8 funktioniert. Wenn das auch Kleinigkeiten sind, ich konnte sie halt nicht verstehen.

Noch nebenbeier: ja klar, wenn der Thread-Starter selbst nicht UTF-8 nutzt, kann meine Erwartung dahingehend auch nicht erfüllt werden, dass diese Zeichen korrekt dargestellt werden können.
 
.... Dann muss man noch gucken, ob das ganze little, oder big endian ist. Deshalb fuegen gute Editoren am Anfang eines Mehrbytezeichentextes ein s.g. "BOM" ein. Wenn man kein UTF-8 benutzt sieht man in ISO-8859-1 immer dieses "". Mit solchen Sachen gibt es Bibliotheken, die versuchen den Zeichensatz zu erraten.
Little- oder Big-Endian ist bei UTF-8 vollkommen egal, da kommt ein Byte nach dem Anderen. Das BOM ist in dem Fall einfach nur Blödsinn und eine schlechte Angewohnheit der Editoren.

FreeBSD kann sehr wohl mit UTF-8 umgehen, nur der terminal emulator kann es noch nicht, obwohl es dafuer ja einen rewrite gibt, der aber soweit ich weiss noch nicht drin ist. ...
Es gibt schon ein paar ganz gut funktionierende Terminals. Rxvt-unicode zum Beispiel. Selbst uxterm funktioniert ganz gut.
 
Das BOM ist schon sinnvoll, um zumindest heuristisch zu erahnen das es UTF-8 ist. Aber es stimmt schon, wenn ich es mir genau ueberlegen braucht UTF-8 selbst das BOM nicht zwingend.

Ich hab ehrlich gesagt keine Probleme mit UTF-8, mit keiner der Software, die ich benutze und ich habe leider auch oefters einige exotische Dateinamen.
 
Diese Little-/Big-Endian Geschichte ist übrigens ein guter Grund auf UTF-8 zu setzen. Ich habe schon mit UTF-16 gearbeitet und musste da die ganze Zeit die Endianness (ist das ein Wort) zwischen den Komponenten herum konvertieren.
 
...
Noch nebenbeier: ja klar, wenn der Thread-Starter selbst nicht UTF-8 nutzt, kann meine Erwartung dahingehend auch nicht erfüllt werden, dass diese Zeichen korrekt dargestellt werden können.

/etc/login.conf behinhaltet schon folgendes:
Code:
...
default:\
...
     :charset=UTF-8:
...

Brauche ich denn zusaetzlich das hier noch?
Code:
:lang=en_US.UTF-8:
 
locale sagt:
Code:
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=

Also schon auf UTF-8 umgestellt.
Gibt es jetzt keine Moeglichkeit mir die Ordnernamen von der Windows NTFS Platter korrekt in FreeBSD unter Gnome/Nautilus anzuzeigen?
 
also, bei mir funktioniert ja kde3 und deshalb weiß ich nicht recht, wie das unter GNOME ist.
In kde3 macht ein Browser-ähnliches Programm diese Darstellung und wie bei Browsern üblich hat es eine Einstellmöglichkeit dafür, eine Kodierung darzustellen.
Da kann gewählt werden, ob Automatisch, ISO oder UTF und zwar zwischen einer ganzen Reihe von Möglichkeiten.
Vielleicht wird diese Einstellung nicht auf deine default-Wünsche übernommen oder steht automatisch falsch?
 
ich muss das wohl korrigieren, was ich eben sagte, denn, als ich nun selbst versuchte, die beschriebene Funktion zu finden, gelang mir das nicht. Vielleicht verwechsele ich da was.

Aber: ich muss für die korrekte Darstellung eine Schrift auswählen, die auch alle Zeichen darstellen kann. Darin könnte natürlich auch ein Problem liegen.
 
@pit234a:
Die Schrift kann das ja. Ich kann ja problemlos beispielsweise in meinem home Verzeichnis Order bzw. Dateien mit chinesischen Characters im Namen anlegen. Das wird auch im gnome-terminal korrekt dargestellt. Nur halt der ntfs mount von Windows weigert sich,
 
was mich und mein wirklich nur bescheidenes Wissen in diesen Dingen anbelangt, bleibt da nur meine Empfehlung von weiter oben übrig: convmv (converters/convmv).

Du weißt ja vermutlich nicht, mit welchem Zeichensatz tatsächlich die Namen der Windows Dateien erstellt worden sind. Bei mir im Netz werden Dateien von Mac und GNU/Linux-Rechnern erstellt und die kann ich mit FreeBSD und UTF-8 (de bei mir) problemlos darstellen. Weil die beiden anderen Systeme offenbar keinen ISO nutzten, stellte ich auf UTF-8 um. (Inzwischen habe ich ein GNU/Linux, das offenbar doch ISO benutzt! Es ist da auf nichts Verlass!)
Nachdem ich auf UTF-8 umgestellt hatte, blieben ja die meisten der gespeicherten Namen noch mit ISO-Code stehen. Nach einer Empfehlung hier, testete ich convmv und damit gelingt das Umbenennen flott und sicher. Es wandelt Dateinamen von - nach und du kannst es ja mal an einigen Beispielen testen und sehen, was dabei herauskommt und welches Format denn deine Namen tatsächlich nun haben. Und natürlich, ob denn Windows schließlich auch mit den gewandelten Namen umgehen kann.
In meinem Fall hat das geholfen, wobei es da ja nur um Umlaute ging und keine Asiatischen Zeichen.
 
Also, ich habe die NTFS Platten jetzt alle mit fuse (ntfs-3g) gemounted und dort werden die ganzen chinesischen Characters korrekt angezeigt (Y) xD
 
Zurück
Oben