My apologies! I stand very much corrected: it is the HTML to Text action that is introducing the line breaks, not Parse JSON, which is using the results as input.
As an example, my test JSON file is 247,506 characters long (including asc(13) line-breaks where appropriate), and is an export from a proprietary database. Some of the data contains HTML-encoded formatting (because the database contains a number of rich-text fields, with bulleted lists, etc.) To have cleaner data, I chose to use the HTML to Text action.
And therein lies the rub.
That action appears to ignore the original line breaks, adding its own seemingly at random. While the first line break it adds is at position 256 (as one might expect when dealing with strings), the rest are added seemingly at random. For example, the next line is 46 characters long; the one after that is 122 characters long, etc.
The break is never in the middle of a word, however, but always replaces a space between words. There is definitely no pattern to WHICH words or phrases are fair game, though.
Using the "body" of the HTML to Text action, the Parse JSON action has no choice except to add the "\n" new-line character to make it legitimate JSON data. So, that action is off the hook.
At this point, I'm just going to change the SharePoint columns to rich-text Multi-Line columns (to accomodate the user-formatted input), and tell the stakeholders that "cleaning" their verbose, formatted input is not practical at this point. (Maybe I'll try to "clean" it further downstream when displaying it; InfoPath comes to mind.)
Nonetheless, it would be nice if that but could be addressed.
-Boonie
