If you search "Apache configuration" on the Internet, most of the pages you search will suggest that you add a httpd.conf: Adddefaultcharset GB2312. For beginners and developers who only use GB2312 coding, this is OK.
However, 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″ this piece of code. When you open the browser to visit the test.php page, you will see the exact page. But what if in fact the browser still interprets the response returned from the server in GB2312 encoding? The reason is that the browser is based on HTTP content-type:text/html in the head of the reply message; charset=gb2312 to decide which encoding to use to explain the answer, that is, the Apache server still uses GB2312 encoding to pass data.
So if Apache's default character set is set to GB2312, even if the UTF-8 encoding is declared on the page, the Apache server will send the HTTP response according to the GB2312 code.
It doesn't matter, we change adddefaultcharset GB2312 to Adddefaultcharset UTF-8, see what result. If you see the garbled code congratulations, you also know is garbled problem; If you see a blank page, then you are miserable, you may think that this is caused by other reasons, and not from the point of view of coding to solve the problem. That's why.
The reason is that the PHP file itself is encoded with the system character set, and Windows XP in Chinese is GB2312, and each file header has a field indicating which fangping encoded the file. When Apache receives a request from the browser, PHP is asked to explain the requested page, such as test.php. PHP will recognize the test.php code fangping GB2312 (just as we use Javac to compile Java source files, the compiler defaults to reading the contents of the source file with the system encoding. If the source file is not saved with system code, you can specify the specific encoding with the command javac-encoding, and the data is passed to Apache in a GB2312 encoded format, and the Apache server does not change the data from PHP, but only in reply In the message head, set the character set to UTF-8: content-type:text/html; Charset=utf-8. That is, you are passing the GB2312 encoded data, while the browser interprets the welcome message with UTF-8 Code.
Since UTF-8 represents a man for 3 bytes, the average GB2312 or BIG5 is two. Page output, due to the above reasons, the situation of half Chinese characters, then the half of the Chinese characters will be combined with the > into a garbled word, resulting in IE can not read the words, will find that in fact the entire leaf has been exported. If the use of Mozilla, Mozilla Firefox, Sarafi Browser This will not cause this problem, but a heap of garbled. This is due to the Firefox browser and IE parsing page encoding strategy is different.
Ok we put test.php to UTF-8 save, and then use browser access, there is no problem. By doing so, all web accessibility under the Apache header can only be encoded in the same way.
How to fix it.
Solution:
First, you can use adddefaultcharset off to turn off the default file encoding so that the Apache server does not set charset on the HTTP welcome message header, just set the content-type:text/html. The browser relies on the Harset set in the HTML file to determine the encoding. Second, the script php.ini file Default_charset = "Utf-8″ function with httpd.conf file, comment out the line, so that PHP automatically identify the file encoding fangping."
So no matter what code you use Fangping, as long as the test.php in the
Meta http-equiv= "Content-type" content= "text/html;" Charset=utf-8″ and you test.php file encoding fangping the same, will not produce garbled problem.
User-submitted data encoding
The character encoding submitted by the browser is determined by the Characher encoding of the client. For example, the current browser's encoding is Gb2312, after the user submits the data, regardless of the Apache set encoding fangping Soul GB2312 or UTF-8, then the server received is still in Gb2312 encoded data. If you want to display the data that the user just submitted on the return page, and the page is encoded with UTF-8, or the user submits the data to be stored in the database, and the database is UTF-8 encoded, the character conversion is necessary.