JSON-Zeichenkodierung - wird UTF-8 von Browsern gut unterstützt oder sollte ich numerische Escape-Sequenzen verwenden?

Question

Ich schreibe einen Webservice, der json verwendet, um seine Ressourcen zu repräsentieren, und ich bin ein bisschen stecken Denken über den besten Weg, um die json kodieren. Das Lesen der json rfc ( http://www.ietf.org/rfc/rfc4627.txt ) ist es klar, dass die bevorzugte Kodierung utf-8 ist. Aber die rfc beschreibt auch einen String-Escaping-Mechanismus für die Angabe von Zeichen. Ich gehe davon aus, dass dieser im Allgemeinen verwendet wird, um Nicht-Ascii-Zeichen zu entschlüsseln, wodurch das resultierende utf-8 gültige ascii wird.

Nehmen wir an, ich habe eine json-Zeichenkette, die Unicode-Zeichen (Code-Punkte) enthält, die nicht ascii-Zeichen sind. Sollte mein Webservice nur utf-8 kodiert, dass und geben Sie es, oder sollte es alle diese Nicht-Ascii-Zeichen zu entkommen und reine ascii zurück?

Ich möchte, dass die Browser in der Lage sind, die Ergebnisse mit jsonp oder eval auszuführen. Hat das Auswirkungen auf die Entscheidung? Mein Wissen über die Javascript-Unterstützung verschiedener Browser für utf-8 ist mangelhaft.

EDIT: Ich wollte klarstellen, dass mein Hauptanliegen, wie die Ergebnisse zu kodieren ist wirklich über Browser Handhabung der Ergebnisse. Was ich gelesen habe, deutet darauf hin, dass Browser empfindlich auf die Kodierung sein können, wenn JSONP insbesondere verwendet wird. Ich habe keine wirklich guten Informationen zu diesem Thema gefunden, also werde ich anfangen müssen, einige Tests durchzuführen, um zu sehen, was passiert. Idealerweise möchte ich nur die wenigen Zeichen, die erforderlich sind, zu entkommen und nur utf-8 kodieren die Ergebnisse.

Answer 1

Die JSON-Spezifikation erfordert UTF-8-Unterstützung von Decodern. Infolgedessen können alle JSON-Decoder UTF-8 genauso gut verarbeiten wie die numerischen Escape-Sequenzen. Dies gilt auch für Javascript-Interpreter, was bedeutet, dass JSONP auch mit UTF-8-kodiertem JSON umgehen kann.

Die Möglichkeit für JSON-Encoder, stattdessen die numerischen Escape-Sequenzen zu verwenden, bietet Ihnen einfach mehr Auswahl. Ein Grund, warum Sie die numerischen Escape-Sequenzen wählen können, wäre, wenn ein Transportmechanismus zwischendurch Ihr Encoder und der vorgesehene Decoder sind nicht binärsicher.

Ein weiterer Grund, warum Sie numerische Escape-Sequenzen verwenden sollten, ist, dass Sie verhindern wollen, dass bestimmte Zeichen im Stream erscheinen, wie z. B. < , & et " die als HTML-Sequenzen interpretiert werden können, wenn der JSON-Code ohne Escaping in HTML platziert wird oder ein Browser ihn fälschlicherweise als HTML interpretiert. Dies kann eine Verteidigung gegen HTML-Injection oder Cross-Site-Scripting sein (Hinweis: Einige Zeichen MÜSSEN in JSON escaped werden, darunter " et \ ).

Einige Frameworks, darunter das von PHP json_encode() (standardmäßig), immer die numerischen Escape-Sequenzen auf der Kodiererseite für jedes Zeichen außerhalb von ASCII ausführen. Dies ist ein größtenteils unnötiger zusätzlicher Schritt, der für eine maximale Kompatibilität mit begrenzten Transportmechanismen und dergleichen gedacht ist. Dies sollte jedoch nicht als Hinweis darauf gewertet werden, dass JSON-Decoder ein Problem mit UTF-8 haben.

Ich denke, Sie können sich einfach entscheiden, was Sie verwenden wollen:

• Verwenden Sie einfach UTF-8, es sei denn, die Software, die Sie zur Speicherung oder zum Transport zwischen Encoder und Decoder verwenden, ist nicht binärsicher.

• Andernfalls verwenden Sie die numerischen Escape-Sequenzen.

Answer 2

Ich hatte dort ein Problem. Wenn ich eine Zeichenkette mit einem Zeichen wie "é" in JSON kodiere, geben alle Browser das gleiche "é" zurück, außer IE, der "é" zurückgibt. \u00e9 ".

Dann mit PHP json_decode(), wird es fehlschlagen, wenn es "é" zu finden, so dass für Firefox, Opera, Safari und Chrome, ich habe zu utf8_encode() vor json_decode() aufrufen.

Hinweis: Bei meinen Tests verwenden IE und Firefox ihr eigenes JSON-Objekt, andere Browser verwenden json2.js.

Answer 3

ASCII ist nicht mehr dabei. Die Verwendung der UTF-8-Kodierung bedeutet, dass Sie nicht die ASCII-Kodierung verwenden. Wofür Sie den Escaping-Mechanismus verwenden sollten, steht im RFC:

Alle Unicode-Zeichen können platziert werden innerhalb der Anführungszeichen stehen, außer mit Ausnahme der Zeichen, die escaped werden müssen: Anführungszeichen, umgekehrter solidus, und die Steuerzeichen (U+0000 bis U+001F)

Answer 4

Lesen des json rfc ( http://www.ietf.org/rfc/rfc4627.txt ) ist klar, dass die bevorzugte Kodierung utf-8 ist.

Zu Ihrer Information: RFC 4627 ist nicht mehr die offizielle JSON-Spezifikation. I RFC 7159 das dann 2017 durch RFC 8259 das ist die aktuelle Spezifikation.

RFC 8259 besagt:

8.1. Zeichenkodierung

JSON-Text, der zwischen Systemen ausgetauscht wird, die nicht Teil eines geschlossenen Ökosystems sind, MUSS mit UTF-8 kodiert werden [RFC3629]. .

Frühere JSON-Spezifikationen haben die Verwendung von UTF-8 bei der Übertragung von JSON-Text nicht verlangt. Die große Mehrheit der JSON-basierten Software-Implementierungen hat sich jedoch für die Verwendung der UTF-8-Kodierung entschieden, da dies die einzige Kodierung ist, mit der Interoperabilität erreicht wird.

Implementierungen MÜSSEN KEINE Byte Order Mark (U+FEFF) an den Anfang eines über das Netzwerk übertragenen JSON-Textes anfügen. Im Interesse der Interoperabilität KÖNNEN Implementierungen, die JSON-Texte parsen, das Vorhandensein einer Byte-Order-Marke ignorieren, anstatt es als Fehler zu behandeln.

Answer 5

Ich stand vor dem gleichen Problem. Bei mir funktioniert es. Bitte überprüfen Sie dies.

json_encode($array,JSON_UNESCAPED_UNICODE);