Entwicklertools · JSON Formatierer und Validator
JSONs Standardhistorie: RFC 4627 bis RFC 8259 und ECMA-404
· Hintergrund
json Standards Validierung
JSON wurde mindestens viermal von zwei Normungsgremien spezifiziert. Dieser Beitrag zeichnet den Weg von Douglas Crockfords json.org zu RFC 8259 und ECMA-404 nach und erklärt, was sich auf dem Weg tatsächlich für Entwickler geändert hat.
Welcher Spezifikation folgt mein Parser?
Welcher Spezifikation folgt ein Parser? Die Antwort ist normalerweise an den Rändern sichtbar und nicht in gewöhnlichen Objekten und Arrays. Testen Sie eine Zeichenfolge der obersten Ebene wie `"ready"`, eine führende Bytereihenfolgemarkierung, doppelte Mitgliedsnamen und ungewöhnlich große Zahlen. Verschiedene Dokumente diskutieren Syntax und Interoperabilität auf verschiedenen Ebenen, während Implementierungen ihre eigenen Datentypen und Fehlerverhalten hinzufügen. Die Benennung eines Standards ist nur dann sinnvoll, wenn der beobachtete Parser-Vertrag von den Annahmen über jede JSON-Implementierung getrennt gehalten wird.
Die Repository-Beweise für ToolAcre sind konkret und enger als eine allgemeine Standardhistorie. Der Formatierer verwendet `JSON.parse` zum Erzeugen von Werten und `JSON.stringify` zum Ausgeben dieser Werte. Nach einem Analysefehler liefert ein lokaler Scanner eine stabile Diagnoseposition und -ursache.
json.org und die frühe Beschreibung von JSON
json.org präsentierte JSON als kompakte Notation, abgeleitet von der objektliteralen Syntax von JavaScript, und dokumentierte seine Kernstrukturen mit einer kleinen Grammatik. Diese frühe Beschreibung hat dazu beigetragen, Entwicklern einen gemeinsamen Namen und eine gemeinsame Referenz für Objekte, Arrays, Zeichenfolgen, Zahlen, Boolesche Werte und Nullen zu geben. Es ist sicherer, die Seite als eine frühe öffentliche Erklärung zu bezeichnen, als ohne hier zitierte historische Beweise zu behaupten, dass eine Seite oder Person im Alleingang ein Format entdeckt oder seine Übernahme etabliert hat.
Die aktuellen Repository-Quellen enthalten keinen Archivverlauf von json.org, Browsernutzung oder Ausschussdiskussionen. Sie zeigen, wie diese Anwendung heute JSON analysiert und diagnostiziert. Dementsprechend bleiben die historischen Aussagen in diesem Artikel nah an veralteten Standarddokumenten und vermeiden die Zuschreibung von Motiven oder Markteffekten, die diese lokalen Dateien nicht beweisen können.
RFC 4627 in 2006 – die erste IETF-Beschreibung, der Medientyp application/json und die Regel, dass ein Text ein Objekt oder Array sein muss
RFC 4627, veröffentlicht in 2006, beschrieb JSON für den Internetaustausch und registrierte den Medientyp `application/json`. Seine Definition eines JSON-Textes erforderte ein Objekt oder Array auf der obersten Ebene, obwohl in diesen Containern Zeichenfolgen, Zahlen und Literale als Werte vorhanden waren. Diese Einschränkung ist ein nützlicher historischer Unterschied, da ein Dokument, das nur `"ready"` enthält, in einer späteren Formulierung ein gültiger Wert sein könnte, während es außerhalb der JSON-Textdefinition von RFC 4627 liegt.
In dem Dokument wurden auch Codierungs- und Sicherheitsbedenken im Zusammenhang mit den damals verfügbaren Implementierungen erörtert. Es sollte nicht als Änderungsprotokoll für dieses Repository gelesen werden: ToolAcre enthält keinen RFC-Kompatibilitätsmodus 4627 und sein Parserpfad delegiert die Wertekonstruktion an die Host-JavaScript-Engine.
ECMA-404 in 2013 – Ecmas minimaler reiner Syntaxstandard und warum zwei Organisationen letztendlich ein Format beschrieben
ECMA-404, erstmals veröffentlicht in 2013, spezifiziert die Syntax von JSON in bewusst kompakter Form. Der Schwerpunkt liegt auf der Grammatik gültigen JSON-Textes und nicht auf einem vollständigen Austauschprofil für jede vernetzte Verwendung. Dieser Umfang hilft zu erklären, warum ECMA-404 und die IETF-Dokumente die gleiche Grundnotation beschreiben können, sich aber in den umgebenden Interoperabilitätsleitlinien, die sie betonen, unterscheiden. Die Existenz zweier Normungsgremien bedeutet nicht, dass es im normalen Gebrauch zwei inkompatible Formate gibt.
Behauptungen darüber, warum Organisationen bestimmte Veröffentlichungspfade gewählt haben, erfordern Dokumentationsquellen, die über diese Codebasis hinausgehen. Daher werden in diesem Artikel keine Rückschlüsse auf die Beweggründe des Ausschusses aus den Daten der Standards gezogen. Der relevante praktische Punkt ist, dass RFC 8259 und ECMA-404 auf eine Syntaxangleichung abzielen, während RFC 8259 Empfehlungen liefert, die für den interoperablen Austausch von Bedeutung sind.
RFC 7159 und RFC 8259
RFC 7159 ersetzte RFC 4627 in 2014 und erweiterte die Definition eines JSON-Textes auf jeden serialisierten Wert, wodurch die Regel der obersten Ebene nur für Objekte oder Arrays entfernt wurde. RFC 8259 ersetzte RFC 7159 in 2017 und bleibt die IETF-Referenz, die normalerweise für JSON zitiert wird. Es erfordert UTF-8 für JSON, die zwischen Systemen außerhalb eines geschlossenen Ökosystems ausgetauscht werden, und zeichnet Interoperabilitätswarnungen in Bezug auf Zahlen, doppelte Namen, Unicode und Byte-Order-Markierungen auf, anstatt so zu tun, als ob die Grammatik allein überall identische Ergebnisse garantiert.
Ein `true` der obersten Ebene ist eine kompakte Möglichkeit, die moderne Stammwertregel in ToolAcre einzuhalten, da `JSON.parse` sie akzeptiert. Dieses Ergebnis zeigt das Verhalten dieser Implementierung. Es wird nicht rekonstruiert, wann jeder Browser, Server oder jede API die umfassendere Definition übernommen hat.
Was sich für arbeitende Entwickler geändert hat
Für arbeitende Entwickler sind die klarsten Spezifikationsänderungen die moderne Akzeptanz jedes JSON-Werts im Stammverzeichnis und eine stärkere Anleitung für interoperable Codierung. Die weniger sichtbare Lektion ist, dass eine gültige Syntax immer noch Auswahlmöglichkeiten bei der Implementierung lässt. Doppelte Objektnamen können reduziert werden, die Reihenfolge der Mitglieder ist kein semantischer Vertrag, sehr große Zahlen können an Präzision verlieren und ungewöhnliche Unicode-Sequenzen können sich unterschiedlich durch Bibliotheken bewegen. Ein standardkonformes Dokument kann daher zusätzliche Einschränkungen durch ein Anwendungsschema erfordern.
In diesem Formatierer passieren doppelte Namen und Nummerntoken zunächst `JSON.parse`, sodass die spätere Formatierung den resultierenden JavaScript-Wert und nicht das ursprüngliche lexikalische Dokument widerspiegelt. Der Scanner trägt zur Diagnose nach einem Ausfall bei; Es behält keine doppelten Elemente oder Zahlen mit beliebiger Genauigkeit bei. Dabei handelt es sich um archivgestützte Beobachtungen.
Was dies nicht abdeckt
Was hiervon nicht abgedeckt wird, sind die Spezifikationen, die über JSON liegen. JSON Schema beschreibt Einschränkungen für Dokumentform und -werte; JSON Zeiger adressiert Stellen innerhalb eines Dokuments; JSON Patch stellt Änderungen dar. Sie lösen andere Probleme als die Basisgrammatik und sollten nicht als spätere Versionen von JSON selbst behandelt werden. JSONC, JSON5 und ähnliche Autorenformate erweitern oder ändern auch die akzeptierte Syntax und erfordern ihre eigenen Parser, anstatt stillschweigend in eine strikte Validierung eingebunden zu werden.
In diesem Artikel wird auch eine umfassende gesellschaftliche Geschichte der Einführung von JSON, der Browserunterstützung oder der Konkurrenz mit XML vermieden, da die aufgeführten Repository-Quellen diese Darstellung nicht untermauern können. Es wurden keine externen Zitate erfunden, um diese Lücke zu schließen.
Takeaway: RFC 8259 ist die zu zitierende Referenz
RFC 8259 ist die praktische IETF-Referenz, die für aktuelle JSON-Syntax- und Interoperabilitätsleitfäden herangezogen werden kann, wobei ECMA-404 den angepassten Ecma-Syntaxstandard bereitstellt. RFC 4627 und RFC 7159 bleiben nützlich, um zu verstehen, wie sich die veröffentlichte Definition geändert hat, insbesondere auf der obersten Ebene. Zitieren Sie das Dokument, das die genaue Behauptung stützt, anstatt „die JSON-Spezifikation“ als vagen Appell an die Autorität zu verwenden, und unterscheiden Sie normative Regeln vom Implementierungsverhalten, das in einem bestimmten Parser beobachtet wird.
Für ToolAcre besteht die vertretbare Aussage darin, dass das Repository den Parser und Serialisierer JSON von JavaScript verwendet und einen strengen lokalen Scanner für die Diagnose nach Fehlern hinzufügt. Tests von Werten der obersten Ebene, fehlerhafter Interpunktion und der Handhabung von Zahlen beschreiben diesen Weg; es handelt sich nicht um historische Quellen.