file_put_contents UTF8 crash

[Henry]

Hallo,

habe gerade ein UTF8 Problem mit file_put_contents();

Ich versuche eine Zeile an eine bestehenden UTF8 Datei anzuhängen. Das Resultat ist eine zerstörte Datei (also komplette Datei nicht nur angehängte Zeile) mit Hieroglyphen.

Ich könnte das ja noch nachvollziehen, wenn die Datei noch nicht existieren würde, tut sie aber und wenn ich mir die anschaue bevor file_put_contents aktiv wird ist auch auch alles in Ordnung, alles leserlich und Editor zeigt klar UTF8 (weil auch bereits Umlaute drin sind) ohne BOM an. Nach file_put_contents() siehts anders aus, wie gesagt Hieroglyphen und Editor zeigt ANSI an. Wie kann das sein, bzw. wo muss ich ansetzen?

Bei ähnlichen Scripten taucht das Problem nicht auf, finde aber keinen gravierenden Unterschied. file_put_contents($fl, $row, FILE_APPEND | LOCK_EX);

Gruss
Henry

[Christian Kruse]

Hallo Henry,

Bei ähnlichen Scripten taucht das Problem nicht auf, finde aber keinen gravierenden Unterschied. file_put_contents($fl, $row, FILE_APPEND | LOCK_EX);

Das sind zu wenig Informationen. Z.B. was ist in $row enthalten? Bist du sicher, dass der dort enthaltene Text in UTF-8 kodiert ist?

Das, was du beschreibst, hört sich danach an, dass der Editor nach deinem anhängen Zeichen enthält, die nicht in UTF-8 kodiert sind und sich deshalb dazu entscheidet, dass die ganze Datei nicht in UTF-8 kodiert ist.

Freundliche Grüße,
Christian Kruse

[Henry]

Hallo Christian,

Das sind zu wenig Informationen. Z.B. was ist in $row enthalten? Bist du sicher, dass der dort enthaltene Text in UTF-8 kodiert ist?

Da bin ich sicher, was den Ausgangstext betrifft. Danach wird dieser aber etliche Male im Script umgewandelt (base64, zu array zu string, etc…) was das auch kompliziert macht dies hier genauer darzustellen. Aber da wird wohl der Wurm drin sein.

Das, was du beschreibst, hört sich danach an, dass der Editor nach deinem anhängen Zeichen enthält, die nicht in UTF-8 kodiert sind und sich deshalb dazu entscheidet, dass die ganze Datei nicht in UTF-8 kodiert ist.

Da triffst du wohl den Nagel auf dem Kopf. Weiß zwar noch nicht genau warum, aber ja die letzte Zeile sieht noch hierogyphenhafter als der Rest aus. Das hilft mir schon mal, hätte nicht gedacht, dass die ganze Datei dann wegen einer schädlichen Zeile nicht mehr erkannt wird. Und hätte dann auch nicht erwartet, dass alles falsch dargestellt wird. Selbst wenn ich dem Editor dann sage ist UTF8 ist das nicht reparabel.

Danke für den Hinweis.

Gruss
Henry

[Christian Kruse]

Hallo Henry,

Das, was du beschreibst, hört sich danach an, dass der Editor nach deinem anhängen Zeichen enthält, die nicht in UTF-8 kodiert sind und sich deshalb dazu entscheidet, dass die ganze Datei nicht in UTF-8 kodiert ist.

Da triffst du wohl den Nagel auf dem Kopf. Weiß zwar noch nicht genau warum, aber ja die letzte Zeile sieht noch hierogyphenhafter als der Rest aus. Das hilft mir schon mal, hätte nicht gedacht, dass die ganze Datei dann wegen einer schädlichen Zeile nicht mehr erkannt wird.

Man kann die Kodierung nur mit Heuristiken erkennen. „Ist valide in UTF-8, also wird es wohl UTF-8 sein“ ist ein häufiger Algorithmus. Wenn jetzt ein Zeichen kein valides UTF-8 ist, dann gilt die Prämisse halt nicht mehr und der Algorithmus kommt zu einem anderen Ergebnis.

Und hätte dann auch nicht erwartet, dass alles falsch dargestellt wird. Selbst wenn ich dem Editor dann sage ist UTF8 ist das nicht reparabel.

Wenn du den Editor manuell auf UTF-8 stellst, sollte nur die letzte Zeile unleserlich sein; der Rest der Datei sollte korrekt dargestellt werden. Zumindest würde ich das so implementieren.

Freundliche Grüße,
Christian Kruse

[Raketen]

Da bin ich sicher, was den Ausgangstext betrifft. Danach wird dieser aber etliche Male im Script umgewandelt (base64, zu array zu string, etc…) was das auch kompliziert macht dies hier genauer darzustellen. Aber da wird wohl der Wurm drin sein.

Das nehme ich auch an. An irgend einer Stelle hast Du vermutlich schlicht die falsche, für UTF-8-kodierten Text nicht geeignete Funktion verwendet. Was dann den Textbetrachter bzw. Editor dazu bewegt, Dir alles verknorkst darszustellen weiß dieser. Vielleicht meint ja dieser Textbetrachter, es sei UTF-16, UTF-32 oder was ganz anderes.

Eine Liste von Multibyte-Funktionen, bei denen man es für sinnvoll erachtet hat, die normalen Textfunktionen zu ersetzen bzw. zu ergänzen, habe ich schon mal für ich herausgesucht.

[pl]

Moin,

beim Schreiben in Dateien (und überhaupt beim Datentransport) muss die Kodierung ausgeschaltet sein. Das wäre zu prüfen. Die Kodierung spielt nur innerhalb eines Programmes (egal ob das MSWord, PHP oder C ist) eine Rolle. Dateien hingegen kennen keine Kodierung.

MFG

[TS]

Hello,

Moin,

beim Schreiben in Dateien (und überhaupt beim Datentransport) muss die Kodierung ausgeschaltet sein. Das wäre zu prüfen. Die Kodierung spielt nur innerhalb eines Programmes (egal ob das MSWord, PHP oder C ist) eine Rolle. Dateien hingegen kennen keine Kodierung.

Formuliere dies bitte nochmal neu und besser.

Es steckt ja ein Fünkchen Wahrheit drin, nämlich, dass man jede Schicht einzeln betrachten muss. Welches ist denn diejenige, die der (persistenten) Speicherung am nächtsten ist? Welche folgt dann? Usw...?

Und male uns am besten ein Bild, das das Datenmodell nebst Datenfluss weiter aufdröselt in den jeweiligen Situationen, ähnlich mehrfachem ISO/OSI... (zuzüglich Kontextwechsel).

Wenn Du das gut machst, setze ich mich dafür ein, dass ein Wikiartikel daraus wird. ;-)

Ich finde, die Minusser sollten ihre Bewertung solange zurückziehen.

Glück Auf
Tom vom Berg

[Christian Kruse]

Hallo TS,

Ich finde, die Minusser sollten ihre Bewertung solange zurückziehen.

Die Aussage von PL ist so schlicht dummes Zeug. Die Bewertungen sind berechtigt.

Freundliche Grüße,
Christian Kruse

[TS]

Hello Christian,

ich wünsche dir auch ein frohes und gesundes Neues Jahr. ;-)

Ich finde, die Minusser sollten ihre Bewertung solange zurückziehen.

Die Aussage von PL ist so schlicht dummes Zeug. Die Bewertungen sind berechtigt.

Wenn Du deine Empathiefähigkeit noch ein klein wenig steigern könntest, wären wir hier auch dieses Jahr wieder auf dem richtigen Weg. :-)

Mobbing ist keine Option!

Stell doch pl lieber die passenden Fragen, um ihn auf die Verständnisebene zu führen. Das kostet doch auch nicht mehr Energie.

Glück Auf
Tom vom Berg

[Christian Kruse]

Hallo TS,

Ich finde, die Minusser sollten ihre Bewertung solange zurückziehen.

Die Aussage von PL ist so schlicht dummes Zeug. Die Bewertungen sind berechtigt.

Wenn Du deine Empathiefähigkeit noch ein klein wenig steigern könntest, wären wir hier auch dieses Jahr wieder auf dem richtigen Weg. :-)

PL bringe ich schon lange keine Empathie mehr entgegen. Die hat er sich nachhaltig verspielt.

Mobbing ist keine Option!

Negativ-Bewertung ist kein Mobbing.

Stell doch pl lieber die passenden Fragen, um ihn auf die Verständnisebene zu führen. Das kostet doch auch nicht mehr Energie.

Jegliche Kommunikation mit PL in den letzten 10 Jahren verlief gleich, egal, was ich versucht habe. Warum sollte ich jetzt in der Bring-Schuld stehen?

Nein. Hier steht Rolf in der Bring-Schuld.

Freundliche Grüße,
Christian Kruse

[TS]

Hello Christian,

Ich finde, die Minusser sollten ihre Bewertung solange zurückziehen.

Die Aussage von PL ist so schlicht dummes Zeug. Die Bewertungen sind berechtigt.

Wenn Du deine Empathiefähigkeit noch ein klein wenig steigern könntest, wären wir hier auch dieses Jahr wieder auf dem richtigen Weg. :-)

PL bringe ich schon lange keine Empathie mehr entgegen. Die hat er sich nachhaltig verspielt.

Mobbing ist keine Option!

Negativ-Bewertung ist kein Mobbing.

Stell doch pl lieber die passenden Fragen, um ihn auf die Verständnisebene zu führen. Das kostet doch auch nicht mehr Energie.

Jegliche Kommunikation mit PL in den letzten 10 Jahren verlief gleich, egal, was ich versucht habe. Warum sollte ich jetzt in der Bring-Schuld stehen?

Nein. Hier steht Rolf in der Bring-Schuld.

Ich hatte Dich jetzt für einen der Wenigen gehalten, der im Sinne des Threads die passenden Fragen hätte stellen können. Man muss dafür schließlich den Durchblick haben!

Ist doch für den OP nachher sogar egal, wer diese Fragen nachher sinnvoll beantwortet. Die Chance dazu gönne ich aber auch PL.

Der OP ist allerdings auch noch einige Informationen schuldig.

Glück Auf
Tom vom Berg

[Matthias Apsel]

Hallo TS,

Ist doch für den OP nachher sogar egal, wer diese Fragen nachher sinnvoll beantwortet. Die Chance dazu gönne ich aber auch PL.

Gerade in Bezug auf Zeichencodierung und Dateien sind in den letzten Jahren mit PL so viele sinnlose Wortwechsel geführt worden …

Bis demnächst
Matthias

[TS]

Hello mein lieber Matthias,

auch Dir ein erfolgreiches und gesundes Neues Jahr!

Ist doch für den OP nachher sogar egal, wer diese Fragen nachher sinnvoll beantwortet. Die Chance dazu gönne ich aber auch PL.

Gerade in Bezug auf Zeichencodierung und Dateien sind in den letzten Jahren mit PL so viele sinnlose Wortwechsel geführt worden …

Dann wäre es doch mal an der Zeit, dass wir die aus dem Archiv heraussuchen und verständlich für alle Leser auswerten und zu einem Artikel zusammenführen.

Ich habe da im heterogenen Umfeld auch häufig Probleme.

Thema
-Mount-Optionen und
-Transfer-Translating.

Glück Auf
Tom vom Berg

[Matthias Scharwies]

Servus!

Dann wäre es doch mal an der Zeit, dass wir die aus dem Archiv heraussuchen und verständlich für alle Leser auswerten und zu einem Artikel zusammenführen.

@TS Frohes neues Jahr!

Diese Artikel existieren bereits:

• Zeichencodierung (in der Versionsgeschichte habe ich chronologisch Svenrtbg, @dedlfix, Redeemer und @Julius gefunden.

• Kontextwechsel (der Klassiker von dedlfix)

Glück Auf
Tom vom Berg

Herzliche Grüße

Matthias Scharwies

[Auge]

Hallo

Ich hatte Dich jetzt für einen der Wenigen gehalten, der im Sinne des Threads die passenden Fragen hätte stellen können. Man muss dafür schließlich den Durchblick haben!

Alle Fragen, die pl zu seinen Aussagen zu diesem Thema gestellt wurden, die ich über die Jahre hier gelesen habe, hat pl gekonnt ignoriert oder mit Ablenkungen vom Thema quittiert. Das erneut zu wiederholen ist vergebliche Liebesmüh oder, um es deutlicher zu sagen, absolut sinnlos.

Tschö, Auge

[TS]

Hello Auge,

Ich hatte Dich jetzt für einen der Wenigen gehalten, der im Sinne des Threads die passenden Fragen hätte stellen können. Man muss dafür schließlich den Durchblick haben!

Alle Fragen, die pl zu seinen Aussagen zu diesem Thema gestellt wurden, die ich über die Jahre hier gelesen habe, hat pl gekonnt ignoriert oder mit Ablenkungen vom Thema quittiert. Das erneut zu wiederholen ist vergebliche Liebesmüh oder, um es deutlicher zu sagen, absolut sinnlos.

Das ist super, dass Du die ganzen Fragen nicht nur aus Hörensagen kennst!

Dann könntest Du sie doch mal zusammentragen und wir suchen gemeinsam nach den richtigen Antworten darauf. Das ist ja gerade die Fähigkeit, die ich @CK unterstellt habe. Es hat eben nicht Jeder den Durchblick.

Lass es uns doch mal gemeinsam versuchen! Das Thema kommt doch immer wieder.

Glück Auf
Tom vom Berg

[Auge]

Hallo

Alle Fragen, die pl zu seinen Aussagen zu diesem Thema gestellt wurden, die ich über die Jahre hier gelesen habe, hat pl gekonnt ignoriert oder mit Ablenkungen vom Thema quittiert. Das erneut zu wiederholen ist vergebliche Liebesmüh oder, um es deutlicher zu sagen, absolut sinnlos.

Das ist super, dass Du die ganzen Fragen nicht nur aus Hörensagen kennst!

Dann könntest Du sie doch mal zusammentragen und wir suchen gemeinsam nach den richtigen Antworten darauf.

Ich weiß absolut nicht, wo du gedanklich hin willst. Ich habe jedenfalls keine Lust, mir Gedanken zu pls Ergüssen zu machen.

Lass es uns doch mal gemeinsam versuchen! Das Thema kommt doch immer wieder.

Bloß, weil pl seine Psalme wieder und wieder hervorbringt, heißt das nicht, dass da ein Thema wäre.

Tschö, Auge

[pl]

Hello,

Moin,

beim Schreiben in Dateien (und überhaupt beim Datentransport) muss die Kodierung ausgeschaltet sein. Das wäre zu prüfen. Die Kodierung spielt nur innerhalb eines Programmes (egal ob das MSWord, PHP oder C ist) eine Rolle. Dateien hingegen kennen keine Kodierung.

Formuliere dies bitte nochmal neu und besser.

Gerne hab ich gerade eben gemacht.

Und natürlich auch in weiteren Artikeln zu meinem Hobby 😉

MFG

Die meisten Probleme mit Zeichenkodierungen treten auf wenn genau diese Grundsätze nicht beachtet werden!

[dedlfix]

Tach!

beim Schreiben in Dateien (und überhaupt beim Datentransport) muss die Kodierung ausgeschaltet sein. Das wäre zu prüfen. Die Kodierung spielt nur innerhalb eines Programmes (egal ob das MSWord, PHP oder C ist) eine Rolle. Dateien hingegen kennen keine Kodierung.

Formuliere dies bitte nochmal neu und besser.

Es steckt ja ein Fünkchen Wahrheit drin, nämlich, dass man jede Schicht einzeln betrachten muss. Welches ist denn diejenige, die der (persistenten) Speicherung am nächtsten ist? Welche folgt dann? Usw...?

Das Thema ist nicht Perl, und deswegen interessieren keine Perl-spezifischen Geschichten. "Kodierung ausschalten" zum Beispiel ist nichts, das für PHP eine Bedeutung hätte. Das existiert hier nicht. Stattdessen muss man dafür sorgen, dass die Strings korrekt kodiert sind, die man zusammenfügen und/oder an Dateien anhängen möchte.

Ja, PHP hat immer noch keine vollständige Multibyte-Unterstützung. Es arbeitet nach wie vor hauptsächlich auf Byte-Ebene. Ein String ist quasi nur ein Array of Bytes. Möchte man eine konkrete Kodierung beachten, muss man die Multibyte-Funktionen verwenden, oder einigen anderen Funktionen die verwendete Kodierung dieser Strings per Parameter mitteilen.

Wie auch immer, für den vorliegenden Fall ist es prinzipiell recht einfach. Der Teufel steckt in den Details. Generell ist es sinnvoll, wenn man Daten entgegennimmt, diese in ein Rohformat zu bringen. Das ist das Format, mit dem man im Kern des Programms alle Berechnungen und Manipulationen anstellen möchte. Da der gesamte Zeichenvorrat von Unicode verarbeitet werden soll, ist UTF-8 eine sinnvolle Möglichkeit für das "Roh"format. Das heißt also, dass Eingabedaten gegebenenfalls nach UTF-8 umkodiert werden müssen. Ebenso sind sämtliche Transportkodierungen zu entfernen (zum Beispiel Base64 oder URL-Encodierung).

Sollen Daten ausgegeben werden, muss gegebenenfalls umkodiert werden und eventuelle Kodierungen für den Transport berücksichtigt werden.

Neben Umkodierungen an Ein- und Ausgängen ist auch noch zu beachten, dass der Rest der Verarbeitung auf UTF-8 aufbaut. Das betrifft vor allem die Code-Dateien des Programms, wenn darin Nicht-ASCII-Zeichen in Litralen vorkommen.

dedlfix.

[pl]

"Kodierung ausschalten" zum Beispiel ist nichts, das für PHP eine Bedeutung hätte.

Doch. Auch PHP hat Funktionen die mit kodierten Zeichen arbeiten. Z.B. die mb_ Funktionen.

Im Übrigen ist das alles weder auf Perl noch auf PHP beschränkt. Es gilt allgemein, daß beim Speichern/Transport die Kodierung ausgeschaltet werden muss.

MFG

[Der Martin]

Hallo,

"Kodierung ausschalten" zum Beispiel ist nichts, das für PHP eine Bedeutung hätte.

Doch. Auch PHP hat Funktionen die mit kodierten Zeichen arbeiten. Z.B. die mb_ Funktionen.

Ja, aber die Aussage passt als Widerspruch nicht zum zitierten Satz.

Im Übrigen ist das alles weder auf Perl noch auf PHP beschränkt. Es gilt allgemein, daß beim Speichern/Transport die Kodierung ausgeschaltet werden muss.

Nochmal: Es gibt kein "Codierung ausschalten". Man kann lediglich Daten nach einer bestimmten Codierung interpretieren, oder sie in eine andere Codierung überführen.
Beim Speichern in eine Datei oder beim Zurücklesen aus einer Datei passiert nichts dergleichen. Die Daten (Strings) werden Byte für Byte so, wie sie auch im Arbeitsspeicher vorliegen, gespeichert. Zumindest in PHP und in C ist das so. Bei diesem Vorgang spielt die Codierung, in der die Strings vorliegen oder interpretiert werden, keine Rolle. Entscheidend ist, dass der Dateiinhalt nach dem Zurücklesen wieder mit derselben Codierung betrachtet wird, denn beim reinen Speichern und Zurücklesen hat sich daran nichts verändert.

Henrys Problem ist, dass er anscheinend Strings, die in unterschiedlichen Codierungen vorliegen, in einer Textdatei zusammenführt. Ein gewöhnlicher Editor kann aber normalerweise nur eine einheitliche Codierung für den gesamten Dateiinhalt anwenden.

Also muss man untersuchen, wie es zu den unterschiedlichen Codierungen kommt. Dabei muss man im Zweifelsfall die gesamte Verarbeitungskette verfolgen. Man kann auch das entstandene Chaos (die verstümmelte Datei) auf Byte-Ebene anschauen (etwa als Hex-Dump) und versuchen zu erkennen, was man da tatsächlich hat. Daraus kann man unter Umständen Rückschlüsse ziehen, was wirklich passiert ist und so die Fehlersuche abkürzen und erleichtern.
Das ist eine meiner bevorzugten Debugging-Strategien: Sieh dir das vorliegende falsche Ergebnis an und versuche zu analysieren, wie es entstanden ist - also quasi vom Ende der Kette in Richtung Anfang.

So long,
 Martin

[dedlfix]

Tach!

"Kodierung ausschalten" zum Beispiel ist nichts, das für PHP eine Bedeutung hätte.

Doch. Auch PHP hat Funktionen die mit kodierten Zeichen arbeiten. Z.B. die mb_ Funktionen.

Da wird nichts ausgeschaltet, sondern explizit (als Parameter) oder implizit (über mb_internal_encoding()) angegeben, welche Kodierung zu verwenden sei. Dein "Ausschalten" bezog sich auch nicht auf diese Funktionen für die interne Verarbeitung, sondern auf das Schreiben in Dateien.

Im Übrigen ist das alles weder auf Perl noch auf PHP beschränkt. Es gilt allgemein, daß beim Speichern/Transport die Kodierung ausgeschaltet werden muss.

Ein Ausschalten ist mir weder in PHP noch in den anderen von mir verwendeten Systemen vorgekommen. So allgemeingültig kann es also nicht sein.

Beispiel C#, das arbeitet bei Strings mit einer für den Programmierer irrelevanten internen Kodierung. Das sind einfach Strings mit dem Zeichenvorrat von Unicode. Beim Import von Daten muss man angeben, was die Ausgangskodierung ist, und beim Exportieren, welche Zielkodierung verwendet werden soll.

dedlfix.

[TS]

Hello,

wie sehen denn die Abbilder der

• Datei vor dem Append
• des Appandstrings
• der Datei nach dem Append

als Hex-Darstellung aus?

Glück Auf
Tom vom Berg