-
Notifications
You must be signed in to change notification settings - Fork 59
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
hz-gb-2312 encoding and WHATWG compatibility #84
Comments
Confirmed. This is another piece of change I've missed. It would be enough to fix the Any deviation from the current WHATWG specification is unintentional and to be fixed. Please file an issue or PR dealing with such deviations. (I'm kind of lazy and not always aware of all changes to the specification, but I think at some point I have implemented all encodings in the specification correctly.) |
Haha, I went through the whole spec and this is the last one I've found with regard to names and labels. Do you just want to ...rip out the entire HZ implementation though? I think it'd be a shame to throw it away/not expose it some other way. |
@aneeshusa I want to keep the encoding, simply making it invisible from |
OK, that's reasonable. I can put in a PR for that in a few minutes (it should be only a line, I think.) |
Fixes lifthrasiir#84. Keep the current HZ implementation, but surface hz-gb-2312 as replacement in encoding_from_whatwg_label to match the spec. This maintains WHATWG compatibility and also allows use of the actual HZ encoding/decoding implementation.
The WHATWG Encoding Spec lists hz-gb-2312 as mapping to the replacement encoding, which uses the UTF-8 encoder and throws a special replacement encoding error for its decoder. However, it looks like this crate implements the actual HZ encoding. For WHATWG compatibility, this would have to get folded in with the rest of the replacement encodings, but I don't know if that's acceptable considering other people may be using the current implementation.
Would you prefer to maintain strict WHATWG compatibility or keep the current implementation? If the current implementation is kept, this deviation needs to be well documented - it isn't too hard to work around, but is a bit annoying and could catch someone unaware because the rest of the crate is compatible.
The text was updated successfully, but these errors were encountered: