Byte order mark

📅 آخر تحديث: ١٧ يوليو ٢٠٢٦
✍️ نُشر في: ١٧ يوليو ٢٠٢٦
الموسوعة الحرة

The byte order mark (BOM) is a particular usage of the special Unicode character code, U+FEFFZERO WIDTH NO-BREAK SPACE, whose appearance as a magic number at the start of a text stream can signal several things to a program reading the text:[1]

  • the byte order, or endianness, of the text stream in the cases of 16-bit and 32-bit encodings;
  • the fact that the text stream's encoding is Unicode, to a high level of confidence;
  • which Unicode character encoding is used.

BOM use is optional. Its presence interferes with the use of UTF-8 by software that does not expect non-ASCII bytes at the start of a file but that could otherwise handle the text stream.

Unicode can be encoded in units of 8-bit, 16-bit, or 32-bit integers. For 16- and 32-bit representations, a computer receiving text from arbitrary sources needs to know which byte order the integers are encoded in. The BOM becomes a noncharacter Unicode code point if its bytes are swapped. Hence, the process accessing the text can examine these first few bytes to determine the endianness, without requiring some contract or metadata outside of the text stream itself. Generally the receiving computer will swap the bytes to its own endianness, if necessary, and would no longer need the BOM for processing.

The byte sequence of the BOM differs per Unicode encoding (including UTF-8 and ones outside the Unicode standard such as UTF-7, see table below), and none of the sequences is likely to appear at the start of text streams stored in other encodings. Therefore, placing an encoded BOM at the start of a text stream can indicate that the text is Unicode and identify the encoding scheme used. This use of the BOM is called a "Unicode signature".

Usage

The BOM is, simply, the Unicode codepoint U+FEFFZERO WIDTH NO-BREAK SPACE, encoded in the current encoding. A text file beginning with the bytes FE FF suggests that the file is encoded in big-endian UTF-16.[2]

The name ZWNBSP (zero-width no-break space) should be used if the BOM appears in the middle of a data stream. Unicode says it should be interpreted as a normal codepoint (namely a word joiner), not as a BOM. Since Unicode 3.2, this usage has been deprecated in favor of U+2060WORD JOINER.[1]

The Unicode 1.0 name for this codepoint is also BYTE ORDER MARK.[3]

UTF-8

تمثيل UTF -8 لـ BOM هو تسلسل البايت ( السداسي العشري ) .EF BB BF

يسمح معيار يونيكود باستخدام علامة ترتيب البايتات (BOM) في ترميز UTF-8 ، [ 4 ] ولكنه لا يشترط استخدامها أو يوصي به. [ 5 ] يتميز ترميز UTF-8 بترتيب بايتات ثابت، [ 6 ] لذا فإن استخدامها الوحيد فيه هو الإشارة في البداية إلى أن دفق النص مُرمّز بترميز UTF-8، أو أنه تم تحويله إلى UTF-8 من دفق يحتوي على علامة ترتيب بايتات اختيارية. كما لا يوصي المعيار بإزالة علامة ترتيب البايتات عند وجودها، وذلك لتجنب فقدان المعلومات أثناء عملية التحويل بين الترميزات، ولضمان استمرار عمل التعليمات البرمجية التي تعتمد عليها. [ 7 ] [ 8 ] توصي فرقة عمل هندسة الإنترنت (IETF) بأنه إذا كان البروتوكول (أ) يستخدم ترميز UTF-8 دائمًا، أو (ب) لديه طريقة أخرى للإشارة إلى الترميز المستخدم، فإنه "ينبغي عليه منع استخدام U+FEFF كتوقيع". [ 9 ] ومن الأمثلة على عدم اتباع هذه التوصية بروتوكول IETF Syslog الذي يشترط أن يكون النص بتنسيق UTF-8 ويشترط أيضًا استخدام BOM. [ 10 ]

عدم استخدام علامة ترتيب البايتات (BOM) يسمح بأن يكون النص متوافقًا مع الإصدارات السابقة من البرامج المصممة لـ ASCII الموسع . على سبيل المثال، تسمح العديد من لغات البرمجة باستخدام بايتات غير ASCII في السلاسل النصية ، ولكن ليس في بداية الملف.

لا يُعدّ وجود علامة ترتيب البايتات (BOM) ضروريًا للكشف عن ترميز UTF-8. يُعدّ UTF-8 ترميزًا متفرقًا: إذ إنّ نسبة كبيرة من تركيبات البايتات الممكنة لا تُنتج نصًا صالحًا بترميز UTF-8. من المرجح أن تحتوي البيانات الثنائية والنصوص بأي ترميز آخر على تسلسلات بايتات غير صالحة كـ UTF-8، لذا فإنّ وجود مثل هذه التسلسلات غير الصالحة يُشير إلى أنّ الملف ليس UTF-8، بينما يُعدّ غياب التسلسلات غير الصالحة مؤشرًا قويًا جدًا على أنّ النص UTF -8. عمليًا، الاستثناء الوحيد هو النص الذي يحتوي على بايتات من نطاق ASCII فقط، إذ قد يكون هذا ترميزًا غير ASCII ذي 7 بتات، ولكن هذا غير مرجح في أي بيانات حديثة، وحتى في هذه الحالة يكون الفرق عن ASCII طفيفًا (مثل تغيير '\' إلى '¥').

تتعامل مُجمّعات ومُفسّرات مايكروسوفت [ 11 ] ، والعديد من البرامج على نظام مايكروسوفت ويندوز، مثل المفكرة (قبل إصدار ويندوز 10 رقم 1903 [ 12 ] )، مع علامة ترتيب البايتات (BOM) كرقم سحري إلزامي بدلاً من استخدام طرق استدلالية. تُضيف هذه الأدوات علامة ترتيب البايتات عند حفظ نص بتنسيق UTF-8، ولا يُمكنها تفسير UTF-8 إلا بوجود علامة ترتيب البايتات أو إذا كان الملف يحتوي على ASCII فقط. يُضيف ويندوز باور شيل (حتى الإصدار 5.1) علامة ترتيب البايتات عند حفظ مستندات XML بتنسيق UTF-8. مع ذلك، أضاف باور شيل كور 6 -Encodingخيارًا في بعض أوامر cmdlets يُسمى utf8NoBOM، ما يسمح بحفظ المستند بدون علامة ترتيب البايتات. كما يُضيف جوجل دوكس علامة ترتيب البايتات عند تحويل مستند إلى ملف نصي عادي للتنزيل.

UTF-16

في ترميز UTF-16 ، يمكن وضع علامة ترتيب البايتات (BOM U+FEFF) كأول بايتات في ملف أو سلسلة أحرف للإشارة إلى ترتيب البايتات (ترتيب البايتات) لجميع وحدات الترميز ذات 16 بت في الملف أو السلسلة. إذا تمت محاولة قراءة هذه السلسلة بترتيب بايتات خاطئ، فسيتم تبديل البايتات، مما ينتج عنه الحرف □ U+FFFE، الذي يُعرّفه يونيكود بأنه " حرف غير موجود " ولا ينبغي أن يظهر في النصوص.

بالنسبة لمجموعات الأحرف المسجلة لدى IANA UTF-16BE و UTF-16LE، لا ينبغي استخدام علامة ترتيب البايت لأن أسماء مجموعات الأحرف هذه تحدد بالفعل ترتيب البايت.

تنص الفقرة D98 من معيار المطابقة (القسم 3.10) لمعيار يونيكود على ما يلي: "قد يبدأ نظام ترميز UTF-16 بعلامة ترتيب البايتات (BOM) أو لا يبدأ بها. ومع ذلك، في حال عدم وجود علامة ترتيب البايتات، وفي غياب بروتوكول أعلى مستوى، يكون ترتيب البايتات في نظام ترميز UTF-16 هو ترتيب البايتات الكبير (Big-Endian)". ويخضع تطبيق بروتوكول أعلى مستوى للتأويل. فعلى سبيل المثال، يمكن القول ضمنيًا أن الملفات المحلية على جهاز كمبيوتر، والتي يكون ترتيب البايتات الأصلي فيها هو ترتيب البايتات الصغير (Little-Endian)، مُرمّزة بنظام UTF-16LE. ولذلك، يُتجاهل افتراض ترتيب البايتات الكبير (Big-Endian) على نطاق واسع. ويحدد معيار الترميز W3C / WHATWG المستخدم في HTML5 أن المحتوى المُصنّف إما "utf-16" أو "utf-16le" يُفسّر على أنه ترتيب البايتات الصغير (Little-Endian) "للتعامل مع المحتوى المنشور". [ 13 ] مع ذلك، إذا وُجدت علامة ترتيب البايتات، فيجب التعامل مع هذه العلامة على أنها "أكثر موثوقية من أي شيء آخر". [ 14 ]

بدون علامة ترتيب البايتات (BOM)، يظل من الممكن إلى حد كبير تحديد ما إذا كان النص بتنسيق UTF-16 وترتيب البايتات فيه إذا كان النص طويلاً بما يكفي. تحتوي الأحرف في كتلة الأحرف اللاتينية الأساسية (من U+0001 إلى U+007F) على بايت NUL (0x00) في الأعلى؛ حتى في النصوص غير اللاتينية، تُستخدم نهايات الأسطر والمسافات (المضمنة في هذه الكتلة) بشكل متكرر. إذا كانت بايتات NUL أكثر شيوعًا عند الإزاحات الزوجية في الملف، فمن المرجح أن يكون النص بتنسيق UTF-16 ذي ترتيب البايتات الكبير، وإذا كانت أكثر شيوعًا عند الإزاحات الفردية، فمن المرجح أن يكون بتنسيق UTF-16 ذي ترتيب البايتات الصغير.

UTF-32

على الرغم من إمكانية استخدام علامة ترتيب البايتات (BOM) مع ترميز UTF-32 ، إلا أن هذا الترميز نادرًا ما يُستخدم في الإرسال. وفيما عدا ذلك ، تُطبق نفس قواعد ترميز UTF-16 .

تتشابه علامة ترتيب البايتات (BOM) لترميز UTF-32 ذي الترتيب الصغير مع علامة ترتيب البايتات لترميز UTF-16 ذي الترتيب الصغير، متبوعةً بحرف NUL الخاص بترميز UTF-16، وهو مثال نادر على تشابه علامة ترتيب البايتات في ترميزين مختلفين. يتعين على المبرمجين الذين يستخدمون علامة ترتيب البايتات لتحديد الترميز تحديد أيهما أكثر احتمالاً: UTF-32 أم UTF-16 مع الحرف NUL في البداية. يسهل اكتشاف UTF-32 بدون علامة ترتيب البايتات لأن كل بايت رابع يكون NUL.

علامات ترتيب البايتات عن طريق الترميز

يوضح هذا الجدول كيفية تمثيل BOM كسلسلة بايت في ترميزات مختلفة وكيف يمكن أن تظهر هذه التسلسلات في محرر نصوص يفسر كل بايت كترميز قديم ( Windows-1252 مع تدوين الإقحام لعناصر التحكم C0 ):

التشفيرالتمثيل ( السداسي العشري )التمثيل ( العشري )تم تفسير البايتات على أنها Windows-1252
UTF-8 [ أ ]EF BB BF239 187 191أنا"
UTF-16 ( BE )FE FF254 255خاصتك
UTF-16 ( LE )FF FE255 254ÿþ
UTF-32 (BE)٠٠ ٠٠ FE FF0 0 254 255^@ ^@þÿ
UTF-32 (LE)FF FE 00 00255 254 0 0ÿþ^@^@
UTF-7 [ أ ]2B 2F 76 [ b ] [ 16 ] [ 17 ]43 47 118+/v
UTF-1 [ أ ]F7 64 4C247 100 76÷dL
UTF-EBCDIC [ أ ]DD 73 66 73221 115 102 115Ýsfs
جامعة ولاية سانت كلاود [ أ ]0E FE FF [ c ]14 254 255^N þÿ
BOCU-1 [ أ ]FB EE 28251 238 40ûî(
GB18030 [ أ ]84 31 95 33132 49 149 511•3
  1. ١ ٢ ٣ ٤ ٥ ٦ ٧ لا يُعدّ هذا حرفيًا علامة "ترتيب البايتات"، إذ أن وحدة الترميز في هذه الترميزات هي بايت واحد، وبالتالي لا يمكن أن تحتوي على بايتات بترتيب "خاطئ". مع ذلك، يمكن استخدام علامة ترتيب البايتات للإشارة إلى ترميز النص الذي يليها. [ ٦ ] [ ١٥ ]
  2. ↑ متبوعًا بـ38،39،2B، أو2F(ASCII8،9،+أو/)، اعتمادًا على الحرف التالي.
  3. ↑ يسمح SCSU بترميزات أخرى لـ U+FEFF، والشكل الموضح هو التوقيع الموصى به في UTR #6. [ 18 ]

انظر أيضاً

مراجع

  1. 1 2 "الأسئلة الشائعة - UTF-8، UTF-16، UTF-32 وBOM" . Unicode.org . تم الاطلاع عليه بتاريخ 28 يناير 2017 .
  2. ^ "كارتا كوم يعدل" . doi.org . تم الاسترجاع 17 يونيو 2026 .
  3. ↑ "مسافة بدون كسر بعرض صفري (U+Feff)" .
  4. ↑ "معيار يونيكود 5.0، الفصل 2: ​​البنية العامة" (ملف PDF) . صفحة 36. تاريخ الاطلاع: 29 مارس 2009. الجدول 2-4 . أنظمة ترميز يونيكود السبعة 
  5. ↑ "معيار يونيكود 5.0، الفصل 2: ​​البنية العامة" (ملف PDF) . صفحة 36. تاريخ الاطلاع: 30 نوفمبر 2008. استخدام علامة ترتيب البايتات (BOM) ليس إلزاميًا ولا يُنصح به لترميز UTF-8، ولكنه قد يُصادف في سياقات يتم فيها تحويل بيانات UTF-8 من أشكال ترميز أخرى تستخدم علامة ترتيب البايتات، أو عندما تُستخدم علامة ترتيب البايتات كتوقيع UTF-8. 
  6. 12"FAQ - UTF-8, UTF-16, UTF-32 & BOM: Can a UTF-8 data stream contain the BOM character (in UTF-8 form)? If yes, then can I still assume the remaining UTF-8 bytes are in big-endian order?". Unicode.org. Retrieved 4 January 2009.
  7. ↑"Re: pre-HTML5 and the BOM from Asmus Freytag on 2012-07-13 (Unicode Mail List Archive)". Unicode.org. Retrieved 14 July 2012.
  8. ↑"Bug ID: JDK-6378911 UTF-8 decoder handling of byte-order mark has changed". Bugs.java.com. Retrieved 14 October 2021.
  9. ↑Yergeau, Francois (November 2003). UTF-8, a transformation format of ISO 10646. IETF. doi:10.17487/RFC3629. RFC3629. Retrieved 15 May 2014.
  10. ↑Gerhards, Rainer (March 2009). "MSG". The Syslog Protocol. IETF. sec. 6.4. doi:10.17487/RFC5424. RFC5424.
  11. ↑Alf P. Steinbach (2011). "Unicode part 1: Windows console i/o approaches". Retrieved 24 March 2012. However, since the C++ source code was encoded as UTF-8 without BOM (as is usual in Linux), the Visual C++ compiler erroneously assumed that the source code was encoded as Windows ANSI.
  12. ↑"Windows 10 Notepad is Getting Better UTF-8 Encoding Support". BleepingComputer. Retrieved 7 March 2023.
  13. ↑"UTF-16LE". Encoding Standard. WHATWG.
  14. ↑"Decode". Encoding Standard. WHATWG.
  15. ↑Yergeau, François (8 November 2003). "RFC 3629 - UTF-8, a transformation format of ISO 10646". Ietf Datatracker. Retrieved 28 January 2017.
  16. ↑Honermann, Tom (2 January 2021). "Clarify guidance for use of a BOM as a UTF-8 encoding signature"(PDF). Unicode.
  17. ↑"SDL Documentation".
  18. ↑Markus Scherer. "UTS #6: Compression Scheme for Unicode". Unicode.org. Retrieved 28 January 2017.