Http://parttime.wengege.com/h/login.html
The response code is actually: Gbk,utf-8.
http/1.1 OK
server:nginx/1.4.1
Date:mon, June 15:28:28 GMT
content-type:text/html; Charset=gbk,utf-8
content-length:1843
Last-modified:mon, June 15:28:16 GMT
Connection:keep-alive
ETag: "5395d290-733"
Accept-ranges:bytes
This/login.html content is opened with EditPlus for Utf-8. Has also been saved as several times for Utf-8.
Where does it make the browser judge GBK? So garbled?
Reply to discussion (solution)
content-type:text/html; Charset=gbk,utf-8???
Do you have such a character set declaration?
How does the browser know which ones are GBK and which are utf-8?
Try a different editor, like Notepad or EmEditor.
content-type:text/html; Charset=gbk,utf-8???
Do you have such a character set declaration?
How does the browser know which ones are GBK and which are utf-8?
That's exactly the question I'm going to ask.
The above is not a declaration, it is an HTTP response.
Try a different editor, like Notepad or EmEditor.
I changed a few editors to save. There are GBK characters inside. So the 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 appears on Linux and cannot be reproduced under Windows.
Also, I switched to the other test directory. The content is displayed intact.
The contents of the HTTP header are declared in addition to the status codes.
If you
Header (' Content-type:text/html;charset=gbk,utf-8 ');
There will be content-type:text/html;charset=gbk,utf-8 in the HTTP cast.
PHP.ini's Default_charset
Httpd.conf's Default_charset
And so on, they can be set.
It is estimated that the server is configured by default
I can't figure out what's wrong.
If there is no code that can be displayed properly on the same server, it should be a configuration issue.
If there is a normal code to change the normal code to the same content of this file, not normal to see the problem changed the sentence
The text changed to the normal display of the words with a 16 binary viewer compared to two files
It is estimated that the server is configured by default
I can't figure out what's wrong.
If there is no code that can be displayed properly on the same server, it should be a configuration issue.
If there is a normal code to change the normal code to the same content of this file, not normal to see the problem changed the sentence
The text changed to the normal display of the words with a 16 binary viewer compared to two files
There is no problem with other codes on my server.
And
I will be able to access this file by moving directories ....
Http://parttime.wengege.com/h/test.html
The above connection is also, in Chrome under the garbled (JS introduced garbled, Strange is the other part garbled good). It's completely normal under IE.
Nginx configuration problem? Test Apache for a second?
The conclusion is self-evident.
The login template file is Utf-8 encoded, but the PHP program header declaration or server default configuration output response header is GBK, Utf-8, will appear webkit and chrome garbled, and IE normal
The test template file itself is gb2312 encoded, and the response header is still GBK, Utf-8, and the 9 floor situation will occur.
I guess that WebKit and chrome identify the code, the response header takes precedence over the header declaration in the DOM, and IE happens the opposite
I see the landlord server on the JS file response header CharSet are gbk,utf-8, should be the server default output problem
Read the above back, think of a???。
???? Htaccess, the default charset in the. htaccess??
The conclusion is self-evident.
Yes, where did GBK come from? The point is, where did GBK come from? Moderator. My dear. The direction was mistaken. I'm also thinking, where the hell did GBK come from?
I know the problem is on the GBK. GBK is the result, not the beginning.
Read the above back, think of a???。
???? Htaccess, the default charset in the. htaccess??
I checked it yesterday, but I didn't find it. There is a coding problem in the htaccess file.
The login template file is Utf-8 encoded, but the PHP program header declaration or server default configuration output response header is GBK, Utf-8, will appear webkit and chrome garbled, and IE normal
The test template file itself is gb2312 encoded, and the response header is still GBK, Utf-8, and the 9 floor situation will occur.
I guess that WebKit and chrome identify the code, the response header takes precedence over the header declaration in the DOM, and IE happens the opposite
I see the landlord server on the JS file response header CharSet are gbk,utf-8, should be the server default output problem
There is no problem finding the header anywhere. There is no login template at the same time. This is normal HTML, not a template. Thank you for your attention.
No
. In htaccess
Adddefaultcharset GBK
Adddefaultcharset Utf-8
The result is content-type:text/html; Charset=utf-8
That only the last instruction is valid
It is, if
Adddefaultcharset Gbk,utf-8
then is content-type:text/html; Charset=gbk,utf-8.
So the problem goes back, the character set declaration is set, not the built-in
Read the above back, think of a???。
???? Htaccess, the default charset in the. htaccess??
Now the problem is: All files have been checked (CSS,PHP,JS) and determined to be utf-8 encoded.
There are a few questions to make:
First, the normal HTML is UTF-8 encoded. HTTP response is actually gbk,utf-8. So garbled. The question is, where did GBK come from? Where did these three characters come from?
I have searched the entire site GBK these three characters. No wins!!!
Second, even if the HTML occasionally succeeds, but the introduction of JS or garbled. Specifies that the ingestion code is utf-8.
Third, through the website inspection, "Success identification" code is still "GBK". And then the Web site crashes countless times.
It was amazing, the test results said there was a problem with the line. All the characters I've ever beaten, or so. Change directory of the file thinkphp3.1 login or normal. and thinkphp3.2 running this HTML is not normal. The key is that the HTML and thinkphp hair relationship is not up to AH?
Your JS file also has content-type:text/html; Charset=gbk,utf-8
Apparently, it's inside the Web server configuration file.
You find the GBK word in the server configuration file, you should be able to find it.
If you really don't want to find it, just add it in. htaccess
Adddefaultcharset Utf-8
It's covered with the original settings.
You save when you choose No BOM and then try again, I grabbed the bag found your HTML has BOM header
New discovery: Have BOM header actually led to my browser, choose the coded menu dimmed?
There is no problem finding the header anywhere. There is no login template at the same time. This is normal HTML, not a template. Thank you for your attention.
HTML and templates The same thing ~ I guess the reason for the 2 problems, IE has been strong and not chaotic (the response header and Dom coding declaration of different priorities), And why the test text is not messy (perhaps test.html file is GBK encoding and login.html is Utf-8), in addition you said: I changed to the other test directory, the content is intact display. Will it also be the reason why the file became GBK encoded? As for the most critical why the response head has GBK beyond my knowledge, focus on learning
Problem reason found, is nginx this site configuration used charset Gbk,utf-8 so set up. It's OK to remove the GBK. So garbled solution.
Problem reason found, is nginx this site configuration used charset Gbk,utf-8 so set up. It's OK to remove the GBK. So garbled solution.
First on the 10 floor on the issue of configuration, a faint sense of existence is ignored
Also, I switched to the other test directory. The content is displayed intact.
Be a sentence?? The
What is the purpose???? It's all out. Of The default charset is Gbk,utf8.
Pro, you said the Nginx configuration, too big. The configuration I refer to is the configuration of this virtual host. This nginx has a lot of websites, other no problem.
Problem reason found, is nginx this site configuration used charset Gbk,utf-8 so set up. It's OK to remove the GBK. So garbled solution.
First on the 10 floor on the issue of configuration, a faint sense of existence is ignored
Also, I switched to the other test directory. The content is displayed intact.
Be a sentence?? The
What is the purpose???? It's all out. Of The default charset is Gbk,utf8.
After changing the directory, do not know how to add BOM head, so it can.
Pro, you said the Nginx configuration, too big. The configuration I refer to is the configuration of this virtual host. This nginx has a lot of websites, other no problem.
Other web site is OK, 12 floor on the mention JS file response head is Gbk,utf-8, instantly can lock target AH ~
You study a half-day PHP script and BOM, the newcomer is rare to look at you with a grudge