<?php
function safeencoding($string,$outencoding ='utf-8')
{
$encoding = "utf-8";
for($i=0;$i
原理很簡單，因為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 中，位元組順序記號被放置為檔案或字串流的第乙個字元，以標示在此檔案或字串流中，以所有十六位元為單位的字碼的尾序（位元組順序）。
而統一碼中，值為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 則用來表示位元組順序。
PHP判斷字符集並轉碼的函式
function safeencoding string,outencoding utf 8 encoding utf 8 for i 0 i 原理很簡單，因為gb2312 gbk是中文兩位元組，這兩個位元組是有取值範圍的，而utf 8中漢字是三位元組，同樣每個位元組也有取值範圍。而英文不 管在何種...
PHP自動判斷字符集並轉碼的詳解
php自動判斷字符集並轉碼的例項參考。原理 因為gb2312 gbk是中文兩位元組，這兩個位元組是有取值範圍的，而utf 8中漢字是三位元組，同樣每個位元組也有取值範圍。而英文不 管在何種編碼情況下，都是小於128，只占用乙個位元組 全形除外 如果是檔案形式的編碼檢查，還可以直接check utf ...
關於PHP自動判斷字符集並轉碼的詳解
原理很簡單，因為gb2312 gb程式設計客棧k是中文兩位元組，這兩個位元組是有取值範圍的，而utf 8中漢字是三位元組，同樣每個位元組也有取值範圍。而英文不 管在何種編碼情況下，都是小於128，只占用乙個位元組 全形除外 如果是檔案形式的編碼檢查，還可以直接check utf 8的bom資訊。話不...