最近經常有同學在使用LAMP/WAMP時，遇到這樣的編碼錯誤問題：
A網站程序編碼UTF-8編碼安裝成功，運行成功。
B網站程序編gb2312也要安裝在同一服務器上。
這樣就出現問題了，Apache默認編碼UTF-8在解析A網站的時候沒有任何問題，當運行B網站時出現的"蝌蚪文"亂碼問題。
單純的修改Apache默認編碼為gb2312這樣就導致A網站出現"蝌蚪文"。
問題分析：
如果你在網上搜索 “apache配置”，搜到的頁面大多都會建議你在httpd.conf中加上這麼一句：AddDefaultCharset GB2312。
對於新手而且是只用GB2312編碼的開發人來說，這麼做是ok的。但是如果要想使用UTF-8字符集的話，比如 在test.php文件中需要有 meta http-equiv="Content-Type" content="text/html; charset=UTF-8" 這段代碼。
這時你再打開浏覽器訪問test.php頁面的話，你看到的是正確的頁面。但是如果實際上浏覽器還是以GB2312編碼解釋從服務器返回的response，為什麼呢？原因是浏覽器是根據http應答消息頭部中的 Content-type: text/html; charset=GB2312 來決定使用何種編碼解釋應答，也就是說apache服務器仍然用GB2312編碼傳遞數據。
所以說如果apache的默認字符集被設置成了GB2312，即使在頁面中聲明使用UTF-8編碼，apache服務器還是會按照GB2312編碼來傳送http response。沒關系，我們把AddDefaultCharset GB2312 改成 AddDefaultCharset UTF-8，看看什麼結果？
如果你看到亂碼恭喜你，你還知道是亂碼問題；如果你看到是空白頁面，那麼你就慘了，你可能會以為這是其他什麼原因造成的，而不會從編碼的角度去考慮怎麼解決問題。這是為什麼？原因在於php文件本身是用系統字符集來編碼的，中文的windows XP都是用GB2312，每一個文件頭部都有字段指示該文件是用何種方式編碼的。當apache接到浏覽器的請求後，會讓php去解釋所請求的頁面，比如 test.php。php會識別出test.php的編碼方式是GB2312後(就像我們用javac編譯java源文件時，編譯器默認用系統編碼讀源文件裡的內容。
如果源文件不是用系統編碼來保存的，可以用命令javac -encoding指定具體的編碼)，把數據以GB2312的編碼格式傳遞給apache，而apache服務器不會改變從php傳來的數據，只是在應答消息頭部中把字符集設置成UTF-8： Content-type: text/html; charset=UTF-8. 也就是說你傳遞的是GB2312編碼的數據，而浏覽器卻以UTF-8編碼來解釋應答消息。
由於UTF-8為3個字節表示一個漢子，而普通的GB2312或BIG5是兩個。頁面輸出時，由於上述原因，出現半個漢字的情況，這時該半個漢字會和的>結合成一個亂碼字，導致IE無法讀完的話，會發現實際上整個葉面全部已經輸出了。如果使用的是Mozilla、Mozilla Firefox、Sarafi的浏覽器這不會造成這個問題，而是一堆亂碼。這是由於Firefox浏覽器和IE解析網頁編碼的策略不同產生的。OK,我們把test.php以UTF-8保存，再用浏覽器訪問時，就沒有問題了。
可這樣做，會使得apache目錄下的所有web應用只能用同一種編碼。如何搞定？
解決辦法：
首先，可以使用AddDefaultCharset off來關閉默認文件編碼，這樣apache服務器就不會在http應答消息頭部設置charset，只是設置Content-type: text/html. 而浏覽器就會依靠html文件中設置的harset來決定編碼。
其次，腳本php.ini文件中的default_charset = “UTF-8″作用同httpd.conf文件，把該行注釋掉，使php自動識別文件的編碼方式。
這樣不論你用什麼編碼方式，只要test.php中的meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″ 與你test.php文件編碼方式相同，就不會產生亂碼問題。用戶提交數據的編碼浏覽器提交的字符編碼由客戶端的characher encoding決定。
例如，當前浏覽器的編碼是Gb2312，用戶提交數據後，無論apache設置的編碼方式是GB2312還是UTF-8，這時在服務器端接收到的仍是以Gb2312編碼的數據。
如果要在返回頁面上顯示用戶剛才提交的數據，而該頁面是用UTF-8編碼的或者要在數據庫中存儲的用戶提交的數據，而數據庫是UTF-8編碼的，那就要做字符轉換了。
