高手請進，無數高手完全弄不懂的編碼問題.神奇的亂碼

也就是此貼，http://bbs.csdn.net/topics/390807783?page=1#post-397542169

此貼有詳細描述。解決此問題人可以得240分。這麼個小問題，困擾二三天了，我已經從http底層看了資料包，依然無法解決。
-------------------------------------------------------------------------------------------
無數高手搞不定的（亂碼）編碼問題：只有在代碼放入linux下用chrome訪問時才亂碼。其它任何情況正常。
windows下任何瀏覽器下無任何問題。
linux下。只有chrome訪問出現亂碼。（手工修改chrome編碼當然可以正常顯示了。）
-----------------------------------
http://parttime.wengege.com/h/login.html

響應編碼居然為：gbk,utf-8.

HTTP/1.1 200 OK
Server: nginx/1.4.1
Date: Mon, 09 Jun 2014 15:28:28 GMT
Content-Type: text/html; charset=gbk,utf-8
Content-Length: 1843
Last-Modified: Mon, 09 Jun 2014 15:28:16 GMT
Connection: keep-alive
ETag: "5395d290-733"
Accept-Ranges: bytes

此/login.html內容用editplus開啟看為utf-8.也已經另存新檔好幾次為utf-8了。

是哪裡讓瀏覽器判斷是gbk了呢？從而亂碼？

-------------------------
引用 2 樓 changjay 的回複:
換一個編輯器試試，比如記事本或者emeditor之類的
我換了幾個編輯器儲存了。w3c檢查裡面有GBK字元。所以將utf-8識別為gbk了。真是奇怪了。無數次另存新檔轉化過。

http://parttime.wengege.com/h/test.html
上面串連也是，在chrome下有亂碼（JS引入時有亂碼，奇怪的是其它部分亂碼好了）。在ie下完全正常。
----------------------------------------------------
現在問題是：所有檔案都檢查過了(css,php,js)，確定為utf-8編碼。
有幾個問題搞不定：
一、普通的html為utf-8編碼。http響應居然為gbk,utf-8.所以出現亂碼。問題是gbk哪來的？這三個字元哪來的?
我已經全站搜尋GBK這三個字元。無獲！！！
二、就算html偶爾成功後，但引入js還是亂碼。指定引入編碼為utf-8.

三、通過w3c爛網站檢查，“成功識別”編碼依然為 “gbk”. 然後w3c網站無數次崩潰。

真是神奇，檢查結果說某行有問題。所有字元我從新打過，還是如此。換個目錄的檔案thinkphp3.1的登入還是正常。而thinkphp3.2下運行此html就是不正常。關鍵是這html和thinkphp毛關係都扯不上啊？

回複討論(解決方案)

也許是apache的配置問題吧，記得apache配置中有字元集的設定的

又來了？
windows下任何瀏覽器下無任何問題。這話說的太武斷！
這是 XP 360極速瀏覽器的


我不否認 IE 中為沒有問題
這是因為 IE 有強大的字元集識別功能，完全可以忽視 Content-Type: text/html; charset 的影響
這就是網景倒閉的原因之一。
而那些在網景倒閉時公布的瀏覽器代碼（10餘兆c程式）基礎上建立起來的各種瀏覽器，由於微軟專利的原因，是無法解決這個問題的
當然這是題外話，不在討論的序列中

你還是要找到在哪裡會有 charset=gbk 的
不要過分相信工具軟體，最好手工逐行尋找。畢竟設定檔也就哪幾個

但也不排除你而外安裝了什麼外掛程式，造成了這種情況

此問題在我本機上完美重現
只要是login.html儲存為utf-8編碼無BOM，必定亂碼。儲存時保留BOM，側無亂碼。用UltraEdit反覆測試多次，均如此。

關鍵是你以前的項目有沒有這種情況！ 如果沒有那就是代碼問題，如果也有，那可能是服務端問題、作業系統問題或者壓根就是你代碼輸入的有錯誤(原先sql語句裡錯了一個字母，折騰一天，因為覺得自己不能犯小錯誤，實際上還是犯了！)

沒什麼實質性的東西，我的一點建議，主要是看看到底是代碼原因，還是運行環境的原因！

此問題在我本機上完美重現
只要是login.html儲存為utf-8編碼無BOM，必定亂碼。儲存時保留BOM，側無亂碼。用UltraEdit反覆測試多次，均如此。

怎麼保留BOM 謝謝

檢查一下nginx.conf設定檔？有沒有gbk？

又來了？
windows下任何瀏覽器下無任何問題。這話說的太武斷！
這是 XP 360極速瀏覽器的

xu大，我感覺樓主指的是windows上的伺服器，既然換伺服器沒事，估計就是nginx哪裡的配置或者模組幹擾了吧？

此問題在我本機上完美重現
只要是login.html儲存為utf-8編碼無BOM，必定亂碼。儲存時保留BOM，側無亂碼。用UltraEdit反覆測試多次，均如此。

怎麼保留BOM 謝謝

用UltraEdit另存新檔，格式選 'UTF-8' 是保留，選 'UTF-8 -無BOM' 是不保留。

不要幹擾人家的判斷

$url = 'http://parttime.wengege.com/h/login.html';$s = file_get_contents($url, false, null, 0, 10);//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

顯然
3c21444f435459504520 是沒有 BOM 頭的
efbbbf3c21444f435459 是有 BOM 頭的

BOM 頭對於瀏覽器而言，至多會影響到顯示樣式，而不會造成亂碼

$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無BOM頭

BOM 頭對於瀏覽器而言，至多會影響到顯示樣式，而不會造成亂碼

這可說不說，伺服器返回是gbk,utf8這樣的編碼，如果沒有BOM頭來說明，是按gbk顯示還是按utf8顯示？明顯這裡是按gbk來顯示的。

又來了？
windows下任何瀏覽器下無任何問題。這話說的太武斷！
這是 XP 360極速瀏覽器的


我不否認 IE 中為沒有問題
這是因為 IE 有強大的字元集識別功能，完全可以忽視 Content-Type: text/html; charset 的影響
這就是網景倒閉的原因之一。
而那些在網景倒閉時公布的瀏覽器代碼（10餘兆c程式）基礎上建立起來的各種瀏覽器，由於微軟專利的原因，是無法解決這個問題的
當然這是題外話，不在討論的序列中

你還是要找到在哪裡會有 charset=gbk 的
不要過分相信工具軟體，最好手工逐行尋找。畢竟設定檔也就哪幾個

但也不排除你而外安裝了什麼外掛程式，造成了這種情況

謝謝你版主。
我的意思是代碼在windows下運訪問不會有任何問題。
你看到的是在linux下啟動並執行，就是有問題。

ob_start();
header("Content-Type: text/html; charset=gbk,utf8");
echo "測試文本";
ob_flush();
?>
儲存為無BOM和有BOM，就會亂碼和正常

檢查一下nginx.conf設定檔？有沒有gbk？

又來了？
windows下任何瀏覽器下無任何問題。這話說的太武斷！
這是 XP 360極速瀏覽器的

xu大，我感覺樓主指的是windows上的伺服器，既然換伺服器沒事，估計就是nginx哪裡的配置或者模組幹擾了吧？

是的，這位兄弟正解，版主大人，熬夜太多，水平是極高的，但精神恍惚，最近回複 我問題時，理解的和我說的恰好相反。
我講了很多次是響應，xu大說是請求，還給我列了很例子。.... 我指的windows伺服器。他說是windows下訪問。我說gbk是自動產生的。他說gbk是我手工設定的。..... 正好和我相反。

也許是apache的配置問題吧，記得apache配置中有字元集的設定的

同樣的ngnix配置下，其它項目都沒有問題，差不多代碼。

經測試，儲存為utf-8 +bom 可以解決此問題。但原因何在呢？有人能夠解釋嗎？

header("Content-Type: text/html; charset=gbk,utf8");
是發出回應的頭

get_headers(url)
得到的 Content-Type: text/html; charset=gbk,utf8
是伺服器的響應

我什麼時候說過請求啦？
相應的頭不是你設定的嗎？放在設定檔裡自動發出，也是你設定的

我一點都沒搞混，而是你自己忙暈了！
你換了伺服器就正常了，這恰恰表示了出問題的伺服器的配置有問題！

以前的相同的代碼，還有其它一些html代碼，都是沒有bom頭的，也沒有亂碼。

關鍵是你以前的項目有沒有這種情況！ 如果沒有那就是代碼問題，如果也有，那可能是服務端問題、作業系統問題或者壓根就是你代碼輸入的有錯誤(原先sql語句裡錯了一個字母，折騰一天，因為覺得自己不能犯小錯誤，實際上還是犯了！)

沒什麼實質性的東西，我的一點建議，主要是看看到底是代碼原因，還是運行環境的原因！

以前沒有這樣情況

此問題在我本機上完美重現
只要是login.html儲存為utf-8編碼無BOM，必定亂碼。儲存時保留BOM，側無亂碼。用UltraEdit反覆測試多次，均如此。

是啊，兄台找到結果了。但原因何在？這也是我想知道的問題。

其實誰也沒有找到原因，只是觀察到一些現象
Content-Type: text/html; charset= gbk,utf8
這個 gbk 才是真正的原因，只不過你不肯需找他的來源罷了

為什麼發出gbk，不在伺服器上翻，估計誰也沒法說出具體原因。

xuzuning版主正解！
問題原因找到，是nginx此網站配置時使用了charset gbk,utf-8 這樣設定了。去掉gbk就ok了。所以亂碼解決。
是我在thinkphp網站有一個網友和我碰到同樣問題。提醒我上伺服器上查看設定檔解決的。

header("Content-Type: text/html; charset=gbk,utf8");
是發出回應的頭

get_headers(url)
得到的 Content-Type: text/html; charset=gbk,utf8
是伺服器的響應

我什麼時候說過請求啦？
相應的頭不是你設定的嗎？放在設定檔裡自動發出，也是你設定的

我一點都沒搞混，而是你自己忙暈了！
你換了伺服器就正常了，這恰恰表示了出問題的伺服器的配置有問題！

謝謝！！！

當然，版主也同時提醒我看伺服器上設定檔了。xu大，早點提醒我就好了。

如果是ngix charset ?置??，?甚???folder放就可以呢？ ??folder??也是用同一?charset的。所以之前才想是不是有.htaccess影??前folder。就是因???，?我?有?得是default charset?置??。

你說你的檔案確實儲存的是UTF8，好像每個頁面的mate標籤是可以設定瀏覽的編碼的，會不會是設定了GBK
或者是後台代碼輸出的字元是GBK？

你用的是cms嗎？是不是從gbk轉成utf8的

其實我對php不熟悉，也只是猜測 猜測哈

