Diskussion:JavaScript Object Notation

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Darf ein Weblink auf ein kommerzielles Angebot verweisen?[Quelltext bearbeiten]

Unter Weblinks ist angegeben:

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[Quelltext bearbeiten]

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)

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[Quelltext bearbeiten]

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."[Quelltext bearbeiten]

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[Quelltext bearbeiten]

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

Character Encoding[Quelltext bearbeiten]

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)

Verschiebung des Artikels[Quelltext bearbeiten]

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)

Codebeispiel[Quelltext bearbeiten]

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[Quelltext bearbeiten]

"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"[Quelltext bearbeiten]

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...[Quelltext bearbeiten]

...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[Quelltext bearbeiten]

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[Quelltext bearbeiten]

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[Quelltext bearbeiten]

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?[Quelltext bearbeiten]

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[Quelltext bearbeiten]

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?[Quelltext bearbeiten]

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[Quelltext bearbeiten]

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)

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.[Quelltext bearbeiten]

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
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"[Quelltext bearbeiten]

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


Standards[Quelltext bearbeiten]

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[Quelltext bearbeiten]

  • 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))

Unterschied zu YAML[Quelltext bearbeiten]

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)

Array (geordnete Liste)[Quelltext bearbeiten]

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)