Diskussion:JavaScript Object Notation

Darf ein Weblink auf ein kommerzielles Angebot verweisen?

Unter Weblinks ist angegeben:

• JSON und JSON-RPC: Ajax ohne XML Einführungstutorial der iX 01/2006.

Dieser Artikel ist nur noch gegen Bezahlung einzusehen. Sollte ein Wikipedia-Artikel auf ein kommerzielles Angebot verweisen? --Thommy 11:06, 24. Okt. 2009 (CEST)

O.g. Link entfernt und durch JSON als XML-Alternative ersetzt. -- Thommy 21:05, 27. Okt. 2009 (CET)

Gewagte Aussage

Ich halte die Aussage, das XML-Format sei flexibler für etwas gewagt. Theoretisch lässt sich doch auch in JSON alles nachbilden, was XML beherrscht. Oder übersehe ich da was? Frabi 21:24, 18. Jul 2006 (CEST)

Ich habe den Abschnitt ergänzt und den Hinweis eingefügt, dass XML eine Auszeichnungssprache ist, wogegen JSON ein Datenaustauschformat ist. So besser? 80.136.117.124 12:08, 3. Nov. 2006 (CET)

Das ist allerdings auch an den Haaren herbeigezogen. XML kann genauso wie JSON als Datenaustauschformat dienen. z.B. das RSS-Format für Podcasts und Text-Nachrichten. --2003:CE:671A:EF00:FC9A:F3FA:AA6B:F432 09:08, 3. Apr. 2021 (CEST)

Sehr gut! Eine Kleinigkeit habe ich vermisst: Eigenschaftsnamen und Werte werden in " eingeschlossen: Was wenn ein Wert ein " enthält? Nutze ich dann unicode escapes oder gibt es ein anderes Kurzzeichen? (gedoppelte " wie in csv, backslash, aber wie wird dann der literale backslash geschrieben? etc.) Vielleicht noch als kleine side note einfügen? HolgerKrauth 21:24, 21. Jul 2006 (CEST)

Ähnlichkeiten

Das JSON-Format erinnert von der Syntax her sehr stark an die ASCII-Property lists von NeXTStep, GNUstep bzw. Mac OS X. Auf der offiziellen Webseite steht nichts dazu, aber vielleicht weiß jemand, ob es da Zusammenhänge gibt oder diese Ähnlichkeit rein zufällig ist. --Robb der Physiker 12:27, 25. Jul 2006 (CEST)

"Dies gilt im Besonderen bei der Entwicklung von desktopähnlichen Anwendungen."

Ich denke mal hier sind desktopähnliche Web-Anwendungen gemeint?! Ein kleiner aber feiner Unterschied!

80.136.117.124 11:52, 3. Nov. 2006 (CET)

Da sich niemand dazu geäußert hat, habe ich es jetzt einfach mal abgeändert. --Einundachtzig 08:23, 6. Feb. 2007 (CET)

Kategorie hinzugefügt

Habe einfach mal die Kategorie "Datenformate" hinzugefügt (und umgekehrt). Einwände?

Character Encoding

Mindestens 50% der Probleme mit XML sind auf Schwierigkeiten mit dem Character encoding zurückzuführen. Ein simples " " oder ein falsch codiertes Zeichen wie öäüßÁÄČĎÉÍĽĹŇÓÔŔŠŤÚÝŽ machen XML ungültig.

XML und UTF-8 garantieren, dass die Zeichen richtig beim Endverbraucher ankommen. Für den Programmierer wird es allerdings nicht einfacher. Wie das mit JSON gehandelt wird steht nicht im Artikel.

Genau die Programmierer die Probleme mit Character encoding haben verwenden JSON. Das garantiert fast, dass man fehlerhaft encodierte Daten in die Datenbank bekommt. XML meldet genau dann einen Fehler wenn der Fehler zum ersten mal auftritt. Der fehlende UTF-8 check und mangelhafte Validierungsmöglichkeiten sind die größten Nachteile von JSON gegenüber XML. (nicht signierter Beitrag von 212.186.64.225 (Diskussion) 12:29, 8. Jan. 2011 (CET))

Man kann bei der Übertragung allerdings auch das Character-Encoding angeben. Eine entsprechende Option bieten die meisten Programmierschnittstellen. Zudem kann das ENcoding auch über entsprechende HTTP-Header gesteuert werden. Accept: application/json; charset=UTF-8 oder Content-Type: application/json; charset=UTF-8. Inwieweit das von der Programmlogik korrekt interpretiert wird und ob Byte-Streams korrekt in Unicode Character zurückgewandelt werden (UTF-8, UCS-2 und andere Multibyte-Formate), ist natürlich Sache des Programmierers und einer entsprechenden Testabdeckung. Oft ist auch einfach das Encoding der Datenbank falsch oder es wird das falsche Spaltenformat verwendet. RIMOLA (Diskussion) 08:26, 18. Apr. 2013 (CEST)

Der Hauptunterschied beim Encoding ist doch, dass es bei JSON UTF-8 ist, während es bei XML frei gewählt werden kann. Ein nicht-wohlgeformtes XML ist kein XML und ich kann auch ungültiges JSON schreiben. (Die Fehlertoleranz von aktuellen Parserimplementierungen ist doch für die Formbeschreibung uninteressant). Zu JSON / UTF-8 sagt RFC-8259 "JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8" --BTonY (Diskussion) 14:32, 14. Mai 2020 (CEST)

Verschiebung des Artikels

Der Artikel sollte laut den Namenskonventionen eigentlich nach JavaScript Object Notation verschoben werden. Ich habe jedenfalls dort mal einen Redirect auf diese Seite angelegt. -- 217.228.233.247 21:11, 5. Nov. 2007 (CET)

Meinungen zur Verschiebung? -- Jowereit 17:48, 20. Nov. 2007 (CET)

Laut Wikipedia:Namenskonventionen#Abkürzungen sollen Abkürzungen unter dem gebräuchlicherem Namen verfasst werden. Ich denke JSON ist gebräuchlicher als JavaScript Object Notation. --Fomafix 18:12, 20. Nov. 2007 (CET)

Ich sehe das genauso und würde vorschlagen, eine Verschiebung durchzuführen. --MGChecker – (📞| 📝| ) 23:29, 23. Nov. 2024 (CET)

Codebeispiel

Zu folgender Zeile hab ich eine Anmerkung:

"Deckung"  : 1e+6,

Ich tät Geldbeträge nicht unbedingt als Floatingpointzahl angeben ;) --Pythagoras1 (⠙⠊⠎⠉⠥⠎⠎⠊⠕⠝) 22:56, 24. Feb. 2008 (CET)

Ich bin nicht sicher, ob du wirklich "Floatingpointzahl" und nicht eher die Exponentialschreibweise im Beispiel meintest, aber vom Prinzip her ist "1e+6" ja erstmal nur eine Notation. Wie ein Parser diese Angaben interpretiert und ob er sie zu einer Gleitkomma- oder einer Integerzahl auswertet, ist davon ja unabhängig. Darüber hinaus halte ich die Verwendung von Gleitkommazahlen für Beträge für durchaus sinnvoll, da diese ja auch Nachkommastellen enthalten können.

--193.25.183.52 09:48, 8. Dez. 2010 (CET)

Ich denke mit dem Teil wie der Parser das auswertet hast du recht, allerdings impliziert die Angabe durchaus, dass eine Fließkommazahl gemeint ist. Wenn du diesen ganzahligen Betrag (der auch bei 1,50€ noch ganzzahlig ist, denn es sind 150 Cent) binär speicherst kommt es zu Rundungsfehlern.

Unterschied zu XML

"Beide Formate sind nicht unbedingt zum Repräsentieren von großen Binärdatenmengen geeignet."

IMO ist XML überhaupt nicht zum Speichern von Binärdaten benutzbar (laut spec). --Azaël 15:22, 9. Dez. 2008 (CET)

Doch, z.B. mit Base64. – Torsten Bronger 17:04, 30. Jan. 2009 (CET)

Kann mal jemand den Text überarbeiten? Wozu gibt es [1] und [2] --194.138.39.61 11:32, 14. Apr. 2010 (CEST)?

"In der Regel reduziert JSON auch den Overhead im Vergleich zu XML."

Ist das einfach schlechtes Deutsch und soll bedeuten, dass JSON *gleichen* Overhead produziert? Oder fehlt da ein vergleichendes Wort? Weniger? Mehr?

"Computer-Format"

Ist der Ausdruck Computer-Format nicht zu trivial? Müsste es nicht eigentlich eine Formulierung wie beispielsweise Auszeichnungssprache sein?--Stegosaurus Rex 18:06, 28. Apr. 2009 (CEST)

Obwohl der Name auf eine alleinige Verwendung in JavaScript hindeutet...

...stammt die Notation von JavaScript und wurde NICHT extra als Notation zum Datenaustausch entwickelt. Diese Kurzschreibweise zur Definition von Objekten hat es in JavaScript schon immer gegeben. Der Artikel stellt die Syntax jedoch als ein gesondert entwickeltes Format dar. Diese Notation ist ein nativer Bestandteil von JS, andere Sprachen müssen hingegen die Syntax parsen, bevor sie daraus Informationen gewinnen können (wird im Artikel als Schnittstelle bezeichnet). Außerdem kann JSON z. B. in JavaScript direkt mit der eval()-Funktion in ein JavaScript-Objekt umgesetzt werden., es ist durch die Notation bereits ein JavaScript-Objekt. Genauso als ob es in einer JS-Datei oder in den SCRIPT-Tags angegeben worden wäre. --Carminox 03:06, 17. Mai 2009 (CEST)

Die Javascript-Syntax unterscheidet sich in wesentlichen Punkten von JSON. So ist

   {
   "foo": 'bar', // hello!
   baz: 1,
   }

gültiges JavaScript, aber kein gültiges JSON. Die Aussage, dass JSON zum Datenaustausch entwickelt wurde, ist daher zutreffend; man könnte es so formulieren: "Die JSON-Syntax wurde aus der JavaScript-Syntax (durch Einschränkung auf eine Teilmenge) entwickelt." -- 78.42.121.103 18:10, 2. Nov. 2009 (CET)

Douglas Crockford

Der Javascript-Guru sollte im Zusammenhang mit JSON gewürdigt werden. Siehe englische Wikipedia. (nicht signierter Beitrag von 194.180.18.131 (Diskussion) 15:52, 12. Mai 2010 (CEST))

Welcher Content-Type? application/json oder application/jsonrequest

Laut http://datatracker.ietf.org/doc/rfc4627/ ist der korrekte content-type application/json. Jedoch wird auf http://www.json.org/JSONRequest.html application/jsonrequest empfohlen. Weiß jemand, was nun der korrekte content-type ist, bzw kann das in den Artikel eingebaut werden? --91.12.12.207 16:57, 4. Jul. 2010 (CEST)

Auch wenn der Wiki-Artikel es so suggeriert, gibt es noch keinen festen Standard seitens IETF/RFC. RFC4627 war als "informational" und der aktuelle RFC7159 ist als "proposed standard" deklariert. Da aber durch alle Versionen hinweg sich der Content-Type 'application/json' nicht geändert hat, kann man davon ausgehen, dass dieser irgendwann als Standard zählt. --MA-Maddin (Diskussion) 10:42, 24. Mai 2017 (CEST)

Plist-Format hat sich in OS X geändert

bin zu faul, den Artikel zu editieren, aber: NextSTEP bzw. MacOS X kennt eine ähnliche Technik, um einfache Objektbäume zu laden oder zu speichern, sie heißen dort „Property Lists“

Das stimmt nicht mehr, PLists werden inzwischen längst binär gespeichert. (nicht signierter Beitrag von 85.183.51.16 (Diskussion) 16:14, 19. Jul 2010 (CEST))

Standardmäßig schon, aber du kannst diese in XML-Plists umwandeln und die API versteht auch XML-Plists. --Robb der Physiker 13:09, 20. Jul. 2010 (CEST)

XML nicht typisiert?

also wenn ich mir mal DTDs angucke (Document Type Definition) dann finde ich, dass XML (bei Bedarf) um einiges stärker typisiert ist als so einiges was schon als "stark typisiert" bezeichnet wird... (nicht signierter Beitrag von 80.138.12.89 (Diskussion) 23:09, 11. Nov. 2010 (CET))

mit XML Schema ist XML typisiert und unterstützt sogar Vererbungsmechanismen bei Typdefinitionen. Die Aussage (XML sei nicht typisiert) sollte daher aus dem Artikel entfernt werden. (nicht signierter Beitrag von 194.153.147.4 (Diskussion) 10:47, 3. Jan. 2011 (CET))

JSON vs. AJAX

AJAX heisst "Asynchron Javascript AND XML". Das ist eigentlich genau das Gegenteil von JSON. (nicht signierter Beitrag von 212.186.64.225 (Diskussion) 12:29, 8. Jan. 2011 (CET))

Im Laufe der Zeit hat das Akronym "Ajax" seine ursprüngliche Bedeutung verloren und steht nun für beliebige Datenübertragungen via XMLHttpRequest-Objekt. (Und auch dieses Objekt hat einen irreführenden Namen, das wird aber in http://www.w3.org/TR/XMLHttpRequest/#introduction geklärt.) --217.24.207.26 17:32, 6. Jul. 2011 (CEST)

Eindeutigkeit von Schlüsseln?

Müssen Schlüssel in einem Objekt eindeutig sein? Kurzum: Ist sowas erlaubt?

{
   "foo":"bar",
   "foo":"yuk",
   "foo":"bar",
   "foo":42
}

Wenn ja: Kommen damit auch alle JSON-Bibliotheken mit zurecht? --RokerHRO 19:17, 21. Feb. 2011 (CET)

Der Schlüssel ist doch eindeutig ("foo"). Lt. ECMA (http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf , Anmerkung oberhalb 15.12.3) ist das obige Beispiel erlaubt. Dem Schlüssel "foo" sollte der Wert 42 zugewiesen sein. Ob damit alle Bibliotheken zurechtkommen kann ich nicht beantworten, Javascript schon. Pmatu 22:54, 23. Feb. 2011 (CET)

Naja, mit "eindeutig" meinte ich, dass dem Schlüssel "foo" nur ein Wert eindeutig zugeordnet wird. Im Übrigen ist JSON zwar legales JavaScript, aber JSON ist deutlich strenger als JavaScript, wenns darum geht, welche Konstrukte erlaubt sind und welche nicht. Hier geht es um JSON, nicht um JavaScript. --RokerHRO 23:41, 24. Feb. 2011 (CET)

Der Punkt 15.12 von ECMA-262 (s. Link oben) behandelt genau das "JavaScript Object Notation" (JSON) - Objekt. JSON ist nun mal aus den ECMA-Standards abgeleitet http://www.ietf.org/rfc/rfc4627.txt und dort auch (s. Link oben) spezifiziert. << Pmatu 14:45, 25. Feb. 2011 (CET)

Das RFC Dokument meint (Teilweise im Gegensatz zum ECMA Dokument) dazu, dass das Verhalten der Parser in diesem Fall unvorhersehbar ist. Auch wenn viele Parser die letzte Angabe (wie oben beschrieben) zurückgeben, so kann man doch nicht erwarten dass das bei allen der Fall sein wird. Das bedeutet, dass so eine Struktur zwar zulässig ist, aber nicht eindeutig interpretiert wird.

Der RFC besagt, es SOLLTE ("SHOULD") eindeutig sein. Bei EMCA-404 steht leider gar nix. Das führt zu echten Problemen, siehe https://justi.cz/security/2017/11/14/couchdb-rce-npm.html . Daher ändere ich den Text jetzt ab

Vergleich XML/JSON

Der Vergleich in seiner derzeitigen Form hinkt. XML ist mächtiger, da jeder Knoten sowohl Attribute als auch Kinder haben kann. Die Kinder wiederum können Textknoten sein. Man kann sich das leicht klarmachen, wenn man versucht, dieses XML-Dokument in JSON zu "konvertieren".

<tag foo="test"><foo>test</foo>foo=test</tag>

Es geht einfach nicht ohne Informationsverlust. Also bitte nicht Äpfel mit Birnen vergleichen! Außerdem wird im Beispiel der Unterschied zwischen <foo>true</foo> und <foo/> nicht beachtet (im JSON sind ja ebenfalls "true" und true unterschiedliche Dinge) --217.24.207.26 17:14, 6. Jul. 2011 (CEST)

Prinzipell kann man jedes XML-Dokument in eine äquivalente JSON-Struktur umwandeln und wieder zurück.

Beispielsweise so:

XML	JSON
<tagname/>	{ "name":"tagname" }
<tagname>	{ "name":"tagname"
</tagname>	}
<tagname foo="bar">	{ "name":"tagname", "attr"={"foo":"bar"}
<tagname> something </tagname>	{ "name":"tagname" "content":"something" }

Im Allgemeinen will man sowas aber nicht, sondern verwendet JSON so, dass möglichst wenig redundante Informationen übertragen werden. --RokerHRO 11:43, 7. Jul. 2011 (CEST)

Stimmt, mit zusätzlichen Magic Keys ist natürlich eine äquivalente Umwandlung möglich. Wenn man das auf obiges Beispiel anwendet, würde das äquivalente JSON also so aussehen:

{"name":"tag","attr":{"foo":"test"},"content":[{"name":"foo","content":"test"},"foo=test"]}

Macht also 91 Bytes im Vergleich zu 45 bei XML. Auch wenn man die Schlüsselwörter durch einbuchstabige ersetzt, bleiben 70 Bytes übrig:

{"n":"tag","a":{"foo":"test"},"c":[{"n":"foo","c":"test"},"foo=test"]}

Die Aussage, JSON sei leichtgewichtiger als XML ist im allgemeinen also falsch. --217.24.207.26 14:47, 13. Jul. 2011 (CEST)

Moment mal! Es ging hier in diesem Abschnitt nur um die Behauptung, JSON sei weniger mächtig als XML. Und ich habe gezeigt, dass JSON zu XML gleich mächtig ist, wenn man das unbedingt will. Daher das etwas pathologische JSON-Format.

 

Was die Größe der Darstellung angeht:
Im Allgemeinen setzt man aber JSON an Stellen ein, wo der Empfänger weiß, welche Datentypen die übertragenenen Daten haben, und man muss sie daher nicht über derartige Krücken mit übertragen, wie ich sie oben angab. Und in all diesen Fällen wird eben nur ein { … } als Objektbegrenzer genommen, statt eines <typname> … </typname> usw.

Man kann das sogar noch weitertreiben, indem sich Sender und Empfänger auf die Reihenfolge der Objekt-Member einigen, dann kann man das Objekt als Array übertragen und es wird noch kompakter. Allerdings ändert man dann auch die Semantik. Ich würde das zwar nicht tun, da ich in den Fällen, wo man derart auf Größe optimieren müsste, wohl eher ein Binärprotokoll wie XDR oder ASN.1 PER so nehmen würde. Aber manchmal ist ja das Protokoll vorgegeben, nicht aber der Inhalt…

--RokerHRO 10:13, 14. Jul. 2011 (CEST)

Selbstverständlich lässt sich mit JSON die gleiche Information speichern wie mit XML (Wenns gar nicht anders geht, nimmt man halt

{"xml":"<foo>...</foo>"}

, bzw.

<json><[!CDATA[{...}]]></json>

). Das bedeutet aber nicht, dass die beiden Formate gleich mächtig sind. Es geht ja darum, die vorhandenen Strukturen zu nutzen, und nicht zu missbrauchen. Meines Erachtens ist die Größe der resultierenden Daten ein guter Indikator hierfür. Wenn ichs mir genauer überlege, gibt es umgekehrt auch JSON-Konstrukte, die nur mit Trickserei in XML gespeichert werden können, z.B. so verrückte Sachen wie

{"":null, "":"", "<": false}

.

In der Praxis benutze ich gerne JSON und bin davon überzeugt, dass es für viele Anwendungen die richtige Wahl ist. Ich will aber darauf hinaus, dass die beiden Formate nicht, wie der Artikel suggeriert, kompatibel sind. (Und somit sind JSON/XML-Konvertierer meist sehr fragwürdig) --95.113.9.29 21:36, 14. Jul. 2011 (CEST)

Soweit ich das überblicke ist die Problematik der Konvertierung von XML nach JSON und umgekehrt, eine ähnliche wie sie auch schon vor vielen Jahren in den diversen XML-Binding Frameworks wie JAXB für Java behandelt wurde. Mir erscheint JSON letztlich nicht anderes wie ein JAVA Bean Hierarchie nur halt für JavaScript. Und die Dokumentation von JAXB z.B. zeigt deutlich, dass es sich bei Java Beans (so auch JSON) und XML bei weitem nicht um äquivalente (einfach ineinander umwandelbare) Datenstrukturen handelt, wie dieser Artikel über JSON suggeriert. Ich plädiere daher, siehe auch meinen Kommentar zum Abschnitt "Ersatz für XML in Bereiche..." weiter unten, für eine Steichung bzw. Überarbeitung des Vergleichs von XML und JSON in diesem Artikel. ArchibaldWagner (Diskussion) 22:12, 15. Jun. 2014 (CEST)

Der Abschnitt ist aus meiner Sicht ziemlich einseitig. Zwar lässt sich jedes JSON fast (!) verlustfrei nach XML konvertieren, ein Beispiel ist json-to-xml im XSLT 3.0 Standard, andersherum ist es aber auf alle Fälle nicht so leicht möglich. Was mir spontan an Unterschieden in Bezug auf Flexibiltät, Mächtigkeit etc, einfällt, ist Character Encoding, XInclude, XML Namespaces, Darstellung binärer Daten --BTonY (Diskussion) 14:32, 14. Mai 2020 (CEST)

Ersatz für XML in Bereichen, wo Ressourcen (Speicherplatz, CPU-Leistung) sparsam eingesetzt werden sollen. Dies gilt im Besonderen bei der Entwicklung von desktopähnlichen Webanwendungen.

Der Satz ist einfach nur Mist. Firefox/Chrome fressen hunderte an MiByte an RAM für Webapplikationen. Die ganze Webseite ist ohnehin schon als DOM verfügbar. Da man manchmal noch ein JSON Parser benötigt ist die Chance grösser das man mit JSON sogar mehr Speicherverbrauch haben könnte als wenn ma XML verwendet. Die ganze Aussage würde ich löschen oder mit Fakten belegen. (nicht signierter Beitrag von 83.76.206.239 (Diskussion) 11:35, 15. Apr. 2012‎)

Diese Forderung zur Entfernung dieses Satzes unterstütze ich voll und ganz. Und weiter der ganze Artikel über JSON ist mir zu einseitig, also nicht neutral, was den Vergleich von XML und JSON angeht. Er erscheint mir zu sehr aus dem Blickwinkel eines Java-Script Webanwendungs-Entwicklers geschrieben zu sein. Der Artikel in der englichen Wikipedia ist deutlich besser. Der Absatz über den Vergleich von JSON und XML gehört entweder ganz entfernt oder zumindest die subjektiven Wertungen müssen entfernt werden. Zum Vergleich von XML und JSON empfehle ich die folgenden Referenzen

• analysis_of_json_use_cases
• json-and-xml-comparison

sorgfältig zu lesen.

Auch die Aussage, dass XML nicht typisiert sei, gibt dem Leser ein falsches Bild (ich hoffe, das ist keine Absicht), denn mit XML-Schema können sehr flexibel Bedingungen für eine XML-Datei gesetzt werden, die XML sehr sicher machen und meines Wissen deutlich weiter gehen wie die Java-Script Typsierung von JSON. Diese Flexibilität ist bei JSON meines Wissens nicht gegeben.

Sicher gibt es Vorteile von JSON, wenn grössere verschachtelte Datenfelder zu übertragen sind und diese mit Java-Script bearbeitet werden sollen (wofür XML ja auch nie vorgesehen war), aber wo gibt es für JSON so etwas wie das mächtige XPATH, um schnell auf bestimmte Knoten des Objekt-Baumes zu zugreifen. Außerdem fehlt mir in JSON so etwas wie die funktionale Programmierung mit Templates wie in XSLT, die in vielen Fällen komplexe Schleifenprogrammierung überflüssig machen. Und überhaupt wie ist das mit den Namensräumen in JSON? Wie kann ich mit JSON Inhalt und Darstellung so gut trennen wie mit XML, XSLT und CSS? Außerdem werden die meisten Inhalte im WEB mit html, was xml irgendwie ähnlich ist - besser wäre eh xhtml, übertragen, trotz der angeblichen Ressourcenverschwendung.

Ich denke dieser Artikel gehört gründlich überarbeitet. ArchibaldWagner (Diskussion) 22:15, 14. Jun. 2014 (CEST)

"Jedes gültige JSON-Dokument soll ein gültiges JavaScript sein"

Deutsch nicht falsch gut... Cemaydin~dewiki (Diskussion) 12:23, 21. Dez. 2015 (CET)

Standards

zwei konkurrierende Standards spezifiziert, RFC 7159[2] von Douglas Crockford und ECMA-404. so steht es in der Einleitung wird aber später nie thematisiert -- A1000 (Diskussion) 15:59, 21. Mär. 2016 (CET)

Belegte Byte-Größe

• Nach Entfernung der optionalen Leerzeichen ist das JSON-Objekt 226 Byte, das XML-Objekt 279 Byte groß - ein Zuwachs um 23 %. Oftmals können Attribute auch als Kindknoten formuliert werden, das Beispiel könnte dann wie folgt aussehen:

Auch wenn die zugrunde liegende Aussage stimmt, dass XML mehr Overhead prodziert, sollte man in diesem Beispiel zumindest erwähnen, dass in dem XML-Beispiel mit dem Tag "Kreditkarte" auch eine zusatzliche Information hinzugefügt wurde. Anderenfalls kann man die Kreditkarteninformation natürlich auch dem JSON-Beispiel hinzufügen. (nicht signierter Beitrag von Baschtie (Diskussion | Beiträge) 13:18, 9. Aug. 2016 (CEST))

In obigem Text sollte "279" durch "281" und "23 %" durch "24 %" ersetzt werden. (Beim Weglassen der optionalen Leerzeichen verbleiben 2 Leerzeichen, und zwar zwischen "Kreditkarte" und "Herausgeber" und zwischen "Inhaber" und "Name".) (nicht signierter Beitrag von 2001:871:5A:3343:A4A7:6073:6F71:7E3C (Diskussion) 23:42, 28. Jan. 2021 (CET))

Unterschied zu YAML

In Absatz "Ähnliche Techniken" steht der Satz "Allerdings ist YAML eine Markup-Sprache zur reinen Serialisierung und in keiner Sprache gültiger Code."

Das klingt erstmal wie ein Nachteil, da JSON aber sowieso nicht mittels eval ausgewertet werden sollte, ist dies kein interessanter Unterschied. Er zeigt höchstens welche Historie die beiden Formate haben. (nicht signierter Beitrag von 78.51.131.177 (Diskussion) 19:26, 25. Mär. 2017 (CET))

Ich habe den entsprechenden Teil entfernt. Wenn ihn jemand drin haben möchte, müsste er verständlich formuliert werden. --Trustable (Diskussion) 15:56, 18. Apr. 2017 (CEST)

Immerhin bedeutet „in keiner Sprache gültiger Code“ ganz nebenher auch: mit syntaktisch falschem Inhalt („irrtümlicher Interpretationsversuch“ – irrtümlich? Oder gewollt?): kein unauffälliges XSS, ob nun im Vorbeigehen oder mühevoll versteckt! (nicht signierter Beitrag von 93.229.109.243 (Diskussion) 13:19, 14. Dez. 2023 (CET))

Array (geordnete Liste)

Unter der Beschreibung "Array" steht, das es sich um eine geordnete Liste handelt. In RFC 7159 ist davon nichts zu Lesen. In ECMA-404 steht stattdessen, die Reihenfolge ist "signifikant". Das würde ich mit "wichtig" und nicht mit geordnet übersetzen. Als "geordnet" würde ich eine sortierte Liste ansehen. Alle von mir gefundenen Beispiele enthalten aber ungeordnete Listen. --Wodrich (Diskussion) 17:20, 15. Apr. 2017 (CEST)

Zitat aus dem RFC: "An array is an ordered sequence of zero or more values." Ich verstehe geordnet so, dass die Reihenfolge der Array-Elemente wichtig ist und diese an Hand ihres Index geordnet sind. --Robb der Physiker (Diskussion) 14:54, 18. Apr. 2017 (CEST)

Einleitung unvollständig

Ich hatte von JSON nie was gehört (glaube ich), bin damit grad das erste Mal konfrontiert worden, wollte wissen, was das ist, habe hier nachgeschlagen, und weiß genauso wenig wie zuvor... Ganz grundsätzlich, was ist das? Diese Info sollte eine Einleitung doch schon hergeben... Ich habe gerade auf einer Internetseite ein Formular ausgefüllt, auf Senden geklickt, und dann kam eine Seite mit Systeminfos und oben rechts stand JSON. Was jemanden wie mich dann interessiert, ist in allererster Linie, ob das ein Fehler auf meinem System oder auf dem Server ist. Also ist JSON auf meinem PC installiert oder ein Bestandteil meines Browsers, oder aber ist das auf dem Server installiert, auf dem die Formularseite liegt? Wie so oft, wenn bei der Google-Suche ein Link einer genau passenden Wikipedia-Seite mit aufgeführt wird, und ich mir die Info dort holen will, habe ich sie auch diesmal nicht gefunden und werde weiter suchen müssen. Bin da bestimmt nicht der einzige... --Zopp (Diskussion) 12:37, 18. Jul. 2018 (CEST)

GeoJSON

Wieso ist hier GeoJSON nicht erwähnt und kurz der Unterschied beschrieben? Gruss, --Markus (Diskussion) 07:23, 6. Sep. 2018 (CEST)

Wahrscheinlich, weil es noch niemand reingeschrieben hat. :-D

Ob allerdings jedes x-beliebige Datenformat, das auf JSON basiert, hier erwähnt werden muss, weiß ich nicht. --RokerHRO (Diskussion) 16:32, 9. Sep. 2018 (CEST)

Vielleicht findet sich ja noch jemand, der wenigstens GeoJSON ergänzt :-) Gruss, --Markus (Diskussion) 17:02, 25. Okt. 2018 (CEST)

ÜA: Abschnitt JSON#Ähnliche Techniken (erl.)

Der Satz „Diese sind entweder als XML, als kompaktes Binärformat oder als ASCII bzw. UTF-8 kodiert.“ verwurstet Dinge unterschiedlichen Typus', wie eine Auszeichnungssprache, ein Datenformat und Zeichenkodierungen, zu einem „kodiert“. Auf der Seite, die das als Quelle belegen soll, ist auch weder „binary“ noch „UTF-8“ zu finden. Da ich über Apple's Property Lists zu wenig Bescheid weiß, lasse ich das mal mit Vorbehalt so stehen, wobei die "Verwurstung" auf alle Fälle ein Unding ist. --Geri, ✉  23:11, 19. Sep. 2019 (CEST)

Mime-Type inkonsistent

Warum hat JSON eigentlich den Mime-Type application/json und nicht text/json? JSON ist immer eine lesbare Textdatei wie auch text/html. Da es kein Binärformat ist, für das ein spezielles Programm notwendig wäre, ist es inkonsistent hier application als Präfix zu wählen. Ähnliches könnte für JavaScript gelten, allerdings ist JavaScript zur Ausführung bestimmt, was bei reinem JSON (kein JSON-P) nicht der Fall ist. --2003:CE:671A:EF00:FC9A:F3FA:AA6B:F432 09:06, 3. Apr. 2021 (CEST)

Hm, application/json ist in RFC 4627 relativ kommentarlos definiert. Allerdings gibt es z.B. auch application/xhtml+xml und das ist ja auch „text“. --Robb der Physiker (Diskussion) 11:03, 18. Nov. 2022 (CET)

Über ein halbes Jahr nach der IP.

Das MIME-Konzept ging seit den 1990er Jahren krumme Wege, und nicht immer war alles restlos konsistent.

Aber der Teil vor dem Schrägstrich soll das vorgeben, was hinterher bei rumkommt.

• Ein text/ soll einen Text in menschlicher Sprache liefern. Auch ein HTML-Dokument ist allgemein ein Text, auch wenn vielleicht illustriert und nur Bildchen dargestellt.
• image/svg+xml soll ein Bildchen liefern; und zwar unabhängig davon, dass SVG immer eine lesbare Textdatei ist. Es geht also nicht um das Quelltextformat, sondern um das Ergebnis.

Ursprünglich hieß es noch text/javascript, aber das ist mittlerweile obsolet, weil application/javascript anzeigt, dass das Ergebnis nur durch ein Anwendungsprogramm auszuwerten wäre. So auch mit einem allgemeinen Datenobjekt.

VG --PerfektesChaos 17:38, 18. Nov. 2022 (CET)

alternative formate

gudn tach!
alternative formate sollten nur dann aufgefuehrt werden, wenn sie entweder auch zahlreich verwendet werden oder wenigstens in akademischen kreisen stark rezipiert werden. insofern sollte sowas wie "simple markup language", was quasi nirgends beachtet wird, auch nicht bei uns erwaehnt werden. -- seth 16:01, 4. Sep. 2021 (CEST)

Unverständlich

"Nicht signifikante Leerraum-Zeichen sind verwendbar" - was ist nicht signifikant? Was will der Satz überhaupt mitteilen? Wäre es nicht ein leichtes die Whitespace-Chars aufzuführen, die erlaubt sind? -- Amtiss, SNAFU ? 17:42, 8. Nov. 2022 (CET)

Dieser Abschnitt kann archiviert werden. Amtiss, SNAFU ? 17:51, 8. Nov. 2022 (CET)

Abschnitt Einschränkungen

Der Abschnitt bezieht sich scheinbar auf irgendeine JSON-Bibliothek/-Funktion, sagt aber nicht welche und ist nicht bequellt.

Es ist nicht generell der Fall oder erforderlich, dass Infinity/NaN als null gespeichert wird, viele Parser verletzen (optional) den Standard und erlauben die Spezialwerte direkt im JSON [3], alternativ könnte man sie auch in einen String verpacken. Der JSON-Standard gibt jedenfalls nicht direkt vor wie Datumswerte oder Funktionen zu serialisieren sind, sondern sagt nur, dass es eben kein direktes Format dafür im JSON-Standard gibt, so dass man diese halt irgendwie z. B. als Text oder Zahl speichern muss. -- Jonathan 10:43, 16. Feb. 2023 (CET)

Hallo Jonathan, nachdem ich deine Begründung gelesen habe, erscheint mir das Entfernen des Abschnitts zunächst angebracht. Zuerst war mir aufgefallen, dass allgemein bekannte Mängel (die NaN-Sache war mir z.B. bekannt) schon benannt werden sollten, aber klar: Es fehlte, in welchen Implementierungen diese auftreten. Die Einfügung des Abschnitts geschah am 26. Juni 2013 durch MovGP0, von dem wir Beiträge bis Dezember 2022 sehen. Ihn sollte man sicherlich zur Diskussion einladen und vermutlich wäre er bereit, die Angaben durch zusätzliche Informationen und Quellen zu ergänzen. Grüße --Uncopy (Diskussion) 11:22, 10. Mai 2023 (CEST) PS: done --Uncopy (Diskussion) 11:29, 10. Mai 2023 (CEST)

Danke für das Ansprechen des Benutzers. Ich halte es ebenfalls für sinnvoll die Limitierungen aufzuführen, aber eben ohne (in der Allgemeinheit) falsche Behauptungen. Ich erstelle gleich mal einen Entwurf. -- Jonathan 09:34, 21. Mai 2023 (CEST)

„Vergleich mit XML“

Wenn ich jetzt nur wüßte, was da verglichen wird. Äpfel mit Äpfeln, wie mir scheint. Oder, soll es so sein, XML mit XML. Und wie da vergleichend gezählt wird („prozentuale Zunahme(!) durch ein Entfernen?) … Klar, die Delimiter sind in JSON identisch mit XML. Oder wie? (nicht signierter Beitrag von 93.229.109.243 (Diskussion) 13:10, 14. Dez. 2023 (CET))