Diskussion:JavaScript Object Notation

message: 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)
thread_title:  Darf ein Weblink auf ein kommerzielles Angebot verweisen? 

message: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Gewagte Aussage 

message: 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)
thread_title:  Ähnlichkeiten 

message: 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)
replies: text: Da sich niemand dazu geäußert hat, habe ich es jetzt einfach mal abgeändert. --Einundachtzig 08:23, 6. Feb. 2007 (CET)
thread_title:  "Dies gilt im Besonderen bei der Entwicklung von desktopähnlichen Anwendungen." 

message: 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)
replies: text:  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)
thread_title:  Character Encoding 

message: 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)
replies: text: Meinungen zur Verschiebung? -- Jowereit 17:48, 20. Nov. 2007 (CET)
replies: text:  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)
thread_title:  Verschiebung des Artikels 

message: "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)
replies: text: Doch, z.B. mit Base64. – Torsten Bronger 17:04, 30. Jan. 2009 (CET)

text: Kann mal jemand den Text überarbeiten? Wozu gibt es  und  --194.138.39.61 11:32, 14. Apr. 2010 (CEST)
thread_title:  Unterschied zu XML 

message: 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)
thread_title:  "Computer-Format" 

message: 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)
thread_title:  Douglas Crockford 

message: 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)
replies: text: 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)
thread_title:  Welcher Content-Type? application/json oder application/jsonrequest 

message: 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)
replies: text: 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)
thread_title:  Plist-Format hat sich in OS X geändert 

message: 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)
thread_title:  XML nicht typisiert? 

message: 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)
replies: text: 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)
thread_title:  JSON vs. AJAX 

message: 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.  
: 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)
thread_title:  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. 

message: Deutsch nicht falsch gut...
Cemaydin~dewiki (Diskussion) 12:23, 21. Dez. 2015 (CET)
thread_title:  "Jedes gültige JSON-Dokument soll ein gültiges JavaScript sein" 

message: 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)
thread_title:  Standards 

message: * 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)
thread_title:  Belegte Byte-Größe 

message: 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)
replies: text: 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)
thread_title:  Array (geordnete Liste) 

message: 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)
thread_title:  Einleitung unvollständig 

message: 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)
thread_title:  ÜA: Abschnitt [[JSON#%C3%84hnliche Techniken]] (erl.) 

message: 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)
thread_title:  alternative formate 

message: "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)
thread_title:  Unverständlich 

message: 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 , 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)
replies: text: 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)
replies: text: 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)
thread_title:  Abschnitt Einschränkungen