Re: [Json] On characters and code points

[Stefan Drees <[e-mail]>]

On 2013-06-07 18:01, Tim Bray wrote:
> On Fri, Jun 7, 2013 at 8:56 AM, Paul Hoffman ... wrote:
>
>     This may be a part of the spec where some people have to hold their
>     noses. The Unicode definition of "character" does not include
>     non-characters, and the code points for some of those non-characters
>     make sense in JSON strings when those strings. Bjoern has pointed
>     out a good one: strings used for test cases of other code. The issue
>     not just unpaired surrogates. Do we *really* want to prohibit:
>         { "End of data marker": "\uFFFF" }
>
>
> Yes, I *really* want to prohibit that. The one corner case it buys you
> is outweighed by a factor of a thousand or so in not being able to use
> general-purpose string processing software to deal with JSON payloads.
> BTW, a huge amount of deployed software out there ALREADY processes JSON
> text fields using general-purpose string processing libraries, and will
> explode unpredictably and in hard-to-debug ways if this starts happening.

and what about { "Decorate my slash": "\/" } and "general-purpose string 
processing software". Isn't this also a case, where you need a 
"pre-conditioner" that replaces the JSON specific escape sequence "\" 
with "/" before feeding it into "general-purpose string processing 
software" :-?)


> Also, consider the lovely consequences when unpaired surrogates start
> showing  up in key fields and are fed to hash functions in every
> programming language in the world, which expect to receive Unicode
> characters.
>   -T
>

For today I better not imagine all these laguages and implementations 
blindly stuffing some json text transformed into their own memory 
structures ... maybe later during the weekend


>     ...

Stefan.