TJson.Format und Umlaute

[Schokohase]

Zur Ausgangsfrage zurück:

Zitat von Codehunter:

Aber wie bekomme ich ein korrekt UTF8-kodiertes und formatiertes JSON zusammen?

ganz einfach mit

Delphi-Quellcode:

procedure p();
var
   jsonObject: TJSONObject;
begin
   jsonObject := TJsonObject.Create();
   jsonObject.AddPair('text', 'Straße');

   Writeln( jsonObject.ToString() ); // unformatiert
   WriteLn( Rest.Json.TJson.Format(jsonObject) ); // formatiert
end;

ergibt

Code:

{"text":"Straße"}
{
  "text":"Straße"
}

Um davon jetzt eine UTF8 kodierte Bytefolge zu erhalten nimmt man z.B. TEncoding.UTF8.GetBytes( json ); .
Wenn man etwas mit Indy verschicken will, dann reicht es in der Regel den String zu verwenden und die entsprechend gewünschte Kodierung anzugeben. Das Umwandeln von dem String in die Kodierung übernehmen dann eigentlich die Indy-Komponenten.

Nur so nebenbei erwähnt:

Das Ergebnis

Code:

{"text":"Stra\u00DFe"}

wird ja auch in einem Delphi-Unicode zurückgegeben. Ist also auch nicht UTF8 oder was auch immer vermutet.

[Uwe Raabe]

Der Unterschied sind die intern verwendeten Methoden. Während ToString und Format auf ToChars zurückgreifen, macht ToJSON Gebrauch von ToBytes. Bei einem TJSONString ist ToBytes aber so implementiert, daß es alle Zeichen > #128 (und auch ein paar < #32) als /u escaped darstellt. Das ToChars beschränkt sich da lediglich auf ein paar spezielle Zeichen.

[Codehunter]

Zitat von Uwe Raabe:

Der Unterschied sind die intern verwendeten Methoden. Während ToString und Format auf ToChars zurückgreifen, macht ToJSON Gebrauch von ToBytes. Bei einem TJSONString ist ToBytes aber so implementiert, daß es alle Zeichen > #128 (und auch ein paar < #32) als /u escaped darstellt. Das ToChars beschränkt sich da lediglich auf ein paar spezielle Zeichen.

Jepp so seh ich das auch. Nur unglücklicherweise mag der Server keine unmaskierten Umlaute und (warum auch immer) kein unformatiertes Json. Heißt, ich muss meinen Request dem nicht standardkonformen Server bekömmlich vorverdauen. Also mit Zeilenumbrüchen, Indentations und \u-escaped Umlaute.

[Uwe Raabe]

Zitat von Codehunter:

Nur unglücklicherweise mag der Server keine unmaskierten Umlaute und (warum auch immer) kein unformatiertes Json.

Das ist allerdings schon recht ungewöhnlich, was eine fertige Implementierung für diesen Fall doch eher unwahrscheinlich macht.

[Codehunter]

Aus meiner Perspektive sind solche Extrawürste leider eher der Normalzustand. Wenn ich mal Glück habe dann habe ich es mit dem IIS zu tun. Aber auffallend oft habe ich solche Exoten, wenn sie auf Nginx laufen. Scheinbar gibt es da ein paar sehr freakige Frameworks. Inzwischen habe ich rausgefunden, dass der Request nicht komplett formatiert sein muss, es genügt ein einzelnes Linefeed ($10) am Ende. Ohne dieses bekomme ich immer 400er Fehler.

[sh17]

Ein Grund, warum ich zu XML zurück gewechselt bin.

[Codehunter]

Nö, Json hat schon viele Vorteile. Allein der viel kleinere Footprint. Aber letztlich nicht meine Entscheidung.

[Uwe Raabe]

Zitat von sh17:

Ein Grund, warum ich zu XML zurück gewechselt bin.

Na ja, wenn du einen REST-Service bedienen sollst, der dir das Format vorgibt, hast du eben nicht die Wahl.

Abgesehen davon gibt es sicher auch Server mit schlechten XML-Implementierungen.

[Schokohase]

Zitat von Codehunter:

Inzwischen habe ich rausgefunden, dass der Request nicht komplett formatiert sein muss, es genügt ein einzelnes Linefeed ($10) am Ende. Ohne dieses bekomme ich immer 400er Fehler.

Das klingt alles sehr seltsam.

Könntest du mit dem Telerik Fiddler einmal den HTTP-Request aufzeichnen, anonymisieren und hier reinstellen?