-
Notifications
You must be signed in to change notification settings - Fork 364
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistent handling of surrogate pair characters #447
Comments
Thanks for the report! The solution sounds reasonable, would you like to put together a PR? |
JustAnotherArchivist
added a commit
to JustAnotherArchivist/ultrajson
that referenced
this issue
Apr 17, 2022
This allows surrogates anywhere in the input, compatible with the json module from the standard library. This also refactors two interfaces: - The PyUnicode to char* conversion is moved into its own function, separated from the JSONTypeContext handling, so it can be reused for other things in the future. - Converting the char* output to a Python string with surrogates intact requires the string length for PyUnicode_Decode (or any of its alternatives). While strlen could be used, the length is already known inside the encoder, so the encoder function now also takes an extra size_t pointer argument to return that. This also permits output that contains NUL bytes (even though that would be invalid JSON), e.g. if an object's __json__ method return value were to contain them. Fixes ultrajson#156 Fixes ultrajson#447 Supersedes ultrajson#284
JustAnotherArchivist
added a commit
to JustAnotherArchivist/ultrajson
that referenced
this issue
Apr 17, 2022
This allows surrogates anywhere in the input, compatible with the json module from the standard library. This also refactors two interfaces: - The `PyUnicode` to `char*` conversion is moved into its own function, separated from the `JSONTypeContext` handling, so it can be reused for other things in the future (e.g. indentation and separators) which don't have a type context. - Converting the `char*` output to a Python string with surrogates intact requires the string length for `PyUnicode_Decode` & Co. While `strlen` could be used, the length is already known inside the encoder, so the encoder function now also takes an extra `size_t` pointer argument to return that and no longer NUL-terminates the string. This also permits output that contains NUL bytes (even though that would be invalid JSON), e.g. if an object's `__json__` method return value were to contain them. Fixes ultrajson#156 Fixes ultrajson#447 Supersedes ultrajson#284
JustAnotherArchivist
added a commit
to JustAnotherArchivist/ultrajson
that referenced
this issue
Apr 17, 2022
This allows surrogates anywhere in the input, compatible with the json module from the standard library. This also refactors two interfaces: - The `PyUnicode` to `char*` conversion is moved into its own function, separated from the `JSONTypeContext` handling, so it can be reused for other things in the future (e.g. indentation and separators) which don't have a type context. - Converting the `char*` output to a Python string with surrogates intact requires the string length for `PyUnicode_Decode` & Co. While `strlen` could be used, the length is already known inside the encoder, so the encoder function now also takes an extra `size_t` pointer argument to return that and no longer NUL-terminates the string. This also permits output that contains NUL bytes (even though that would be invalid JSON), e.g. if an object's `__json__` method return value were to contain them. Fixes ultrajson#156 Fixes ultrajson#447 Supersedes ultrajson#284
JustAnotherArchivist
added a commit
to JustAnotherArchivist/ultrajson
that referenced
this issue
May 30, 2022
This allows surrogates anywhere in the input, compatible with the json module from the standard library. This also refactors two interfaces: - The `PyUnicode` to `char*` conversion is moved into its own function, separated from the `JSONTypeContext` handling, so it can be reused for other things in the future (e.g. indentation and separators) which don't have a type context. - Converting the `char*` output to a Python string with surrogates intact requires the string length for `PyUnicode_Decode` & Co. While `strlen` could be used, the length is already known inside the encoder, so the encoder function now also takes an extra `size_t` pointer argument to return that and no longer NUL-terminates the string. This also permits output that contains NUL bytes (even though that would be invalid JSON), e.g. if an object's `__json__` method return value were to contain them. Fixes ultrajson#156 Fixes ultrajson#447 Fixes ultrajson#537 Supersedes ultrajson#284
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Ultrajson does not correctly handle surrogate pair characters. Per RFC 7159, unmatched surrogate pair characters are permitted in JSON:
This behavior also disagrees with the built-in json module, which can handle strings containing surrogates correctly.
Ultrajson will correctly parse strings containing surrogate pair characters, if they're written in an escaped form, but it will not parse unescaped surrogate pair characters, and it will never dump Python strings containing surrogate pairs to JSON. This means ujson fails to round-trip certain inputs; see the example below.
What did you do?
Attempted to
.dumps()
a string containing a surrogate pair character.What did you expect to happen?
It is encoded into a string.
What actually happened?
An exception is raised:
What versions are you using?
Please include code that reproduces the issue.
Solving this problem is a bit annoying in native code. In Python, the solution is simply to add "surrogatepass" as a second parameter to
str.encode()
. That functionality isn't exposed in native code, however. The solution I used in Atheris (which found this bug) was to first try encoding the string using the normal method, and if that doesn't work, fall back to encoding it by dynamically making a call to thestr.encode()
function in Python. Since you only have to take the slow route if the fast route fails, this is not likely to meaningfully affect performance.The text was updated successfully, but these errors were encountered: