Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Umlaute im Dateinamen werden durch Fragezeichen ersetzt
72 views
Skip to first unread message
Christoph Schneegans
May 15, 2014, 7:57:41 PM5/15/14
to
Hallo allerseits!
Mit einem Java-Programm
final java.io.File original = new java.io.File("/tmp/f�o.txt");
final java.io.File canonical = original.getCanonicalFile();
java.lang.System.out.println(original);
java.lang.System.out.println(canonical);
erhalte ich auf einem Linux-System A folgende Ausgabe:
/tmp/f�o.txt
/tmp/f?o.txt
Auf einem anderen Linux-System B und ebenso auf mehreren Windows-
Systemen erhalte ich mit demselben Programm hingegen das erw�nschte
Ergebnis:
/tmp/f�o.txt
/tmp/f�o.txt
/tmp/ ist jeweils f�r den Benutzer schreibbar und enth�lt auch keine
Dateien mit �hnlichen Namen, die ja das Ergebnis von
java.io.File.getCanonicalFile() evtl. beeinflussen k�nnten.
Ich sehe zwischen A und B auch keine offensichtlichen Unterschiede;
Dateisystem ist auf beiden ext3, und env sagt jeweils:
LANG=en_US.UTF-8
Wo k�nnte ich noch schauen?
(Ich habe absichtlich keinen Followup-To-Header gesetzt. Wenn im Laufe der
Diskussion klar wird, wo das Problem liegt, m�ge das nachgeholt werden.)
--
<http://schneegans.de/lv/> � Validator f�r BCP 47
Mit einem Java-Programm
final java.io.File original = new java.io.File("/tmp/f�o.txt");
final java.io.File canonical = original.getCanonicalFile();
java.lang.System.out.println(original);
java.lang.System.out.println(canonical);
erhalte ich auf einem Linux-System A folgende Ausgabe:
/tmp/f�o.txt
/tmp/f?o.txt
Auf einem anderen Linux-System B und ebenso auf mehreren Windows-
Systemen erhalte ich mit demselben Programm hingegen das erw�nschte
Ergebnis:
/tmp/f�o.txt
/tmp/f�o.txt
/tmp/ ist jeweils f�r den Benutzer schreibbar und enth�lt auch keine
Dateien mit �hnlichen Namen, die ja das Ergebnis von
java.io.File.getCanonicalFile() evtl. beeinflussen k�nnten.
Ich sehe zwischen A und B auch keine offensichtlichen Unterschiede;
Dateisystem ist auf beiden ext3, und env sagt jeweils:
LANG=en_US.UTF-8
Wo k�nnte ich noch schauen?
(Ich habe absichtlich keinen Followup-To-Header gesetzt. Wenn im Laufe der
Diskussion klar wird, wo das Problem liegt, m�ge das nachgeholt werden.)
--
<http://schneegans.de/lv/> � Validator f�r BCP 47
Marcel Müller
May 16, 2014, 2:23:12 AM5/16/14
to
Hallo!
[f'up nach d.c.l.java]
On 16.05.14 01.57, Christoph Schneegans wrote:
> Hallo allerseits!
>
> Mit einem Java-Programm
>
> final java.io.File original = new java.io.File("/tmp/f�o.txt");
> final java.io.File canonical = original.getCanonicalFile();
> java.lang.System.out.println(original);
> java.lang.System.out.println(canonical);
>
> erhalte ich auf einem Linux-System A folgende Ausgabe:
>
> /tmp/f�o.txt
> /tmp/f?o.txt
Du hast beim �ffnen der Datei keine Codepage (in Java Charset) angegeben.
Default ist 7 Bit ASCII. Da gibt es kein '�'.
Dar�ber hinaus versucht die JVM aus der Systemkonfiguration das Locale
zu ermitteln, und daraus wiederum, wenn m�glich eine andere
Default-Codepage als ASCII. Unter Unix ist die Codepage i.A.
benutzerspezifisch. Es kann also durchaus am angemeldeten User liegen.
Bei Dateinamen kommt noch hinzu, dass diese unter Unix bin�r sind,
hingegen unter Windows Unicode (UCS2). Hei�t, wenn zwei Programme mit
verschiedenen Codepages im selben Unix-Dateisystem herumfuhrwerken,
k�nnen sie unterschiedliche Dateinamen sehen. Unter Windows hingegen
sehen sie solange dieselben Dateinamen, wie alle verwendeten Zeichen in
beiden Codepages existieren - nicht nur, wenn auch ihre Codierung gleich
ist, wie unter Unix. Das gilt auch bei Benutzung �ber das Netzwerk von
einem anderen Rechner aus!
Zuguterletzt gibt es noch das Normalisierungsproblem bei Unicode. Die
Unicode-Darstellung ist nicht immer eineindeutig. Verschiedene Bin�re
Darstellungen k�nnen semantisch gleich sein. Dann hat man bin�r
unterschiedliche Dateinamen, die eigentlich gleich sein sollten. Hei�t
der Zugriff auf den vermeintlich selben Dateinamen endet mit File not
found, weil im Dateisystem nicht dieselbe Unicode-Darstellung verwendet
wurde.
Aus diesem Grund sind Sonderzeichen in Dateinamen immer ein gewisses Risiko.
Unter Linux hat sich zwar UTF-8 recht weit verbreitet, aber nicht alle
Programme kommen mit Multibyte Zeichens�tzen klar.
> Ich sehe zwischen A und B auch keine offensichtlichen Unterschiede;
> Dateisystem ist auf beiden ext3, und env sagt jeweils:
>
> LANG=en_US.UTF-8
>
> Wo k�nnte ich noch schauen?
Die Java-VM k�nnte schlicht buggy sein.
Marcel
[f'up nach d.c.l.java]
On 16.05.14 01.57, Christoph Schneegans wrote:
> Hallo allerseits!
>
> Mit einem Java-Programm
>
> final java.io.File original = new java.io.File("/tmp/f�o.txt");
> final java.io.File canonical = original.getCanonicalFile();
> java.lang.System.out.println(original);
> java.lang.System.out.println(canonical);
>
> erhalte ich auf einem Linux-System A folgende Ausgabe:
>
> /tmp/f�o.txt
> /tmp/f?o.txt
Default ist 7 Bit ASCII. Da gibt es kein '�'.
Dar�ber hinaus versucht die JVM aus der Systemkonfiguration das Locale
zu ermitteln, und daraus wiederum, wenn m�glich eine andere
Default-Codepage als ASCII. Unter Unix ist die Codepage i.A.
benutzerspezifisch. Es kann also durchaus am angemeldeten User liegen.
Bei Dateinamen kommt noch hinzu, dass diese unter Unix bin�r sind,
hingegen unter Windows Unicode (UCS2). Hei�t, wenn zwei Programme mit
verschiedenen Codepages im selben Unix-Dateisystem herumfuhrwerken,
k�nnen sie unterschiedliche Dateinamen sehen. Unter Windows hingegen
sehen sie solange dieselben Dateinamen, wie alle verwendeten Zeichen in
beiden Codepages existieren - nicht nur, wenn auch ihre Codierung gleich
ist, wie unter Unix. Das gilt auch bei Benutzung �ber das Netzwerk von
einem anderen Rechner aus!
Zuguterletzt gibt es noch das Normalisierungsproblem bei Unicode. Die
Unicode-Darstellung ist nicht immer eineindeutig. Verschiedene Bin�re
Darstellungen k�nnen semantisch gleich sein. Dann hat man bin�r
unterschiedliche Dateinamen, die eigentlich gleich sein sollten. Hei�t
der Zugriff auf den vermeintlich selben Dateinamen endet mit File not
found, weil im Dateisystem nicht dieselbe Unicode-Darstellung verwendet
wurde.
Aus diesem Grund sind Sonderzeichen in Dateinamen immer ein gewisses Risiko.
Unter Linux hat sich zwar UTF-8 recht weit verbreitet, aber nicht alle
Programme kommen mit Multibyte Zeichens�tzen klar.
> Ich sehe zwischen A und B auch keine offensichtlichen Unterschiede;
> Dateisystem ist auf beiden ext3, und env sagt jeweils:
>
> LANG=en_US.UTF-8
>
> Wo k�nnte ich noch schauen?
Marcel
Christoph Schneegans
May 16, 2014, 5:48:52 AM5/16/14
to
Marcel M�ller schrieb:
> [f'up nach d.c.l.java]
Hm, ich sehe keinen Header, aber die Ursache des Fehlers ist IMHO auch
noch eingegrenzt, weshalb ich erneut ein Crossposting schreibe.
> On 16.05.14 01.57, Christoph Schneegans wrote:
>
>> Mit einem Java-Programm
>>
>> final java.io.File original = new java.io.File("/tmp/f�o.txt");
>> final java.io.File canonical = original.getCanonicalFile();
>> java.lang.System.out.println(original);
>> java.lang.System.out.println(canonical);
>>
>> erhalte ich auf einem Linux-System A folgende Ausgabe:
>>
>> /tmp/f�o.txt
>> /tmp/f?o.txt
>
> Du hast beim �ffnen der Datei keine Codepage (in Java Charset) angegeben.
Ich �ffne die Datei ja auch gar nicht. Das Programm hat auch �berhaupt
keine Probleme mit (UTF-8-codierten) Nicht-ASCII-Zeichen im Datei_inhalt_.
Ich achte sehr darauf, da� die JVM mit -Dfile.encoding=utf-8 gestartet
wird, und java.nio.charset.Charset.defaultCharset() liefert hier deshalb
_immer_ UTF-8.
In canonical.toString() steht �brigens wirklich U+003F QUESTION MARK,
�berpr�ft im Eclipse-Debugger, das ist also keine Folge der
Konsolenausgabe oder ein Fehler im Posting.
> Bei Dateinamen kommt noch hinzu, dass diese unter Unix bin�r sind,
> hingegen unter Windows Unicode (UCS2). Hei�t, wenn zwei Programme mit
> verschiedenen Codepages im selben Unix-Dateisystem herumfuhrwerken,
> k�nnen sie unterschiedliche Dateinamen sehen.
Ist bekannt, aber erst einmal k�mpfe ich ja nur mit *einem* Programm.
> Zuguterletzt gibt es noch das Normalisierungsproblem bei Unicode.
Ist auch bekannt, d�rfte hier aber nicht das Problem sein.
--
<http://schneegans.de/usenet/mids/> � Postings verlinken
> [f'up nach d.c.l.java]
Hm, ich sehe keinen Header, aber die Ursache des Fehlers ist IMHO auch
noch eingegrenzt, weshalb ich erneut ein Crossposting schreibe.
> On 16.05.14 01.57, Christoph Schneegans wrote:
>
>> Mit einem Java-Programm
>>
>> final java.io.File original = new java.io.File("/tmp/f�o.txt");
>> final java.io.File canonical = original.getCanonicalFile();
>> java.lang.System.out.println(original);
>> java.lang.System.out.println(canonical);
>>
>> erhalte ich auf einem Linux-System A folgende Ausgabe:
>>
>> /tmp/f�o.txt
>> /tmp/f?o.txt
>
> Du hast beim �ffnen der Datei keine Codepage (in Java Charset) angegeben.
keine Probleme mit (UTF-8-codierten) Nicht-ASCII-Zeichen im Datei_inhalt_.
Ich achte sehr darauf, da� die JVM mit -Dfile.encoding=utf-8 gestartet
wird, und java.nio.charset.Charset.defaultCharset() liefert hier deshalb
_immer_ UTF-8.
In canonical.toString() steht �brigens wirklich U+003F QUESTION MARK,
�berpr�ft im Eclipse-Debugger, das ist also keine Folge der
Konsolenausgabe oder ein Fehler im Posting.
> Bei Dateinamen kommt noch hinzu, dass diese unter Unix bin�r sind,
> hingegen unter Windows Unicode (UCS2). Hei�t, wenn zwei Programme mit
> verschiedenen Codepages im selben Unix-Dateisystem herumfuhrwerken,
> k�nnen sie unterschiedliche Dateinamen sehen.
> Zuguterletzt gibt es noch das Normalisierungsproblem bei Unicode.
--
<http://schneegans.de/usenet/mids/> � Postings verlinken
Michael Baeuerle
May 16, 2014, 5:12:26 AM5/16/14
to
Marcel M�ller wrote:
>
> Zuguterletzt gibt es noch das Normalisierungsproblem bei Unicode. Die
> Unicode-Darstellung ist nicht immer eineindeutig. Verschiedene Bin�re
>
> Zuguterletzt gibt es noch das Normalisierungsproblem bei Unicode. Die
> Darstellungen k�nnen semantisch gleich sein. Dann hat man bin�r
> unterschiedliche Dateinamen, die eigentlich gleich sein sollten. Hei�t
> der Zugriff auf den vermeintlich selben Dateinamen endet mit File not
> found, weil im Dateisystem nicht dieselbe Unicode-Darstellung verwendet
> wurde.
Oder es wird eine andere Datei verwendet deren Name semantisch identisch
> found, weil im Dateisystem nicht dieselbe Unicode-Darstellung verwendet
> wurde.
ist. Und mehrere Dateien gleichen Namens in einem Verzeichnis sind immer
Kandidaten f�r den ber�hmten Schuss in den Fu�.
> Aus diesem Grund sind Sonderzeichen in Dateinamen immer ein gewisses Risiko.
> Unter Linux hat sich zwar UTF-8 recht weit verbreitet, aber nicht alle
Das Problem existiert mit Unicode leider immer, auch wenn man statt
einer Multibyte bzw. Multiword Darstellung (UTF-8 oder UTF-16) eine
Singleword Darstellung (UTF-32 oder UCS-2) verwendet. Deswegen kann
es in der Microsoft Welt genauso auftreten.
[Fup2 dcoulm gesetzt]
Micha
Christoph Schneegans
May 16, 2014, 9:54:48 AM5/16/14
to
Christoph "Ingrid" Schneegans schrieb:
> Ich sehe zwischen A und B auch keine offensichtlichen Unterschiede;
> Dateisystem ist auf beiden ext3, und env sagt jeweils:
>
> LANG=en_US.UTF-8
Argh. Ich hatte "env" mit dem falschen Benutzer aufgerufen. F�r den
Benutzer, der das Programm effektiv ausf�hrte, war die Umgebungsvariable
LANG nicht gesetzt. Jetzt tut alles so, wie es soll. Sorry f�r die
Aufregung.
--
<http://schneegans.de/sv/> � Schema-Validator f�r XML
> Ich sehe zwischen A und B auch keine offensichtlichen Unterschiede;
> Dateisystem ist auf beiden ext3, und env sagt jeweils:
>
> LANG=en_US.UTF-8
Benutzer, der das Programm effektiv ausf�hrte, war die Umgebungsvariable
LANG nicht gesetzt. Jetzt tut alles so, wie es soll. Sorry f�r die
Aufregung.
--
<http://schneegans.de/sv/> � Schema-Validator f�r XML
0 new messages