xml serde roundtrip loses CR/LF encoding

[francisdb]

use pretty_assertions::assert_eq;
use serde::{Deserialize, Serialize};

#[derive(Debug, Deserialize, Serialize)]
struct Root {
    #[serde(rename = "@value")]
    value: String,
}

const xml: &str = r#"<root value="new&#xD;&#xA;line"/>"#;

#[test]
fn test_attribute_value_normalization() {
    let read: Root = quick_xml::de::from_str(xml).unwrap();
    assert_eq!("new\r\nline", read.value);
    let written = quick_xml::se::to_string(&read).unwrap();
    assert_eq!(r#"<root value="new&#xD;&#xA;line"/>"#, written);
}

yields

thread 'test_attribute_value_normalization' panicked at tests/atest.rs:18:5:
assertion failed: `(left == right)`

Diff < left / right > :
<<root value="new&#xD;&#xA;line"/>
><Root value="new
>line"/>

Any workaround possible for the serializer?

Is this related to #115 ?

[Mingun]

No, this is more related to #371. Normalization of attributes does not handled correctly yet neither in Writer or serde. The only workaround is to use #[serde(serialize_with)] and normalize value yourself.

[francisdb]

@Mingun if I normalize in serialize_with to 
 I end up with 
 as probably afterwards there is another normalize step? Any workaround for the workaround 😅?

[Mingun]

Uh... doesn't think about that. One possible workaround for that is to make two-step escaping:

• using serialize_with replace necessary symbols to some markers (for example, \n -> \u0001#xA;
• using custom implementation of std::fmt::Write replace these markers with actual escape codes (for example, \u0001 -> &). You can be sure, that the whole marker will be written in one call to write_str, so multicharacter markers are not a problem

Or modify internals of quick-xml and use patched version. If you'll feel that those modification are not hackish, make a PR 😄 .

[francisdb]

Or modify internals of quick-xml and use patched version. If you'll feel that those modification are not hackish, make a PR 😄 .

would that not duplicate efforts already done in #379 ?

[dralley]

At the end of the day #379 just needs to be finished. I'll try to find time for it this weekend but if anyone else wants to take it over I'm also OK with that. I've been extremely busy with other work unfortunately.