Some time ago, the page in a project suddenly appeared garbled in IE6. I did various troubleshooting at that time, and finally speculated that it was a problem with the use of HTML5 DOCTYPE and Charset and Chinese comments, so I temporarily used the old Charset method to fix it. Later The garbled code never appeared again.
In fact, I have never been sure whether HTML5 Charset can be recognized by IE6, so I did some tests.
First, let’s talk about the two Charset declaration methods. In fact, everyone should be familiar with them:
We will refer to the first method as the HTML5 method and the second method as the HTML4 method.
Test environment:
Windows XP Sp2, Chinese version + English version of IE6, and IE9 under Windows 7 and its various compatibility modes and the current Stable version of Chrome, Firefox, etc.;
Because we use HTML files are all encoded in UTF8, so the HTML files in the test cases here are also in UTF8 (no BOM) format. The project is similarly encoded with gbk or gb2312.
Two methods are used for testing:
meta method: including HTML5 and HTML4 methods and their mashups
Server-side method: setting charset on the server side, nginx is used here, charset=utf-8
Test case—— Meta method:
UTF8
UTF8 HTML4 method
UTF8-GB2312
UTF8+ Chinese comment before meta
UTF8+ Chinese comment between HTML and HEAD
GB2312
GB2312 HTML4 method
GB2312-UTF8
GB2312+Chinese comments before meta
GB2312+Chinese comments between HTML and HEAD
Test case - server method:
Server setting encoding
meta encoding and server encoding are inconsistent
Each use case above can be accessed directly
Test results:
The test cases performed consistently in each browser;
UTF-8 solutions were all displayed normally;
charset was declared as gb2312, which was inconsistent with the UTF-8 encoding of the document, so all garbled characters;
1, 6 use HTML5 charset to define UTF8 and gb2312 respectively. 1 displays normally without garbled characters, and 6 has garbled characters - this is true for both the Chinese version of IE6 and the English version of IE6, indicating that IE6 can recognize the HTML5 charset;
1,2 use cases As with use cases 6 and 7, defining charset using HTML5 and HTML4 methods respectively has the same effect;
It is worth noting that the third use case first uses the HTML5 method to set the UTF-8 encoding, and then uses the HTML4 encoding setting. It is gb2312, but the page is displayed normally, while in the eighth use case, the result page displays garbled characters, so it can be inferred that the second meta tag does not take effect;
4 and 5 use cases are not garbled, indicating that simple HTML comments are not It will definitely lead to garbled characters. There is no test here about what may happen when loading external files such as js with different encodings in these two locations;
In the server method, use case 1 does not use meta to set charset, and the page displays normally, while use case 2 uses The meta setting charset=gb2312 is different from the server version, but there is still no garbled code, indicating that the charset returned by the server has a higher priority;
Conclusion:
In fact, regarding the specifications of charset, Google's development documents also explain it:
must be in the HEAD tag;
must be before any other content, that is, it must be at the front of HEAD;
including spaces and DOCTYPE declarations , should be within the first 512 bytes;
HTML5 and HTML4 have the same effect, just use one of them;
The above test also proves that item 4 is correct, and both writing methods are acceptable.
In addition, it is also a good idea to set charset on the server side. The charset statement is obtained directly in the HTTP response, which is more efficient and more convenient. Google is currently using this approach.
So as long as the page is written in a standardized way, there will be no problem of garbled characters. So you can boldly use HTML5's DOCTYPE and Charset declarations. But please try to follow the specifications in Google documents mentioned above. Don’t put too many things in the head, and put external resources such as js at the back.
It is inevitable that there will be omissions during the test. If there are any errors, please correct them and discuss them together~~