Thanks Björn, this was a good catch.
The JSON that Objo was producing was technically valid. For example:
{"FirstName":"Bj\u00F6rn","LastName":"Eir\u00EDksson"}
is semantically the same JSON as:
{"FirstName":"Björn","LastName":"Eiríksson"}
A conforming JSON parser should decode both to the same string values. So this was not broken JSON, but it was still not the right behaviour for JSONItem.
The cause was that JSONItem uses .NET’s System.Text.Json under the hood. By default, its encoder is conservative and escapes characters outside Basic Latin. That is useful in some contexts, especially where JSON might be embedded into HTML or JavaScript, but JSONItem.ToString() is intended to serialise a JSON payload. In that context, ordinary Unicode characters should remain readable UTF-8 text.
I’ve changed JSONItem.ToString() and JSONItem.ToFormattedString() so they now preserve ordinary Unicode characters:
{"FirstName":"Björn","LastName":"Eiríksson"}
The writer still escapes characters that JSON requires to be escaped, such as quotes, backslashes, and control characters like newlines. So this still produces valid JSON, just without unnecessarily escaping normal text.
I also added regression tests covering:
- compact JSON output preserving
Björn and Eiríksson
- formatted JSON output preserving the same characters
- continued escaping of quotes, backslashes, and newline characters
This will be in the next release: https://feedback.objo.dev/bug/538
