ترميز النصّ ونهاية السطر في Windows - أساسيّات mojibake و CRLF/LF

في مشاورات النصّ على Windows تختلط الموضوعات الآتية دفعة واحدة وبوتيرة عالية:

• ما الفرق بين Shift_JIS و UTF-8
• لماذا يحدث mojibake
• ما الفرق بين CRLF و LF
• لماذا قد يتعذّر القراءة رغم التحويل إلى UTF-8
• لماذا يبدو الملفّ نفسه مختلفًا في المحرّر والوحدة و Excel و Git

هذا لا يحدث لأنّ اليابانيّة صعبة في ذاتها. في الغالب السبب أنّ تسلسل البايتات نفسه قُرئ بافتراض آخر، أو أنّ محتوىً قُرئ خطأً حُفظ كما هو.

وفي Windows ما زال عالم Unicode وعالم صفحة الرموز يتعايشان. فوق ذلك تتراكم BOM ونهاية السطر والكشف التلقائيّ في المحرّر وصفحة رموز الوحدة وتحويل نهاية السطر في Git، فيبدو الحديث معقّدًا.

ترتّب هذه المقالة ما يختلط كثيرًا في Windows: Shift_JIS / UTF-8 / UTF-16، وسبب mojibake، والفرق بين CRLF و LF، ولماذا يسهل الاضطراب في هذا الموضوع، بشكل موجَّه إلى الممارسة.

المحتوى قائم على Microsoft Learn و PowerShell و Git والمعلومات العلنيّة من عائلة W3C / Unicode حتّى أبريل 2026. التفاصيل في المراجع في النهاية.

القارئ المستهدف وبيئة الافتراض

إن كنت متعجّلًا فاقرأ هكذا: للصورة الكلّيّة الفصلان 1 و 2، لفصل السبب الفصلان 3 و 8، ولحسم قاعدة التشغيل ابدأ من الفصل 7.

جدول المحتويات

1. ما ينبغي تثبيته أوّلًا
2. تفكيك المصطلحات
   • 2.1 ما الفرق بين Unicode / UTF-8 / UTF-16 / CP932
   • 2.2 كيف نفكّر في Shift_JIS و CP932
   • 2.3 فخاخ كلمات ANSI و Unicode و UTF-8N
   • 2.4 ما هو BOM، ولماذا يُلحق بـ UTF-8 أيضًا
3. لماذا يحدث mojibake
   • 3.1 حقيقة mojibake
   • 3.2 خلل العرض وتلف البيانات أمران مختلفان
   • 3.3 الإسقاط إلى أحرف لا تُمثَّل لا يعود
4. ماذا يعني فرق محرف نهاية السطر
   • 4.1 CRLF / LF / CR
   • 4.2 نهاية السطر مسألة منفصلة عن ترميز الأحرف
   • 4.3 \n وبايتات نهاية السطر في الملفّ ليسا بالضرورة الشيء نفسه
5. لماذا يسهل الاضطراب في Windows تحديدًا
   • 5.1 تعايش Unicode وصفحات الرموز القديمة
   • 5.2 التسميات غير متّسقة
   • 5.3 ASCII وحده يخفي المشكلة
   • 5.4 محتوى الملفّ واسم الملفّ والوحدة وملفّ المصدر طبقات مختلفة
   • 5.5 BOM ونهاية السطر يعملان على محور منفصل أيضًا
   • 5.6 الأدوات تغيّر من تلقاء نفسها
6. أنماط حوادث شائعة
7. قواعد تقلّل الحوادث في الممارسة
8. التحقيق في mojibake وفرق نهاية السطر بهذه الأسئلة الخمسة
9. الخلاصة
10. مقالات ذات صلة
11. المراجع

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 19، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

1. ما ينبغي تثبيته أوّلًا

إن رُتِّبت الخلاصة أوّلًا، فالمهمّ النقاط السبع الآتية.

• الملفّ النصّيّ ليس السلسلة نفسها، بل يقوم على تسلسل بايتات + ترميز أحرف + نهاية سطر. وقد يُلحق BOM (Byte Order Mark، علامة ترتيب البايتات) أيضًا.
• يحدث mojibake حين يُفَكّ تسلسل البايتات نفسه كترميز أحرف آخر.
• حادث نهاية السطر يحدث حين يكون الترميز صحيحًا لكنّ افتراض فاصل السطر منحرفًا.
• Unicode و UTF-8 ليسا المعنى نفسه. Unicode حديث مجموعة الأحرف، و UTF-8 و UTF-16 حديث ترميز يحوّل ذلك إلى بايتات.
• ما يُدعى Shift_JIS في Windows يُفضَّل في الممارسة وعيه كـ CP932 / صفحة رموز يابانيّة من عائلة Windows حتّى لا ينحرف الحديث.
• صار UTF-8 لا يكفي كمواصفة بعد. قاعدة التشغيل تكتمل بحسم وجود BOM و نهاية السطر.
• مصدر الاضطراب ليس اليابانيّة ذاتها، بل بقاء افتراضات عدّة مختلفة التاريخ على Windows نفسه.

عند التعامل مع نصّ Windows، نقطة الانطلاق فصل الأربعة الآتية.

1. ما تسلسل بايتات ذلك الملفّ
2. بأيّ ترميز أحرف كُتب
3. بأيّ ترميز أحرف قُرئ
4. هل نهاية السطر CRLF أم LF

انفصال هذه وحدها يقلّل الحيرة كثيرًا.

2. تفكيك المصطلحات

2.1 ما الفرق بين Unicode / UTF-8 / UTF-16 / CP932

أسرع أن تُفكَّك الكلمات مرّة.

مثلًا حرف あ الواحد تختلف بايتاته حسب الترميز.

文字: あ

UTF-8    : E3 81 82
CP932    : 82 A0
UTF-16LE : 42 30

المهمّ أنّ الحرف وتسلسل البايتات شيئان مختلفان. يعالج التطبيق على الشاشة ما يبدو «حرفًا»، لكنّ الحفظ والاتّصال يتبادلان في النهاية بايتات. الحوادث تقع في الغالب عند حدود ذلك التحويل.

2.2 كيف نفكّر في Shift_JIS و CP932

في الميدان كثيرًا ما تُدعى ملفّات نصّ Windows اليابانيّ جملةً Shift_JIS. في الحديث يُفهم المقصود، لكنّ في الممارسة هذا فضفاض قليلًا.

إن أردت وعيًا أدقّ بنصّ Windows اليابانيّ القديم، فأأمن التفكير بـ CP932، أو صفحة رموز يابانيّة من عائلة Windows.

الفضفضة هنا تحرّف حديثًا كهذا.

• قيل احفظ بـ Shift_JIS، وكان الطرف يفترض CP932 في جانب Windows
• عولج في Linux / macOS كـ shift_jis، فلم تتطابق الإعادة في جزء من الملفّات الآتية من Windows
• قيل احفظ ANSI، وكانت صفحة الرموز تعتمد على البيئة

لذلك في المواصفات ومذكّرات التحقيق أأمن الكتابة كالآتي قدر الإمكان.

• CP932 لا Shift_JIS
• ACP (active code page) / في البيئة اليابانيّة عادة CP932 لا ANSI
• تجسيد ملموس مثل UTF-8 no BOM, LF لا نصّ

2.3 فخاخ كلمات ANSI و Unicode و UTF-8N

حول Windows، تسميات الكلمات نفسها مصدر اضطراب.

أشدّ الثلاثة التباسًا هذه.

• ANSI يظهر في واجهة Windows والشروح القديمة، وليس ASCII. في الغالب يشير إلى صفحة الرموز النشطة (ACP) لذلك الجهاز.
• Unicode في بعض المحرّرات والأدوات تعني Unicode في القائمة UTF-16LE. قول حُفظ بـ Unicode لا يعني بالضرورة UTF-8.
• UTF-8N يظهر في محرّرات دائرة اليابانيّة، وهو عادة تسمية واجهة لتمييز UTF-8 no BOM. ليس الاسم الرسميّ للترميز.

أي أنّ الكلمة نفسها تنزاح معناها حسب الأداة في Windows. هذا أوّل موضع اضطراب كبير.

2.4 ما هو BOM، ولماذا يُلحق بـ UTF-8 أيضًا

BOM اختصار Byte Order Mark (علامة ترتيب البايتات)، وهو الرمز U+FEFF يُوضع في رأس الملفّ أو الجدول. كما يقول الاسم، دوره الأصليّ بيان ترتيب البايتات.

UTF-16 و UTF-32 يمثّلان الحرف بكتلة من 2 بايت / 4 بايت، فيلزم إبلاغ القارئ إن كانت الكتلة «من البايت الأدنى (little endian)» أم «من البايت الأعلى (big endian)». لذلك يُوضع BOM في الرأس، وترتيب بايتات ذلك الـ BOM يعلن أنّ ما يلي بالترتيب نفسه.

السؤال هنا: UTF-8 يعمل بوحدة البايت الواحد فلا مشكلة ترتيب، فلماذا يُلحق BOM.

السبب أنّ BOM في UTF-8 لا يُستخدم لترتيب البايتات بل كـ علامة (توقيع) تقول «هذا الملفّ UTF-8». UTF-8 متوافق مع ASCII، فإن كان المحتوى أحرفًا إنجليزيّة وأرقامًا فقط لم يُميَّز عن صفحة الرموز القديمة. وضع EF BB BF في الرأس يتيح للقارئ الحكم «اقرأ كـ UTF-8 لا كصفحة رموز نشطة».

وبالعكس يصير الأمر كالآتي.

• مزيّة إلحاق BOM: يصعب على القارئ إخفاق تخمين الترميز. وخصوصًا Windows PowerShell 5.1 تقرأ ملفّ السكربت بلا BOM كصفحة رموز نشطة، فالسكربت الذي يحتوي أحرفًا غير ASCII ينكسر من دون BOM.
• عيب إلحاق BOM: تزيد 3 بايتات زائدة في الرأس. في أنظمة لا تعرف BOM يُعامل الأمر كأنّ محرفًا غير مرئيّ اختلط في رأس السطر الأوّل. حوادث مثل عدم تطابق اسم العمود الأوّل في ترويسة CSV، أو عدم التعرّف على سطر #! في سكربت الصدفة، تأتي من هنا.

أي أنّ BOM في UTF-8 ليس حديث «إلحاقه صحيح / خطأ»، بل بند إعداد يُحسَم بحسب من يقرأ. لذلك كما في 7.1 يلزم حسم «with BOM أم no BOM» لا «صار UTF-8» وحده.

3. لماذا يحدث mojibake

3.1 حقيقة mojibake

حقيقة mojibake بسيطة جدًّا.

1. تُحوَّل السلسلة إلى بايتات بترميز أحرف معيّن
2. تُعاد تلك البايتات إلى سلسلة بترميز أحرف آخر
3. إن لم يتطابق الافتراض صارت سلسلة أخرى

مثلًا حفظ あ بـ UTF-8 يعطي البايتات الآتية.

E3 81 82

قراءتها كـ UTF-8 تعطي あ، وقراءتها بافتراض CP932 تظهر سلسلة أخرى مثل 縺�. التالف هنا ليس «اليابانيّة» بل افتراض فكّ الترميز.

إن قيل mojibake في سطر واحد:

قُرئ تسلسل البايتات نفسه كترميز أحرف مختلف.

flowchart TB
    A["الحرف あ"] -->|"حفظ بالترميز UTF-8"| B["البايتات E3 81 82<br/>هذا وحده ما في الملفّ"]
    B -->|"فكّ الترميز كـ UTF-8"| OK["الحرف あ ── الافتراض متطابق"]
    B -->|"فكّ الترميز كـ CP932"| NG["سلسلة أخرى مثل 縺 ── الافتراض منحرف"]

الشكل 1: في الشعبتين محتوى الملفّ (تسلسل البايتات) واحد. المختلف هو الافتراض الذي وضعه جانب القراءة فقط.

3.2 خلل العرض وتلف البيانات أمران مختلفان

المهمّ هنا فصل مرحلة ما زال الرجوع ممكنًا عن مرحلة يصعب الرجوع منها.

مثلًا في التدفّق الآتي ما زال الرجوع ممكنًا.

1. فتح ملفّ UTF-8 كـ CP932
2. يظهر على الشاشة مثل 縺�
3. لم يُحفَظ بعد

في هذه المرحلة تبقى البايتات الأصليّة UTF-8. إعادة الفتح بالترميز الصحيح قد تعيدها.

الخطر هو هذا التدفّق.

1. قراءة ملفّ UTF-8 خطأً كـ CP932
2. حفظ المحتوى الظاهر تالفًا كما هو
3. فقدان بايتات UTF-8 الأصليّة

إلى هنا يصير الأمر تلف بيانات لا خلل عرض.

flowchart TD
    F["ملفّ محفوظ بـ UTF-8<br/>البايتات E3 81 82"]
    F -->|"فتح بافتراض CP932"| V["يظهر على الشاشة مثل 縺<br/>= خلل عرض. البايتات ما زالت UTF-8"]
    V -->|"إعادة الفتح"| OK["تعيين الترميز الصحيح يعيد الأصل"]
    V -->|"الحفظ كما هو"| BAD["إعادة كتابة السلسلة المقروءة خطأً بـ CP932<br/>= تلف بيانات. تُفقد البايتات الأصليّة"]
    BAD --> NG["حتّى إن عُرف الترميز الصحيح لاحقًا لا يعود"]

الشكل 2: نقطة الفصل خطوة واحدة: «أُعيد الفتح أم حُفظ». في التحقيق أكّد هذا أوّلًا دائمًا.

عمليًّا مهمّ عدم تلخيص الأمر بجملة «صار mojibake»، وفصل هذين على الأقلّ.

• هل تسلسل البايتات نفسه ما زال صحيحًا
• هل أُعيد حفظ المحتوى المقروء خطأً أصلًا

3.3 الإسقاط إلى أحرف لا تُمثَّل لا يعود

خطر آخر هو إسقاط سلسلة Unicode إلى صفحة رموز ضيّقة مثل CP932.

حين تتضمّن أحرفًا غير موجودة لدى الطرف يحدث أحد الآتي.

• تُستبدل بـ ?
• يدخل محرف استبدال
• يحدث خطأ تحويل
• تُقرَّب إلى حرف قريب آخر

مثلًا بعض الرموز التعبيريّة والكانجي الموسَّع لا تسقط إلى CP932 كما هي. هذا الحادث ينبغي التفكير فيه لا بـ «هل يُقرأ» بل بـ هل يعود بعد التحويل ذهابًا وإيابًا.

المعلومة المفقودة مرّة لا تعود حتّى إن عُرف الترميز الصحيح لاحقًا.

4. ماذا يعني فرق محرف نهاية السطر

4.1 CRLF / LF / CR

نهاية السطر بايتات أيضًا.

• CR = carriage return = 0D
• LF = line feed = 0A
• في ملفّات نصّ Windows التقليديّ CRLF (0D 0A)
• في Linux / Unix الشائع LF (0A)
• CR وحده يظهر في سياقات قديمة مثل Mac القديم

جدولًا يكون كالآتي.

4.2 نهاية السطر مسألة منفصلة عن ترميز الأحرف

هذه نقطة مهمّة جدًّا.

نهاية السطر مسألة منفصلة عن ترميز الأحرف.

الملفّ نفسه بـ UTF-8 قد يكون نهاية سطره CRLF أو LF. مثلًا محتوى A ثمّ سطر ثمّ B تتغيّر بايتاته كالآتي.

UTF-8 + LF   : 41 0A 42
UTF-8 + CRLF : 41 0D 0A 42

أي أنّه شائع أن يكون:

• UTF-8 ونهاية السطر وحدها مختلفة
• CP932 ونهاية السطر LF
• UTF-16LE ونهاية السطر CRLF

لذلك حين يقال صار UTF-8 وما زال مختلفًا، قد يكون في الواقع نهاية السطر وحدها منحرفة لا الترميز.

4.3 \n وبايتات نهاية السطر في الملفّ ليسا بالضرورة الشيء نفسه

من منظور المطوّر هذا موضع اضطراب متواضع.

كتابة \n في الشيفرة لا تعني بالضرورة ظهور 0A وحده في الملفّ. في وضع النصّ لواجهة اللغة أو وقت التشغيل أو I/O، قد يُحوَّل \n إلى CRLF على Windows.

أي قد ينحرف الآتي.

• تمثيل نهاية السطر في الشيفرة
• السلسلة وقت التشغيل
• البايتات المحفوظة في الملفّ
• نهاية السطر الظاهرة في المحرّر

لذلك يقع حادث «ظننت أنّي كتبت LF وكان الملفّ CRLF».

المحرّرات الحديثة تتعامل مع LF وحده عادة، لكنّ الأدوات المحيطة والتطبيقات القديمة والتشغيل ما زالت تفترض CRLF. لذلك مشكلة نهاية السطر ليست «حديث الماضي»، بل تظهر في الممارسة الآن أيضًا.

5. لماذا يسهل الاضطراب في Windows تحديدًا

5.1 تعايش Unicode وصفحات الرموز القديمة

أكبر سبب لتعقيد Windows هو هذا.

في Windows بقي المساران:

• طريق يستخدم Unicode
• طريق يعالج بصفحة رموز

الأصول الأحدث والويب والعابرة للمنصّات تميل إلى UTF-8، بينما تبقى CSV و TXT والسجلّات ومحيط Excel وتكامل أنظمة العمل القديمة على CP932. وفوق ذلك يظهر UTF-16LE عادة حول بعض المخرجات والواجهات.

أي أنّ ثقافات نصّ عدّة تتعايش داخل Windows واحد.

5.2 التسميات غير متّسقة

ما يزيد الاضطراب ليس التقنية بقدر انحراف التسمية.

• يقال Shift_JIS والواقع CP932
• يقال ANSI والواقع صفحة الرموز النشطة
• يقال Unicode والواقع UTF-16LE
• يقال UTF-8 ووجود BOM غير محسوم
• تظهر تسميات خاصّة بالمحرّر مثل UTF-8N

إن بقي هذا ضبابيًّا بدا الحديث متفاهمًا بينما الكيان غير متطابق.

5.3 ASCII وحده يخفي المشكلة

هذا كبير أيضًا.

UTF-8 متوافق مع نطاق ASCII، فقد «يُقرأ بشكل ما» ملفّ الأحرف الإنجليزية والأرقام والرموز فقط حتّى بافتراض خاطئ. وفي جانب CP932 أيضًا نطاق ASCII المكافئ لا ينكسر ظاهره بسهولة، فلا تظهر المشكلة.

النتيجة حالة كهذه.

• ملفّ إعداد إنجليزيّ فقط يبدو سليمًا
• ينكسر في اللحظة التي يُدخل فيها سطر يابانيّ
• مشكلة كامنة طويلًا تشتعل أوّل مرّة أثناء التشغيل

لذلك تبدو حوادث الترميز كأنّها «كانت تعمل حتّى أمس وانكسرت اليوم فجأة». في الواقع كثيرًا ما يكون اللغم موجودًا من قبل، وظهر في لحظة دخول أحرف غير ASCII.

5.4 محتوى الملفّ واسم الملفّ والوحدة وملفّ المصدر طبقات مختلفة

في Windows يضلّ المرء إن سمّى الآتي كلّه «ترميز أحرف».

• اسم الملفّ / المسار
• محتوى الملفّ
• العرض على الوحدة
• ترميز ملفّ الشيفرة نفسه
• شكل السلسلة وقت التشغيل
• العرض على الحافظة أو عناصر الواجهة

مثلًا قد يظهر اسم ملفّ يابانيّ عاديًّا بينما محتوى الملفّ محفوظ بـ CP932. والعكس: الملفّ نفسه UTF-8، لكنّ العرض وحده ينكسر إن لم تطابق صفحة رموز الوحدة.

عمليّة مثل chcp 65001 تؤثّر في الأساس على افتراض جانب الوحدة، وليست حديث تغيير بايتات ملفّ قائم.

وفوق ذلك، كون ملفّ الشيفرة UTF-8 لا يعني أنّ ملفّ السجلّ الذي يُكتب وقت التشغيل UTF-8. يلزم فصل طبقة الترميز التي يدور الحديث عنها في كلّ مرّة.

وفي Windows اليابانيّ قد يظهر \ كعلامة الين، وهذا أيضًا يختلط بسهولة بحديث الترميز. غير أنّه في الغالب مشكلة خطّ عرض أو حرف، لا تغيّر معنى فاصل المسار أو الهروب.

5.5 BOM ونهاية السطر يعملان على محور منفصل أيضًا

قول UTF-8 وحده يحسم النصف فقط.

عمليًّا يؤثّر أيضًا:

• هل يوجد BOM أم لا
• هل نهاية السطر CRLF أم LF

مثلًا، في UTF-8 نفسه،

• أدوات Windows تقرأ إن وُجد BOM
• معالجة Unix تضيف محرفًا زائدًا في العمود الأوّل إن وُجد BOM
• أدوات قديمة تصعب عليها LF وحده
• CRLF قد يفسد سكربت الصدفة أو يوسّع diff

أي أنّ التطابق في الترميز لا يمنع الحادث بعد.

5.6 الأدوات تغيّر من تلقاء نفسها

الأشدّ إزعاجًا أنّ أداة اليد تغيّر ضمنًا.

• المحرّر يكشف تلقائيًّا
• عند الحفظ يُلحق BOM أو يُنزع
• Git يحوّل CRLF / LF
• الصدفة أو الأمر يحفظ بالترميز الافتراضيّ
• تصدير CSV يستخدم صفحة رموز غير متوقَّعة
• إصدار آخر من PowerShell أو الأداة يختلف افتراضه

أي أنّ طبقة ما تضيف افتراضًا من تلقاء نفسها حتّى إن لم يصرّح العامل، وهذا واقع Windows.

هذا حقيقة «لم أغيّر شيئًا فانكسر». في الواقع ليس نادرًا أنّ القيمة الافتراضيّة للأداة هي التي تغيّر، لا الإنسان.

6. أنماط حوادث شائعة

جدول الحوادث النموذجيّة كالآتي.

الأخطر نمط رؤية خلل العرض ثمّ الحفظ كما هو فيتثبّت الحادث.

7. قواعد تقلّل الحوادث في الممارسة

من هنا: ماذا يُحسَم كقاعدة تشغيل ليقلّ الحادث.

7.1 حسم الخطّ الأساس للنصّ الجديد

في الملفّات الجديدة، UTF-8 مرشّح أوّل معقول. غير أنّ ذلك وحده لا يكفي.

على الأقلّ أأمن حسم الآتي أيضًا.

• UTF-8 with BOM أم UTF-8 no BOM
• نهاية السطر CRLF أم LF
• من يقرأ الملفّ
• هل تلزم مواءمة أدوات Windows القديمة
• هل يقرأ Linux / macOS / CI / الحاوية أيضًا

مثلًا لشيفرة المصدر وملفّات الإعداد العابرة للمنصّات كثيرًا ما يكون UTF-8 no BOM + LF المرشّح الأوّل. أمّا إن لزم المواءمة مع أدوات Windows القديمة أو تشغيل قائم، فقد يبقى UTF-8 with BOM أو CP932 + CRLF لازمًا.

المهمّ ليس نظريّة «ما الصحيح»، بل الحسم بـ مع من تتبادل.

7.2 لا تغيّر الملفّات القديمة القائمة من تلقاء نفسك

إن كان الملفّ القائم CP932، فأأمن عدم تحويله إلى UTF-8 عرضًا مع تعديل يوميّ صغير.

التشغيل الآمن كالآتي.

• الملفّ القائم يحافظ على ترميزه الأصليّ / BOM / نهاية السطر
• تحويل الترميز يُفصل كمهمة ترحيل أخرى
• التحويل بالجملة بعد التحقّق من الهدف ومن جانب الاستخدام في المصبّ

حوادث mojibake كثيرًا ما تأتي من «تحديث عابر بحسن نيّة».

7.3 عامل الترميز ونهاية السطر كجزء من الواجهة

CSV و TXT والسجلّات وملفّات الإعداد والبروتوكول البسيط واجهة في شكل النصّ نفسه لا في المحتوى وحده.

في المواصفة أأمن كتابة الآتي على الأقلّ.

• ترميز الأحرف
• وجود BOM
• نهاية السطر
• وجود الترويسة
• مواصفة علامات الاقتباس / الفاصل
• بأيّ أداة جرى التحقّق

مثلًا حروف CSV الثلاثة لا تكفي. الحديث يصعب انحرافه أوّل مرّة عند كتابة UTF-8 with BOM, CRLF, فاصل فاصلة، ترويسة موجودة.

7.4 صرّح عند حدود القراءة والكتابة

في الشيفرة أيضًا أأمن عدم الميل إلى القيمة الافتراضيّة الضمنيّة.

• صرّح بترميز الأحرف عند قراءة الملفّ وكتابته
• انتبه إلى الترميز أيضًا في تمرير النصّ بين العمليّات
• ثبّت نهاية السطر كمواصفة في التصدير / الاستيراد
• لا تجعل إعادة توجيه الصدفة الفضفاضة مسار إنتاج

وخصوصًا في Windows، «تمّ الحفظ» و «حُفظ بتسلسل بايتات صحيح» ليسا الشيء نفسه.

7.5 شارك قواعد Git والمحرّر أيضًا

Git ليس أداة تصحّح الترميز تلقائيًّا. أمّا نهاية السطر فقد يدخل تحويل.

لذلك أأمن حسم الآتي على مستوى المستودع.

• هل شيفرة المصدر أساسها LF
• هل يُسمح بـ CRLF لنصّ Windows فقط
• كيف يُثبَّت بـ .gitattributes
• كيف تُشارك إعدادات المحرّر

مهمّ التفكير في الترميز ونهاية السطر كلّ على حدة. حتّى إن وحّد Git نهاية السطر، يبقى حادث الترميز كما هو.

7.6 لا تتوقّف عند «صار mojibake»؛ قُل ما الذي انحرف

في الميدان تنفع إعادة الصياغة هذه.

• صياغة سيّئة: صار mojibake
• صياغة جيّدة: يبدو أنّ ملفّ UTF-8 no BOM يُفتح بافتراض CP932
• صياغة سيّئة: نهاية السطر غريبة
• صياغة جيّدة: ملفّ LF حُوِّل إلى CRLF فزاد الفرق

مجرّد القدرة على قول ما انحرف تغيّر سرعة التحقيق كثيرًا.

7.7 للتحقّق - مواضع النظر حسب الأداة

القواعد السابقة لا تدور إلّا مع وسيلة التحقّق. لثلاثة شائعة نرتّب «أين ترى الترميز الحاليّ» و «أين تغيّره».

VS Code

الترميز الافتراضيّ في VS Code هو UTF-8 (بلا BOM). عند التغيير لكلّ ملفّ انقر عرض شريط الحالة، واختر إن كنت تعيد فتح الملفّ المفتوح الآن بترميز آخر، أم تعيد حفظه بترميز آخر. إن كان مجرّد قراءة خطأ فإعادة الفتح أوّلًا، وهذا يقابل حكم 3.2.

عند تغيير الافتراضيّ عيّن files.encoding في الإعداد. القيم مثل utf8 (بلا BOM)، utf8bom (مع BOM)، utf16le، windows1252. يمكن الفصل حسب اللغة أيضًا.

{
  "files.encoding": "utf8",
  "[powershell]": {
    "files.encoding": "utf8bom"
  }
}

فصل 2.4 «سكربت Windows PowerShell 5.1 وحده مع BOM» يمكن التعبير عنه بهذا الإعداد حسب اللغة.

المفكرة

مفكرة Windows 10 من Build 18963 فما بعد تملك عمودًا في شريط الحالة يعرض ترميز المستند، وافتراضيّ الملفّ الجديد UTF-8 (بلا BOM). عند الحفظ افتح «ملف» ثمّ «حفظ باسم»، واختر من حقل «الترميز» في الحوار. هذا الحقل يتيح اختيار وجود BOM أيضًا، فاعكس هنا سياسة 7.1.

عند بلاغ «فُتح في المفكرة فصار mojibake»، أسرع أن تبدأ بهذا الحقل وعرض شريط الحالة.

PowerShell

افتراضيّ PowerShell يختلف كثيرًا حسب الإصدار. من دون معرفة ذلك كثيرًا ما يصير الاستشارة «أخرجت بـ PowerShell فلم تقرأ الأداة».

• PowerShell 6 فما بعد (سلسلة PowerShell 7): افتراضيّ كلّ مخرجات النصّ utf8NoBOM، أي UTF-8 بلا BOM.
• Windows PowerShell 5.1: الافتراضيّ غير موحَّد حسب الأمر.

أهمّ ما في 5.1 جدولًا كالآتي.

للقراءة أيضًا افتراضيّ. عند غياب BOM، تعدّ Get-Content ومحرّك PowerShell ملفّ السكربت Default (صفحة الرموز النشطة)، بينما تعدّ Import-Csv و Select-String UTF-8. أي أنّ الملفّ نفسه يتغيّر افتراضه حسب الأمر الذي يقرأه.

هل لملفّ اليد BOM يظهر بالنظر إلى بايتات الرأس.

# PowerShell 7: 先頭 3 バイトを 16 進で表示する
Get-Content -Path .\sample.txt -AsByteStream -TotalCount 3 | Format-Hex

# Windows PowerShell 5.1 には -AsByteStream がないので -Encoding Byte を使う
Get-Content -Path .\sample.txt -Encoding Byte -TotalCount 3 | Format-Hex

الرأس EF BB BF يعني UTF-8 with BOM، و FF FE يعني UTF-16LE، وغير ذلك بلا BOM. النظر نفسه كجدول 2.4.

إن أردت تثبيت الافتراضيّ صراحة استخدم $PSDefaultParameterValues.

# Encoding パラメーターを持つすべてのコマンドレットの既定を UTF-8 にする
$PSDefaultParameterValues['*:Encoding'] = 'utf8'

هنا فخ بين الإصدارات. السلسلة نفسها utf8 تعني في Windows PowerShell 5.1 UTF-8 with BOM، ومن PowerShell 6 فما بعد UTF-8 no BOM. إن أردت تثبيت وجود BOM أيضًا، فأأمن التصريح بـ utf8BOM / utf8NoBOM المتاحتين من PowerShell 6 فما بعد.

و$OutputEncoding هو ترميز التمرير مع البرنامج الخارجيّ، ولا يؤثّر في ترميز حفظ الملفّ بإعادة التوجيه أو الأوامر. هذا موضع يسهل خلطه.

8. التحقيق في mojibake وفرق نهاية السطر بهذه الأسئلة الخمسة

إن حرت في التحقيق، أسرع طريق هو العودة إلى هذه الأسئلة الخمسة.

1. ما تسلسل بايتات هذا الملفّ الآن
   • UTF-8
   • UTF-8 with BOM
   • CP932
   • UTF-16LE
2. من كتبه أوّلًا، وبأيّ افتراض
   • المحرّر
   • تطبيق قديم
   • تصدير Excel
   • الصدفة / السكربت
   • دفعة / وسيط
3. من يقرأ الآن، وبأيّ افتراض
   • الكشف التلقائيّ في المحرّر
   • صفحة رموز الوحدة
   • الترميز الافتراضيّ للمكتبة
   • مواصفة جانب الاستيراد
4. ما BOM ونهاية السطر
   • مع BOM / بلا BOM
   • CRLF / LF
5. هل حُفظ المحتوى المقروء خطأً أصلًا
   • ما زال عرضًا فقط
   • أُعيد الحفظ وفُقدت البايتات

امتلاء هذه الخمسة يُظهر السبب في الغالب.

9. الخلاصة

يبدو ترميز أحرف Windows ونهاية السطر معقّدين لا لأنّ اليابانيّة صعبة. بل لأنّ تسلسل البايتات وترميز الأحرف و BOM ونهاية السطر والقيمة الافتراضيّة للأداة توجد كلّ على حدة، وفوق ذلك تتعايش في Windows ثقافات نصّ قديمة وحديثة.

ما يستحقّ التذكّر تحديدًا هذه الستّ.

• mojibake نتيجة قراءة تسلسل البايتات نفسه كترميز أحرف آخر
• مشكلة نهاية السطر محور منفصل عن الترميز
• لا تثق أكثر ممّا ينبغي بكلمات Shift_JIS و CP932 و ANSI و Unicode
• صار UTF-8 لا يكفي، ويلزم BOM ونهاية السطر أيضًا
• افصل خلل العرض عن تلف البيانات بعد إعادة الحفظ
• في المواصفة اكتب مثل UTF-8 no BOM, LF لا نصّ

بمعنى آخر، التعامل مع نصّ Windows عمليًّا ليس «حديث سلسلة»، بل كيف توحَّد مواعدة تسلسل البايتات.

10. مقالات ذات صلة

• مدخل إلى ترميز النصّ على Windows - تشوّه النصّ عند التعامل مع Linux
• قواعد توجيه تقلّل حوادث mojibake لـ Codex على Windows

11. المراجع

1. Microsoft Learn, Code Page Identifiers - Win32 apps https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
2. Microsoft Learn, about_Character_Encoding - PowerShell https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_character_encoding?view=powershell-7.6
3. Microsoft Learn, Understanding file encoding in VS Code and PowerShell https://learn.microsoft.com/en-us/powershell/scripting/dev-cross-plat/vscode/understanding-file-encoding?view=powershell-7.6
4. W3C Internationalization, Character encodings: Essential concepts https://www.w3.org/International/articles/definitions-characters/
5. Git documentation, gitattributes https://git-scm.com/docs/gitattributes
6. Git documentation, git-config https://git-scm.com/docs/git-config
7. Microsoft Learn, The Unicode standard - Globalization (بايتات BOM، واستخدام BOM في UTF-8 كتوقيع) https://learn.microsoft.com/en-us/globalization/encoding/unicode-standard
8. Microsoft Learn, What was new in 20H1 Windows 10 Insider Preview Builds (افتراضيّ UTF-8 في المفكرة في Build 18963، وإضافة عرض الترميز إلى شريط الحالة) https://learn.microsoft.com/en-us/previous-versions/windows-insider/archive/new-in-20h1

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

لماذا يحدث mojibake؟

لأنّ تسلسل البايتات نفسه قُرئ بترميز أحرف مختلف عن الذي كُتب به. مثلًا حفظ «あ» بـ UTF-8 يعطي البايتات E3 81 82، وقراءتها بافتراض CP932 تظهر سلسلة أخرى مثل «縺». التالف هنا ليس اليابانيّة بل افتراض decode. غير أنّ إعادة حفظ المحتوى المقروء خطأً تفقد البايتات الأصليّة، فيصير الأمر تلف بيانات لا خلل عرض، لذلك مهمّ إعادة الفتح بالترميز الصحيح قبل الحفظ.

ما الفرق بين CRLF و LF؟

فرق بايتات فاصل السطر. CRLF بايتان 0D 0A ويُستخدم تقليديًّا في ملفّات نصّ Windows، و LF بايت واحد 0A وهو شائع في Linux / macOS وكثير من أدوات التطوير. المهمّ أنّ نهاية السطر مسألة منفصلة عن ترميز الأحرف. الملفّ نفسه بـ UTF-8 قد يكون CRLF أو LF، لذلك حين يبقى شيء «مختلفًا رغم التحويل إلى UTF-8» قد يكون المنحرف نهاية السطر لا الترميز.

هل Shift_JIS و CP932 الشيء نفسه؟

في الحديث اليوميّ يُفهم المقصود، لكنّ في الممارسة أأمن الفصل. إن أردت وعيًا أدقّ بنصّ Windows اليابانيّ القديم، فكّر بـ CP932 أو صفحة رموز يابانيّة من عائلة Windows. بالمثل، «ANSI» في Windows يشير في الغالب إلى صفحة الرموز النشطة لذلك الجهاز، و«Unicode» في قائمة المحرّر قد تعني UTF-16LE. في المواصفات ومذكّرات التحقيق اكتب بشكل ملموس مثل «UTF-8 no BOM, LF» حتّى لا ينحرف الحديث.

ماذا ينبغي حسمه في مواصفة الملفّ النصّيّ؟

«صار UTF-8» لا يكفي؛ قاعدة التشغيل تكتمل بحسم وجود BOM ونهاية السطر أيضًا. في ملفّات التبادل مثل CSV والسجلّات أأمن كتابة الترميز ووجود BOM ونهاية السطر ووجود الترويسة ومواصفة الفاصل. لشيفرة المصدر والإعدادات العابرة للمنصّات كثيرًا ما يكون UTF-8 no BOM + LF المرشّح الأوّل، بينما قد يبقى UTF-8 with BOM أو CP932 + CRLF لازمًا لمواءمة أدوات Windows القديمة.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.