json_ParseString handling of new line (\n)

[timhall]

See VBA-tools/VBA-Web#270 #44

I believe the n case in json_ParseString should be changed to append a vbLf instead of a vbCrLf or there should be an option to override the default behavior

[bwmilby]

I don't think the proposed solution complies with ECMA-404. The JSON spec has \n and \r as the encoding for vbLf and vbCr respectively and does not include any conversion between Unix/Mac line endings and Windows vbCrLf.

A well formed JSON from an external source should be consistent in how it treats normal line endings. So it would be faster to do a search/replace than to do it with a comparison for each line ending. These days I would think that you would either see \n or \r\n but not \n\r nor \r. If the source doesn't contain \r\n, then you could post-process strings with a replace of vbLf with vbCrLf to get normal Windows line endings. I would suggest that be a setting for something like "normalizeWindowsLineEndings" which would default to "false".

PR #44

[houghtonap]

We need to be careful when talking about whitespace with JSON. Both the original and ECMA specifications are agnostic with regard to whitespace outside a string. Any combination of line terminators are acceptable. This treatment makes the specifications agnostic to the platform that the JSON was generated on. Parsers treat all line terminators as whitespace. Now if you're talking about inside a string that's a different matter. Andrew. Get Outlook for Android

…

________________________________ From: Brian Milby <[email protected]> Sent: Thursday, November 14, 2019 8:45:17 PM To: VBA-tools/VBA-JSON <[email protected]> Cc: Subscribed <[email protected]> Subject: Re: [VBA-tools/VBA-JSON] json_ParseString handling of new line (\n) (#67) I don't think the proposed solution complies with ECMA-404. The JSON spec has \n and \r as the encoding for vbLf and vbCr respectively and does not include any conversion between Unix/Mac line endings and Windows vbCrLf. A well formed JSON from an external source should be consistent in how it treats normal line endings. So it would be faster to do a search/replace than to do it with a comparison for each line ending. These days I would think that you would either see \n or \r\n but not \n\r nor \r. If the source doesn't contain \r\n, then you could post-process strings with a replace of vbLf with vbCrLf to get normal Windows line endings. I would suggest that be a setting for something like "normalizeWindowsLineEndings" which would default to "false". — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#67?email_source=notifications&email_token=AIKTRAZRXQAPQ3FIST2CGALQTX5K3A5CNFSM4DWQ2F62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEED7YDA#issuecomment-554171404>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIKTRA24WCECJAY5YC64GQTQTX5K3ANCNFSM4DWQ2F6Q>.

[bwmilby]

The bug report is for string processing. Export is handled properly. The current code will convert \n to vbCrLf when importing JSON. This results in an extra CR for something that was encoded using this library (or anything that puts \r\n into the JSON). The proposed solution is to turn a naked \r or \n into \r\n when importing a string. In my copy, I just corrected the import to us vbLf for \n.