Fix CDATA handling #374
Closed
Fix CDATA handling #374
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
Now debug representation is readable
failures:
de::tests::trivial::struct_::cdata::byte_buf
de::tests::trivial::struct_::cdata::char_
de::tests::trivial::struct_::cdata::f32_
de::tests::trivial::struct_::cdata::f64_
de::tests::trivial::struct_::cdata::false_
de::tests::trivial::struct_::cdata::i128_
de::tests::trivial::struct_::cdata::i16_
de::tests::trivial::struct_::cdata::i32_
de::tests::trivial::struct_::cdata::i64_
de::tests::trivial::struct_::cdata::i8_
de::tests::trivial::struct_::cdata::isize_
de::tests::trivial::struct_::cdata::string
de::tests::trivial::struct_::cdata::true_
de::tests::trivial::struct_::cdata::u128_
de::tests::trivial::struct_::cdata::u16_
de::tests::trivial::struct_::cdata::u32_
de::tests::trivial::struct_::cdata::u64_
de::tests::trivial::struct_::cdata::u8_
de::tests::trivial::struct_::cdata::usize_
de::tests::trivial::struct_::text::byte_buf
… trivial tests
failures:
de::tests::trivial::struct_::text::byte_buf
de::tests::trivial::struct_::cdata::byte_buf
…tead of `BytesText` This commit revert changes from 85f9f68
|
Merged in Mingun/fast-xml@9795a68 |
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.
Fixes #311, closes #370.
Now
CDataevent has its own dedicated typeBytesCDatainstead ofBytesText. New type can be converted toBytesTextby calling.escape()method, so migrating should be easy, but it is better to review usages, because usually you want to have unescaped data and CDATA section already provide them.The API a bit dangerous because it not checked for forbidden sequence
]]>-- you can create aBytesCDatacontaining it. Because this is general problem with other event content types, I leaved it now as is. This API should be fixed in another PR.This PR changes how raw bytes are deserialized, for example, to a
Vec<u8>. Before such field always get a unmodified content from the reader -- it means that you can consider raw bytes types as a way to access to raw reader content in your structs. This is dangerous practice, because other formats do not behave like this. Actually, I would prefer to prohibit (de)serializing (into)Vec<u8>and similar at all. This is conceptually right, but maybe unpractical. So now bytes deserialized similarly to strings -- text content unescaped, CDATA content remained unchanged.I'm thinking about providing encoding handler to a (de)serializer, that should be used to encode / decode binary data to strings, that will be stored in XML, for example, hex, or base64, and by default (
handler == None) emit an error on attempt (de)serializing binary data. But this is for another PR.Unescaping takes into account only default XML entities, namely
<,>,&,', and". Adding support for document-defined entities is the purpose for another PR.