Solutions to website garbled characters caused by Apache default encoding errors

Recently, some people often encounter such encoding errors when using LAMP/WAMP:

Website A program code UTF-8 code installation successful, run successful.

B website program gb2312 must also be installed on the same server.

So there is A problem, Apache default encoding UTF-8 in the resolution of A site without any problem, when running B site when the "zookeeper text" garbled problem.

Simply modifying the default Apache code to gb2312 causes A website A to see the "invalid answer ".

Problem Analysis:

If you search for "apache configuration" on the Internet, we recommend that you add the following sentence to httpd. conf: adddefacharcharset GB2312.

This is OK for beginners who only use GB2312 encoding. But if you want to use the UTF-8 character set, for example, in the test. php file, you need meta http-equiv = "Content-Type" content = "text/html; charset = UTF-8" code.

In this case, if you open your browser to access the test. php page, you will see the correct page. But if the browser still uses GB2312 encoding to explain the response returned from the server, why? The reason is that the browser determines the encoding used to interpret the response based on the Content-type: text/html; charset = GB2312 in the http Response Message Header. That is to say, the apache server still uses GB2312 encoding to transmit data.

So if apache's default character set is set to GB2312, even if it is declared to use UTF-8 encoding on the page, the apache server still transmits http response according to GB2312 encoding. It doesn't matter. Let's change AddDefaultCharset GB2312 to adddefacharcharset UTF-8 to see what results?

If you see Garbled text, congratulations, you still know it's a garbled text problem; if you see a blank page, then you're miserable, you may think this is caused by other reasons, instead, we will not consider how to solve the problem from the encoding perspective. Why? The reason is that PHP files are encoded using the system character set. windows XP in Chinese uses GB2312. Each file header has a field to indicate the encoding method of the file. When apache receives a request from the browser, it will ask php to explain the requested page, such as test. php. Php will recognize that the encoding method of test. php is GB2312 (just like when we use javac to compile the java source file, the compiler uses the system encoding by default to read the content in the source file.

If the source file is not saved using system encoding, you can use the javac-encoding command to specify the specific encoding.) The data is transmitted to apache in GB2312 encoding format, the apache server does not change the data from php, but sets the character set to UTF-8: Content-type: text/html; charset = UTF-8 in the response message header. that is to say, you pass the GB2312 encoding data, but the browser is coded in UTF-8 to explain the Response Message.

Because the UTF-8 is 3 bytes to indicate a man, while the ordinary GB2312 or BIG5 is two. When the page is output, half a Chinese character may occur due to the above reasons. Then, the half Chinese character will be combined with the & gt; into a garbled character, which causes IE to fail to read the text, you will find that all the leaves have been output. If you are using Mozilla, Mozilla Firefox, and Sarafi browsers, this will not cause this problem, but a bunch of garbled characters. This is because the Firefox browser and IE parse webpage encoding policies are different. OK, we save test. php as a UTF-8, and then access the browser, there is no problem.

In this way, all web applications under the apache directory can only use the same encoding. How can this problem be solved?

Solution:

First, you can use adddefacharcharset off to disable the default file encoding, so that the apache server does not set charset in the http Response Message Header, but only sets Content-type: text/html. the browser depends on the harset set in the html file to determine the encoding.

Second, the default_charset = "UTF-8" in the script php. ini file works with the httpd. conf file, comment out the line, so that php automatically recognizes the file encoding method.

In this way, no matter what encoding method you use, you only need test. meta in php http-equiv = "Content-Type" content = "text/html; charset = UTF-8" with you test. PHP files are encoded in the same way. The character encoding submitted by the browser is determined by the characher encoding of the client.

For example, the current browser encoding is Gb2312, after the user submits the data, whether apache sets the encoding method is GB2312 or UTF-8, then the server side received the data is still in Gb2312 encoding.

If you want to display the data that the user just submitted on the return page, which is UTF-8-encoded or the data that the user submitted to store in the database, and the database is UTF-8-encoded, character conversion is required.