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:

Zitat von Codehunter (Beitrag 1481393)

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:

Zitat von mjustin (Beitrag 1481397)

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"}
  ]
}

Delphi-Quellcode:

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

(XML)

Code:

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

Delphi-Quellcode:

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:

Zitat von Uwe Raabe (Beitrag 1481400)

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

Aber klar doch, Application/JSON

Zitat:

Zitat von mjustin (Beitrag 1481397)

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 :evil:

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:

Zitat von mjustin (Beitrag 1481397)

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

Delphi-Quellcode:

true

und

Delphi-Quellcode:

false

, sowie

Delphi-Quellcode:

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.

[Codehunter]

Zitat:

Zitat von himitsu (Beitrag 1481417)

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.

Ja da muss man höllisch aufpassen. Wenn dort C-kompatible Vergleiche geschehen, dann gilt:

(links Client-Request, rechts Server)
true=true
false=false
"true"=true
"false"=true
0=false
1=true
>1=true

[himitsu]

0=false
"0"=true

Ja, wenn man den "Stringinhalt" nicht interpretiert, dann
* ein leerer String ist

Delphi-Quellcode:

0

* ein String mit irgendwas drin, der ist ungleich

Delphi-Quellcode:

0

* und alles ungleich

Delphi-Quellcode:

0

(C=null, D=nil) ist

Delphi-Quellcode:

true

(da wird quasi einfach alles hart nach Integer gecastet und =0 ist false, sowie <>0 wird true)

[Neutral General]

Zitat:

Zitat von Codehunter (Beitrag 1481414)

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.

Du kannst aber nicht einfach casten wie du willst. Entweder steckt hinter dem Wert ein TJSONString oder es steckt dahinter ein TJSONBool. Du kannst kein TJSONValue das tatsächlich ein TJSONString ist nach TJSONBool casten ohne dass dir ggf. was um die Ohren fliegt!

Und zu der original Frage:

Ich hab ehrlich gesagt jetzt nicht in einer Spezifikation nachgeschaut aber meinem Verständnis nach ist

"True"

gültiges JSON. Es ist ein einzelner Json-String.

true

wäre auch gültig und wäre ein einzelner Json-Bool.

[Der schöne Günther]

Ich handhabe es ehrlich gesagt genauso, und hatte so auch noch nie Probleme beim Zusammenspiel von Delphis System.JSON und JSON-Bibliotheken für andere Sprachen, z.B. jsoncpp:

1. "true" ist ein String
2. true ist ein Boolean
3. [true] ist ein Array mit einem Boolean drin
4. usw.

[Codehunter]

Ich habe den Parser jetzt dahingehend angepasst, dass man mit einem XPath "/" ein Rootelement ohne Objektstruktur als Wert ansprechen kann.

Davon unabhängig ist das Lesen von Bool-Strings mit TJSONObject dennoch seltsam:

Delphi-Quellcode:

if ParseJSONValue('"true"') is TJSONBool then ... // Ergibt ein JA

Womit immer noch nicht geklärt ist, wie der Parser hier eigentlich Strings von Bools unterscheidet.

Umgekehrt erzeugt er bei mir aber auch bei

Delphi-Quellcode:

(JSONValue as TJSONBool).AsBoolen := True

den String

Code:

"true"

Also mit Anführungszeichen. Das macht mich jetzt echt knülle weil ich nicht weiß was die Serverparser draus machen :shock: Ich hab da bisher nicht drauf geachtet... :pale:

[Neutral General]

Boolean Werte haben in JSON keine Anführungszeichen. Wenn der Server "true" schickt ist das technisch ein String. Was die Anwendung damit macht ist ne andere Sache.
"true" in einer JSON-Klasse als Boolean zu werten halte ich für falsch.

Was du da schreibst kann ich übrigens nicht nachvollziehen:

Delphi-Quellcode:

procedure TForm4.FormCreate(Sender: TObject);
var val: TJSONValue;
begin
  val := TJSONObject.ParseJSONValue('"true"');
  Caption := val.ClassName;
end;

val ist in dem Fall ein TJSONString, kein TJSONBool.

[Codehunter]

Ich muss das Montag mal in Ruhe durchgehen. Eben noch mal kurz mit der 10.3 CE getestet, da verhält sich das auch anders. Irgendwas stimmt mit dem TJSONObject-Parser in meinem dienstlichen 10.2.3 Pro nicht. Jetzt ist aber erst mal Wochenende :lol: