JSON processing issue

I have an interesting issue which appears to have changed in the latest RO SDK. My browser code passes in some JSON as one of the parameters. This usually gets passed through just fine, but now is being modified in some odd way in the current beta (well, last weeks).

The browser shows this as the body of the request. Note that the szPassword value is the one of interest.

{"id":"{3b367daf-d208-44c1-b206-02f46aa2320b}","method":"FrameworkNewUser.AccountCreate","params":{"szAccountEmail":"sdafdsfsdaf@adsfasd.com","szPassword":"{ \r\n\"option\": \"password\", \r\n\"firstname\": \"dsfsdafdsafa\", \r\n\"lastname\": \"sdfsadfsda\", \r\n\"requestinfo\": \"eddfsadfd\" }","szService":"DTX"}}:

What is ending up in the string in the RO SDK (old method) is this:

szPasswordParams '{ '#$D#$A#$16'option'#$16': '#$16'password'#$16', '#$D#$A#$16'firstname'#$16': '#$16'dsfsdafdsafa'#$16', '#$D#$A#$16'lastname'#$16': '#$16'sdfsadfsda'#$16', '#$D#$A#$16'requestinfo'#$16': '#$16'eddfsadfd'#$16' }'

It is getting a character of ordinal 16 (not sure if that is hex or dec, but neither is right) where the escaped quote used to be. I can’t find anything that shows it to be wrong in the general reading. If you can suggest somewhere to look, I’m happy to examine it.

The source of the problem is the ReadString in uROJSONParser. It has:

if lchar = '\' then begin
...
  else if lchar = '"' then Result := Result + JSON_Char(#22)

I’m not yet sure why this would be done. dec(22) = hex(16)

Seems this has been a creeping feature. I have versions which output the lchar value, and the latest which appends the 22. Others have the WriteString which outputs a double quote for a 22, and others which don’t.

Regardless, this is a breaking change, and should be reversed in the latest version. JSON should be parsed as per the standard, and not using some odd variation to try to allow a double-quote in the quoted string. The standard says to use " as the value, not 22.

Hmm, I now find that the JSON being sent to my browser application is different too, and has the \u0022 codes embedded. I really would rather not have to update the javascript module that is on the web server. Can it not be processed properly?

hmm, recently we had a report that quote was serialized wrongly:

so code was changed for fixing this bug.

I suggest that the wrong fix was made then! :grinning: What is the normal way to pass a unicode character? As I have said, there appears to be older code to process a 22 character, so what is that doing?

I shall dig into this further tomorrow, but right now you have a change that breaks perfectly valid JSON, and breaks the normal RO SDK interface.

Okay, I found your real bug.

procedure WriteString(AStream: TStream; AValue: JSON_String); 

// snip
var 
 i,j: integer; 
 s: string; 
begin 
 WriteChar(AStream, '"'); 
 for i := _StrLow to _StrHigh(AValue)  do begin 
   case ord(AValue[i]) of 
     22 {"}  : WriteTag('"'); 
     92 {\}  : WriteTag('\'); 

Okay, this is the wrong part. The 22 is the HEX version of the double-quote, and the Ordinal Decimal should be 34. So what is happening is that the code is converting the wrong character. I presume that the read is then wrong too. But fixing the read is breaking the rest of the code.

Thanks, logged as bugs://79000

bugs://79000 got closed with status fixed.

fix will be in next beta

Running version 9.4.0.1355 I ran into this again today. The quotation mark (") gets read as decimal 22.

In the uROJsonParser file I propose this fix after running a number of tests here.

In procedure WriteString(AStream: TStream; AValue: JSON_String);
In the case statement change
22 {"} : WriteTag('"');
to:
34 {"} : WriteTag('"');

and in function ReadString(AStream: TStream):JSON_String;
in the while loop change
else if lchar = '"' then Result := Result + JSON_Char(#22)
to:
else if lchar = '"' then Result := Result + JSON_Char(#34)

something is wrong.
9.4.0.1355 doesn’t have

22 {"} : WriteTag('"');

line.
can you check and specify number from ROVersion.inc?

1 Like

You nailed that on the head. I somehow had Delphi pointing to a source folder for .1337 even though I had .1355 installed. It works correctly after pointing it to the .1355 source.

1 Like