JSON/Superobject mit Binären Daten

[Shark99]

Zitat von himitsu:

"binäre" Daten in einem "String" ... wo es hier Probleme geben kann/wird, ist bei der Codierung, z.B. Umwandlung von Unicode (der Typ String seit D2009) z.B. nach ANSI, jenachdem wie das JSON am Ende gespeichert wird.
Außer SuperObjekt sorgt immer dafür, dass das JSON nur noch ASCII-Zeichen enthält.

Was sollte sonst verwendet werden wenn in den Daten sowohl Unicode Strings, als auch Binäres vorkommen kann (da optionale AES Verschlüsselung). Bytechar?

[himitsu]

"wenig" und nicht jede Libt hält sich richtig an alles.
OK, SuperObjekt sollte sich an die Syntax halten, aber wie von SuperObjekt die Strings kodiert werden, weiß ich nicht ganz sicher.

Würde aber alles "Nicht-ASCII" immer mit \u... kodiert, dann gibt es nie Probleme.

[Sir Rufo]

Zitat von himitsu:

"wenig" und nicht jede Libt hält sich richtig an alles.
OK, SuperObjekt sollte sich an die Syntax halten, aber wie von SuperObjekt die Strings kodiert werden, weiß ich nicht ganz sicher.

Würde aber alles "Nicht-ASCII" immer mit \u... kodiert, dann gibt es nie Probleme.

Das ist eher kontraproduktiv, denn der String \u... wird im JSON als \\u... dargestellt. Das bringt irgendwie nichts

[himitsu]

Ich meinte doch das JSON-\u , so wie das #123 im Delphi ... das sollte der nicht nochmal maskieren (hoff ich doch, dass der das nicht macht).

[p80286]

Zitat von Sir Rufo:

Zitat von himitsu:

"wenig" und nicht jede Libt hält sich richtig an alles.
OK, SuperObjekt sollte sich an die Syntax halten, aber wie von SuperObjekt die Strings kodiert werden, weiß ich nicht ganz sicher.

Würde aber alles "Nicht-ASCII" immer mit \u... kodiert, dann gibt es nie Probleme.

Das ist eher kontraproduktiv, denn der String \u... wird im JSON als \\u... dargestellt. Das bringt irgendwie nichts

Jetzt bist du aber sehr kleinlich, wenn deine Json-Software sich um das escapen kümmern kann, dann wirf ihr doch einfach x000D in den Rachen. Wenn sie damit nicht korrekt umgehen kann, solltest Du einen Weg finden wie \u000D in die Json-Datei kommt. Keine Gedanken muß man sich machen, wenn man Base64 oder auch Base16 codiert.
InAußerdem ist die Rede von "Unicode Characters" je nach Sichtweise würde dies z.B. den Bereich von x0000-001F ausschließen, da es sich hierbei um Steuercodes handelt, was meiner Meinung nach wiederum für Basexx spricht.

Gruß
K-H

[Sir Rufo]

Ich glaube fast wir reden aneinander vorbei.

Liegt aber wohl daran, dass ich so ein JSON-String niemals direkt erstelle sondern eben erstellen lasse. SuperObject oder das in Delphi eingebaute Gedöns kümmert sich dann darum, dass der von mir beliebig gewählte string JSON-konform in so einem JSON-Objekt abgelegt wird.

Nur so als Beispiel:

Delphi-Quellcode:

var
  lFoo              : TFoo;
  lFooStr           : string;
  lExpected, lActual: string;
begin
  lExpected := #0 + #1 + #2 + #3 + #4 + #5;

  lFoo := TFoo.Create;
  try
    lFoo.Bar := lExpected;
    lFooStr  := lFoo.ToJson( ).AsJSon( );
  finally
    lFoo.Free;
  end;

  lFoo := TFoo.FromJson( lFooStr );
  try
    lActual := lFoo.Bar;
  finally
    lFoo.Free;
  end;

  Assert( lExpected.Equals( lActual ) );
end;

als JSON-Objekt:

Code:

{"bar":"\u0000\u0001\u0002\u0003\u0004\u0005"}

BTW: Der Delphi-Interne JSON-Serialisierer bekommt das zurückwandeln nicht auf den Schirm, da bleibt TFoo.Bar einfach leer

[p80286]

Zitat von Sir Rufo:

SuperObject oder das in Delphi eingebaute Gedöns kümmert sich dann darum, dass der von mir beliebig gewählte string JSON-konform in so einem JSON-Objekt abgelegt wird.

Jo, wenn denn die Daten die Du hast, ein String sind. Enthält diese Aneinanderreihung von Werten, Werte die nicht Codierungskonform sind, wird es spannend. Und diese Spannung kannst Du umgehen, indem Du deine Werte nimmst und ihnen eine BaseXX-Codierung zukommen läßt.
Eine weitere Möglichkeit, wäre es, ein Array zu nutzen, dem sollte es ziemlich egal sein welche Daten es bekommt.

Gruß
K-H