unicode規範中有乙個bom的概念。bom——byte order mark，就是位元組序標記。在這裡找到一段關於bom的說明：
在ucs 編碼中有乙個叫做"zero widthno-break space"的字元，它的編碼是feff。而fffe在ucs中是不存在的字元，所以不應該出現在實際傳輸中。ucs規範建議我們在傳輸位元組流前，先傳輸字元"zero widthno-break space"。這樣如果接收者收到feff，就表明這個位元組流是big-endian的；如果收到fffe，就表明這個位元組流是little-endian的。因此字元"zero width no-break space"又被稱作bom。
utf-8不需要bom來表明位元組順序，但可以用bom來表明編碼方式。字元"zero width no-breakspace"的utf-8編碼是ef bb bf。所以如果接收者收到以ef bb bf開頭的位元組流，就知道這是utf-8編碼了。
windows就是使用bom來標記文字檔案的編碼方式的。
另外unicode**的faq-bom詳細介紹了bom。官方的自然權威，不過是英文的，看起來比較費勁。
utf-8編碼的檔案中，bom佔三個位元組。如果用記事本把乙個文字檔案另存為utf-8編碼方式的話，用ue開啟這個檔案，切換到十六進製制編輯狀態就可以看到開頭的fffe了。這是個標識utf-8編碼檔案的好辦法，軟體通過bom來識別這個檔案是否是utf-8編碼，很多軟體還要求讀入的檔案必須帶bom。可是，還是有很多軟體不能識別bom。我在研究firefox的時候就知道，在firefox早期的版本裡，擴充套件是不能有bom的，不過firefox 1.5以後的版本已經開始支援bom了。現在又發現，php也不支援bom。
php在設計時就沒有考慮bom的問題，也就是說他不會忽略utf-8編碼的檔案開頭bom的那三個字元。由於必須在<?或者<?php後面的**才會作為php**執行，所以這三個字元將會直接輸出。如果外掛程式的檔案有這個問題，將會導致在後台頁面裡啟用或者不啟用外掛程式後顯示白屏，如果是模版檔案有這個問題，將會導致這三個字元直接輸出，造成頁面上方有乙個小空行。國外的英文外掛程式和模版一般都是用的ascii碼的編碼方式，不會有bom，只有國內的外掛程式和模版會由於作者的不知情造成問題。還有，大家修改模版的時候，由於輸出頁面使用utf-8編碼，那麼修改模版的時候如果有加入中文字元的話，必須把檔案轉成utf-8編碼才能正常顯示，這個時候如果所使用的編輯器自動加上了bom的話，將會造成在頁面上輸出這三個字元，顯示效果就要看瀏覽器了，一般是乙個空行或是乙個亂碼。
在c++builder中如果需要把寬字串輸出到文字檔案中，可以這麼做：
這樣用windows記事本可直接檢視該字串。
BOM中的位置屬性
clientx 以瀏覽器左上頂角為原點，定位 x 軸座標 clienty 以瀏覽器左上頂角為原點，定位 軸座標 offsetx 以當前事件的目標物件左上角為原點，定位x軸座標 offsety 以當前事件的目標物件左上角為原點，定位y軸座標 pagex 以document 物件 即文字視窗 左上角為原...
php 頭bom 關於php中bom頭的簡介
關於php中bom頭的簡介 閱讀 99 這篇文章主要介紹關於php中bom頭的簡介，文中示例 介紹的非常詳細，具有一定的參考價值，感興趣的小夥伴們一定要看完！bom頭是一串隱藏的字元，用於讓記事本等編輯器識別這個檔案是否以utf 8編碼。php不會忽略bom，所以在讀取 包含或者引用這些檔案時，會把...
規範化程式設計 ANSI和UNICODE的使用
到底什麼是ansi，什麼是unicode呢？其實這是兩種不同的編碼方式標準，ansi中的字元採用8bit，而unicode中的字元採用16bit。8bit的ansi編碼只能表示256種字元，表示26個英文本母是綽綽有餘的，但是表示漢字，南韓語，日語等有著成千上萬個字元的非西方字元肯定就不夠了，正是如...