Bug 19291 – Chinese characters shown as garbage on search.yesky.com

• Status: RESOLVED
• Resolution: FIXED
• Component: Evangelism

[Hong Zhao]

1. Go to www.yesky.com and wait until the site is loaded completely.
2. Type some strings in search bar on top of the page and press search.

Expected outcome:
Search result is displayed.

Actual outcome:
Garbage webpage is displayed, Chinese characters are shown as garbage

Note: This page works fine with IE, Firefox, using Etheral to compare the http request data to server with IE, can't see the difference. After the page is loaded (which shows the garbage characters instead of Chinese), in the same page, charset is set as gb2312, except it doesn't use this charset. But if I save the page, and reload from the saved file, the page is shown as Chinese. Looks like it takes http encoding instead charset inside the page.

[Ed Ford]

Packet dump showing that HTTP response header coming down the pipe with charset=iso8859_1.  This is the charset that Webkit is using to display the page.  Switching the charset to GB2312 from the View menu changes the page to display the proper Chinese characters.

Compared results against Firefox 3 -- Firefox is rendering the page with the GB2312 charset despite the iso8859_1 info coming from the header.  Changing the Firefox charset to iso8859_1, the exact same sequences of garbage characters are shown as in Webkit.  With both browsers set to using GB2312, the Chinese character sequence is the same.

[Alexey Proskuryakov]

So, Firefox does not recognize the encoding name "iso8859_1", unlike "iso8859-1". This is a violation of HTML5 rules: "When comparing a string specifying a character encoding with the name or alias of a character encoding to determine if they are equal, user agents must ignore the all characters in the ranges U+0009 to U+000D, U+0020 to U+002F, U+003A to U+0040, U+005B to U+0060, and U+007B to U+007E (all whitespace and punctuation characters in ASCII) in both names, and then perform the comparison case-insensitively."

[Robert Blaut]

Created attachment 22534 [details]
minimal test case

[Robert Blaut]

Opera 9.50 and WebKit behaves correctly here according HTML5 spec. So the report doesn't describe bug in WebKit. 

A charset definition should be corrected on the reported site. Classified as an evangelism bug.

[Robert Blaut]

As I tested today the reported site appears to working fine. Correct charset is sent to the latest WebKit :) The bug is fixed.

[Joel Parks]

re-purposing InTSW keyword for use by QtWebkit team