Deserialize invalid UTF-8 into byte bufs as WTF-8 #877
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lucacasonato
commented
Apr 12, 2022
Comment on lines
+886
to
888
| // TODO: the error message is wrong, this is a lone | ||
| // _trailing_ surrogate | ||
| error(read, ErrorCode::LoneLeadingSurrogateInHexEscape) |
There was a problem hiding this comment.
Worth adding another error code? Would doing so even be semver compatible? (unrelated to this PR)
lucacasonato
commented
Apr 12, 2022
| } | ||
|
|
||
| #[test] | ||
| fn test_byte_buf_de_surrogate_pair() { |
There was a problem hiding this comment.
There was no test for parsing valid surrogate pairs into byte bufs that I could find, so I added one.
lucacasonato
force-pushed
the
wtf8_encoding
branch
from
c3bfa51
to
fbd1d68
Compare
Previously serde-rs#828 added support for deserializing lone leading and trailing surrogates into WTF-8 encoded bytes when deserializing a string as bytes. This commit extends this to cover the case of a leading surrogate followed by code units that are not trailing surrogates. This allows for deserialization of "\ud83c\ud83c" (two leading surrogates), or "\ud83c\u0061" (a leading surrogate followed by "a"). The docs also now make it clear that we are serializing the invalid code points as WTF-8. This reference to WTF-8 signals to the user that they can use a WTF-8 parser on the bytes to construct a valid UTF-8 string.
lucacasonato
force-pushed
the
wtf8_encoding
branch
from
fbd1d68
to
f50e296
Compare
|
@dtolnay Have you had a chance to look into this? It'd be great to get your review. |
purplesyringa
added a commit
to iex-rs/serde-json
that referenced
this pull request
Aug 12, 2024
Closes serde-rs#877. This is a good time to make ByteBuf parsing more consistent as I'm rewriting it anyway. This commit integrates the changes from serde-rs#877 and also handles a leading surrogate followed by a surrogate pair correctly. This does not affect performance significantly. Co-authored-by: Luca Casonato <hello@lcas.dev>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously #828 added support for deserializing lone leading and
trailing surrogates into WTF-8 encoded bytes when deserializing a string
as bytes. This commit extends this to cover the case of a leading
surrogate followed by code units that are not trailing surrogates. This
allows for deserialization of "\ud83c\ud83c" (two leading surrogates),
or "\ud83c\u0061" (a leading surrogate followed by "a").
The docs also now make it clear that we are serializing the invalid code
points as WTF-8. This reference to WTF-8 signals to the user that they
can use a WTF-8 parser on the bytes to construct a valid UTF-8 string.
Follow up to #830 (review).