เครื่องหมายลำดับไบต์ ( BOM ) เป็นการใช้งานเฉพาะของรหัสอักขระยูนิโค้ด พิเศษ U+FEFF ZERO WIDTH NO-BREAK SPACEซึ่งการปรากฏเป็นหมายเลขวิเศษที่จุดเริ่มต้นของสตรีมข้อความสามารถส่งสัญญาณหลายอย่างไปยังโปรแกรมที่อ่านข้อความได้: ^{[ 1 ]}

• ลำดับไบต์ หรือเอนเดียนเนสของสตรีมข้อความในกรณีของการเข้ารหัส 16 บิตและ 32 บิต
• ข้อเท็จจริงที่ว่าการเข้ารหัสของสตรีมข้อความคือ Unicode ด้วยความมั่นใจในระดับสูง
• ใช้การเข้ารหัสอักขระ Unicode แบบใด

การใช้งาน BOM เป็นทางเลือก การมีอยู่ของ BOM จะรบกวนการใช้งานUTF-8โดยซอฟต์แวร์ที่ไม่คาดหวังไบต์ที่ไม่ใช่ASCIIที่ส่วนต้นของไฟล์ แต่สามารถจัดการกับสตรีมข้อความได้ในกรณีอื่นๆ

Unicode สามารถเข้ารหัสได้ในหน่วยจำนวนเต็ม 8 บิต 16 บิต หรือ 32 บิต สำหรับการแสดงผลแบบ 16 บิตและ 32 บิต คอมพิวเตอร์ที่รับข้อความจากแหล่งต่างๆ จำเป็นต้องทราบลำดับไบต์ของจำนวนเต็มเหล่านั้น BOM จะกลายเป็นจุด รหัส Unicode ที่ไม่ใช่ตัว อักขระ หากมีการสลับไบต์ ดังนั้น กระบวนการที่เข้าถึงข้อความสามารถตรวจสอบไบต์ไม่กี่ไบต์แรกเพื่อกำหนดลำดับไบต์ได้โดยไม่ต้องมีข้อตกลงหรือเมตาเดตา ใดๆ นอกเหนือจากกระแสข้อความนั้นเอง โดยทั่วไปแล้ว คอมพิวเตอร์ที่รับข้อความจะสลับไบต์ให้ตรงกับลำดับไบต์ของตนเองหากจำเป็น และจะไม่จำเป็นต้องใช้ BOM ในการประมวลผลอีกต่อไป

ลำดับไบต์ของ BOM จะแตกต่างกันไปตามการเข้ารหัส Unicode แต่ละแบบ (รวมถึงUTF-8และแบบอื่นๆ ที่อยู่นอกมาตรฐาน Unicode เช่นUTF-7ดูตารางด้านล่าง ) และลำดับใดๆ ก็ตามมักจะไม่ปรากฏที่จุดเริ่มต้นของข้อความที่จัดเก็บในรูปแบบการเข้ารหัสอื่นๆ ดังนั้น การวาง BOM ที่เข้ารหัสไว้ที่จุดเริ่มต้นของข้อความสามารถบ่งชี้ได้ว่าข้อความนั้นเป็น Unicode และระบุรูปแบบการเข้ารหัสที่ใช้ การใช้ BOM ในลักษณะนี้เรียกว่า "ลายเซ็น Unicode"

BOM นั้นก็คือรหัส Unicode U+FEFF ZERO WIDTH NO-BREAK SPACEที่เข้ารหัสในรูปแบบการเข้ารหัสปัจจุบัน ไฟล์ข้อความที่เริ่มต้นด้วยไบต์เหล่านี้บ่งชี้ว่าไฟล์นั้นเข้ารหัสในรูปแบบ UTF-16 แบบ big-endian ^{[ 2 ]}FE FF

ชื่อ ZWNBSP ( zero-width no-break space ) ควรใช้หาก BOM ปรากฏอยู่ตรงกลางของสตรีมข้อมูล Unicode ระบุว่าควรตีความว่าเป็นโค้ดพอยต์ปกติ (กล่าวคือตัวเชื่อมคำ ) ไม่ใช่ BOM ตั้งแต่ Unicode 3.2 การใช้งานนี้ถูกยกเลิกและแทนที่ด้วยU+2060 WORD JOINER ^{[ 1 ]}

ชื่อ Unicode 1.0 สำหรับรหัสจุดนี้คือBYTE ORDER MARK. ^{[ 3 ]}

การแสดงผล BOM ในรูปแบบ UTF-8 คือลำดับไบต์ ( เลขฐานสิบ หก )EF BB BF

มาตรฐาน Unicode อนุญาตให้ใช้ BOM ในUTF -8 ^{[ 4 ]}แต่ไม่บังคับหรือแนะนำให้ใช้^{[ 5 ]} UTF-8 มีลำดับไบต์เดียวกันเสมอ^{[ 6 ]}ดังนั้นการใช้ BOM ใน UTF-8 จึงมีเพียงเพื่อส่งสัญญาณในตอนเริ่มต้นว่าสตรีมข้อความถูกเข้ารหัสใน UTF-8 หรือว่าถูกแปลงเป็น UTF-8 จากสตรีมที่มี BOM เสริม มาตรฐานยังไม่แนะนำให้ลบ BOM ออกเมื่อมีอยู่ เพื่อไม่ให้ข้อมูลสูญหายระหว่างการเข้ารหัส และเพื่อให้โค้ดที่พึ่งพา BOM ยังคงทำงานได้^{[ 7 ] [ 8 ]} IETF แนะนำว่าหากโปรโตคอล (ก) ใช้ UTF-8 เสมอ หรือ (ข) มีวิธีอื่นในการระบุว่ากำลังใช้การเข้ารหัสใดอยู่ โปรโตคอลนั้น "ควรห้ามใช้ U+FEFF เป็นลายเซ็น" ^{[ 9 ]}ตัวอย่างของการไม่ปฏิบัติตามคำแนะนำนี้คือโปรโตคอล IETF Syslogซึ่งกำหนดให้ข้อความต้องเป็น UTF-8 และยังกำหนดให้ต้องมี BOM ด้วย^{[ 10 ]}

การไม่ใช้ BOM ช่วยให้ข้อความสามารถใช้งานร่วมกับซอฟต์แวร์ที่ออกแบบมาสำหรับASCII แบบขยายได้ตัวอย่างเช่น ภาษาโปรแกรมหลายภาษาอนุญาตให้ใช้ไบต์ที่ไม่ใช่ASCIIในสตริงแต่ไม่อนุญาตให้ใช้ที่ส่วนต้นของไฟล์

ไม่จำเป็นต้องใช้ BOM ในการตรวจจับการเข้ารหัส UTF-8 UTF-8 เป็นการเข้ารหัสแบบสปาร์ส (sparse encoding): สัดส่วนมากของชุดไบต์ที่เป็นไปได้ไม่ได้ทำให้ได้ข้อความ UTF-8 ที่ถูกต้อง ข้อมูลไบนารีและข้อความในการเข้ารหัสอื่นๆ มักจะมีลำดับไบต์ที่ไม่ถูกต้องตาม UTF-8 ดังนั้นการมีลำดับที่ไม่ถูกต้องดังกล่าวแสดงว่าไฟล์นั้นไม่ใช่ UTF-8 ในขณะที่การไม่มีลำดับที่ไม่ถูกต้องเป็นข้อบ่งชี้ที่ชัดเจนมากว่าข้อความนั้นเป็น UTF-8 ในทางปฏิบัติข้อยกเว้นเพียงอย่างเดียวคือข้อความที่มีเฉพาะไบต์ในช่วง ASCII เท่านั้น เนื่องจากอาจเป็นการเข้ารหัส 7 บิตที่ไม่ใช่ ASCII แต่สิ่งนี้ไม่น่าจะเกิดขึ้นในข้อมูลสมัยใหม่ และถึงแม้จะเป็นเช่นนั้น ความแตกต่างจาก ASCII ก็มีเพียงเล็กน้อย (เช่น การเปลี่ยน '\' เป็น '¥')

คอมไพเลอร์และตัวแปลภาษาของ Microsoft ^{[ 11 ]} และซอฟต์แวร์หลายชิ้นบน Microsoft Windowsเช่นNotepad (ก่อน Windows 10 Build 1903 ^{[ 12 ]} ) ถือว่า BOM เป็นหมายเลขวิเศษ ที่จำเป็น แทนที่จะใช้ฮิวริสติก เครื่องมือเหล่านี้จะเพิ่ม BOM เมื่อบันทึกข้อความเป็น UTF-8 และไม่สามารถตีความ UTF-8 ได้เว้นแต่จะมี BOM อยู่หรือไฟล์มีเฉพาะ ASCII เท่านั้นWindows PowerShell (จนถึง 5.1) จะเพิ่ม BOM เมื่อบันทึกเอกสาร XML UTF-8 อย่างไรก็ตาม PowerShell Core 6 ได้เพิ่ม-Encodingสวิตช์ใน cmdlet บางตัวที่เรียกว่า utf8NoBOM เพื่อให้สามารถบันทึกเอกสารได้โดยไม่มี BOM Google Docsยังเพิ่ม BOM เมื่อแปลงเอกสารเป็น ไฟล์ ข้อความธรรมดาเพื่อดาวน์โหลดด้วย

ในUTF-16 สามารถวาง BOM (Bill of Method U+FEFF) ไว้ที่ไบต์แรกของไฟล์หรือสตรีมอักขระเพื่อระบุลำดับไบต์ (endianness) ของหน่วยรหัส 16 บิตทั้งหมด ของไฟล์หรือสตรีมนั้น หากพยายามอ่านสตรีมนี้ด้วยลำดับไบต์ที่ไม่ถูกต้อง ไบต์จะถูกสลับ ทำให้ได้อักขระ `\n` U+FFFEซึ่ง ยูนิโค้ด กำหนดว่าเป็น " อักขระ ที่ไม่ใช่ตัวอักษร " ที่ไม่ควรปรากฏในข้อความ

• หากหน่วย 16 บิตถูกแสดงใน ลำดับไบต์ แบบบิ๊กเอนเดียน ("UTF-16BE") BOM จะเป็นลำดับไบต์ ( เลขฐาน สิบหก )FE FF
• หากหน่วยประมวลผล 16 บิตใช้ ลำดับไบต์แบบ little-endian ("UTF-16LE") รายการส่วนประกอบ (BOM) จะเป็นลำดับไบต์ ( เลข ฐานสิบหก )FF FE

สำหรับ ชุดอักขระที่จดทะเบียน โดย IANAคือ UTF-16BE และ UTF-16LE ไม่ควรใช้เครื่องหมายลำดับไบต์ เนื่องจากชื่อของชุดอักขระเหล่านี้ได้กำหนดลำดับไบต์ไว้แล้ว

ข้อกำหนด D98 ของการปฏิบัติตามมาตรฐาน Unicode (ส่วนที่ 3.10) ระบุว่า "รูปแบบการเข้ารหัส UTF-16 อาจเริ่มต้นด้วย BOM หรือไม่ก็ได้ อย่างไรก็ตาม เมื่อไม่มี BOM และในกรณีที่ไม่มีโปรโตคอลระดับสูงกว่า ลำดับไบต์ของรูปแบบการเข้ารหัส UTF-16 จะเป็นแบบ big-endian" การที่โปรโตคอลระดับสูงกว่ามีผลบังคับใช้หรือไม่นั้นขึ้นอยู่กับการตีความ ตัวอย่างเช่น ไฟล์ที่อยู่ในเครื่องคอมพิวเตอร์ซึ่งมีลำดับไบต์แบบ little-endian อาจถูกตีความว่าเข้ารหัสเป็น UTF-16LE โดยปริยาย ดังนั้น ข้อสันนิษฐานเรื่อง big-endian จึงถูกละเลยอย่างกว้างขวาง มาตรฐาน การเข้ารหัส W3C / WHATWGที่ใช้ใน HTML5 ระบุว่า เนื้อหาที่ติดป้ายกำกับว่า "utf-16" หรือ "utf-16le" จะต้องถูกตีความว่าเป็น little-endian "เพื่อจัดการกับเนื้อหาที่ใช้งานอยู่" ^{[ 13 ]}อย่างไรก็ตาม หากมีเครื่องหมายลำดับไบต์อยู่ จะต้องถือว่า BOM นั้น "มีอำนาจมากกว่าสิ่งอื่นใด" ^{[ 14 ]}

ถึงแม้จะไม่มี BOM (Bill of Method) ก็ยังค่อนข้างน่าเชื่อถือในการตรวจสอบว่าข้อความนั้นเป็น UTF-16 หรือไม่ และมีลำดับไบต์แบบใด หากข้อความนั้นมีความยาวเพียงพอ อักขระใน บล็อก Basic Latin (U+0001 ถึง U+007F) มีไบต์สูงเป็น NUL (0x00) แม้แต่ในสคริปต์ที่ไม่ใช่ละติน การขึ้นบรรทัดใหม่และช่องว่าง (ซึ่งรวมอยู่ในบล็อกนี้) ก็ถูกใช้บ่อย หากไบต์ NUL ปรากฏบ่อยกว่าที่ตำแหน่งคู่ในไฟล์ ก็มีแนวโน้มที่จะเป็น UTF-16 แบบ big-endian และหากปรากฏบ่อยกว่าที่ตำแหน่งคี่ ก็จะเป็น UTF-16 แบบ little-endian

แม้ว่า BOM จะสามารถใช้กับUTF-32 ได้แต่การเข้ารหัสนี้ไม่ค่อยได้ใช้ในการส่งข้อมูล ส่วนกฎอื่นๆจะเหมือนกับที่ใช้ กับ UTF-16

BOM สำหรับ UTF-32 แบบ little-endian มีรูปแบบเดียวกับ BOM ของ UTF-16 แบบ little-endian ตามด้วยอักขระ NUL ของ UTF-16 ซึ่งเป็นตัวอย่างที่ผิดปกติของการที่ BOM มีรูปแบบเดียวกันในสองการเข้ารหัสที่แตกต่างกัน โปรแกรมเมอร์ที่ใช้ BOM เพื่อระบุการเข้ารหัสจะต้องตัดสินใจว่า UTF-32 หรือ UTF-16 ที่มีอักขระ NUL ตัวแรกนั้นมีความเป็นไปได้มากกว่า UTF-32 สามารถตรวจจับได้ง่ายโดยไม่ต้องใช้ BOM เพราะทุกๆ ไบต์ที่ 4 จะเป็น NUL

ตารางนี้แสดงให้เห็นว่า BOM ถูกแสดงเป็นลำดับไบต์ในรูปแบบการเข้ารหัสต่างๆ อย่างไร และลำดับเหล่านั้นอาจปรากฏในโปรแกรมแก้ไขข้อความที่ตีความแต่ละไบต์เป็นการเข้ารหัสแบบเก่า ( Windows-1252พร้อมสัญลักษณ์เครื่องหมายแคเร็ตสำหรับส่วนควบคุม C0 ) อย่างไร:

• รูปแบบการนำเสนอภาษาอาหรับ-Bบล็อกที่รหัสจุดนั้นU+FEFFสังกัดอยู่
• เครื่องหมายจากซ้ายไปขวา
• โมจิบาเกะ (Mojibake ) คือข้อความที่บิดเบี้ยวซึ่งเกิดจากการถอดรหัสที่ไม่ถูกต้อง

• คำถามที่พบบ่อยเกี่ยวกับ Unicode: UTF-8, UTF-16, UTF-32 และ BOM
• มาตรฐานยูนิโค้ด บทที่ 2.6 รูปแบบการเข้ารหัส
• มาตรฐานยูนิโค้ด บทที่ 2.13 อักขระพิเศษและอักขระที่ไม่ใช่อักขระส่วนเครื่องหมายลำดับไบต์ (BOM)
• มาตรฐานยูนิโค้ด บทที่ 16.8 อักขระพิเศษส่วนเครื่องหมายลำดับไบต์ (BOM): U+FEFF
• เครื่องหมายลำดับไบต์ (BOM) ใน HTML