PHP自動判斷字元集並轉碼_PHP教程

原理很簡單，因為gb2312/gbk是中文兩位元組，這兩個位元組是有取值範圍的，而utf-8中漢字是三位元組，同樣每個位元組也有取值範圍。而英文不 管在何種編碼情況下，都是小於128，只佔用一個位元組（全形除外）。

如果是檔案形式的編碼檢查，還可以直接check utf-8的BOM資訊。話不多說，直接上函數，這個函數是用來對字串進行檢查和轉碼的。

關於BOM

位元組順序記號（英：byte-order mark，BOM）是位於碼點 U+FEFF 的統一碼字元（"零寬度無斷空白"）。當以 UTF-16 或 UTF-32 來將UCS/統一碼字元所組成的字串編碼時，這個字元被用來標示其位元組序。它常被用來當做標示檔案是以 UTF-8 、 UTF-16 或 UTF-32 編碼的記號。

在大部分的字元編碼中，位元組順序記號是一個不太可能出現在其它檔案的樣式（它通常看起來像是一個混淆的控制碼的序列）。如果位元組順序記號被誤解成統一碼檔案中真正的字元時，那麼它將不可視，因為它是零寬度無斷空白。在 Unicode3.2 中， U+FEFF 用於非位元組順序記號的用途已被捨棄（取而代之的是，使用 U+2060 來表示這種用途），以容許 U+FEFF 僅被地用於位元組順序記號的語意。

在 UTF-16 中，位元組順序記號被放置為檔案或字串流的第一個字元，以標示在此檔案或字串流中，以所有十六位元為單位的字碼的尾序（位元組順序）。

• 如果十六位元單位被表示成大尾序，這位元組順序記號字元在序列中將呈現 0xFE ，其後跟著 0xFF（其中的 0x 用來標示十六進位）。
• 如果十六位元單位使用小尾序，這個位元組序列為 0xFF ，其後接著0xFE。

而統一碼中，值為U+FFFE 的碼位被保證將不會被指定成一個統一碼字元。這意味著 0xFF 、 0xFE 將只能被解釋成小尾序中的U+FEFF（因為不可能是大尾序中的 U+FFFE ）。

UTF-8 則沒有位元組順序的議題。UTF-8編碼過的位元組順序記號則被用來標示它是 UTF-8 的檔案。它只用來標示一個 UTF-8 的檔案，而不用來說明位元組順序。[1] 許多 視窗 程式（包含記事本）會添加位元組順序記號到 UTF-8 檔案。然而，在 類Unix系統 系統（大量使用 en:text file ，用於 檔案格式 ，用於行程間通訊）中，這種作法則不被建議採用。因為它會妨礙到如解譯器指令碼開頭的 en:Shebang 等的一些重要的碼的正確處理。它亦會影響到無法識別它的程式設計語言。如 gcc 會報告源碼檔開頭有無法識別的字元。而在 PHP 中，如果沒有啟用輸出緩衝(output buffering)，它會使得頁面內容開始被送往瀏覽器(即：使用者標題檔已被送出)，這使 PHP 指令碼無法指定使用者標題檔(HTTP Header)。位元組順序記號在 UTF-8 中被表示為序列 EF BB BF，對大部分未準備好處理 UTF-8 的 文字編輯器 及 網頁瀏覽器 而言，在 ISO-8859-1 的環境中則會顯示 ??? 。

雖然位元組順序記號亦可以用於 UTF-32 ，但這個編碼很少用於傳輸，其規則如同 UTF-16 。對於已於IANA註冊的字元集 UTF-16BE、UTF-16LE 、 UTF-32BE 和 UTF-32LE 等來說，不可使用位元組順序記號。文檔開頭的 U+FEFF 會被解釋成一個（已捨棄的）"零寬度無斷空白"，因為這些字元集的名字已決定了其位元組順序。對於登入字元集 UTF-16 和 UTF-32 來說，一個開頭的 U+FEFF 則用來表示位元組順序。

http://www.bkjia.com/PHPjc/752415.htmlwww.bkjia.comtruehttp://www.bkjia.com/PHPjc/752415.htmlTechArticle原理很簡單，因為gb2312/gbk是中文兩位元組，這兩個位元組是有取值範圍的，而utf-8中漢字是三位元組，同樣每個位元組也有取值範圍。而英文不 管在...

