| Summary: | cp949 is not a known text encoding name | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Myles C. Maxfield <mmaxfield> | ||||
| Component: | New Bugs | Assignee: | Myles C. Maxfield <mmaxfield> | ||||
| Status: | RESOLVED INVALID | ||||||
| Severity: | Normal | CC: | ap, jonlee | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | WebKit Nightly Build | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
Myles C. Maxfield
2017-05-18 19:13:51 PDT
Created attachment 310592 [details]
Patch
Comment on attachment 310592 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=310592&action=review > Source/WebCore/ChangeLog:5 > + <rdar://problem/29133333> I can't check radar right now, but I think that it's intentional. Could you hold off landing? Comment on attachment 310592 [details] Patch I don't think that we should do this. 1. This encoding name is not in the Web encoding spec <https://encoding.spec.whatwg.org>, and other browsers don't support it. 2. The way this patch implements cp949 doesn't match any non-Web encoding standard either. In ICU, this name maps to ibm-949 encoding, which is entirely different from windows-949: <http://demo.icu-project.org/icu-bin/convexp?s=IANA&s=MIME&s=ALL>. I think that it's a bug somewhere in the client that it passes cp949 when it actually means windows-949 or some other EUC-KR variant. |