TaiwanTonguesApiRobot：從 JSON 檔案批量匯入

2025-08-22T02:21:50Z

從 JSON 檔案批量匯入

新頁面

'''位元組順序記號'''（英語：byte-order mark，'''BOM'''）是佇咧碼點 ` U + FEFF ` 的統一碼字元的名稱。當以 UTF 鋪十六抑是講 UTF 鋪三十二來將 UCS / 統一碼字元所組成的字串編碼時，這字元予人用來標示其位元組序。伊定定予人用來做標示檔案是以 UTF ma八、UTF 鋪十六抑是講 UTF 炕三十二編碼的記號。

位元組順序記號通常有幾種涵義：

一 . 佇咧十六位元佮三十二位元的情況下，文字流的位元組順序。
二 . 表示文字流非常有可能是 Unicode 編碼。
三 . 使用的是佗一種 Unicode 字元編碼。

位元組順序記號的使用是選擇性的。伊的存在會干擾遐的無希望檔案開頭出現非 ASCII 字元、但是會當用其他方式來處理文字流的軟體對 UTF 鋪八的使用。

Unicode 會當八个元、十六位元或者是三十二位元整數為單位進行偏碼。對十六位元佮三十二位元的表示方法，對任意來源接收文字的電腦需要知影整數是以何種位元組順序編碼的。位元組順序記號的編碼方式佮文件檔案的其他部份仝款，如果伊的位元組被調換，就會變一个非字元的 Unicode 碼位。所以，共存取文字的過程中，會當透過檢查這頭幾个位元組來確定位元組順序，不需要文字流本身以外的一寡約定抑是元資料。一般來講，若有必要，接收資料的電腦會將位元組換做家己的位元組順序，無閣需要位元組順序記號來進行處理。

彼每一个 Unicode 編碼（包括講 Unicode 標準以外的編碼，如 UTF 鋪七，見下表）的 BOM 位元組序列攏無仝，啊而且遮的序列攏無可能出現佇咧其他的編碼儲存的文字需要頭殼。所以，佇咧文字流的開頭囥一个編碼的 BOM，會當表明文字是 Unicode，並且捌別所使用的編碼方案。這種著 BOM 字元的使用予人號做「Unicode 簽名」。

==使用==

字元 U + FEFF 若出現佇咧位元組流的頭一个開始，則用來標識該位元組流的位元組序，是懸位佇頭前抑是低位佇頭前。若是伊出現佇元組流的中間，欲表達'''零寬度非換行空格'''的意義，使用者看起來就是一个空格。對 Unicode 三孵二開始，` U + FEFF ` 干焦會當出現佇咧位元組流的頭一張，只會當用佇標識位元組序，就佮伊的名—— 位元組順序記號—— 所表示的仝款；除了這以外的用法已經予人放捒。取代之的是，使用 ` U + 二千空六十 ` 來表達無停空白。

===UTF ma八===

佇咧 UTF 鋪八中，雖然講佇 Unicode 標準上允准位元組順序記號的存在，但實際上並無一定愛需要。UTF 鋪八編碼過的位元組順序記號是被用來標示伊是 UTF 鋪八的檔案。伊干焦標示一个 UTF 鋪八的檔案，毋免講明位元組順序。但是同時，該標準嘛無建議佇咧有一个位元組順序記號的情況之下共刪除，通好佇咧無仝的編碼之間轉換時陣袂擲失資訊，予依賴位元組順序記號的程式會當順利運作。IETF 建議喔，若是一个協定 ( a ) 總是使用 UTF ma八，抑是講 ( b ) 有一寡其他的方法來表明當咧使用的編碼，按呢伊「應該愛禁止使用 U + FEFF 做簽名」。
視窗的程式真濟（包含講記事本）會需要添加位元組順序記號到 UTF 鋪八檔案，若無會當確解析編碼，而出現亂碼。毋過，佇類 Unix 系統（大量使用文字檔案，用佇檔案格式，用佇行程間通訊）中，這種做法則無予人建議採用。因為伊會妨礙著若是解譯器指令碼頭的 Shebang 等的一寡重要的碼的正確處理。伊嘛會影響著無法度識別伊的程式語言。如 gcc 會報告原始碼檔開頭有無法度識別字元。啊若佇咧 PHP 中，若無啟用輸出緩衝（output buffering），伊會使得著頁面的內容開始送去瀏覽器（即：使用者標頭檔已經送出），這個使 PHP 指令碼無法度指定使用者標頭檔（HTTP Header）。位元組順序記號佇咧 UTF 鋪八中予人表示做序列 ` 零 xEF 零 xBB 零 xBF `，對大部份攏袂攢好處理 UTF 鋪八的文字編輯器佮網頁瀏覽器來講，佇咧 ISO 鋪八千八百五十九鋪一的環境內底會顯示 ` ï»¿ `。

Unicode 標準允准佇咧 UTF 鋪八中使用 BOM，但並無要求推薦使用伊。位元組順序佇咧 UTF 鋪八中無任何意義，所以伊佇咧 UTF 鋪八中的唯一的用途是佇開始的時陣發出訊號，表明文字流是用 UTF 鋪八編碼的，抑是表明伊是對包括可選 BOM 的文字是流轉換著 UTF ma八的。該標準嘛無建議佇咧有 BOM 的情況之下共刪除，以便佇無仝的編碼之間往回袂擲失資訊，而且依賴 BOM 的代碼繼續咧做工課。IETF 建議喔，若一个協定愛啥物 ( a ) 總是使用 UTF ma八，欲按怎 ( b ) 有一寡其他的方法來表明當咧使用的編碼，按呢伊 " 應該愛禁止使用 U + FEFF 做簽名 "。

UTF 鋪八是一種稀微的編碼，意思是真大一部份可能的字元組合袂產生有效的 UTF 鋪八文字。任何其他編碼的二進制資料佮文字攏可能包括 UTF 分辨的字元序列，唯一的例外是當文字純粹由 ASCII 範圍的字元組成的時陣。因為所有的現代編碼攏用 ASCII 範圍的位元組來表示 ASCII 字元，所以無論發出遮的位元組的系統拍算欲使用啥物編碼，純純 ASCII 的文字攏會當予安全解說為著 UTF ma八。因為這考慮，使用啟發式的分析方法會使真有把握地檢測出檔案敢是使用 UTF ma八，毋免加入 BOM。
另外一方面，微軟的編譯器佮解說器，以及真濟 Microsoft Windows 最的軟體，就親像記事本，攏將 BOM 當做一个必要的神奇數字，毋是使用啟發式分析法。遮的工具咧共文字儲存為 UTF 鋪八的時添加矣 BOM，並且干焦佇咧 BOM 存在抑是檔案干焦包含 ASCII 字元時才有法度解說講 UTF ma八。Windows PowerShell（截至五孵一版本）咧儲存 UTF ma八的 XML 檔案檔時，會添加一个 BOM。毋過，PowerShell Core 六在一寡 cmdlets 上增加一个-Encoding 開關，這號做「utf 八 NoBOM」，按呢就會使佇咧無 BOM 的情況下儲存檔案檔。Google 文件佇咧將檔案當轉換做純文字檔案以供下載時也會添加 BOM。

===UTF 鋪十六===

佇咧 UTF 鋪十六中，位元組順序記號被囥做檔案或者是文字串流的第一字元，以標示佇這个此檔案抑是文字串流中，以為單位有十六位元為單位的字碼的捀序（位元組順序）。若試圖用錯誤的位元組順序來讀這个流，位元組將被調換，對產生的字元 ` U + FFFE `，這字元予 Unicode 定義做「非字元」，無應該出現佇咧文字內底。比如講，足值為 ` U + FFFE ` 的碼位予保證將袂予人指定做一个統一碼字元。這意味對 ` 零 xFF `、` 零 xFE ` 將只會予人解說做小端序內底的 ` U + FEFF `（因為無可能是端序中的 ` U + FFFE `）。

* 如果十六位元單位被表示做大端序，這位元組順序記號字元在序列中會呈現 ` 零 xFE `，其後綴著 ` 零 xFF `（內底的 ` 零 x ` 按呢用來標示十六進位）。
* 如果十六位元單位使用小端序，這个位元組序列做 ` 零 xFF `，其後接著 ` 零 xFE `。

這兩个序列攏毋是有效 UTF ma八，所以𪜶的出現表明該檔案毋是用 UTF 鋪八編碼的。

對網際網路號碼分配局註冊的字元集 UTF 鋪十六 BE 和 UTF 鋪十六 LE，無應該使用位元組順序記號標記，因為遮的字元集的名稱已經決定了位元組順序。若是佇按呢的文字串流中的任何所在拄著 ` U + FEFF `，將被解說講為一个「零闊度無斷點空間」。

若是無位元組順序記號，會當透過搜揣 ASCII 字元（即佮零 x 二十五空 x 七 E 範圍內的位元組相鄰的零位元組，閣有 CR 和 LF 的零 x 零 A 佮零 x 零 D）來臆該文字敢是 UTF 鋪十六佮其實元組的順序。大量的（就開始遠遠懸就隨機）仝款的順序是 UTF 鋪十六的一个非常好的指示，啊若零是佇咧偶數抑是奇數位元組內底表明了位元組的順序。毋過，這猶原可能會做假日性佮假陰性。

Unicode 標準的一致性條款 D 九十八（第三孵一空節）規定：「 UTF 鋪十六編碼方案會使 BOM 開始，嘛會使不以 BOM 開始。毋過，當下無 BOM 時，佇咧無高層協定的情形下，UTF 鋪十六編碼方案的位元組順序是大端序。」敢有閣較高層次的協定是會當解說的。比如講，佇一台本地位元組順序為小端序的電腦上的檔案，可能是予人靜認為講 UTF 鋪十六 LE 編碼。所以，大端序的推定予人廣泛地忽略矣。佇咧 HTML 五中使用的 W 三 C / WHATWG 編碼標準規定，標記做講「utf 鋪十六」抑是「utf 鋪十六 le」的內容將被解說做小端序，「以處理部署的內容」。毋過，若出現了位元組順序記號，若按呢該記號將予人看做是「比其他任何物件攏閣較有權威性」。

將 UTF 鋪十六解說是基於位元組的編碼的程式可能會顯示出亂七八糟的字元，猶毋過 ASCII 字元會去予人識別出來，因為乎 UTF 鋪十六表示的低字元佮 ASCII 代碼相仝，所以會顯示仝款的字元。零的上字元會當顯示為無、空白、句點，猶閣有其他一寡不變的字型。

===UTF 鋪三十二===

雖然位元組順序記號亦會當用於 UTF 鋪三十二，但這个編碼真少用傳輸，其規則親像 UTF 鋪十六。

小端序 UTF 抹三十二的 BOM 等同小端序 UTF 鋪十六的 BOM 圖樣後壁加一个 NUL 字元，這是一个無四常的例，即 BOM 佇咧兩種無仝款的編碼內底是仝款的形式。使用 BOM 來看別編碼的程式員就愛分辨檔案是 UTF 炕三十二編碼抑是單純以 NUL 成做第一字元。

==無仝編碼的位元組順序記號的表示==

==另見==

* 左右符號
* 正至左符號

==參考文獻==

==外部連結==

* Unicode FAQ : _ UTF ma八 , UTF 鋪十六 , UTF 鋪三十二 & BOM _
* The Unicode Standard , chapter 二孵六 _ Encoding Schemes _
* The Unicode Standard , chapter 二嬸一三 _ Special Characters and Noncharacters _ , section _ Byte Order Mark（BOM）_
* The Unicode Standard , chapter 十六陵八 _ Specials _ , section _ Byte Order Mark ( BOM ) : U + FEFF _

[[分類: 待校正]]

端序記號 - 修訂紀錄

TaiwanTonguesApiRobot：​從 JSON 檔案批量匯入

TaiwanTonguesApiRobot：從 JSON 檔案批量匯入