Path serialization can panic
#57
Comments
|
Good point! Should be simple enough to have it return a syntax error if it gets a non-unicode string. |
|
err, rather tries to serialize to a non-unicode string. So it could either just be serialized as a byte string, or we first try to encode it as a string, then fail back to a byte string if it's non-unicode. |
|
What should happen if you serialize the path Actually, what about path delimiters? :( Should serialization/deserialization even work across systems? What happens for |
|
@tbu-: ah the madness of cross platform things. This is one area where I'm looking forward to #198, which eases overriding which serializer gets used for a field. That'd allow someone with more specific knowledge than serde about how something would get used. For a default, I'd just rather have serde be able to serialize and deserialize the value and get the same results. It's more up to the serializers/deserializers/users to decide if they need to conform the serialized format to some well defined schema. |
The only way to safely serialize a `Path` is to use `.to_string_lossy()`, which replaces invalid UTF-8 characters with the U+FFFD replacement character. Unfortunately this would lose information, so for our default implementations, it'd be better to punt and report an error, and leave it up to the user to decide if they want to use the lossy encoding. Unfortunately, we had no way for `Serializer`s to require some methods on `Serializer::Error`, so there was no way before this patch for the `Path` implementation to generically report that it cannot encode this value. This adds that implementation. breaking-change Closes serde-rs#57.
|
This was implemented in #224 for version 0.7. |
The
Serializeimplementation ofPathincorrectly assumes that all paths can be represented as Unicode strings.The text was updated successfully, but these errors were encountered: