Skip to content
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

Question about changing un/escape behavior #734

Closed
phdavis1027 opened this issue Apr 9, 2024 · 0 comments · Fixed by #739
Closed

Question about changing un/escape behavior #734

phdavis1027 opened this issue Apr 9, 2024 · 0 comments · Fixed by #739

Comments

@phdavis1027
Copy link
Contributor

phdavis1027 commented Apr 9, 2024

Hi all,

Me again! I've circled back to iterating on serialization and deserialization again, and I have a combo question/proposition for a PR. My project talks to a server which speaks an idiosyncratic dialect of XML in which, for example, proper unescape behavior is to map " to ` (backtick). Furthermore, this dialect of XML does not encode ' (single quote/apostrophe) , but it does escape " (double quote). As it is, the unescape method evaluates standard named entities before it evaluates custom entities, so I can't implement my unescape behavior. Furthermore, escape only offers partial_escape and escape, without offering a resolver. I am willing to throw together a PR, but since there are security issues involved I first wanted to poll for thoughts on the changes I'm proposing, which are:

  • In unescape_with, reverse the order of the checks for resolver and named entities, allowing users to override standard XML unescapes.

  • Create an escape_with family of functions which allow this kind of customization going the other way.

EDIT: Just to make clear, since the previous issue I raised here I have abandoned the serde API and am hand-parsing my structs use Reader

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant