UTF-8 (ohne Byte Order Marker) als Encoding festlegen

[lu-j]

Auf dem Workshop wurde beschlossen: Aktuell ist für OParl noch kein Encoding festgelegt und es ist gibt für Clients keine zuverlässige Methode das verwendete Encoding automatisch zu erkennen. UTF-8 (ohne Byte Order Marker) ist mit großem Abstand das verbreitetste Encoding im Internet und soll daher zwingend das Encoding für die OParl Ausgabe sein.

Wir bitten um Feedback!

[akuckartz]

RFC 7159 sagt im Abschnitt "Character Encoding":

JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32. The default encoding is UTF-8, and JSON texts that are encoded in UTF-8 are interoperable in the sense that they will be read successfully by the maximum number of implementations; there are many implementations that cannot successfully read texts in other encodings (such as UTF-16 and UTF-32).

Implementations MUST NOT add a byte order mark to the beginning of a JSON text. In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark rather than treating it as an error.

https://tools.ietf.org/html/rfc7159#section-8.1

[akuckartz]

UTF-8 wird auch durch die "Internet JSON" Spezifikation (I-JSON) gefordert, siehe RFC 7493. OpenGovLD wird Konformität mit I-JSON zumindest empfehlen (https://github.com/OpenGovLD/specs/issues/135).

[noxer]

Ich bin dafür, dass UTF-8 erzwungen wird, es macht es dem Client viel leichter, die Ausgaben des Servers zu interpretieren und kann gleichzeitig alle Codepoints von UTF-16 und -32 darstellen. Sollen HTML-Encodings von Zeichen zugelassen werden? Dann hätten ASCII-basierte RIS eine weitere Möglichkeit die Daten auszugeben.

[the-infinity]

HTML-Encodings sind XML, kein JSON. Erlaubt ist aber natürlich JSON-String-Encoding nach https://tools.ietf.org/html/rfc7159#section-7 Resultat dieses Issues findet sich nun in https://github.com/OParl/specs/commit/1ca666b899874fe3bfc31f3a4287c5bbabe19f0c .