今天，我特地到facebook.com的HTML代碼，並發現了這樣的事情：Facebook字符集檢測機制？
<input type="hidden" value="€,´,€,´,水,Д,Є" name="charset_test"/>
它重複<form>...</form>內兩次。
任何想法這個代碼可能會有用 - 某種服務器端客戶端字符集檢測？據我所知，無論如何，瀏覽器字符集都是通過HTTP請求傳輸的（一個「Accept-Charset」頭文件）。
任何想法，這段代碼可能是有用的 - 某種服務器端的客戶端字符集檢測的？
顯然是這樣。
歐元符號爲字符集探測有用窗口-125X編碼
據我所知，瀏覽器的字符集被在HTTP請求無論如何（一個「接收字符集」報頭）來發送。
它應該在HTTP Content-Type頭中發送的，但這並不意味着用戶代理實際上得到它的權利。
我猜他們在接收腳本中匹配這個，以確保客戶端正確地發送了編碼爲UTF-8的請求，甚至可能是因爲他們知道預期的字符，以實時檢測實際的編碼。
如果我沒有記錯 - 我不得不處理一次 - 在某些情況下，IE6中的表單編碼存在問題。
€,´,€,´,水,Д,Є
我猜有些瀏覽器發送€一樣€和´一樣´，
因此，他們可以檢查像charset_test [0] == charset_test [2]和charset_test [1] == charset_test [ 3]
對於其他人物，我不知道。水可能測試CJK。
正如Pekka所說，這是爲了能夠檢測請求字符集。 HTTP協議不提供指定請求字符集的方法。因此，人們必須依賴協議之外的約定。通常瀏覽器是可預測的，但這個訣竅是百分之百確定的唯一方法。
謝謝，我要去google關於這個IE6相關的表單問題。 – Void 2010-01-06 12:30:38
我可能是錯的，但我認爲它是關於不明確的編碼的東西（即當內容類型標題說明與內容類型META標籤不同時）。無論如何，我認爲Facebook正在這樣做，因爲他們正在被各種客戶訪問，他們需要確保他們的編碼是正確的。 – 2010-01-06 12:59:38