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
element name case changes when added to document with different encoding #1158
Comments
Seems |
Thanks, @knu. I'll use the work-around for now. |
Introduce ClassResolver which will do the class lookup correctly, and use it for Builder and for fragment parsing. Closes #1158
Apologies for not replying for such an embarrassingly long time. Fragment parsing is a bit complicated because libxml2 doesn't recover from errors while parsing a fragment in the context of a specific node (e.g., When an error (like the encoding error here, or any other syntax error) is encountered, Nokogiri's fallback behavior is to parse the fragment outside the context of the node. Unfortunately, though, it was using a hardcoded class to do this: See #2388 for fix. |
Introduce ClassResolver which will do the class lookup correctly, and use it for Builder and for fragment parsing. Closes #1158
Introduce ClassResolver which will do the class lookup correctly, and use it for Builder and for fragment parsing. Closes #1158
Hi,
It looks like element names are serialized in a case-insensitive way if the element is added as a string to a document that declares a different encoding:
This produces:
I tested this on nokogiri 1.6.3.1, libxml2 2.8.0. Is this a libxml2 problem, maybe?
The text was updated successfully, but these errors were encountered: