مدخل إلى ترميز النصّ على Windows - تشوّه النصّ عند التعامل مع Linux

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

يظهر ذلك بقوّة عند عبور Windows وLinux. يبقى في جانب Windows سياقات متعدّدة: CP932 وUTF-8 وUTF-16 وcode page لوحدة التحكّم وفروق إصدارات PowerShell، بينما يجري جانب Linux في كثير من الأحيان بفرضيّة UTF-8، فينكشف دفعة واحدة انحراف الفرضيّات الذي كان خفيّاً في الاستخدام اليومي.

flowchart TB
    accTitle: شكل انحراف الفرضيّات بين Windows وLinux
    accDescr: مخطّط يبيّن أن جانب Windows تبقى فيه سياقات متعدّدة مثل CP932 وUTF-16 وcode page لوحدة التحكّم وفروق الإصدارات، وأن الجمع مع جانب Linux الذي يجري غالباً بفرضيّة UTF-8 يكشف انحراف الفرضيّات.
    w1["جانب Windows"] --> w2["CP932 / UTF-16 / code page / فروق الإصدار"]
    l1["جانب Linux"] --> l2["فرضيّة UTF-8 قويّة"]
    w2 --> z1["ينكشف انحراف الفرضيّات"]
    l2 --> z1

الشكل 1: عند التقاء السياقات المتعدّدة المتبقّية في Windows مع فرضيّة UTF-8 في Linux، ينكشف الانحراف دفعة واحدة.

المسألة أقرب إلى محاذاة الفرضيّة التي تُعالَج بها البايتات منها إلى صعوبة معالجة اليابانيّة. ترتّب هذه المقالة ترميز Windows من زاوية «لماذا يحدث تشوّه النصّ»، وتلخّص عمليّاً النقاط التي تزداد فيها الحوادث عند الجمع مع Linux.

الجمهور من يمرّر CSV أو سجلاّت أو ملفّات إعداد صُنعت على Windows إلى جانب Linux، أو العكس، ويريد تشخيص التشوّه واستعادته بنفسه. لا نفترض معرفة بلغة أو إطار معيّن. أمثلة الأوامر تستخدم iconv وPowerShell.

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

إن اقتصرنا على النقاط المهمّة، فهذه ستّة.

• تشوّه النصّ ليس مشكلة «حروف» بل مشكلة «كيف فُسِّرت البايتات».
• يتعايش على Windows مسار Unicode مع مسار code page القديم، فتختلف الفرضيّة حتى داخل الجهاز الواحد حسب السياق.
• فرضيّة UTF-8 قويّة في جانب Linux، لذا يسهل الحادث إذا اختلط CP932 أو UTF-16 من جانب Windows.
• مرحلة انهيار العرض وحدها ومرحلة حفظ المحتوى التالف ينبغي فصلهما.
• اجعل UTF-8 الخيار الأوّل للنصّ الجديد، وأبقِ ملفّات legacy القائمة كما هي حتى مهمّة ترحيل صريحة.
• encoding الملفّ، وencoding المحرّر، وcode page لوحدة التحكّم، وتمثيل السلسلة داخل التطبيق، أمور مختلفة. خلطها يُضيّع التحقيق.

قول «تشوّه النصّ على Windows» لا يحدّد السبب. على الأقل افصل أيّ من التالي انحرف.

• ترميز الملفّ نفسه
• ترميز الحفظ
• تفسير المحرّر
• code page للإدخال/الإخراج في وحدة التحكّم
• تمثيل السلسلة داخل التطبيق
• locale في جانب Linux والـ encoding المتوقّع

flowchart TB
    accTitle: الطبقات التي تُفصَل عند تشخيص تشوّه النصّ
    accDescr: مخطّط يبيّن أن قول «تشوّه النصّ على Windows» لا يحدّد السبب، وأنّه يلزم فصل أيّ من ترميز الملفّ نفسه وترميز الحفظ وتفسير المحرّر وcode page لوحدة التحكّم وتمثيل السلسلة داخل التطبيق وlocale في Linux قد انحرف.
    s0["تشوّه النصّ على Windows"] --> q1{"أين الانحراف"}
    q1 --> a1["ترميز الملفّ نفسه"]
    q1 --> a2["ترميز الحفظ"]
    q1 --> a3["تفسير المحرّر"]
    a1 --> a4["code page لوحدة التحكّم"]
    a2 --> a5["تمثيل السلسلة داخل التطبيق"]
    a3 --> a6["locale في Linux"]

الشكل 2: «تشوّه النصّ» وحده لا يحدّد السبب؛ انظر أيّاً من هذه الطبقات الستّ انحرف.

1.1 مصطلحات تظهر لاحقاً

نلخّص باختصار الاختصارات التي تظهر في المتن دون شرح.

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

2. ماهيّة تشوّه النصّ

ماهيّة تشوّه النصّ بسيطة جدّاً.

1. تُرمَّز السلسلة (encode) بترميز ما إلى بايتات
2. تُفَكّ تلك البايتات (decode) بترميز ما إلى سلسلة
3. إن لم تتطابق فرضيّة encode مع decode، تُقرأ كسلسلة أخرى

flowchart TB
    accTitle: تطابق فرضيّة encode وdecode
    accDescr: مخطّط يبيّن أن البايتات الناتجة عن encode السلسلة إذا أُعيدت decode إلى سلسلة، تعود إلى الأصل عند تطابق الفرضيّتين، وتُقرأ كسلسلة أخرى عند الانحراف.
    e1["encode السلسلة إلى بايتات"] --> e2["decode البايتات إلى سلسلة"]
    e2 --> j1{"هل الفرضيّتان متطابقتان"}
    j1 -->|"متطابقتان"| r1["تعود السلسلة الأصليّة"]
    j1 -->|"منحرفتان"| r2["تُقرأ كسلسلة أخرى"]

الشكل 3: ماهيّة تشوّه النصّ هي عدم تطابق فرضيّة encode وdecode.

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

E3 81 82

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

المهم أن ما يحدث هنا ليس «اليابانيّة انكسرت»، بل انحرفت تفسيرات البايتات نفسها.

انظر الاتجاه المعاكس أيضاً. حفظ あ بـ CP932 يعطي البايتات التالية.

82 A0

محاولة قراءتها كـ UTF-8 تفشل لأن 0x82 و0xA0 لا يصلحان كبايت بداية لـ UTF-8، فيصيران حرفَي استبدال ويظهران مثل ��. من جهة UTF-8 لا تقوم كحرف أصلاً.

مثال أطول يُظهر السمة أوضح. حفظ 日本語 بـ CP932 يعطي البايتات التالية.

93 FA 96 7B 8C EA

قراءتها كـ UTF-8 تصير مثل ���{��. ما ينبغي النظر إليه هنا هو أن البايت الرابع 0x7B وحده يمرّ كـ { في ASCII. البايت الثاني في CP932 قد يقع في نطاق ASCII، فتختلط في النتيجة رموز مثل { أو \.

أي أن الأعراض تختلف حسب الاتجاه.

يمكن تخمين السبب بسرعة: «إن توالت كانجي غير مقروءة فأنت تقرأ UTF-8 كـ CP932» و«إن امتلأت بأحرف الاستبدال فأنت تقرأ CP932 كـ UTF-8». تذكّر هذا اللاتماثل يسرّع التشخيص.

2.1 إن انهار العرض فقط، فقد يبقى الاسترداد ممكناً

لتشوّه النصّ مرحلة يمكن فيها الاسترداد. مثلاً، إن لم تتغيّر البايتات الأصليّة، قد يكفي إعادة الفتح بالـ encoding الصحيح.

الخطر هو التسلسل التالي.

1. قراءة ملفّ UTF-8 خطأً كـ CP932
2. يظهر على الشاشة مثل 縺�
3. حفظ «السلسلة الظاهرة» كما هي
4. تضيع بايتات UTF-8 الأصليّة

عند دخول هذه المرحلة لا يبقى الأمر انهيار عرض، بل تلفاً للبيانات.

flowchart TB
    accTitle: مسار تحوّل انهيار العرض إلى تلف بيانات
    accDescr: مخطّط يبيّن أن قراءة ملفّ UTF-8 خطأً كـ CP932 حتى يظهر مشوّهاً على الشاشة، ثم حفظ السلسلة الظاهرة كما هي حتى تضيع بايتات UTF-8 الأصليّة، يحوّل المسألة من انهيار عرض إلى تلف بيانات.
    d1["قراءة ملفّ UTF-8 خطأً كـ CP932"] --> d2["يظهر مشوّهاً على الشاشة"]
    d2 --> d3["حفظ السلسلة الظاهرة كما هي"]
    d3 --> d4["تضيع بايتات UTF-8 الأصليّة"]
    d2 -.-> n1["حتى هنا يكفي إعادة الفتح"]
    d4 -.-> n2["من هنا تلف بيانات"]

الشكل 4: القراءة الخاطئة وحدها قابلة للاسترداد، أمّا حفظ المحتوى المقروء خطأ فيحوّلها إلى تلف بيانات.

2.2 أخطر منه إسقاط «حرف لا يُمثَّل» إلى code page ضيّق

حادث نموذجي آخر هو إسقاط سلسلة Unicode إلى code page قديم مثل CP932.

إذا تضمّنت السلسلة حرفاً غير موجود في code page الطرف:

• يُستبدَل بـ ?
• يدخل حرف الاستبدال �
• يُحوَّل إلى حرف قريب مختلف
• تفشل التحويلة

هذا الحادث لا يُرى بـ مقروء / غير مقروء فقط، بل بـ هل تعود السلسلة بعد التحويل ذهاباً وإياباً. الحرف الضائع مرّة لا يُستعاد حتى بعد معرفة الـ encoding الصحيح.

flowchart TB
    accTitle: حادث الإسقاط إلى code page ضيّق
    accDescr: مخطّط يبيّن أن تحويل سلسلة Unicode إلى code page ضيّق مثل CP932 يستبدل الحروف غير الموجودة أو يفشل التحويل، فلا تعود بعد الذهاب والإياب، وأن الحرف الضائع لا يُستعاد حتى بمعرفة الـ encoding الصحيح.
    u1["سلسلة Unicode"] --> u2["تحويل إلى code page ضيّق مثل CP932"]
    u2 --> j1{"الحرف غير الموجود لدى الطرف"}
    j1 --> r1["يتحوّل إلى ? أو حرف استبدال"]
    j1 --> r2["حرف مختلف أو فشل التحويل"]
    r1 --> k1["لا يعود بعد الذهاب والإياب"]
    r2 --> k1
    k1 -.-> n1["الحرف الضائع لا يُستعاد"]

الشكل 5: حادث الإسقاط إلى code page ضيّق يُرى بالذهاب والإياب لا بمقروء / غير مقروء.

3. لماذا يسهل التعقيد على Windows

تعقيد Windows ليس لأنّه قديم فحسب. السبب أن عالم Unicode وعالم code page القديم ما زالا يتعايشان.

3.1 مساران في Windows API: Unicode وcode page

في Windows API مساران كبيران.

• عائلة W: wide character. تعامل Unicode كـ UTF-16
• عائلة A: مسار code page يُدعى ANSI

أي أن داخل Windows يوجد منذ البداية «طريق Unicode» و«طريق active code page في تلك اللحظة». لذلك تتغيّر الفرضيّة حتى على Windows نفسه حسب أيّ API أو أيّ أداة مرّت.

flowchart TB
    accTitle: مسارا Windows API
    accDescr: مخطّط يبيّن أن Windows API يتعايش فيه منذ البداية مسار W الذي يعامل Unicode كـ UTF-16 ومسار A الذي يعامل active code page في تلك اللحظة، فتتغيّر الفرضيّة حسب المسار.
    api["Windows API"] --> w1["عائلة W (wide character)"]
    api --> a1["عائلة A (تُدعى ANSI)"]
    w1 --> w2["تعامل Unicode كـ UTF-16"]
    a1 --> a2["تعامل بـ active code page"]
    w2 --> z1["الفرضيّة تتغيّر حسب المسار"]
    a2 --> z1

الشكل 6: داخل Windows يوجد منذ البداية طريق Unicode وطريق code page.

3.2 «اليابانيّة على Windows» ليست واحدة

في اليابانيّة على Windows تختلط عمليّاً أربعة أمور.

• CP932: شائع في النصّ القديم على Windows الياباني
• UTF-8: يزداد في الأصول النصّيّة الجديدة والويب والأنظمة متعدّدة المنصّات
• UTF-16LE: ما زال يظهر بانتظام في سياق أدوات Windows وواجهات API
• code page لوحدة التحكّم: طبقة أخرى تؤثّر في إدخال/إخراج cmd.exe وبعض أدوات وحدة التحكّم

المهم هنا أن chcp 65001 لا يجعل الملفّ أيضاً UTF-8. تغيير code page لوحدة التحكّم ومسألة ماهيّة بايتات الملفّ القائم أمران منفصلان.

flowchart TB
    accTitle: chcp 65001 والملفّ القائم مسألتان منفصلتان
    accDescr: مخطّط يبيّن أن chcp 65001 يغيّر code page لوحدة التحكّم فقط، وأن بايتات الملفّ القائم لا تتغيّر، فإعداد وحدة التحكّم ومحتوى الملفّ مسألتان منفصلتان.
    c1["تنفيذ chcp 65001"] --> c2["يتغيّر code page لوحدة التحكّم"]
    f1["بايتات الملفّ القائم"] --> f2["لا تتغيّر"]
    c2 --> n1["وحدة التحكّم والملفّ مسألتان منفصلتان"]
    f2 --> n1

الشكل 7: chcp 65001 يغيّر تفسير وحدة التحكّم فقط، وتبقى بايتات الملفّ كما هي.

يُدعى النصّ القديم على Windows الياباني كثيراً «Shift_JIS» على عجل، لكن في الممارسة الوعي باسم CP932 يقلّل انحراف الحوار. يكفي أن يُصرَّح بأن الحديث عن «ترميز ياباني قديم آتٍ من Windows».

3.3 اسم الملفّ ومحتوى الملفّ مسألتان منفصلتان

إذا ظهرت أسماء الملفّات اليابانيّة على Windows بشكل طبيعي، يسهل الظنّ «إذن المحتوى سليم أيضاً». هنا الخطر.

• طبقة التعامل مع المسار / اسم الملفّ
• طبقة قراءة محتوى الملفّ
• طبقة العرض في وحدة التحكّم

هذه الثلاث مختلفة.

مثلاً، قد يُعالَج المسار الياباني بلا مشكلة بينما محتوى الملفّ محفوظ بـ CP932 فيُكسَر عندما يقرأه جانب Linux كـ UTF-8. والعكس: حتى إن كان المحتوى UTF-8، ينهار العرض وحده إن لم يطابق code page لوحدة التحكّم.

علاقة الطبقات كالتالي.

flowchart LR
    W["الكاتب<br/>تطبيق / محرّر / سكربت"] --> FB["بايتات الملفّ<br/>هذه وحدها هي الحقيقة"]
    FB --> R1["قارئ A: المحرّر<br/>كشف تلقائي أو encoding محدّد"]
    FB --> R2["قارئ B: وحدة التحكّم<br/>code page للإدخال/الإخراج"]
    FB --> R3["قارئ C: داخل التطبيق<br/>encoding الافتراضي للمكتبة"]
    FB --> R4["قارئ D: جانب Linux<br/>فرضيّة UTF-8 وفق locale"]
    R1 --> S1["ينهار العرض فقط<br/>وإعادة الحفظ تحوّله إلى تلف"]
    R2 --> S2["ينهار العرض فقط<br/>الملفّ سليم"]
    R3 --> S3["تفسد نتيجة المعالجة<br/>وتنتقل إلى المصبّ"]
    R4 --> S4["decode error أو حرف استبدال"]

الشكل 8: الحقيقة بايتات الملفّ وحدها، وقرّاء المحرّر ووحدة التحكّم والتطبيق وجانب Linux مستقلّون عن بعضهم.

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

3.4 القيم الافتراضيّة في PowerShell والأدوات المحيطة غير موحّدة

ما يزيد الحوادث بهدوء على Windows هو أن البايتات الناتجة تختلف حسب المسار حتى مع نيّة «كتابة نصّ» نفسها.

ما يستحق الانتباه خصوصاً:

• Windows PowerShell 5.1 encoding الافتراضي فيه غير متّسق
• بعض cmdlet وإعادة التوجيه تنتج UTF-16LE
• مسارات أخرى تستخدم active ANSI code page
• من PowerShell 7 فما فوق الافتراضي UTF-8 بدون BOM

أي أن «نصّ أخرجه PowerShell» لا يحدّد encoding. يلزم النظر حتى أيّ إصدار، وأيّ cmdlet، وأيّ مسار كتابة.

أي مسار ينتج أيّ بايتات مرتَّب في about_Character_Encoding على Microsoft Learn. استخراج الشائع يعطي الجدول التالي.

جانب القراءة أيضاً فيه فرق. عند قراءة ملفّ بلا BOM، Get-Content في 5.1 يعدّه ANSI، بينما Import-Csv وSelect-String يعدّانه UTF-8. الفرضيّة منقسمة داخل الجلسة نفسها.

ما يصيب الممارسة أكثر هو أن نفس «كتابة نصّ» تجعل Out-File UTF-16LE وSet-Content CP932. «النصّ الذي يشبه الثنائي لكثرة بايتات NUL» المذكور في 4.3 يأتي في الغالب من افتراضي > أو Out-File.

flowchart TB
    accTitle: لاتماثل جانب القراءة في Windows PowerShell 5.1
    accDescr: مخطّط يبيّن أن قراءة ملفّ بلا BOM في Windows PowerShell 5.1 تجعل Get-Content يعدّه ANSI بينما Import-Csv وSelect-String يعدّانه UTF-8، فتنقسم الفرضيّة داخل الجلسة نفسها.
    b1["ملفّ بلا BOM"] --> g1["القراءة بـ Get-Content"]
    b1 --> i1["القراءة بـ Import-Csv أو Select-String"]
    g1 --> g2["يُعدّ ANSI"]
    i1 --> i2["يُعدّ UTF-8"]
    g2 --> z1["الفرضيّة تنقسم داخل الجلسة نفسها"]
    i2 --> z1

الشكل 9: في 5.1 حتى الملفّ نفسه بلا BOM يُفترَض له encoding مختلف حسب cmdlet القراءة.

كذلك في 5.1 حتى تحديد -Encoding UTF8 يصير مع BOM. لكتابة UTF-8 بدون BOM في 5.1 تُكتَب من جانب .NET.

# Windows PowerShell 5.1 で UTF-8 no BOM を書く
$text = "日本語を含む本文"
[System.IO.File]::WriteAllText(
    "C:\work\output.txt", $text,
    (New-Object -TypeName System.Text.UTF8Encoding -ArgumentList $false))

جعل وسيط UTF8Encoding مساوياً $false هو تحديد عدم إرفاق BOM. في PowerShell 7 النتيجة نفسها بـ -Encoding utf8NoBOM.

4. حوادث نموذجيّة عند الجمع مع Linux

ما كان يدور تقريباً على Windows وحده ينكسر فجأة عند إدخال Linux، وهذا شائع. السبب بسيط: فرضيّة UTF-8 قويّة في جانب Linux.

4.1 نصّ حُفظ بـ CP932 على Windows يقرأه Linux كـ UTF-8

الحادث الأكثر شيوعاً.

• تطبيق قديم أو تشغيل قديم على Windows يكتب CSV / TXT / log بـ CP932
• سكربت أو أداة في جانب Linux تقرأ بفرضيّة UTF-8 وفق locale
• النتيجة decode error أو � أو سلسلة بلا معنى

ليس العيب في أداة Linux حينها، بل السبب الجذري أن البايتات المستلمة بلا عقد encoding.

flowchart TB
    accTitle: حادث قراءة نصّ CP932 كـ UTF-8 في Linux
    accDescr: مخطّط يبيّن أن تطبيقاً قديماً أو تشغيلاً قديماً على Windows يكتب CSV أو سجلاّت بـ CP932، ثم يقرأ سكربت أو أداة في Linux بفرضيّة UTF-8 وفق locale بلا عقد encoding، فينتج decode error أو حرف استبدال.
    p1["تطبيق قديم يكتب CSV / log بـ CP932"] --> p2["تمرير بلا عقد encoding"]
    p2 --> p3["جانب Linux يقرأ بفرضيّة UTF-8 وفق locale"]
    p3 --> p4["decode error / حرف استبدال"]
    p2 -.-> n1["السبب الجذري غياب العقد"]

الشكل 10: العيب ليس في أداة Linux، بل في غياب عقد encoding على البايتات.

4.2 UTF-8 بدون BOM صُنع في Linux / VS Code يعدّه جانب Windows ANSI

هناك حادث في الاتجاه المعاكس أيضاً.

• صناعة سكربت / إعداد / نصّ UTF-8 بدون BOM في Linux أو VS Code
• Windows PowerShell 5.1 أو أداة قديمة تعدّ الملفّ بلا BOM code page من جانب ANSI
• تتكسّر فقط الأسطر التي تتضمّن يابانيّة أو non-ASCII

يُلام UTF-8 غالباً هنا، لكن السبب الفعلي هو اختلاط قارئ لا يخمن UTF-8 بدون BOM تخميناً صحيحاً.

flowchart TB
    accTitle: حادث عدّ UTF-8 بدون BOM كـ ANSI
    accDescr: مخطّط يبيّن أن ملفّ UTF-8 بدون BOM صُنع في Linux أو VS Code إذا قرأه Windows PowerShell 5.1 أو أداة قديمة كـ code page من جانب ANSI، تتكسّر فقط الأسطر التي تتضمّن يابانيّة أو non-ASCII.
    v1["صناعة UTF-8 بدون BOM في Linux / VS Code"] --> v2["قراءة 5.1 أو أداة قديمة"]
    v2 --> v3["عدّ الملفّ بلا BOM من جانب ANSI"]
    v3 --> v4["تتكسّر فقط أسطر non-ASCII"]
    v3 -.-> n1["السبب قارئ لا يخمن"]

الشكل 11: في الحادث المعاكس السبب قارئ لا يستطيع تخمين UTF-8 بدون BOM.

4.3 جانب Windows يكتب UTF-16LE، وفي Linux «لا يبدو نصّاً»

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

• بعض مخرجات Windows PowerShell 5.1 أو أدوات قديمة تكتب UTF-16LE
• أدوات النصّ في Linux تفترض دفق بايت واحد بـ UTF-8
• النتيجة «نصّ يشبه الثنائي» اختلطت فيه بايتات NUL بكثرة

UTF-16LE نفسه ليس سيّئاً. لكن فرضيّة تمريره كما هو إلى أدوات معالجة النصّ في Linux لا تتوافق في كثير من المواضع.

flowchart TB
    accTitle: حادث ظهور UTF-16LE كثنائي في جانب Linux
    accDescr: مخطّط يبيّن أن UTF-16LE الذي تكتبه بعض مخرجات Windows PowerShell 5.1 أو أدوات قديمة، إذا أُمرر إلى أداة نصّ في Linux تفترض دفق بايت واحد بـ UTF-8، يبدو كنصّ يشبه الثنائي لكثرة بايتات NUL.
    u1["بعض مخرجات 5.1 أو أدوات قديمة"] --> u2["تكتب UTF-16LE"]
    u2 --> u3["أداة النصّ في Linux تفترض دفق بايت واحد"]
    u3 --> u4["تختلط بايتات NUL فيبدو كثنائي"]

الشكل 12: UTF-16LE نفسه ليس سيّئاً، لكنّه لا يتوافق مع فرضيّة معالجة النصّ في Linux.

4.4 وجود BOM أو غيابه يولّد احتكاكاً أيضاً

BOM ليس الـ encoding نفسه، لكنّه يؤثّر بقوّة في الممارسة.

• بعض أدوات Windows تستفيد من وجود BOM
• بعض أدوات Linux تعامل BOM كبايتات زائدة في الرأس
• النتيجة انكسار العمود الأوّل أو رأس السطر الأوّل فقط، أو فضلات غير مرئيّة، أو انحراف نتيجة المقارنة

في UTF-8 خصوصاً، البايتات مختلفة حتى مع نفس UTF-8 حسب وجود BOM أو غيابه. «جعلناه UTF-8» وحده لا يحدّد بعد نصف قاعدة التشغيل.

flowchart TB
    accTitle: الاحتكاك الناجم عن وجود BOM أو غيابه
    accDescr: مخطّط يبيّن أن البايتات تختلف حتى مع نفس UTF-8 حسب وجود BOM أو غيابه، وأن بعض أدوات Windows تستفيد من BOM بينما بعض أدوات Linux تعاملها كبايتات زائدة في الرأس، فينكسر الرأس فقط.
    b0["حتى نفس UTF-8 بايتات مختلفة مع BOM / بدونه"] --> w1["بعض أدوات Windows"]
    b0 --> l1["بعض أدوات Linux"]
    w1 --> w2["وجود BOM يفيد"]
    l1 --> l2["تعامل كبايتات زائدة في الرأس"]
    l2 --> l3["ينكسر الرأس فقط أو تلحق فضلات غير مرئيّة"]

الشكل 13: «جعلناه UTF-8» لا يكفي؛ القاعدة تكتمل بقرار وجود BOM أو غيابه.

4.5 الثقة بمظهر وحدة التحكّم تُضلّل

عند عبور Windows وLinux، وحدة التحكّم أيضاً خطرة.

• لوحدة التحكّم في Windows code page للإدخال / الإخراج
• طرف Linux يعمل غالباً بفرضيّة locale UTF-8
• المرور عبر WSL أو SSH أو حاوية أو CI يزيد مسارات العرض

في هذه الحالة يسهل الخطأ في الحكم بأن «ظهر في وحدة التحكّم إذن الملفّ سليم» أو «انهار في وحدة التحكّم إذن الملفّ تالف». هل التالف هو الظاهر أم البايتات المحفوظة، يؤكَّد كلّ على حدة بأمان أكبر.

4.6 جدول الحوادث النموذجيّة

5. تحقيق تشوّه النصّ بأربعة أسئلة

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

5.1 ما البايتات الأصليّة

أوّل ما يُنظَر إليه هو «ما بايتات هذا الملفّ الآن». الوعي بالبايتات لا بالمظهر.

• UTF-8؟
• UTF-8 مع BOM؟
• CP932؟
• UTF-16LE؟
• هل أُعيد الحفظ في الطريق فصار شيئاً آخر؟

5.2 من كتب أوّلاً، وبأيّ فرضيّة

ثم حدّد «الكاتب الأوّل».

• تطبيق قديم على Windows؟
• PowerShell 5.1 أم 7؟
• سكربت Linux؟
• VS Code؟
• تصدير من Excel؟
• وسيط / دفعة / CI ما؟

ما دام هذا غامضاً، يبقى تخمين encoding حظّاً.

5.3 من يقرأ الآن، وبأيّ فرضيّة

يلزم أيضاً فرضيّة القارئ لا الكاتب وحده.

• هل المحرّر يكشف تلقائيّاً؟
• هل PowerShell ينظر إلى BOM؟
• هل جانب Linux يعامل UTF-8 وفق locale؟
• هل المكتبة تستخدم encoding افتراضيّاً؟
• هل حُدِّد صراحة Encoding.UTF8 أو cp932؟

تشوّه النصّ يحدث هنا تقريباً.

5.4 هل حُفظ المحتوى المقروء خطأ بالفعل

أخيراً تأكّد هل الضرر توقّف عند العرض.

• هل البايتات ما زالت كما هي؟
• هل حفظ أحد المحتوى الظاهر تالفاً؟
• هل دخل ? أو � في الفرق؟
• هل أُعيدت كتابة النصّ كاملاً بترميز آخر؟

إذا امتلأت هذه الأربعة يظهر السبب في الغالب.

flowchart TB
    accTitle: أربعة أسئلة لتحقيق تشوّه النصّ
    accDescr: مخطّط يبيّن أن ملء أربعة أسئلة بالترتيب، ما البايتات الأصليّة، ومن كتب أوّلاً وبأيّ فرضيّة، ومن يقرأ الآن وبأيّ فرضيّة، وهل حُفظ المحتوى المقروء خطأ، يُظهر في الغالب سبب تشوّه النصّ.
    q1["س1: ما البايتات الأصليّة"] --> q2["س2: من كتب أوّلاً وبأيّ فرضيّة"]
    q2 --> q3["س3: من يقرأ الآن وبأيّ فرضيّة"]
    q3 --> q4["س4: هل حُفظ المحتوى المقروء خطأ"]
    q4 --> r1["يظهر السبب"]

الشكل 14: إذا ضللت في التحقيق، أسرع طريق هو العودة إلى هذه الأربعة وملؤها بالترتيب.

6. كيف تُصلَح الملفّات المكسورة

إذا ظهر السبب فالخطوة التالية الاستعادة. أوّل قرار هنا هو هل ما زالت البايتات الأصليّة موجودة.

• البايتات الأصليّة موجودة: أعد القراءة بالـ encoding الصحيح واكتب بالـ encoding المطلوب. هذا إجراء هذا الفصل
• نتيجة القراءة الخاطئة حُفظت بالفعل: لا يبقى إلا الرجوع من نسخة احتياطيّة أو تاريخ Git. الحروف التي صارت حرف استبدال � أو ? لا تُستعاد حتى بمعرفة الـ encoding الصحيح

لذلك أوّل ما ينبغي فعله هو أخذ نسخة من هدف العمل. نفّذ التحويل على النسخة ولا تلمس الملفّ الأصلي.

flowchart TB
    accTitle: أوّل تفرع في الاستعادة
    accDescr: مخطّط يبيّن أن الاستعادة تبدأ بالتأكّد من بقاء البايتات الأصليّة، فإن بقيت أُعيدت القراءة والكتابة بالـ encoding الصحيح، وإن حُفظت نتيجة القراءة الخاطئة فلا يبقى إلا الرجوع من نسخة احتياطيّة أو تاريخ Git، وأن العمل يتمّ على نسخة.
    s1["خذ نسخة أوّلاً"] --> j1{"هل بقيت البايتات الأصليّة"}
    j1 -->|"بقيت"| r1["أعد القراءة والكتابة بالـ encoding الصحيح"]
    j1 -->|"ضاعت بالحفظ"| r2["ارجع من نسخة احتياطيّة أو تاريخ Git"]
    r2 -.-> n1["الحروف التي صارت حرف استبدال لا تُستعاد"]

الشكل 15: الاستعادة بعد أخذ نسخة، ثم ينقسم الطريق حسب بقاء البايتات الأصليّة.

6.1 إن كنت في جانب Linux فاستخدم iconv

لجعل ملفّ CP932 UTF-8، iconv هو الأوضح.

# CP932 -> UTF-8
iconv -f CP932 -t UTF-8 input.csv > output.csv

إن أخطأت encoding المصدر يتوقّف في الوسط كالتالي.

iconv: illegal input sequence at position 0

التوقّف نفسه معلومة أنّه «ليس ذلك الـ encoding»، لذا أسرع تجربة المرشّحين بتغييرهم. إن لم يتوقّف مهما مرّرت، فقد يكون الملفّ ASCII فقط.

لإسقاط UTF-16LE إلى UTF-8 استخدم -f UTF-16LE. لكن تحويل ملفّ مع BOM مع التصريح بـ -f UTF-16LE قد يُبقي BOM كحرف U+FEFF في المخرج. إن أردت ترك التعامل مع BOM لـ iconv استخدم -f UTF-16، وتأكّد دائماً من الحرف الأوّل بعد التحويل.

6.2 إن كنت في جانب Windows فاستخدم PowerShell

من PowerShell 6.2 فما فوق يمكن تمرير رقم code page مباشرة إلى -Encoding. CP932 هو 932.

# PowerShell 6.2 以降。CP932 -> UTF-8 no BOM
Get-Content -Path .\input.csv -Encoding 932 |
    Set-Content -Path .\output.csv -Encoding utf8NoBOM

والعكس، لتمرير ملفّ UTF-8 صُنع في Linux إلى طرف لا يقرأ إلا CP932:

Get-Content -Path .\input.csv -Encoding utf8 |
    Set-Content -Path .\output.csv -Encoding 932

لكن لهذه الكتابة أثرين جانبيّين.

1. Get-Content يقسم إلى أسطر، وSet-Content يعيد إرفاق سطر جديد بعد كل سطر. أي أن رمز السطر الجديد يُوحَّد
2. حتى إن لم يكن في نهاية الملفّ الأصلي سطر جديد، يُرفَق في المخرج

للحفاظ على البايتات بما فيها السطر الجديد، عالج الكلّ دون تقسيم إلى أسطر.

# 改行をそのまま保ったまま CP932 -> UTF-8 no BOM
$text = [System.IO.File]::ReadAllText(
    "C:\work\input.csv", [System.Text.Encoding]::GetEncoding(932))
[System.IO.File]::WriteAllText(
    "C:\work\output.csv", $text,
    (New-Object -TypeName System.Text.UTF8Encoding -ArgumentList $false))

GetEncoding(932) يُستخدم كما هو في Windows PowerShell 5.1. إن رمى استثناء في PowerShell 7 في تلك البيئة، نفّذ التالي مرّة ثم استخدمه.

[System.Text.Encoding]::RegisterProvider(
    [System.Text.CodePagesEncodingProvider]::Instance)

إرفاق BOM أو لا يُقرَّر حسب الطرف الآخر كما في 7.1. في المثال أعلاه جعل وسيط UTF8Encoding مساوياً $true يرفق BOM.

6.3 ما يجب النظر إليه حتماً بعد التحويل

التحويل لا ينتهي عند «لم يظهر خطأ». انظر على الأقل التالي.

• هل تُقرأ سطران أو ثلاثة يابانيّة نموذجيّة قراءة صحيحة
• هل ازداد ? أو �. إن ازدادا فذلك الحرف ضاع
• هل تغيّر عدد الأسطر
• هل BOM ورمز السطر الجديد يطابقان فرضيّة الطرف المستلم
• هل تغيّر حجم الملفّ تغيّراً متطرّفاً. التحويل من CP932 إلى UTF-8 يزيد الجزء الياباني من 2 بايت إلى 3، فزيادة طفيفة طبيعيّة

الثاني مهم خصوصاً. إسقاط UTF-8 يتضمّن حروفاً غير موجودة في CP932 إلى CP932 يُسقط معلومات حتماً. كما في 2.2، تأكّد حتى من العودة بعد الذهاب والإياب.

flowchart TB
    accTitle: ما يجب النظر إليه حتماً بعد التحويل
    accDescr: مخطّط يبيّن أن التحويل لا ينتهي عند غياب الخطأ، بل يُؤكَّد أن أسطراً يابانيّة نموذجيّة تُقرأ، وأن ? أو حرف الاستبدال لم يزددا، وأن عدد الأسطر وBOM والسطر الجديد وحجم الملفّ كما هو متوقّع، وأن ازدياد حرف الاستبدال يعني ضياع ذلك الحرف.
    c1["ينتهي التحويل بلا خطأ"] --> c2["اقرأ سطرين أو ثلاثة يابانيّة نموذجيّة"]
    c2 --> c3["هل ازداد ? أو حرف الاستبدال"]
    c3 --> c4["أكّد عدد الأسطر وBOM والسطر الجديد والحجم"]
    c3 -.-> n1["إن ازدادا فذلك الحرف ضاع"]

الشكل 16: التحويل لا ينتهي عند «لم يظهر خطأ»؛ تأكيد المحتوى جزء من المجموعة.

6.4 اقطع التحويل بالجملة كمهمّة ترحيل

أخيراً حديث التشغيل. إصلاح ملفّ واحد مكسور وتقريب المستودع كلّه من CP932 إلى UTF-8 عملان مختلفان. الثاني، كما في 7.2 من الفصل التالي، لا يُفعَل في أثناء إصلاح وظيفة يومي؛ خطّطه كمهمّة ترحيل مستقلّة.

7. قواعد تشغيل تقلّل الحوادث

من هنا حديث أقرب إلى الممارسة. في القضايا التي تعبر Windows وLinux، تقرير القواعد التالية أوّلاً يقلّل الحوادث كثيراً.

7.1 اجعل UTF-8 الخيار الأوّل للملفّات الجديدة

للملفّات النصّيّة الجديدة، جعل UTF-8 الخيار الأوّل معقول. لكن لا تتوقّف هنا. يلزم تقرير التعامل مع BOM أيضاً.

طريقة تقرير موصى بها:

• نصّ يُقرأ كثيراً من جانب Linux: اجعل الأساس UTF-8 بدون BOM
• سكربت تقرأه أداة قديمة على Windows أو Windows PowerShell 5.1: صرّح بوجود BOM أو غيابه حسب الطرف الآخر
• إن وُجد طرف واضح يحتاج UTF-16LE، اكتب ذلك المتطلّب كمواصفة

كتابة «توحيد UTF-8» وحدها تُشعل نزاع BOM لاحقاً.

flowchart TB
    accTitle: طريقة تقرير encoding للملفّ الجديد
    accDescr: مخطّط يبيّن أن الملفّ النصّي الجديد يُجعَل UTF-8 خياره الأوّل دون التوقّف هناك: إن كثر القراءة من Linux فالأساس UTF-8 بدون BOM، وإن قرأته أداة قديمة أو Windows PowerShell 5.1 يُصرَّح بوجود BOM حسب الطرف، وإن وُجد طرف يحتاج UTF-16LE يُكتَب المتطلّب كمواصفة.
    s1["ملفّ نصّي جديد"] --> s2["اجعل UTF-8 الخيار الأوّل"]
    s2 --> j1{"من يقرأ"}
    j1 -->|"جانب Linux أكثر"| r1["الأساس UTF-8 بدون BOM"]
    j1 -->|"5.1 أو أداة قديمة"| r2["صرّح بوجود BOM حسب الطرف"]
    j1 -->|"طرف يحتاج UTF-16LE"| r3["اكتب المتطلّب كمواصفة"]

الشكل 17: للملفّ الجديد اجعل UTF-8 الخيار الأوّل، ثم احسم التعامل مع BOM حسب الطرف.

7.2 أبقِ ملفّات legacy القائمة حتى مهمّة ترحيل صريحة

إن كان الملفّ القائم CP932، أأمن ألّا يُحوَّل إلى UTF-8 من تلقاء نفسه في أثناء إصلاح وظيفة يومي.

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

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

كثير من حوادث تشوّه النصّ يبدأ من «تحويل إلى UTF-8 في أثناء ذلك» بحسن نيّة.

7.3 عامل encoding كجزء من الواجهة

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

مثلاً، نريد كتابة التالي على الأقل كمواصفة.

• هل هذا الملفّ UTF-8 أم CP932 أم UTF-16LE
• في حالة UTF-8 هل يُرفَق BOM
• هل السطر الجديد LF أم CRLF
• أيّ من Linux / Windows هو المنتج / المستهلك
• هل دفعة أو ETL في الطريق يعيد الحفظ

«نمرّر كنصّ» ليست مواصفة.

7.4 لا تثق بالقيمة الافتراضيّة؛ صرّح عند الكتابة

في الشيفرة كما في السكربت، التصريح بـ encoding أأمن.

الخطر في تفكير من هذا النوع:

• الحفظ بالافتراضي
• سيصير مناسباً على الأرجح حسب نظام التشغيل
• ظهر في وحدة التحكّم إذن الملفّ سليم
• هناك كشف تلقائي إذن لا بأس

القيمة الافتراضيّة تتغيّر عادة بين Windows / Linux، وPowerShell 5.1 / 7، والمحرّر، ووقت التشغيل. ما لم تصرّح، يسهل أن يكون العمل صدفة.

7.5 افصل تأكيد وحدة التحكّم عن تأكيد الملفّ

قاعدة تؤثّر بهدوء وبقوّة.

• تأكيد العرض في وحدة التحكّم
• تأكيد إعادة فتح الملفّ

افصل هذين.

حتى إن طابق chcp أو عرض الطرفيّة، فلا معنى إن كان الملفّ المحفوظ بترميز آخر. والعكس: حتى إن كان الملفّ سليماً، ينكسر المظهر وحده إن لم يطابق code page عرض وحدة التحكّم.

7.6 Git لا يصلح encoding

هادئ لكن مهم.

Git أساساً يتتبّع البايتات فقط. أي أن البايتات التالفة أيضاً تُدخَل في التاريخ بجدّيّة كما هي.

لذلك عندما:

• يظهر فرق ضخم دون أن تغيّر شيئاً
• يصير فرق غامض في الأسطر اليابانيّة فقط
• يتغيّر السطر الأوّل فقط
• يتغيّر السطر الجديد وencoding معاً

أولى أن تشكّ في حادث إعادة ترميز قبل تغيير المحتوى.

flowchart TB
    accTitle: Git لا يصلح encoding
    accDescr: مخطّط يبيّن أن Git يتتبّع البايتات أساساً فقط فتدخل البايتات التالفة في التاريخ كما هي، لذا عند ظهور فرق ضخم دون تغيير أو فرق غامض في الأسطر اليابانيّة فقط ينبغي الشكّ في حادث إعادة ترميز قبل تغيير المحتوى.
    g1["Git يتتبّع البايتات فقط"] --> g2["البايتات التالفة تدخل التاريخ كما هي"]
    g2 --> g3["فرق ضخم أو فرق غامض في الأسطر اليابانيّة فقط"]
    g3 --> g4["اشكّ في حادث إعادة الترميز قبل تغيير المحتوى"]

الشكل 18: Git يسجّل البايتات التالفة أيضاً بجدّيّة، لذا الشكّ أوّلاً في إعادة الترميز عند الفرق الغامض.

8. قائمة التحقّق الدنيا

نضع قائمة التحقّق التي نريد تثبيتها أوّلاً في القضايا التي يختلط فيها Windows وLinux.

flowchart TB
    accTitle: تدفّق قائمة التحقّق
    accDescr: مخطّط يبيّن تدفّق تأكيد encoding وBOM والسطر الجديد الحالي قبل التحرير، وتجنّب الاتّكال على الافتراضي والكشف التلقائي أثناءه، وتأكيد إعادة الفتح والفرق بعده، مع التعامل مع التحويل بالجملة كمهمّة ترحيل منفصلة.
    c1["قبل التحرير: أكّد encoding وBOM والسطر الجديد الحالي"] --> c2["أثناء التحرير: تجنّب الاتّكال على الافتراضي والكشف التلقائي"]
    c2 --> c3["بعد التحرير: أكّد إعادة الفتح والفرق"]
    c3 -.-> t1["التحويل بالجملة يُفصَل كمهمّة ترحيل"]

الشكل 19: التحقّق يُقسَم إلى قبل التحرير وأثناءه وبعده، والتحويل بالجملة يُقطَع كمهمّة منفصلة.

8.1 قبل التحرير

• ما encoding هذا الملفّ الآن
• هل يوجد BOM
• هل السطر الجديد LF أم CRLF
• هل سجّلت سطرين أو ثلاثة يابانيّة نموذجيّة
• هل عرفت أيّ من جانب Linux / Windows هو المستهلك النهائي

8.2 أثناء التحرير

• هل تكتب معتمداً على encoding الافتراضي
• هل تحفظ متّكلاً على الكشف التلقائي
• هل تستخدم مسار PowerShell أو إعادة توجيه الصدفة على عجل
• هل تطمئن لمجرّد أن العرض مقروء

8.3 بعد التحرير

• هل أكّدت بإعادة الفتح بعد الحفظ
• هل الأسطر النموذجيّة لم تنهار في جانب Linux وفي جانب Windows
• هل ازداد ? أو � في الفرق
• هل انكسر السطر الأوّل أو العمود الأوّل فقط
• هل صار الفرق الضخم BOM / السطر الجديد فقط

8.4 ما ينبغي فعله كمهمّة ترحيل

• تحويل جملة من CP932 إلى UTF-8
• توحيد سياسة BOM لـ UTF-8
• جرد السكربتات بافتراض PowerShell 5.1
• تدوين تمرير النصّ عبر CI / حاوية / WSL / SSH
• توحيد إعدادات الحفظ في المحرّر / المنسّق / الدفعة

9. الخلاصة

إن لخّصنا مشكلة ترميز Windows بجملة، فالجوهر أن عالم Unicode وعالم code page القديم ما زالا يتعايشان.

وتزداد الحوادث عند الجمع مع Linux لأن جانب Linux يجري غالباً بفرضيّة UTF-8، فتظهر دفعة واحدة CP932 وUTF-16 وcode page لوحدة التحكّم وفروق إصدارات PowerShell في جانب Windows.

النقاط الخمس التي ينبغي تذكّرها:

• تشوّه النصّ انحراف في تفسير البايتات
• انهيار العرض وتلف البيانات مختلفان
• على Windows فكّر بفصل طبقات الملفّ / المحرّر / وحدة التحكّم / API
• اجعل UTF-8 الخيار الأوّل للنصّ المتبادَل مع Linux
• افصل تحويل ملفّات legacy القائمة عن الإصلاح العادي

معاملة «تشوّه النصّ على Windows» كما هي توسّع الحديث أكثر من اللازم. لكن القطع بأربعة أسئلة:

• ما البايتات الأصليّة
• من كتب وكيف
• من قرأ وكيف
• هل حُفظ بالفعل

يرتب المسألة كثيراً.

الترميز هادئ، لكن بين Windows وLinux هو عقد الإدخال/الإخراج نفسه. أوّل إجراء ينفع هو ألّا تُترَك هذه النقطة غامضة.

روابط مرجعية

Windows / Microsoft

• Code Pages - Win32 apps | Microsoft Learn
• Code Page Identifiers - Win32 apps | Microsoft Learn
• Unicode in the Windows API - Win32 apps | Microsoft Learn
• Console Code Pages - Windows Console | Microsoft Learn
• chcp | Microsoft Learn
• Use UTF-8 code pages in Windows apps | Microsoft Learn

PowerShell / VS Code

• about_Character_Encoding | Microsoft Learn
• Understanding file encoding in VS Code and PowerShell | Microsoft Learn

GNU / Linux locale

• GNU gettext manual: Header Entry
• Debian Reference, Chapter 8. I18N and L10N

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

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

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

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

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

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

ما سبب تشوّه النصّ على Windows؟

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

هل يمكن إعادة ملفّ تشوّه نصّه إلى أصله؟

إذا لم تتغيّر البايتات الأصليّة، قد يكفي إعادة فتحه بالـ encoding الصحيح. الخطر هو حفظ المحتوى الظاهر بعد القراءة الخاطئة كما هو؛ عندئذ لا يبقى الأمر عرضاً منهاراً بل تلفاً للبيانات. كذلك إذا أُسقطت سلسلة Unicode إلى code page ضيّق مثل CP932 فتحوّلت إلى `?` أو حرف استبدال، فإن الحروف الضائعة لا تُستعاد حتى بعد معرفة الـ encoding الصحيح.

هل يجعل chcp 65001 الملفّات UTF-8 أيضاً؟

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

ما القاعدة الآمنة لتبادل النصّ بين Windows وLinux؟

اجعل UTF-8 الخيار الأوّل للملفّات الجديدة، وقرّر أيضاً التعامل مع BOM. للنصّ الذي يُقرأ كثيراً من جانب Linux اجعل الأساس UTF-8 بدون BOM، ولأدوات legacy مثل Windows PowerShell 5.1 صرّح بوجود BOM أو غيابه حسب الطرف الآخر. لا تحوّل ملفّات CP932 القائمة في أثناء إصلاح يومي؛ افصل ذلك كمهمّة ترحيل صريحة. CSV والسجلّات encoding نفسه فيها جزء من الواجهة، لذا اكتب encoding وBOM ورمز السطر الجديد كمواصفات.

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

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

غو كومورا

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

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