That is why I maintain my own JSON parser. First I started with the parse from FreePascal's standard library. Then I ran test cases on it, and there were lots o

That is why I maintain my own JSON parser. First I started with the parse from FreePascal's standard library. Then I ran test cases on it, and there were lots of issues I had to patch. First it was accepting all kinds of numbers, so I rewrote it to only accept the numbers from the spec Then it was removing invalid \u escapes, while I needed it to replace them with U+FFFD. Then I needed the unchanged input. Besides the test cases from the article, I ran test cases from the W3C XPath test suite. The W3C has a very odd understanding of JSON. Besides the normal numbers and Unicode U+FFFD replacement, the JSON parser must be able to parse it unchanged. That means, if the input number is like 100 or 1e2, the parser must be able to return that as string "100" or "1e2". Those are different numbers. And there must be a user defined replacement of invalid \u, like you set the replacement to identity and the input is "\uDEAD\u002D\udead", then the parser must parse that as "\uDEAD-\udead" while keeping the case.