Encoding problem: why is the response gbk displayed when it is UTF-8?

Encoding problem: why is the response gbk displayed when it is UTF-8? Http://parttime.wengege.com/h/login.html

The response encoding is gbk and UTF-8.

HTTP/1.1 200 OK
Server: nginx/1.4.1
Date: Mon, 09 Jun 2014 15:28:28 GMT
Content-Type: text/html; charset = gbk, UTF-8
Content-Length: 1843
Last-Modified: Mon, 09 Jun 2014 15:28:16 GMT
Connection: keep-alive
ETag: "5395d290-733"
Accept-Ranges: bytes

This/login.html content can be opened with editplus as UTF-8. it has been saved as UTF-8 several times.

Where does the browser determine if it is gbk? So as to garbled characters?

Reply to discussion (solution)

Content-Type: text/html; charset = gbk, UTF-8 ???
Is there a character set declaration like this?
How does the browser know which are gbk and UTF-8?

Try another editor, such as Notepad or emeditor.

Content-Type: text/html; charset = gbk, UTF-8 ???
Is there a character set declaration like this?
How does the browser know which are gbk and UTF-8?

This is what I want to ask.
The above is not a declaration, but an http response.

Try another editor, such as Notepad or emeditor.

I changed several editors and saved them. It contains GBK characters. Therefore, UTF-8 is recognized as gbk. It's strange.
I have studied the code for 10 years. There has never been a problem with coding.
The above problem only occurs in linux and cannot be reproduced in windows.

In addition, I switched to another test Directory. The content is displayed in good condition.

Besides the status code, the content in the http header is declared.
If you
Header ('content-type: text/html; charset = gbk, utf-8 ');
Content-Type: text/html; charset = gbk, UTF-8

Default_charset of php. ini
Default_charset of httpd. conf
And so on.

It is estimated that the server is configured by default.
I can't figure out the problem.

If no code can be properly displayed on the same server, it should be a configuration problem.
If the code that can be normally displayed changes the normal code to the same content of the file, the problem may occur if it is abnormal.
If the text changed to this file can still be normally displayed, use a hexadecimal viewer to compare the two files.

It is estimated that the server is configured by default.
I can't figure out the problem.

If no code can be properly displayed on the same server, it should be a configuration problem.
If the code that can be normally displayed changes the normal code to the same content of the file, the problem may occur if it is abnormal.
If the text changed to this file can still be normally displayed, use a hexadecimal viewer to compare the two files.

There is no problem with other codes on my server.
And,
I can move this file to a directory and access it normally ....

Http://parttime.wengege.com/h/test.html
The above connection is also, there are garbled characters in chrome (garbled characters when JS is introduced, and the strange thing is that other garbled characters are good ). It is completely normal in ie.

Nginx configuration problems? Test it with apache?

The conclusion is self-evident.

The login template file is UTF-8 encoded, but the php program header declaration or the server default configuration output response header is gbk, UTF-8, webkit and chrome garbled, and IE is normal
The test template file is gb2312 encoded, the response header is still gbk, UTF-8, and the ninth floor will appear.

I guess webkit and chrome recognize encoding. the response header takes precedence over header declaration in DOM, while IE is the opposite.
I can see that the js file response header charset on the landlord server is both gbk and UTF-8, which should be the default output of the server.

After reading the above back ?, Think of one ???.
? No? At ?? Object? Yes? Set. htaccess in. htaccess? What if default charset is set?

The conclusion is self-evident.

Yes. Where did GBK come from? Where does GBK come from? Moderator. Dear. Wrong direction. I am also thinking, where did GBK come from?
I know the problem occurs on GBK. GBK is the result, not the beginning.

After reading the above back ?, Think of one ???.
? No? At ?? Object? Yes? Set. htaccess in. htaccess? What if default charset is set?

I checked it yesterday and did not find it. There is an encoding problem in the htaccess file.

The login template file is UTF-8 encoded, but the php program header declaration or the server default configuration output response header is gbk, UTF-8, webkit and chrome garbled, and IE is normal
The test template file is gb2312 encoded, the response header is still gbk, UTF-8, and the ninth floor will appear.

I guess webkit and chrome recognize encoding. the response header takes precedence over header declaration in DOM, while IE is the opposite.
I can see that the js file response header charset on the landlord server is both gbk and UTF-8, which should be the default output of the server.

No header issue found. There is no login template. This is common html, not a template. Thanks for your attention.

No
. Htaccess
Adddefacharcharset gbk
Adddefacharcharset UTF-8
The result is Content-Type: text/html; charset = utf-8
That is, only the last command is valid.

However, if
Adddefacharcharset gbk, UTF-8
It is Content-Type: text/html; charset = gbk, UTF-8

So the problem went around again, and the character set declaration was set, not built-in.

After reading the above back ?, Think of one ???.
? No? At ?? Object? Yes? Set. htaccess in. htaccess? What if default charset is set?

Now the problem is: All files have been checked (css, php, js) and are determined to be UTF-8 encoded.
There are several questions that may not be fixed:
1. the common html is UTF-8 encoded. The http response is gbk and UTF-8, so garbled characters appear. Where does gbk come from? Where are these three characters?
I have searched the whole site for the three GBK characters. No !!!
2. even if html is successful occasionally, the introduction of js is garbled. UTF-8 encoding is specified.

3. check the w3c bad website. The "successfully identified" code is still "gbk", and the w3c website crashes countless times.

It's amazing. the check result says there is a problem with a line. I typed all the characters again. Log on to the thinkphp3.1 file in another directory. However, running this html in thinkphp3.2 is not normal. The key is that the relationship between html and thinkphp cannot be reached?

Your js files also contain Content-Type: text/html; charset = gbk, UTF-8
Apparently it's something in the web server configuration file.
You can find the gbk in the server configuration file.

If you really don't want to find it, add it to. htaccess.
Adddefacharcharset UTF-8

This overwrites the original settings.

Try again when you save it without bom. I caught the packet and found that your html has a bom header.

New discoveries: even browsers with bom headers will be grayed out by selecting the encoding menu?

No header issue found. There is no login template. This is common html, not a template. Thanks for your attention.

The same is true for html and templates ~ Bytes is UTF-8). In addition, if you change to another test Directory, the content is displayed in good condition. Is it because the file is gbk encoded? As for the most critical reason why the response header gbk is out of my knowledge, take a look.

The cause is that charset gbk and UTF-8 are used for nginx website configuration. Remove gbk and then OK. So garbled solutions.

The cause is that charset gbk and UTF-8 are used for nginx website configuration. Remove gbk and then OK. So garbled solutions.

The configuration problem was raised on the 10th floor at the beginning, and the weak sense of presence was ignored.

In addition, I switched to another test Directory. The content is displayed in good condition.

By? Sentence ?? .

? Object ?,?? Yes? Outbound ?? . Because? The default charset is gbk, utf8.

The nginx configuration you mentioned is too big. Configuration refers to the configuration of this virtual host. There are many websites on nginx, and there are no other problems.

The cause is that charset gbk and UTF-8 are used for nginx website configuration. Remove gbk and then OK. So garbled solutions.

The configuration problem was raised on the 10th floor at the beginning, and the weak sense of presence was ignored.

In addition, I switched to another test Directory. The content is displayed in good condition.

By? Sentence ?? .

? Object ?,?? Yes? Outbound ?? . Because? The default charset is gbk, utf8.

After changing the directory, I don't know how to add the bom header, so I can.

The nginx configuration you mentioned is too big. Configuration refers to the configuration of this virtual host. There are many websites on nginx, and there are no other problems.

Other websites are okay. on the 12th floor, we mentioned that the js file response header is gbk and UTF-8, which instantly locks the target ~
You have been studying php scripts and BOM for a long time, and it's hard for new people to look at you with resentment.