Encoding.name() vs. WHATWG encoding name about rust-encoding HOT 4 CLOSED

Encoding is not intended to be a direct interface to the WHATWG-compatible encoding. That's why Text{En,De}coder has a separate encoding method. Maybe we need whatwg_name in the future, when #4 is complete.

Regarding your examples, 1 is my mistake (shift_jis is correct, it is a rare case of using underscores in the standardized encoding name), 2 is implemented separately in whatwg module, and 3 is intentional and indeed it is a different encoding than EUC-KR. In fact, Shift_JIS should really have been windows-932 or windows-31j (JIS X 0208 alone is not enough to implement it), but I'm still not decided on which standard should name be based as no single standard covers all major encodings. For example, Windows code page 949 is missing in IANA Character Sets registration and that's why many browsers use x-windows-949 instead of a typical windows-949. I'm even worried about encodings with the asymmetric encoder and decoder, which seems very common in WHATWG encodings for the compatibility purpose.

from rust-encoding.

Other than "get an encoding form a label" and its quirks such as mapping latin1 to windows1252, I don’t think that "WHATWG-compatible" should be a different API for the actual decoding/encoding. Or is there a reason I’m missing that would prevent the APIs to be unified?

from rust-encoding.

@SimonSapin It is not a matter of the actual decoding/encoding, and these APIs won't be changed whatsoever. It is rather a matter of mapping the string label to the actual decoder/encoder, and in this respect WHATWG only considers Web browsers. So I think it is better to rename name to make sure that the name is specific to WHATWG's quirks.

from rust-encoding.

ae41ef4 and 97b4005 directly fixed this issue.

from rust-encoding.