Fallstricke bei JSON-Zahlen: Integer jenseits von 2^53, NaN und Infinity sowie exakte Dezimalzahlen

Worum es geht

Die JSON-Grammatik (RFC 8259, zitiert) erlaubt Zahlen beliebiger Grösse und Genauigkeit, überlässt es aber den Implementierungen, Grenzen zu setzen; sie merkt an, dass IEEE-754-binary64-Software das ist, was ein Sender im Allgemeinen erwarten kann, dass Integer innerhalb von [-(2^53)+1, (2^53)-1] insofern interoperabel sind, als Implementierungen sich exakt über ihre Werte einig sind, und dass Werte, die die Grammatik nicht ausdrücken kann, wie Infinity und NaN, nicht zulässig sind. I-JSON (RFC 7493, zitiert) macht daraus Regeln für interoperable Nachrichten: nicht mehr Grösse oder Genauigkeit senden, als ein Double bietet, und grössere oder exakte Werte, etwa 64-Bit-Integer, als Strings codieren, weil JavaScript einen Integer jenseits von 9007199254740991 nicht als exakt behandeln kann. Die Python-json-Dokumentation (zitiert) besagt, dass allow_nan standardmässig auf true steht, sodass nan und inf als NaN und Infinity geschrieben werden, was die Spezifikation nicht zulässt. MDN (zitiert) besagt, dass JSON.stringify NaN und Infinity als null behandelt.

Warum es wichtig ist

Eine 64-Bit-Datenbankkennung über 2^53 übersteht einen Python-Roundtrip, verliert aber in einem Browser unbemerkt ihre unteren Ziffern. Ein Notebook, das NaN in eine JSON-Datei schreibt, erzeugt ein Dokument, das andere Parser ablehnen, während derselbe Wert, durch einen Browser geleitet, zu null wird und wie ein absichtliches «fehlt» aussieht. Ein in ein binäres Double geparster Geldbetrag ist nicht mehr der gesendete Dezimalbetrag, und jeder Rechenschritt darauf rundet.

So wird es angewendet

• Den numerischen Vertrag pro Feld dokumentieren: Integer mit einem Bereich, Dezimalzahl mit einer Skala, oder Gleitkommazahl; alles, was 2^53 überschreiten könnte, reist als String.
• Kennungen ab dem ersten Release als Strings serialisieren; ein späterer Wechsel ist ein Breaking Change für jeden Client.
• Exakte Dezimalzahlen (Geldbeträge, Messwerte mit fester Skala) als Strings serialisieren und in einen Dezimaltyp parsen; der verwandte Artikel zu Decimal erklärt, warum Doubles der falsche Container sind.
• Nicht endliche Werte an der Grenze ablehnen: in Python allow_nan=False übergeben, damit die Serialisierung einen Fehler auslöst, statt NaN auszugeben; in JavaScript vor dem Stringify Number.isFinite prüfen. «Fehlt» bewusst als null oder als abwesendes Feld darstellen.
• Mit einem Schema validieren, das type, minimum und maximum festlegt, sowie ein Muster für string-codierte Zahlen.

Stolpersteine

-0 ist eine gültige JSON-Zahl, aber JavaScripts JSON.stringify(-0) liefert "0". Exponentialschreibweise ist für Integer zulässig (1e2), und manche Parser typisieren den Wert dann als Gleitkommazahl. JavaScript-BigInt-Werte lösen bei JSON.stringify eine Exception aus, sofern nicht ein Replacer oder eine toJSON-Methode sie umwandelt. RFC 8259 lässt doppelte Feldnamen undefiniert, und I-JSON verbietet sie; Parser behalten üblicherweise den letzten, was Duplicate-Key-Smuggling zu einem Validierungsproblem macht.