New issue
Advanced search Search tips

Issue 705377 link

Starred by 0 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Apr 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Compat



Sign in to add a comment

Chrome cannot select the correct character encoding

Reported by go2super...@gmail.com, Mar 27 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Example URL:
http://www.flashget.com/tw/addons.htm

Steps to reproduce the problem:
1. Just visit the URL and you can see the problem.

What is the expected behavior?

What went wrong?
When you visit some Traditional-Chinese page, Chrome cannot select the correct character encoding (it's should be Big5 or Unicode, not GB2312). So those pages looks weird.

Does it occur on multiple sites: No

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 56.0.2924.87  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 24.0 r0
 
Labels: Needs-Triage-M58 Needs-Bisect
Components: Blink>Fonts
Labels: -Needs-Bisect -Needs-Triage-M58 M-59 OS-Linux OS-Mac
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on windows 7, Ubuntu 14.04 and Mac 10.12.3 using chrome version 57.0.2987.133 and canary 59.0.3060.1.
This is non regression issue as the issue seen from M30 old builds.
Marking it as Untriaged to get more inputs form Dev.

Thanks,

Comment 3 by e...@chromium.org, Apr 3 2017

Components: -Blink>Fonts Blink>Loader
Components: -Blink>Loader Blink>TextEncoding
Cc: jinsuk...@chromium.org
File is being served with a header:

  Content-Type: text/html; charset=utf8

Document also contains: 

  <meta http-equiv="Content-Type" content="text/html; charset=big5">

After loading, document.charset returns: "UTF-8".

Appearance is the same in both Firefox and Chrome (both are interpreting as UTF-8)


Status: WontFix (was: Untriaged)
I think this is working as expected - encoding info in HTTP header takes precedence over the one in the document meta tag. Please use a chrome extension (one mentioned here https://bugs.chromium.org/p/chromium/issues/detail?id=597488#c70) to switch encoding manually.

Let me mark it as WontFix. Feel free to reopen it if there's other things to take into account.
Same behavior in Safari.

Per https://html.spec.whatwg.org/multipage/syntax.html#determining-the-character-encoding

"3. If the transport layer specifies a character encoding, and it is supported, return that encoding with the confidence certain, and abort these steps."

Also note:

https://www.w3.org/International/questions/qa-html-encoding-declarations

"The HTTP header information has the highest priority when it conflicts with in-document declarations other than the byte-order mark."

Working as intended.



Sign in to add a comment