JSON Encoder

[chipfryer27]

Hi

There appears to be a small bug with the JSON Encoder component. I'm using the encoder to send to a PHP script. I checked the script by sending a string from a browser and I get the expected reply.

If I only have one element the encoder returns (for example) "{\"Name1\":\"Data1\"}" and I can send this off to the PHP script without any problem.

If I encode two elements it returns (for example) "{\"Name1\":\"Data1\", \"Name2\":\"Data2\"}" but this causes issues.

It appears that the problem is when encoding multiple "elements", the component inserts a space after the comma before the next element begins.

If I step through the chart and manually edit the string, e.g. "{\"Name1\":\"Data1\",\"Name2\":\"Data2\"}" removing the space after the comma, then the PHP script happily accepts.

Regards

[kersing]

Whitespace is allowed within json. However there shouldn’t be backslashes before the double quotes. Valid json looks like this:

Code: Select all

{ “element1name”: “string value”, “element2name”: true,
“element3name”: 3 }

Where all quotes should be regular double quotes which the forum software keeps messing with.
See https://www.json.org/json-en.html.

[chipfryer27]

Hi

The backslashes are added before the quotes automatically by Flowcode, for further transmission and I believe used as an "escape-character".

Sorry if I wasn't clear before.

I have tested the scripts by sending from a browser and everything works as expected. When in Flowcode I create a json string with multiple elements the space is added between each pair which seems to mess things.

If I use the browser and send with or without space I see as expected but in FC with the space I get issues. Removing the space resolves. It sends to the same script as the browser so I am pretty certain it is something within FC.

With Space.JPG (15.63 KiB) Viewed 1764 times

No Space.JPG (15.49 KiB) Viewed 1764 times

In the above json is the variable created when FC encodes.

Regards

[chipfryer27]

Hi

Further to the above I created a script echoing as it progresses

Entering into a browser > http://localhost/json1.php?{\"Sensor\":\"FC1\", \"Value\":123} (note: with space)

It first returns the query string > {\%22Sensor\%22:\%22FC1\%22,%20\%22Value\%22:123}

Then runs urldecode giving > {\"Sensor\":\"FC1\", \"Value\":123}

It then runs stripslashes giving > {"Sensor":"FC1", "Value":123}

It then runs json_decode giving > Array ( [Sensor] => FC1 [Value] => 123 )

I can then assign variables giving > Sensor = FC1 and Value = 123

If I omit the space after the comma, I get

{\%22Sensor\%22:\%22FC1\%22,\%22Value\%22:123} (Note: no %20 after comma and no spaces as it progresses)
{\"Sensor\":\"FC1\",\"Value\":123}
{"Sensor":"FC1","Value":123}
Array ( [Sensor] => FC1 [Value] => 123 )

I can still assign as before and get > Sensor = FC1 and Value = 123

These values (sent from browser) seem identical to me when decoded so again seems to point at something within FC.

In the script I actually want to access, these variables are then used to update a database. With a space in FC I have problems, no space no issue. Accessing the script using a browser, with or without space has no issue.

Regards

[kersing]

The issue is that you can’t ever use a get request with a space in the URL. If required it should be URL encoded (something like %20).

[chipfryer27]

Hi

"Wood" and "Trees" spring immediately to mind... Many thanks

Although the space is entered in the browser it deals with it by adding the %20

http://localhost/json1.php?{\"Sensor\":\"FC1\", \"Value\":123}

turns to

http://localhost/json1.php?{\%22Sensor\ ... ue\%22:123}

I was just playing around with embedded. I suppose most json requests are by POST so this is probably moot.

Thanks again.
Regards

[chipfryer27]

Hi

I still feel that adding a space when encoding multiple elements is a bug, as when FC takes this json string for further transmission within FC, the space doesn't get encoded into %20.

Regards

[kersing]

Sorry to disagree, the space is not a bug. And putting URL escaped characters in it would break json compatibility and would introduce a bug.
Modifying the URL code to make sure all characters in the URL are properly encoded would be a better solution. Keep in mind there are json use cases that do not use a GET and require proper json. (The backslash encoding of the quotes is already an issue and should (if it isn’t) be a property so it can be switched of for proper json)

Skipping the space on an embedded platform would make sense. One byte less is a significant savings for some controllers. The question is whether json is the right encoding on such controllers.

[chipfryer27]

Hi

Modifying the URL code to make sure all characters in the URL are properly encoded would be a better solution

That is probably what I am eluding to. Within FC, the components are doing all the work (thankfully).

Many basic chips can be "internet enabled" by using devices such as an 8266 and they could create and send a simple string with even the modest of resources and I appreciate that a basic GET string is, in my modest opinion, the most obvious way. There are systems out there though that do accept json as GET so that was what I was trying to achieve. I'm just "playing", no real reason or need other than better understanding.

Sorry to disagree

My aspiration is to have enough embedded knowledge to hold a conversation with you, let alone disagree on a subject. Over the years I have very much appreciated the time you have taken to assist in the forum and I have certainly learned a lot from your contributions.

Regards