That's the sticker, http://bbs.csdn.net/topics/390807783?page=1#post-397542169.
This post is described in detail. The person who solves this problem can get 240 points. Such a small problem, troubled two or three days, I have read the packet from the HTTP bottom, still cannot solve.
-------------------------------------------------------------------------------------------
Countless master confused (garbled) coding problem: only in the code into Linux under the use of chrome access is garbled. Any other condition is normal.
There is no problem under any browser under Windows.
Linux under. Only chrome access appears garbled. (Manually modifying the chrome code will, of course, show up properly.) )
-----------------------------------
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?
-------------------------
Reference 2 Floor Changjay's reply:
Try a different editor, like Notepad or EmEditor.
I changed a few editors to save. There are GBK characters in the book. So the utf-8 is recognized as GBK. It's strange. Countless times saved as conversions.
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.
----------------------------------------------------
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?
Reply to discussion (solution)
Perhaps the configuration problem of Apache, remember that the Apache configuration has the character set of the
Not again?
There is no problem under any browser under Windows. This is too arbitrary to say!
This is the XP 360 speed browser
I don't deny that IE is not a problem
This is because IE has a powerful character set recognition function, can completely ignore content-type:text/html; Effects of CharSet
This is one of the reasons for the failure of Netscape.
The browser code (10 trillion C program), which was published on the basis of Netscape's collapse, was built on a variety of browsers, and because of the Microsoft patent, it was impossible to solve the problem.
Of course, this is a digression, not in the sequence of discussions.
You still have to find out where it's going to be CHARSET=GBK.
Do not trust the tool software too much, it is best to manually search by line. After all, the configuration files are just a few
But it doesn't rule out what plug-ins you have installed.
This problem is perfectly reproduced on my own machine.
As long as the login.html saved as utf-8 code without BOM, must be garbled. Keep BOM on save, no garbled on side. Repeated testing with UltraEdit, all the same.
The key is your previous project there is no such situation! If not, that is the code problem, if there is, it may be a service-side problem, operating system problems, or it is your code input error (the original SQL statement in the wrong letter, tossing the day, because feel that they can not make a small mistake, actually still committed!) )
Nothing substantial, my point of advice, mainly to see if it is the code, or the cause of the operating environment!
This problem is perfectly reproduced on my own machine.
As long as the login.html saved as utf-8 code without BOM, must be garbled. Keep BOM on save, no garbled on side. Repeated testing with UltraEdit, all the same.
How to keep BOM Thank you
Check the nginx.conf configuration file? Any GBK?
Not again?
There is no problem under any browser under Windows. This is too arbitrary to say!
This is the XP 360 speed browser
Xu Big, I feel that the landlord refers to the server on Windows, since the server is OK, the estimate is nginx where the configuration or module interference it?
This problem is perfectly reproduced on my own machine.
As long as the login.html saved as utf-8 code without BOM, must be garbled. Keep BOM on save, no garbled on side. Repeated testing with UltraEdit, all the same.
How to keep BOM Thank you
Save with UltraEdit, format select ' UTF-8 ' is reserved, select ' UTF-8-no BOM ' is not retained.
Don't disturb the judgment of others.
$url = ' http://parttime.wengege.com/h/login.html '; $s = file_get_contents ($url, false, NULL, 0,//echo bin2hex ($s); 3c21444f435459504520$url = ' http://parttime.wengege.com/h/test.html '; $s = file_get_contents ($url, false, NULL, 0, 10 ); Echo Bin2Hex ($s); efbbbf3c21444f435459
Obviously
3c21444f435459504520 is not a BOM header
efbbbf3c21444f435459 is a BOM head.
BOM header for the browser, at most will affect the display style, without causing garbled
$url = ' http://parttime.wengege.com/Public/js/search.js ';
$s = file_get_contents ($url, false, NULL, 0, 10);
echo Bin2Hex ($s); 2f2fe6a0b9e68daee7b1
/public/js/search.js No BOM head
BOM header for the browser, at most will affect the display style, without causing garbled
This can be said that the server returned is Gbk,utf8 such a code, if there is no BOM header to explain, is to press GBK display or press UTF8 display? Obviously this is shown by GBK.
Not again?
There is no problem under any browser under Windows. This is too arbitrary to say!
This is the XP 360 speed browser
I don't deny that IE is not a problem
This is because IE has a powerful character set recognition function, can completely ignore content-type:text/html; Effects of CharSet
This is one of the reasons for the failure of Netscape.
The browser code (10 trillion C program), which was published on the basis of Netscape's collapse, was built on a variety of browsers, and because of the Microsoft patent, it was impossible to solve the problem.
Of course, this is a digression, not in the sequence of discussions.
You still have to find out where it's going to be CHARSET=GBK.
Do not trust the tool software too much, it is best to manually search by line. After all, the configuration files are just a few
But it doesn't rule out what plug-ins you have installed.
Thank you moderator.
I mean the code is not going to have any problems with Windows down-shipment access.
What you see is running under Linux, which is a problem.
Ob_start ();
Header ("content-type:text/html; Charset=gbk,utf8 ");
echo "Test text";
Ob_flush ();
?>
Save as no BOM and BOM, will be garbled and normal
Check the nginx.conf configuration file? Any GBK?
Not again?
There is no problem under any browser under Windows. This is too arbitrary to say!
This is the XP 360 speed browser
Xu Big, I feel that the landlord refers to the server on Windows, since the server is OK, the estimate is nginx where the configuration or module interference it?
Yes, this brother is the solution, moderator, master, stay up too much, the level is very high, but in a trance, recently replied to my question, understand and I said exactly the opposite.
I spoke many times to respond, and Xu said it was a request, and gave me a list of examples. .... I mean the Windows Server. He said it was under Windows access. I say GBK is automatically generated. He said GBK I set it by hand. ..... Just the opposite of me.
Perhaps the configuration problem of Apache, remember that the Apache configuration has the character set of the
The same Ngnix configuration, the other projects are no problem, almost the code.
Tested, Save as Utf-8 +bom can resolve this issue. But why? Can anyone explain?
Header ("content-type:text/html; Charset=gbk,utf8 ");
Is the head of the response.
Get_headers (URL)
Get the content-type:text/html; Charset=gbk,utf8
Is the response of the server
When did I say the request?
is the corresponding header not set by you? Put it in the config file automatically, and you set it up.
I am not confused at all, but you are too busy to faint!
You changed the server is normal, this is exactly the problem of the server configuration problems!
Before the same code, there are some other HTML code, there is no BOM header, there is no garbled.
The key is your previous project there is no such situation! If not, that is the code problem, if there is, it may be a service-side problem, operating system problems, or it is your code input error (the original SQL statement in the wrong letter, tossing the day, because feel that they can not make a small mistake, actually still committed!) )
Nothing substantial, my point of advice, mainly to see if it is the code, or the cause of the operating environment!
There was no such situation before.
This problem is perfectly reproduced on my own machine.
As long as the login.html saved as utf-8 code without BOM, must be garbled. Keep BOM on save, no garbled on side. Repeated testing with UltraEdit, all the same.
Yes, brother Taiwan has found the result. But why? This is also the question I want to know.
In fact, no one found the reason, just observed some phenomena
content-type:text/html; charset= Gbk,utf8
This GBK is the real reason, but you won't need to find his source.
Why the issue of GBK, not on the server, it is estimated that no one can say the specific reasons.
Xuzuning Moderator Positive 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.
I was on the thinkphp website have a netizen and I encountered the same problem. Remind me to check the configuration file on the server to resolve.
Header ("content-type:text/html; Charset=gbk,utf8 ");
Is the head of the response.
Get_headers (URL)
Get the content-type:text/html; Charset=gbk,utf8
Is the response of the server
When did I say the request?
is the corresponding header not set by you? Put it in the config file automatically, and you set it up.
I am not confused at all, but you are too busy to faint!
You changed the server is normal, this is exactly the problem of the server configuration problems!
Thank you!!!
Of course, the moderator also reminds me to look at the server configuration files. Xu Big, remind me early.
If it is Ngix charset???????? Folder can be put on it??? Folder?? It's also charset with the same. So before I thought there was. htaccess shadow?? Front folder. Because of???, I have to be the default charset??。
You said that your files are really UTF8, as if the mate tag of each page can be set to browse the encoding, will not be set up GBK
Or is the background code output character GBK?
Are you using a CMS? Is it from GBK to UTF8?
In fact, I am not familiar with PHP, but also just guess guess ha