Problem mit JSON und Umlauten

[Bububoomt]

Ich habe eine Seite auf einen anderen Server kopiert, und habe nun mit JSON ein problem. Daten die Umlaute enthalten sind auf mal NULL.
Jetzt habe ich gegoogelt und finde die INFO, die Daten müssen UTF8 sein.

Komisch ist, dass es auf dem einen Server klappt, auf dem anderen nicht.
Frage mich gerade woran das liegt. Php Version?

Ode woran kanns liegen, das es bei dem einen klappt?

 

[theHacker]

Daten die Umlaute enthalten sind auf mal NULL.

Kann ich mir nicht wirklich vorstellen. Du hast bei Zeichensatzproblemen undarstellbare Zeichen bzw. 2 andere Zeichen statt einem normalen Zeichen. Niemals verschwindet aber ein kompletter String. Bzw. selbst dann hättest du nur n Leerstring und nicht NULL.
D.h. dein NULL wird von der Anwendung verursacht.

[...] die Daten müssen UTF8 sein.

In welchem Zeichensatz die Daten sind, bestimmt auch allein die Anwendung. Wenn du ein 'ä' haben willst und sendest 0xe4 an den Browser, dann is der Zeichensatz ISO-8859-1, sendest du 0xc3 0xa4, so ist der Zeichensatz UTF-8.

Der Fehler, der passieren kann, ist, dass du einen falschen Content-Type-Header sendest und der Empfänger die Daten anders interpretiert, als er soll, z.B. würde ein Browser bei 0xc3 0xa4, wenn er die Info kriegt, er soll ISO-8859-1 darstellen, 'ä' ausgeben.
Die Daten sind dann aber immer noch richtig. Sie werden nur falsch dargestellt.

 

[Bububoomt]

Also es ist wirklich so, das Json daraus null macht. Das findet man auch beim googeln. Nur daher weiß ich dass es an Json liegt.

Habe nochmal geschaut. Ea wurde nicht der gesamte string ausgegeben. Nur bis zum ersten Umalut.
Rest wurde abgeschnitten.

Wundere mich aber über diesen Unterschied.mache jetzt noch ein utf8_encoding und dann klappt es.

Hmm aber komisch halt das die Daten in der db utf8sein sollten und die Verbindung es auch sein müste.

 

[theHacker]

Also es ist wirklich so, das Json daraus null macht.

JSON macht nichts. Es ist nur ein Datenformat.

 

[ice-breaker]

RFC 4627 schreibt vor, dass Strings in JSON Unicode sein müssen. Sollten es dann iso-8859-1 Strings sein, kann ein En- oder Decoder da schon null draus machen, das ist schon alles in Ordnung.

 

[Bububoomt]

JSON macht nichts. Es ist nur ein Datenformat.

ja richtig, bin halt noch Müde.

Also JQuery macht es.
Fragte mich halt nur wieso so ein unterschied. Wobei ich ja gemerkt habe das das andere auch fehlerhaft war.

 

[ice-breaker]

Weil das JSON-Dateiformat nach RFC 4627 explizit Unicode Strings fordert.
JSON ist aber eine Untermenge der JavaScript-Syntax ECMAScript3. ECMAScript3 ist aus dem Jahre 1999, der JSON-Standard aus 2006.

Somit ist es eben abhängig nach welchem Standard dein "JSON" geparst wird. Da Browser die Syntax schon deutlich vor 2006 unterstützt haben, sind denen eben die JSON-Regeln egal, ein String kann in jedem Charset sein. Bei Funktionen wie JSON.stringify im Browser kommt es eben nun darauf an, wie der ECMAScript5 Standard diese definiert, auf die schnelle habe ich im Standard nichts gefunden. Aber es scheint so, als ob die ECMAScript-Object Restriktionen gelten, somit jeder Zeichensatz erlaubt ist.
Ist die Implementierung aber eben nach RFC 4627 gebaut, dann ist nur Unicode erlaubt.

Ich denke das bringt etwas Licht in das Dunkel. JSON ist aus dem ECMAScript-Standard einfach nur ein Dateiformat ohne Zeichensatz, aber nach dem RFC 4627 als Datenformat für Übertragungen mit Unicode Zeichensatz.


Nachtrag: Interessanterweise habe ich eben gefunden, dass JavaScript sogar von einem UTF-16 Zeichensatz ausgeht, wie das zu den ganzen Browserimplementierungen passt, die sich dem Zeichensatz der Seite anpassen ist mir da ein Rätsel.

Nachtrag2: Der Nebel lichtet sich UTF-16 ist wirklich der Zeichensatz für JavaScript. Aber alle Operationen auf Strings arbeiten ohne Wissen von Charsets, die arbeiten einfach auf Bytes, solange man ASCII hat wird str.length also wunderbar funktionieren, für UTF-8/UTF-16/iso-8859-1 und Sonderzeichen wird aber nicht Länge des Strings in Zeichen sondern in Bytes rauskommen.

 

[Bububoomt]

Also ich meinte wieso auf Server A bis zum Umlaut der String ausgegeben wird und auf Server B Null.
Ich werde da mal wenn ich zeit habe noch bischen testen, vorallem wieso das nicht UTF 8 ist, weil es das eh schon sein sollte. Hauptsache es läuft erstmal.

 

[ice-breaker]

Du hast noch immer nicht beschrieben was wo wie gemacht wird Wird mit json_encode() ein JSON-Datenobjekt erstellt? Wird dies an einen Client gesendet? Was macht der damit? Was sind die Unterschiede der Seiten? Ist das generierte JSON-Objekt ok aber nicht der auf dem Client geparste?

Du hast eben ziemlich viele Glaskugel-Fragen offen gelassen

 

[Bububoomt]

Ähm dachte das soweit schon geschrieben habe.

Aber nochmal:
Server A
->Jquery Ajax Aufruf
->php ein Array mit diversen Daten wird per json_encode() zurückgegeben
->Jquery decodiert es ($.parseJSON(data)), und es gibt Daten die abgeschnitten sind bei Umlauten

Server B


->Jquery Ajax Aufruf
->php ein Array mit diversen Daten wird per json_encode() zurückgegeben
->Jquery decodiert es ($.parseJSON(data)), und es gibt Daten die null sind die Umlauten enthalten

Es ist die gleiche Seite, nur auf einem anderen Server. Bis auf die PHP Version sehe ich keinen Unterschied. Naja die DB-Version ist sicherlich auch etwas neuer.

 

[theHacker]

Wie lauten die URLs der beiden AJAX-Aufrufe? Ich würde das gerne mal sehen.

 

[Bububoomt]

müßte ich nun erstmal eine testumgebung erstellen, weil die Domain ja nun auch auf dem anderen Server ist und zudem ja nun ich das utf8_encoding ausführe.