Ist "true" valides JSON?

[Codehunter]

Hallo!

Das ist mal wieder eine Frage wo mir einfach kein gescheiter Titel eingefallen ist ^^

Ein REST-Server antwortet mir bei einem Request mit "true" im Response Body. Also nur diese vier Buchstaben, ohne jeglichen weiteren Markup. Wenn ich das so mit TJSONObject.ParseJSONValue() lade, gibt es mir ein TJSONBool-Objekt zurück. Jetzt frage ich mich, ob das "true" als solches überhaupt valides JSON ist oder ob ParseJSONValue() in dem Fall nicht Nil zurück geben müsste.

Grüße
Cody

[mkinzler]

https://www.json-buddy.com/json-vali...-line-tool.htm

[himitsu]

Ja.

Also für sich alleine ist es schon valide. (aber nur komplett kleingeschrieben)
https://www.json.org/json-en.html

Da die viele JSON-Reader als "root" ein Objekt haben wollen .... aber dennoch ja


Und wer nicht erst was downloaden will, da gibt es auch Mehreres:
json online

[mjustin]

Laut Spezifikation auf https://www.json.org/json-en.html ist true (nur diese vier Buchstaben) nicht valide. Valide ist z.B. "true".
Die Validierung z.B. auf https://jsonformatter.curiousconcept.com/# mit den dort verfügbaren vier verschiedenen Spezifikationen liefern jedoch interessante, unterschiedliche Ergebnisse

Update:
sorry, true ist ein valider boolean Wert, ich hatte die Doku zur McKeeman Form nicht gelesen. "true" ist auch valide, aber als String, nicht boolean.

[Uwe Raabe]

Zitat von Codehunter:

Ein REST-Server antwortet mir bei einem Request mit "true" im Response Body.

Gibt der Client im Accept denn auch an, dass er JSON haben möchte?

[venice2]

Zitat von mjustin:

mit den dort verfügbaren vier verschiedenen Spezifikationen liefern jedoch interessante, unterschiedliche Ergebnisse

Das ist doch in Delphi so gegeben der Compiler erkennt bzw. akzeptiert doch so oder so nicht die NORM..

Er versteht nicht das
If x <> 0 then -> if x then ein und das gleiche ist.
Wie soll er dann so etwas verstehen.

[Codehunter]

Wieder was gelernt! Den Fall muss ich dann entsprechend behandeln in meinem Parser. Gibt es noch mehr solche Spezialfälle? Zum Teil geben die REST-Server ja die wildesten Sachen aus, manchmal sind nicht alle Fehlerzustände abgefangen und der Server würgt nur eine Standard-HTML-Fehlerseite hervor

Ich wünschte ich könnte meinen Parser mal veröffentlichen. Geht aber leider nicht, weil Auftragsarbeit. Das Ding stellt INI, JSON und XML auf eine gemeinsame Objektbasis und lässt sich mit XPath lesen und schreiben:

(INI)

Code:

[mysection]
myvalue1=Foo
myvalue2=Bar

Delphi-Quellcode:

Document['mysection/myvalue1'].AsString {= 'Foo'} {oder}
Document['mysection/[1]'].AsString {= 'Bar'}

(JSON)

Code:

{
  "objarray": [
    {"stringobj":"Foo"},
    {"stringobj":"Bar"}
  ]
}

Document['objarray[0]/stringobj'].AsString {= 'Foo'}

(XML)

Code:

<root>
  <mygroup>
    <myvalue>Foo</myvalue>
    <myvalue>Bar</myvalue>
  </mygroup>
</root>

Document['mygroup/myvalue[1]'].AsString {= 'Bar'}

Das Ziel war, den Export-Code nur einmal zu schreiben und dann je nach gewähltem Dateiformat nur die Parserklasse zu tauschen. Weil das aber so einfach zu benutzen ist, kommt es inzwischen auch im REST-Frontend zum Einsatz und da hab ich es immer wieder mit wilden Konstrukten zu tun die damals im Parser nicht berücksichtigt wurden.

Zitat von Uwe Raabe:

Gibt der Client im Accept denn auch an, dass er JSON haben möchte?

Aber klar doch, Application/JSON

Zitat von mjustin:

Laut Spezifikation auf https://www.json.org/json-en.html ist true (nur diese vier Buchstaben) nicht valide. Valide ist z.B. "true".

Genau, das wäre auch meine Denke gewesen. Aber ich habe an anderer Stelle auch Responses wie {"myobject":true} die ebenfalls von TJSONObject klaglos verdaut werden obwohl ich das nur so kenne: {"myobject":"true"}

[DeddyH]

Ich kenne true oder false nur unquoted, laut https://json-schema.org/understandin...e/boolean.html ist das auch richtig so (wie will man das auch sonst von einem String unterscheiden?).

[Codehunter]

Wenn man auf https://jsonformatter.curiousconcept.com/# vertrauen möchte, wäre es nach RFC8259 und RFC7159 in beiden Schreibweisen valide, nach RFC4627 und ECMA404 keine von beiden. Immer wieder schön wenn die Standards so eindeutig sind

Bei TJSONObject ist mir ehrlich gesagt völlig egal, ob es als String oder Bool interpretiert wird. Ich caste das einfach nach Bedarf von TJSONValue nach TJSONString oder TJSONBool.

Wenn man annimmt, dass JSON aus Javascript heraus entstanden ist und das dortige Objektmodell widerspiegelt, dann wäre es einleuchtend dass Bools ohne Anführungszeichen notiert werden. Aber die Ausgangsfrage war ja, ob ein simples "true" als gesamter JSON-Body valide ist oder nicht. Denn spinnt man den Gedanken weiter, dann dürfte in so einem Fall auch kein TJSONBool heraus kommen sondern es müsste ein simpler Boolean sein (Objekt vs. einfacher Typ)

[himitsu]

Zitat von mjustin:

Laut Spezifikation auf https://www.json.org/json-en.html ist true (nur diese vier Buchstaben) nicht valide. Valide ist z.B. "true".
Die Validierung z.B. auf https://jsonformatter.curiousconcept.com/# mit den dort verfügbaren vier verschiedenen Spezifikationen liefern jedoch interessante, unterschiedliche Ergebnisse

Update:
sorry, true ist ein valider boolean Wert, ich hatte die Doku zur McKeeman Form nicht gelesen. "true" ist auch valide, aber als String, nicht boolean.

Jupp, bezüglich der Spezifikation von JSON ist true und false , sowie null valide.

Was die Spezifikation der Schnittstelle des Servers betrifft, da kommt es drauf an, was sie für "Daten" erwartet.
Da kann es auch sein, dass sie einen String verlangt, in dem die Textrepresentation einen booleanischen Wertes vorliegt.