▪字節順序標記（ByteOrderMark）

BOM —— Byte Order Mark，中文名譯做「字節順序標記」。在這裏找到一段關於 BOM 的說明：

在UCS 編碼中有一個叫作 "Zero Width No-Break Space" ，中文譯名做「零寬無間斷間隔」的字符，它的編碼是 FEFF。而 FFFE 在 UCS 中是不存在的字符，因此不該該出如今實際傳輸中。UCS 規範建議咱們在傳輸字節流前，先傳輸字符 "Zero Width No-Break Space"。這樣若是接收者收到 FEFF，就代表這個字節流是 Big-Endian 的；若是收到FFFE，就代表這個字節流是 Little- Endian 的。所以字符 "Zero Width No-Break Space" （「零寬無間斷間隔」）又被稱做 BOM。

UTF-8 不須要 BOM 來代表字節順序，但能夠用 BOM 來代表編碼方式。字符 "Zero Width No-Break Space" 的 UTF-8 編碼是 EF BB BF。因此若是接收者收到以 EF BB BF 開頭的字節流，就知道這是 UTF-8編碼了。Windows 就是使用 BOM 來標記文本文件的編碼方式的。

字符U+FEFF若是出如今字節流的開頭，則用來標識該字節流的字節序，是高位在前仍是低位在前。若是它出如今字節流的中間，則表達零寬度非換行空格的意義，用戶看起來就是一個空格。從Unicode3.2開始，U+FEFF只能出如今字節流的開頭，只能用於標識字節序，就如它的名稱——字節序標記——所表示的同樣；除此之外的用法已被捨棄。取而代之的是，使用U+2060來表達零寬度無斷空白。

相似WINDOWS自帶的記事本等軟件，在保存一個以UTF-8編碼的文件時，會在文件開始的地方插入三個不可見的字符（0xEF 0xBB 0xBF，即BOM）。它是一串隱藏的字符，用於讓記事本等編輯器識別這個文件是否以UTF-8編碼。對於通常的文件，這樣並不會產生什麼麻煩。但對於 PHP來講，BOM是個大麻煩。

PHP並不會忽略BOM，因此在讀取、包含或者引用這些文件時，會把BOM做爲該文件開頭正文的一部分。根據嵌入式語言的特色，這串字符將被直接執行（顯示）出來。由此形成即便頁面的 top padding 設置爲0，也沒法讓整個網頁緊貼瀏覽器頂部，由於在html一開頭有這3個字符呢！

1不一樣編碼的字節順序標記的表示編輯

編碼	表示 (十六進制)	表示 (十進制)
UTF-8	EF BB BF	239 187 191
UTF-16（大端序）	FE FF	254 255
UTF-16（小端序）	FF FE	255 254
UTF-32（大端序）	00 00 FE FF	0 0 254 255
UTF-32（小端序）	FF FE 00 00	255 254 0 0
UTF-7	2B 2F 76和如下的一個字節：[ 38 | 39 | 2B | 2F ]	43 47 118和如下的一個字節：[ 56 | 57 | 43 | 47 ]
en:UTF-1	F7 64 4C	247 100 76
en:UTF-EBCDIC	DD 73 66 73	221 115 102 115
en:Standard Compression Scheme for Unicode	0E FE FF	14 254 255
en:BOCU-1	FB EE 28及可能跟隨着FF	251 238 40及可能跟隨着255
GB-18030	84 31 95 33	132 49 149 51

代碼的時候看到這樣一段
$template_content = str_replace(」/xEF/xBB/xBF」, 」, $template_content);
不知道是何做用,通過一番查找資料,終於解開了這個疑問
資料以下:

在window下面用記事本編輯文件的時候，若是保存爲UNICODE或UTF-8，分別會在文件的開頭加上兩個字節「/xFF/xFE」和三個字 節「/xEF/xBB/xBF」。在讀取的時候就可能會遇到問題，可是不一樣的環境對這幾個多於字符的處理也不同。(其餘的文本編輯工具也存在這個問題, 可是能夠選擇去除bom,如editplus的設置:參數選擇->文件->utf-8, 選擇老是刪除簽名)若是前面三個字符「/xef/xbb/xbf」則保存格式是utf-8若是前兩個字符是「/xff/xfe」則保存格式是UnicodeUnicode規範中有一個BOM的概念。BOM——Byte Order Mark，就是字節序標記。在這裏找到一段關於BOM的說明：在UCS 編碼中有一個叫作」ZERO WIDTH NO-BREAK SPACE」的字符，它的編碼是FEFF。而FFFE在UCS中是不存在的字符，因此不該該出如今實際傳輸中。UCS規範建議咱們在傳輸字節流前，先傳輸 字符」ZERO WIDTH NO-BREAK SPACE」。這樣若是接收者收到FEFF，就代表這個字節流是Big-Endian的；若是收到FFFE，就代表這個字節流是Little- Endian的。所以字符」ZERO WIDTH NO-BREAK SPACE」又被稱做BOM。UTF-8不須要BOM來代表字節順序，但可 以用BOM來代表編碼方式。字符」ZERO WIDTH NO-BREAK SPACE」的UTF-8編碼是EF BB BF。因此若是接收者收到以EF BB BF開頭的字節流，就知道這是UTF-8編碼了。Windows就是使用BOM來標記文本文件的編碼方式的。容易致使header session_star ob_start的問題,utf－8編碼的文件中，BOM佔3個字節，因爲php設計時沒有考慮BOM的問題，這三個字節會直接輸出，若是這時在程序裏調用了session函數，就會出問題了附： 文件應該使用 Unicode (UTF-8) 編碼保存。同時不要使用 字節序標記(BOM) 。與 UTF-16 和 UTF-32 不一樣，UTF-8 編碼的文件不須要指明字節序，並且 字節序標記(BOM) 在PHP中會產生預期以外的輸出，阻止了應用程序設置它本身的 頭信息。應該使用Unix 格式的行結束符(LF)。