Eine JSON-Zeichenkette kann die Escape-Sequenz enthalten: \u Vier-Hex-Ziffern, die zwei Oktette sind.
Nach dem Einlesen der vier Hex-Ziffern in c1, c2, c3, c4 gibt die JSON Spirit C++-Bibliothek ein einzelnes Zeichen zurück, das den Wert (hex_to_num (c1) << 12) + (hex_to_num (c2) << 8) + (hex_to_num (c3) << 4) + hex_to_num (c4) .
Aufgrund der Einfachheit des Dekodierungsschemas und der Tatsache, dass nur 2 Oktette zu dekodieren sind, schließe ich, dass JSON-Escape-Sequenzen nur die UCS-2-Kodierung unterstützen, d. h. Text von BMP U+0000 bis U+FFFF, der "wie er ist" kodiert wird, wobei der Codepunkt als 16-Bit-Codeeinheit verwendet wird.
Da UTF-16 und UCS-2 gültige Codepunkte in U+0000 bis U+FFFF als einzelne 16-Bit-Codeeinheiten kodieren, die numerisch gleich den entsprechenden Codepunkten sind ( wikipedia ), kann man einfach so tun, als ob das dekodierte UCS-2-Zeichen ein UTF-16-Zeichen wäre.
Das Escape-Zeichen unterscheidet sich von einer normalen JSON-Zeichenkette ohne Escape-Zeichen, die "" enthalten kann. any Unicode character except " or \ or control-character " (json spec) . Da JSON eine Teilmenge von ECMAScript ist, bei der davon ausgegangen wird, dass sie UTF-16 ist (Ecma-Standard) schließe ich, dass JSON die UTF-16-Kodierung unterstützt, die breiter als das, was die Escape-Sequenz bietet.
Wenn man nun alle JSON-Strings auf UTF-16 reduziert und sie von UTF-16 nach UTF-8 konvertiert, ist es nach meinem Verständnis möglich, das UTF-8 in einem std::string unter Linux zu speichern, da man bei der Verarbeitung oft ignorieren kann, dass mehrere std::string-Zeichen verbraucht werden, um eine 6 Byte lange UTF-8-Sequenz darzustellen.
Wenn alle oben genannten Annahmen und Interpretationen korrekt sind, kann man JSON sicher parsen und in einem std::string unter Linux speichern. Kann das bitte jemand überprüfen?
