[Bleistift]

Ich lese ein Verzeichnis mit readdir aus. Dort drin hat es einige Dateien mit Umlauten (Hä.txt, Hü.txt ) Ich arbeite grunsätzlich mit UTF-8 und das funktionierte bisher (fast) überall. Hier geht aber irgendwas schief. An den Browser wird

Ha\u0308.txt

und

Hu\u0308.txt

gesendet. Angezeigt wird:

Hä

bzw.

Hü

An was könnte das liegen?

[Bleistift]

Ich kriege es nicht hin... Hat keiner eine Idee, wieso PHP aus "ü" ein u\u0308 macht? Ich hab mal noch folgendes versucht:

PHP-Code:

$x = 'ä' . $filename;
echo $filename 


Herausgekommen ist:

\u00fcHu\u0308.txt

Und angezeigt als:

äHü.txt

Sehr seltsam... Muss also an readdir liegen

[Ben]

http://python.net/pipermail/python-d...q1/004534.html

BTW, zum Zerlegen und Zusammensetzen von zusammengesetzten Zeichen
gibts in Python 2.3 unicodedata.normalize:

 >>> import unicodedata
 >>> unicodedata.normalize("NFD", u"ü")
u'u\u0308'
 >>> unicodedata.normalize("NFC", u"u\u0308")
u'\xfc'

Mit Encoding hat das ganze *überhaupt nix* zu tun.

Aufgrund von "unicodedata" kann man eventuell mal in diese Richtung weitersuchen? *schulterzuck*

[Bleistift]

Ich habe gerade gemerkt, dass das Problem nur auf Windows- und Mac-Systemen besteht. Auf meinem Debian-Server geht alles ohne Probleme. Es bleibt mysteriös...

[Waq]

readdir() übernimmt wohl die Kodierung der Pfade wie sie vom Betriebssystem geliefert wird.
Und nur das Debian-System scheint utf-8 zu liefern. Bei den anderen Systemen könnte man die \u-Kodierungen aber auch nach utf-8 umwandeln...

[Bleistift]

Zitat von Waq

Bei den anderen Systemen könnte man die \u-Kodierungen aber auch nach utf-8 umwandeln...

Aber wie? Mit utf8_encode funktioniert es nicht.

[mepeisen]

Das PHP macht das nicht von sich aus. Das PHP befindet das Zeichen für "sinnvoll".

PHP-Code:

<?php
$dh = opendir('.');
while (($filename=readdir($dh))!==false)
{
if (strlen($filename) != 6) continue;
echo substr($filename, 1, 1);
echo " ";
echo ord(substr($filename, 1, 1));
echo " ";
echo $filename;
echo "\n";
}
?>

Und im Rahmen der Zeichensatz-Genauigkeit ist das ein völlig normales Zeichen. Nicht ganz das, was man laut Konsole erwartet (Da wirds zu ³), aber dennoch völlig akzeptabel. Da ist irgednwas anderes, was da rum pfuscht, vielleicht der Apache oder gar der Internet-Explorer. Der verfälscht sowas zum Beispiel sehr gerne, wenn man laut HTTP-Header Zeichensätze anliefert, die dann nicht eingehalten werden.

[Waq]

Zitat von Bleistift

Aber wie? Mit utf8_encode funktioniert es nicht.

Warum sollte es auch? Die Quelle ist schliesslich nicht iso-8859-1 in dem Sinne.

Hab ma grad gesucht und im manual keine passende Funktion gefunden. In PEAR/PECL könnte man noch gucken.
Oder per Regex die \uabcd in &#abcd; umwandeln und mit http://de2.php.net/manual/en/functio...ericentity.php dekodieren.

[mepeisen]

Zitat von mepeisen

wenn man laut HTTP-Header Zeichensätze anliefert, die dann nicht eingehalten werden.

Ich beharre mal drauf.
UTF-8 ist böse bzgl. Umlauten, da ich kaum glaube, dass deine QQuellcodes in UTF-8 sind.
Internet Explorer ist böse.

Gibst du irgendwo einen Zeichensatz an? via header() oder Meta-Tag? Zum Beispiel.
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
wenn Ja: Ändere das mal spasseshalber.

Deine PHP-Quellen werden wohl zu 100% nicht als UTF-8 gespeichert. Damit ist es völliger Humbug, das 'ü' aus der readdir-Funktion mit einem 'ü' aus dem PHP-Code vergleichen zu wollen. Das lernt man schon in C-Zeiten, dass Windows böse ist *g*
Mein Beispiel von oben sollte einen Hinweis darauf geben, denn 'ü' wird aus Ascii-Sicht als #252 ausgegeben, also als was völlig anderes. In UTF-8 würde soweit ich das auswendig noch weis 195 oder sowas rauskommen, denn ord berücksichtigt nur das erste Zeichen und die Umlaute sind bei utf-8 in zwei Zeichen kodiert. Bei ord() kommt dann bei allen per utf-8 kodierten Umlauten 195 raus.

Lange Rede, kurzer Sinn. Das, was readdir ausgibt, ist !nicht! UTF-8. Das was readdir ausgibt ist !nicht! "normales" Ascii. Dein Zielzeichensatz ist jedoch utf8 (irgendwo per Header oder sonstwo festgelegt), so dass wahlweise PHP, Apache oder der Internet Explorer das Zeichen "kaputt" machen.

Die Funktionen, die ihr sucht, fangen alle mit mb_ an...

P.S.: Das was bei readdir rauskommt, sollte zweifelsfrei ISO-8859-1 sein.

[Waq]

Zitat von mepeisen

UTF-8 ist böse bzgl. Umlauten,

Nein, utf-8 ist da ganz toll

da ich kaum glaube, dass deine QQuellcodes in UTF-8 sind.

Meine PHP-Quellcodes sind in utf-8. Wenn er sagt, dass er utf-8 benutzt sind es seine hoffentlich auch, was im Zweifelsfall er nachprüfen sollte.
Für Gewissheit bräuchten wir natürlich ne URL zum selberangucken.

Mein Beispiel von oben sollte einen Hinweis darauf geben, denn 'ü' wird aus Ascii-Sicht als #252

ASCII geht nur bis #127

Lange Rede, kurzer Sinn. Das, was readdir ausgibt, ist !nicht! UTF-8.

Bei mir schon. Gentoo, locales auf utf-8, Dateisystem auf utf-8 eingestellt. Und ich habs grade getestet. Und ich verwechsle da nix.
Von daher glaube ich ihm, dass das Debian ihm utf-8 liefert. Windows und OSX scheinen sich aber verpflichtet zu fühlen, die hohen utf-Zeichen zu maskieren.

[mepeisen]

Zitat von Waq

Meine PHP-Quellcodes sind in utf-8. Wenn er sagt, dass er utf-8 benutzt sind es seine hoffentlich auch, was im Zweifelsfall er nachprüfen sollte.
Für Gewissheit bräuchten wir natürlich ne URL zum selberangucken.

Jo, ich kenne halt keine gängigen Editoren, die sowas tun. Also in UTF-8 abspeichern. Ich verbessere mich auf 99%
[/quote]

Zitat von Waq

ASCII geht nur bis #127

Dipfelschisser :-P
Ich hab in meiner Jugend zu lange DOS gemacht seufz. OK. Ich verbessere mich: 'ü', das von readdir geliefert wird, ist ein Byte mit der Dezimal-Repräsentation #252. Das deutet auf den von mit im PS angedeuteten Zeichensatz hin... Und nicht auf UTF-8.

Zitat von Waq

Bei mir schon. Gentoo, locales auf utf-8, Dateisystem auf utf-8 eingestellt. Und ich habs grade getestet. Und ich verwechsle da nix.

Dass es bei Linux geht, steht doch nicht zur Debatte, das steht doch oben schon oder verwechsele ich das nun? Und Windows macht das nunmal nicht gleich. Wie ich schrieb... Dass die Zend-Leutchens sowas nicht "korrigieren" ist halt Schicksal.

Zitat von Waq

Von daher glaube ich ihm, dass das Debian ihm utf-8 liefert. Windows und OSX scheinen sich aber verpflichtet zu fühlen, die hohen utf-Zeichen zu maskieren.

Gebe das ganze mal byteweise in eine Datei aus. Da ist es dann nicht als \u irgendwas maskiert. Das ist nicht PHP selbst zumindest nicht während das da in der Variable steht. Entweder echo versucht da (aufgrund einer Zeichensatz-Definition) zu maskieren oder der Apache oder der Internet Explorer. Dass es so ist, kann ich nachvollziehen.
Wenn ich ihm aber per HTTP-Header den korrekten ISO-Zeichensatz vorgebe, wird auch nix maskiert. Erst wenn ich ihm sage, dass das HTML-Dokument ein UTF-8 sei, macht irgendwer was merkwürdiges. Das deutet darauf hin, dass der Rückgabewert von readdir völlig in Ordnung ist.

Alle Versuche, da was zu konvertieren, müssen eigentlich scheitern, weils da imho nichts zu konverteiren gibt.

[Bleistift]

Die Dateien werden alle in UTF-8 abgespeichert (ich arbeite mit Eclipse und Zend Studio und habe es in beiden Editoren so eingestellt)
Ich hab jetzt mal eine Datei namens "ä.txt" angelegt und folgenden Coder verwendet:

PHP-Code:

$filename = explode('.', $filename);
echo strlen($filename[0]) . '   ';
echo strlen('ä') . '   ';
echo ord($filename[0]) . '   ';
echo $filename[0]; 


Die Ausgabe war:

3   2   97   a¨

Das Zeichen ist also länger als ein "normales" ä. ASCII-Code 97 ist ein normales kleines a...
Weil das ä ja 3 Zeichen lang ist, hab ich meinen Code mal ergänzt:

PHP-Code:

echo strlen($filename[0]) . '   ';
echo strlen('ä') . '   ';
echo ord($filename[0][0]) . '   ';
echo ord($filename[0][1]) . '   ';
echo ord($filename[0][2]) . '   ';
echo $filename[0]; 


Ergebnis:

3   2   97   204   136   a¨

Wird jemand schlau daraus?

[Waq]

Argl, ich hab jetz raus was das is. Das ist Unicode, aber recht bescheuertes. Anstatt ä und ü direkt zu schreiben bekommst Du erst das a bzw. u und dann Postfix als eigenes (diakritisches) Zeichen die Punkte.
Schau mal was Unicode 0308 is:
http://de.wikipedia.org/wiki/Interna...sches_Alphabet

Vielleicht machts ja der Ersteller der Datei kaputt? Erstell die mal mit PHP, und gib dabei den Dateinamen in utf-8 mit normalem ä an.

[Bleistift]

Zitat von Waq

Vielleicht machts ja der Ersteller der Datei kaputt? Erstell die mal mit PHP, und gib dabei den Dateinamen in utf-8 mit normalem ä an.

Glaube ich nicht Ich hab die Datei ganz normal im Finder erstellt. Dennoch habe ich jetzt mal eine mit PHP erstellt.

PHP-Code:

$handle = fopen('äöü.txt','w');
fwrite($handle, 'äöü'); 


Ergebnis ist wieder das selbe.
Liegt wohl am Filesystem (Mac OS Extended (Journaled))

//EDIT: Doch nicht... Die Datei wird noch krasser... (a\u0308ou\u0308\u0308.txt) Siehe Anhang.

[dsxs]

*rofl*

Sorry, btt

[Basti]

Die hier gehen in die Richtung:

http://bugs.php.net/bug.php?id=14100
http://bugs.php.net/bug.php?id=39660

Basti

PS:
Ich speichere auch jede PHP-Datei in UTF-8 (auch, wenn in "normalen" Quellcode-Dateien kein Nicht-ASCII-Zeichen zu finden sein wird) und gebe immer UTF-8 aus (META-Tag reicht natürlich nicht. Content-Type-Header muss auch explizit (oder implizit durch den Server) gesetzt werden - zusätzlich noch die Angabe in der XML-Deklaration).

[Bleistift]

Suuuper Lösungsvorschlag:

Yes, you have to wait for PHP6 to get decent Unicode support.

*grrr*
Wenigstens kann es mein Server. Das ist eigentlich das wichtigste

[Bleistift]

Auch noch lustig:

PHP-Code:

$handle = fopen('ääöüéàèéäöüäé.txt.txt','w');
fwrite($handle, 'äöü'); 


Gibt eine ganz coole Datei.

[mepeisen]

Ich dachte du legst die Datei im Explorer oder so an. Dann bauts Windows auch kein Multibyte aus dem ä. So wie du es jetzt hast, ist das sogar logisch, dass das nicht zusammenpasst. Du erwartest, dass ein Unicde-Zeichen (also dein Original als UTF-8 generiertes ä) von Windows in ein Ein-Byte-Zeichen umgewandelt wird. Wieso sollte Windows das tun? Die WinApi verliert sich darüber kein einziges Wort. Also: working as intended. Wenn Windows sowas machen würde (was technisch unmöglich ist) würde es Dateinamen verfälschen und es wäre bis in die Ewigkeit für alle (also die Nicht-Unicode-sprechenden Programme) unmöglich, eine Datei zu öffnen, die laut Dateisystem Sonderzeichen enthält.

Dass du also von readdir ein Multibyte-Zeichen zurückkriegst, ist völlig normal. So stehts auch im Dateisystem und ist ine verständliche Reaktion. Wer das nun fehlinterpretiert ist doch eigentlich egal. Ausm Apache kommts bei mir noch korrekt raus. Kann man bequem via Java oder so prüfen. Bei mir macht erst der Explorer die Maskierung. Und das wohl nur, weil er merkt, dass der Zeichensatz verletzt wird und statt das Zeichen als "undefinierbar" darzustellen oder als zwei einzelne Zeichen, interpretiert er es wohl als Multibyte-Zeichen und wen man das ganze dann anguckt, wirds merkwürdig, weil der Explorer maskiert. Das ist mir mit Java schon unzählige Male passiert. Mich störts nicht, denn wenn man es in einem Formular o.ä. wieder zurückschickt, wirds wieder richtig in PHP ankommen. Also richtig im Sinne eines Multibyte-Zeichens.

Dass PHP kein Unicode spricht. Dass PHP keine Multibyte-Zeichen von Haus aus verwaltet, sondern nur einfache Chars, ist doch schon ewig bekannt. Es ruft für readdir unter Windows schlichtweg die falschen Methoden auf und kann gar keine richtigen Ergebnisse zurückkriegen.

Lange Rede kurzer Sinn: Ich wies am Anfang auf die mb-Funktionen hin. Mit diesen lässt sich das Ergebnis des readdir sinnvoll analysieren und so verarbeiten, dass keine Maskierung seitens Explorer notwendig ist.

[Bleistift]

Nur der Vollständigkeit halber: Die Screenshots sind unter OS X erstellt worden. Aber wohl genau das selbe Problem.
Jedenfalls danke, ich werde mir das mal genau ansehen.