Re: Kodierung von Datei- und Verzeichnisnamen

From: Marc Santhoff <M.Santhoff(at)web.de>
Date: Sun, 26 May 2013 18:40:55 +0200

Am Sonntag, den 26.05.2013, 12:52 +0200 schrieb Polytropon:
> On Sun, 26 May 2013 12:13:21 +0200, Marc Santhoff wrote:
> > Jetzt fragt sich nur noch, warum ein Tcl/Tk-Programm einfach so "exotisch
> > kodiert"[tm] daherkommt, entweder der Interpreter ist modernisiert und mag
> > $LANG nicht oder das Programm macht Murks oder nichts.
>
> Das Dateisystem selbst interessiert es herzlich wenig, was
> da als Dateiname daherkommt. Wenn also ein Programm 2-Byte-
> Zeichen anfordert oder "nicht-normale" 1-Byte-Zeichen (also
> etwa unsere normalen Umlaute oder Eszett), dann bekommt es
> das auch. Wird der Dateiname dann "unter einer anderen Kon-
> vention angezeigt", sieht er "falsch" aus. Es muß also quasi
> immer "Eingabezeichensatz" und "Ausgabezeichensatz" überein-
> stimmen, damit die Anzeige konsistent ist. Das Programm, das
> die Anzeige vollführt, muß die Zeichen natürlich auch an-
> zeigen können (z. B. chineische Zeichen im Terminalfenster,
> da müssen auch die entsprechenden Schriftarten installiert
> sein - aber bei unsere paar olle Umlaute ist das nicht das
> Problem, da wir die auch mit ISO-8859-1 und -15 kriegen).

Soweit verständlich, im Dateisystem landet als Name die zeuichenkette,
die man als Name übergibt. Das oder die Programme daziwschen, die die
Zeichenkette "herstellen" oder umwandlen, machen die Kodierung.

> > Es ist übrigens das von mir schon ewig benutzte TkDesk (x11-fm/tkdesk),
> > das mittlerweile sogar ganz aus den Ports rausgeflogen ist, weil es
> > nicht nur keinen Maintainer sondern noch nicht mal mehr einen
> > Programmierer gibt, der es noch pflegt. :P
>
> Das könnte durchaus der Grund sein. Viele ältere Programme
> gelten als "nicht UTF-8-fest", so z. B. die Datei-Dialoge
> in Gtk-1-Programmen.

Dümmmer, aber deutlich. Wie ich vermutet habe, ist das Programm oder der
Tcl-Interpreter auf UTF-8 eingestellt. Ich habe mal ein Verzeichnis mit
diesem Programm erstellt und dann eines im xterm mit garantierter
ISO8559-Kodierung:

$ mkdir Honigbär
$ hd .
00000000 2a 8c 20 00 0c 00 04 01 2e 00 00 00 b9 3c 07 00 |*. .........¹<..|
00000010 0c 00 04 02 2e 2e 00 00 a0 8a 3d 00 18 00 04 0c |........ .=.....|
00000020 47 6f 6c 64 6c f6 63 6b 63 68 65 6e 00 00 00 00 |Goldlöckchen....|
00000030 a1 8a 3d 00 d0 01 04 08 48 6f 6e 69 67 62 e4 72 |¡.=.Ð...Honigbär|
00000040 00 00 c3 0f 00 00 00 00 00 00 00 00 00 00 00 00 |..Ã.............|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
$ echo $LANG
de_DE.ISO8859-1

Da sieht man, wer der Schuldige ist.

> > Lange Suche brachte ein 'ü' als $c3 $bc hervor. Alle ISO8859-Kodierungen
> > werden falsch dargestellt. Die benutze ich aber eigentlich.
>
> Das ü mit der Darstellung "A-Tilde ein Viertel", wie im Hexdump
> zu sehen, deutet auf ein 2-Byte-Zeichen hin (UTF-8), Wenn es
> ein 1-Byte-Zeichen wäre, würde das ü mit hex fc angezeigt werden.
>
>
>
> > $ hd . | grep -C2 System_
> > 000001e0 65 69 74 65 72 2e 68 74 6d 6c 00 ff 00 00 00 00 |eiter.html.ÿ....|
>
> Also wenn da mal nicht eine Entzündung vorliegt, ich meine,
> wegen "eiter.html"... hoffentlich ist es "der gute, lobens-
> werte" Eiter... ;-)

Zu Deiner Ergötzung und Beruhigung: es war der Halbl-Eiter. ;)

000001d0 74 72 6f 6e 69 6b 6e 65 74 5f 5f 48 61 6c 62 6c |troniknet__Halbl|
000001e0 65 69 74 65 72 2e 68 74 6d 6c 00 ff 00 00 00 00 |eiter.html.ÿ....|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000200 12 19 1f 00 30 00 04 27 53 79 73 74 65 6d 5f 76 |....0..'System_v|
00000210 65 72 73 63 68 6c c3 bc 73 73 65 6c 6e 5f 6d 69 |erschlüsseln_mi|

> > 00000210 65 72 73 63 68 6c c3 bc 73 73 65 6c 6e 5f 6d 69 |erschlüsseln_mi|
>
> Genau da ist das UTF-8-Zeichen (also _die_ Bytes).
>
>
>
>
>

-- 
Marc Santhoff <M.Santhoff(at)web.de>
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sun 26 May 2013 - 18:42:18 CEST

search this site