Encoding

[notyyy]

Hallo,

wenn ich mir im manual fopen, file_get_contents u.s.w. angucken, finde ich keine direkte information darüber in welchem encoding die Datei geladen wird. von welchen Faktoren ist dies GENAU abhängig?

[ChrisB]

Da PHP in Version 5 noch sehr suboptimal mit Kodierungen umgeht, kann ich dir nur raten, dich mit mb_detect_encoding zu beschäftigen, ggf. in Kombination mit iconv zum Umkodieren von Eingabedaten.

[notyyy]

Hallo,

mbstring und iconv sind mir bekannt.

mbstring is a non-default extension

leider kann man sich nicht wirklich auf mb verlassen, da es evtl nicht vorhanden ist. Nun muss es doch Richtliniengeben, wann wie geladen wird?

[nikosch]

Was willst Du hören? Genau um diesen Umstand zu lösen gibt es mb_ Zudem dürfte Dir doch klar sein, dass der Zeichensatz des Strings abhängig vom jeweiligen Inhalt ist.

[notyyy]

[TRASH]
wenn ich die fopen funktion mit dem Streamreader in .net (StreamReader-Konstruktor (String, Encoding) (System.IO)) vergleiche, fällt direkt auf, dass hier ein encoding direkt beim lesen eingestellt werden muss. ein schönes Beispiel ist das Mac OSX Encoding und UTF-8, welche sich kaum unterscheiden.[/TRASH]

Mir ist beim Schreiben des Posts erst wirklich bewusst geworden, dass PHP das nicht interessiert und .net intern immer mit UTF8 arbeitet. Conventiert werden muss halt Manuel oder man muss damit leben. Sollte man sauber entwickeln müsste jeder IO explizit conventiert werden.

ich werde mal darüber nachdenken und ein paar Tests fahren, irgendwie ist mir das derzeit noch ein wenig suspekt und hat gigantische Auswirkungen.

[dr.e.]

.NET und auch JAVA repräsentieren Strings (=Byte-Array mit Encoding). Bei PHP dagegen sind Strings Byte-Arrays und du musst dich um das Encoding selbst kümmern. In deinem Fall ist es also egal, welche Funktion du nutzt, deine Files müssen im korrekten Encoding vorliegen, sonst ist die Performance hinüber. Alles mit utf8_encode() oder iconv() on-the-fly encodieren zu wollen ist zwar aus Software-Design-Gründen gut, dir geht aber extrem Speicher und CPU den Bach runter.

[Gast]

deine Files müssen im korrekten Encoding vorliegen

Das bietet sich auch insofern an, als das PHP6 meines Wissens nach komplett auf utf-8 umsteigt. Mit mb_internal_encoding kann man außerdem explizit das interne encoding festlegen, so dass man auch die mb_*-Funktionen ohne Encoding-Parameter benutzen kann.

[dr.e.]

Das bietet sich auch insofern an, als das PHP6 meines Wissens nach komplett auf utf-8 umsteigt.

Das wiederum wäre ja egal, wenn du in deinem Server/deinem VHOST/pro Request das Input- und Output-Encoding gestlegen kannst und der Server beim Flushen des Ausgabe-Puffers oder beim Schreiben eines Strings auf den Ausgabe-Stream das gesetzte Encoding korrekt verarbeiten würde (siehe JAVA/.NET).

[Gast]

Es geht ja um das Auslesen von Dateien, nicht um das Encoding von Ein-/Ausgaben.

[dr.e.]

Das Auslesen von Files ist in JAVA auch Stream-Handling und unterliegt der beschriebenen Logik.

[fireweasel]

...
wenn ich mir im manual fopen, file_get_contents u.s.w. angucken, finde ich keine direkte information darüber in welchem encoding die Datei geladen wird.

In keiner irgendwie gearteten Kodierung. Einfach die nackten Bytes. Und das ist auch gut so.

Mir ist beim Schreiben des Posts erst wirklich bewusst geworden, dass PHP das nicht interessiert ... Conventiert werden muss halt Manuel ...

Wie schon gesagt: Das ist eine bessere Strategie, als irgendwo implizit eine "Kodierung" anzunehmen. Die Datei-"Bearbeitungs"-Funktionen von PHP arbeiten mit den (binären) Rohdaten als "Byte-Strom". Die müssen und sollen nichts davon mitbekommen, in welcher Art die Nutzdaten kodiert sind. Das geht sie nichts an.

Sollte man sauber entwickeln müsste jeder IO explizit conventiert werden.

Wieso? Nicht jede I/O-Operation bezieht sich auf Text-Files. Wer eine entsprechende Kodierung erwartet, hat vor dem Einlesen zu prüfen, ob sie vorhanden ist (BOM usw.). Wenn ja, wird eingelesen, ohne zu konvertieren (der schnellste Weg). Wenn nein, wird gekuckt, ob eine Umwandlung möglich ist und konvertiert oder eine Fehlermeldung ausgeworfen.

ich werde mal darüber nachdenken und ein paar Tests fahren, irgendwie ist mir das derzeit noch ein wenig suspekt und hat gigantische Auswirkungen.

Wie meinen? Diese Vorgehensweise ist in PHP seit Urzeiten so eingebaut. Mit PHP6 hätte sich das ändern sollen. Das hat sich auf mittlere Sicht erstmal erledigt. Alles bleibt beim Alten.

Das bietet sich auch insofern an, als das PHP6 meines Wissens nach komplett auf utf-8 umsteigt.

Glücklicherweise wurde PHP6 inclusive des dafür geplanten Unicode-Schwachsinns schon vor einiger Zeit gecancelt. Und PHP6 sollte nicht auf UTF-8 basieren (was noch größerer Schwachsinn wäre[1]) sondern auf irgendeiner UTF16-Variante.

Übrig geblieben sind davon die ICU-Funktionen und -Klassen. Die stellen einen halbwegs soliden Grundstock dar, mit dem man ab PHP 5.2.4 arbeiten kann, wenn man Unicode-Fähigkeiten braucht, die über das wenige hinausgehen, was mbstring, iconv oder preg (mit '/u') zu bieten haben. Die Verfügbarkeit dürfte aber ähnlich wie bei mbstring nicht bei jedem 08/15-Hoster gegeben sein.

==
[1] UTF-8 ist ein reines "Transfer-Format". Damit String-Bearbeitung zu betreiben ist wohl selten sinnvoll und ziemlich oft wenig performant.