BigInt über JSON: einen verlustfreien Feldvertrag definieren, bevor ein Replacer hinzugefügt wird

Worum es geht

MDN dokumentiert, dass JSON.stringify BigInt-Werte standardmässig nicht serialisiert und einen TypeError auslöst. Ein Replacer oder eine explizite Umwandlung kann sie kodieren, aber die empfangende Seite muss wissen, wie der beabsichtigte Typ wiederherzustellen ist. Eine Umwandlung über Number kann Präzision verlieren, daher ist die Transportdarstellung Teil des Schemavertrags. MDN: BigInt

Warum es wichtig ist

Ein Agent behebt die Ausnahme möglicherweise, indem er Number auf jedes BigInt anwendet. Das löst die Serialisierung, verändert dabei aber unter Umständen Kennungen oder Zähler. Entscheiden, ob die empfangende Seite Arithmetik, Identitätsvergleich oder Anzeige benötigt, und eine explizite Darstellung wählen, die die erforderliche Information bewahrt.

So wird es angewendet

• Die betroffenen Felder und ihre zulässigen Wertebereiche erfassen. Kennungen von Mengenangaben unterscheiden; eine Kennung muss nicht zu einem numerischen Laufzeittyp werden, nur weil sie Ziffern enthält.
• Bei einer Dezimalstring-Darstellung Vorzeichen-, führende-Null- und Leerstring-Regeln im Schema festlegen. Direkt vom BigInt in seine Stringform umwandeln und eine Number-Zwischenstufe vermeiden.
• Bei Verwendung eines getaggten Objekts dessen genaue Form und Kollisionsstrategie festlegen. Beliebige, von Nutzenden stammende Objekte nicht allein deshalb zu privilegierten numerischen Werten werden lassen, weil sie einen günstig benannten Schlüssel enthalten.
• Round-Trip-Testfälle für null, negative Werte (sofern erlaubt) und Ganzzahlen ausserhalb des sicheren Number-Bereichs der empfangenden Seite vorschlagen. Nach der Wiederherstellung exakte Wertgleichheit prüfen.
• Fehlerhafte Kodierungen testen und sicherstellen, dass die Validierung mit einem klaren Feldfehler scheitert. Dasselbe Schema in erzeugender Seite, konsumierender Seite und gespeicherten Testfällen beibehalten.

Stolpersteine

Ein generischer JSON-Reviver kann den ursprünglichen Typ nicht jeder dezimalähnlich aussehenden Zeichenfolge ableiten. Eine globale Prototyp-Änderung wirkt sich auch auf sachfremde Serialisierung aus, daher ihren Geltungsbereich prüfen, bevor sie übernommen wird. Andere Sprachen haben unter Umständen andere native Ganzzahlbereiche; jede tatsächliche konsumierende Seite testen. Dieser Artikel schlägt eine Prüfung des verlustfreien Vertrags vor und behauptet weder einen universellen Kodierungsstandard noch ausgeführte Interoperabilitätsergebnisse.