فهم ترميزات النصّ على Windows - لماذا يحدث mojibake وما الذي ينكسر عند دخول Linux إلى المعادلة

لا يحدث mojibake على Windows لأنّ النصّ اليابانيّ صعب بطبيعته. في معظم الحالات، يحدث لأنّ التسلسل البايتيّ نفسه فُكَّ ترميزه باستخدام encoding خاطئ، أو لأنّ النصّ المقروء بشكل خاطئ حُفِظ مرّةً أخرى تحت افتراض ترميز مختلف.

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

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

1. الخلاصة العمليّة

إن أردت النسخة المختصرة أوّلاً، فهذه هي النقاط الرئيسيّة:

• mojibake ليس فعلاً مشكلة محارف. إنّه مشكلة تفسير بايتات.
• لا يزال Windows يخلط بين مسارات Unicode ومسارات code pages القديمة، فتتغيّر الافتراضات بحسب الأداة وواجهة الـ API.
• يميل Linux بقوّة نحو UTF-8، ممّا يجعل مفاجآت CP932 وUTF-16 تظهر بسرعة.
• مشكلة العرض وفساد البيانات الفعليّ بعد إعادة الحفظ ليسا في المرحلة نفسها من الفشل.
• استخدم UTF-8 افتراضيّاً للنصّ الجديد، لكن اترك الملفّات القديمة الموجودة على حالها حتّى تُعالَج عمليّة الترحيل بوصفها مهمّة منفصلة.
• ترميز الملفّ، وencoding المحرّر، وconsole code pages، وتمثيل النصّ في الذاكرة طبقات منفصلة. إن دمجتها معاً، يصبح استكشاف الأخطاء مربكاً بسرعة.

لذلك حين يقول أحدهم «الملفّ ظهر فيه mojibake على Windows»، فإنّ هذا الكلام لا يزال فضفاضاً جدّاً. كحدّ أدنى، عليك التفريق بين:

• الترميز الفعليّ للملفّ
• الترميز المستخدم عند حفظه
• تفسير المحرّر
• console input/output code pages
• صيغة النصّ الداخليّة في التطبيق
• الـ locale والترميز المتوقّع على جانب Linux

2. ما هو mojibake فعلاً

في جوهره، فإنّ mojibake بسيط:

1. النصّ يُرمَّز (encoded) إلى بايتات
2. تلك البايتات تُفكّ (decoded) إلى نصّ من جديد
3. إن اختلفت افتراضات الترميز وفكّ الترميز، تغيّر النصّ الناتج

على سبيل المثال، إن حفظت あ في UTF-8، فإنّ البايتات هي:

E3 81 82

افكّ ترميز تلك البايتات بوصفها UTF-8 فتحصل على あ. افكّ ترميزها تحت افتراض موجَّه لـ CP932، وقد ينتهي بك الأمر إلى شيء مثل 縺�. هذا هو mojibake.

النقطة المهمّة هي أنّ النصّ اليابانيّ لم «ينكسر بشكل غامض». البايتات نفسها فُسِّرت ببساطة وفق قواعد خاطئة.

2.1 إن لم تتغيّر البايتات، قد يظلّ التعافي ممكناً

بعض حالات mojibake لا تزال قابلة للعكس. إن كانت البايتات الأصليّة سليمة، فإنّ إعادة فتح الملفّ بالترميز الصحيح قد تستعيد النصّ.

التسلسل الخطر يبدو هكذا:

1. ملفّ UTF-8 يُقرأ خطأً بوصفه CP932
2. يعرض المحرّر نصّاً مشوّشاً
3. يحفظ أحدهم ما يراه
4. يضيع تسلسل البايتات الأصليّ في UTF-8

عند تلك النقطة، لم يعد هذا مجرّد مشكلة عرض. إنّه فساد بيانات فعليّ.

2.2 الحالة الأسوأ هي إقحام محارف غير مدعومة في code page ضيّق

فشل شائع آخر يحدث حين يُدفَع نصّ Unicode إلى code page قديم مثل CP932.

إن لم يستطع code page الهدف تمثيل بعض المحارف، فقد ترى:

• استبدالاً بـ ?
• محارف استبدال مثل �
• تحويلاً إلى محرف مختلف لكن متشابه ظاهريّاً
• فشلاً صريحاً في التحويل

لهذا فإنّ السؤال الحقيقيّ ليس فقط «هل أستطيع قراءته؟»، بل أيضاً «هل يستطيع هذا النصّ أن يقوم برحلة ذهاب وعودة آمنة عبر الترميز المختار؟». إن فُقدت محارف مرّةً، فإنّ معرفة الترميز الصحيح لاحقاً لن تعيد بناءها.

3. لماذا يصبح Windows معقّداً

ليس Windows معقّداً لمجرّد كونه قديماً. إنّه معقّد لأنّ سلوك حقبة Unicode وسلوك code pages القديمة لا يزالان متعايشين.

3.1 لا تزال Windows APIs تكشف كلاًّ من مسارات Unicode وcode pages

على مستوى عالٍ، لا تزال Windows APIs تأتي في عائلتين عريضتين:

• W APIs: واجهات wide-character، قائمة فعليّاً على UTF-16
• A APIs: واجهات بنمط ANSI تعتمد على code page

هذا يعني أنّ Windows كان لديه دائماً مسار Unicode ومسار code page. حتّى على الجهاز نفسه، يمكن أن تتغيّر الافتراضات تبعاً لأيّ API أو أداة لمست البيانات.

3.2 «اليابانيّة على Windows» ليست قصّة ترميز واحدة

عمليّاً، تميل أربعة سياقات نصّيّة إلى الاختلاط معاً:

• CP932 لأصول النصّ اليابانيّ القديمة على Windows
• UTF-8 لملفّات المصدر الأحدث، وأصول الويب، وسير العمل عبر المنصّات
• UTF-16LE لأجزاء من نظام Windows والأدوات
• console code pages لسلوك الإدخال والإخراج في الطرفيّة

أمر واحد يهمّ كثيراً هنا: تشغيل chcp 65001 لا يعني أبداً أنّ ملفّاتك أصبحت فجأةً UTF-8. تغيير console code page وتحديد البايتات المخزّنة بالفعل في ملفّ مسألتان مختلفتان تماماً.

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

3.3 أسماء الملفّات ومحتواها طبقتان منفصلتان

إن بدت أسماء الملفّات اليابانيّة جيّدة على Windows، فإنّ من المغري افتراض أنّ المحتوى أيضاً جيّد. هذا فخّ.

هذه طبقات منفصلة:

• الطبقة التي تتعامل مع المسارات وأسماء الملفّات
• الطبقة التي تقرأ محتوى الملفّ
• الطبقة التي تعرض النصّ في الـ console

يمكنك التعامل بشكل صحيح مع مسار يابانيّ بينما لا تزال تقرأ متن الملفّ بشكل خاطئ. ويمكنك أيضاً امتلاك ملفّ UTF-8 صحيح تماماً يبدو محتواه مكسوراً فقط لأنّ console output code page خاطئ.

3.4 PowerShell والأدوات المحيطة لا تتشارك في افتراض واحد

مصدر شائع جدّاً للمتاعب هو أنّ مسارات إخراج متعدّدة تبدو كلّها وكأنّها «كتابة نصّ»، لكنّها لا تنتج البايتات نفسها.

أمثلة نموذجيّة:

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

لذلك فإنّ «هذا أُخرِج من PowerShell» لا يخبرك بما يكفي. تحتاج إلى معرفة أيّ إصدار PowerShell، وأيّ cmdlet، وأيّ مسار كتابة أنتج الملفّ.

4. حالات الفشل النموذجيّة بمجرّد دخول Linux

سير عمل يبدو أنّه «يعمل في الغالب» داخل Windows ينكسر غالباً بمجرّد لمس Linux للملفّات نفسها. السبب بسيط: تفترض أدوات Linux عادةً UTF-8.

4.1 Windows يكتب CP932، Linux يقرأ UTF-8

هذا على الأرجح أكثر أنماط الفشل شيوعاً:

• تطبيق Windows قديم يكتب ملفّات CSV أو TXT أو logs بترميز CP932
• يقرأ script أو أداة Linux الملفّ تحت افتراض locale من نوع UTF-8
• النتيجة هي خطأ في فكّ الترميز، أو محارف استبدال، أو نصّ يابانيّ غير قابل للقراءة

ليس بالضرورة أنّ جانب Linux يفعل شيئاً خاطئاً. المشكلة الحقيقيّة هي أنّ الملفّ عبر الحدود بدون عقد ترميز صريح.

4.2 Linux أو VS Code ينشئ UTF-8 بدون BOM، Windows يعامله كأنّه ANSI

الاتّجاه المعاكس يفشل أيضاً:

• script أو ملفّ إعدادات يُنشأ على Linux أو في VS Code بوصفه UTF-8 بدون BOM
• لا يستنتج Windows PowerShell 5.1 أو أداة قديمة أخرى UTF-8 بشكل موثوق
• تنكسر فقط الأسطر اليابانيّة أو غير ASCII الأخرى

هذا لا يعني أنّ UTF-8 سيّئ. يعني أنّ القارئ لا يكتشف بشكل موثوق UTF-8 بدون BOM.

4.3 Windows يكتب UTF-16LE، أدوات Linux ترى «ليس نصّاً حقّاً»

هذا مصدر شائع آخر للارتباك:

• جزء من Windows PowerShell 5.1 أو أداة قديمة يكتب UTF-16LE
• تفترض أدوات النصّ على جانب Linux تدفّق نصّ UTF-8 موجَّه إلى بايت واحد
• يبدو الملفّ شبيهاً بـ binary لأنّه يحتوي على كثير من بايتات NUL

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

4.4 معالجة BOM تخلق احتكاكاً أيضاً

BOM ليس الترميز نفسه، لكنّه لا يزال يغيّر السلوك الفعليّ:

• بعض أدوات جانب Windows تكون أسعد بوجود BOM
• بعض أدوات جانب Unix تعامل BOM بوصفه بايتات إضافيّة في البداية
• ينكسر فقط السطر الأوّل أو العمود الأوّل، أو تؤثّر بقايا غير مرئيّة في المقارنات

مع UTF-8 على وجه الخصوص، فإنّ UTF-8 with BOM وUTF-8 without BOM تسلسلَا بايتات مختلفان. قول «نستخدم UTF-8» لا يكفي لسير عمل موثوق.

4.5 مخرجات الـ console قد تضلّل التحقيق

يصبح مسار الـ console أكثر إرباكاً عبر Windows وLinux وWSL وSSH وحاويّات وCI.

• console الخاصّ بـ Windows لديه input وoutput code pages
• طرفيّات Linux تعمل عادةً تحت UTF-8 locale
• قد تحوّل الطبقات الوسيطة ما تراه قبل أن تفحص الملفّ الفعليّ

لهذا فإنّ «بدا صحيحاً في الـ console» و«الملفّ صحيح» ليستا عبارتَين قابلتَين للتبادل.

4.6 جدول فشل بسيط

5. أربعة أسئلة تجعل التحقيق في mojibake أسرع

حين تكون المشكلة لا تزال ضبابيّة، فإنّ هذه الأسئلة الأربعة تختصر التحقيق عادةً.

5.1 ما البايتات الفعليّة الآن؟

ابدأ بالبايتات، لا بالانطباع البصريّ.

• هل هو UTF-8؟
• UTF-8 with BOM؟
• CP932؟
• UTF-16LE؟
• هل أُعيد حفظه بالفعل في صيغة مختلفة؟

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

حدّد الكاتب الأصليّ:

• تطبيق Windows قديم
• PowerShell 5.1 أو PowerShell 7
• script على Linux
• VS Code
• تصدير مدفوع بـ Excel
• middleware أو batch jobs أو CI

إن ظلّ هذا غامضاً، فإنّ تخمينات الترميز تصبح ضرباً من الحظّ.

5.3 من يقرؤه الآن، وتحت أيّ افتراض؟

القارئ يهمّ بقدر ما يهمّ الكاتب:

• هل يقوم المحرّر بكشف تلقائيّ؟
• هل يبحث PowerShell عن BOM؟
• هل يتبع Linux الـ locale الحاليّ ويفترض UTF-8؟
• هل تستخدم مكتبة افتراضها الخاصّ في الترميز؟
• هل يمرّر الكود صراحةً Encoding.UTF8 أو cp932؟

من هنا يبدأ mojibake عادةً.

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

أخيراً، حدّد ما إذا كان الضرر لا يزال على مستوى العرض فقط أم أنّه أصبح دائماً بالفعل:

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

بمجرّد الإجابة عن تلك الأسئلة الأربعة، يصبح السبب أسهل بكثير في الرؤية.

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

في بيئات Windows وLinux المختلطة الحقيقيّة، فإنّ بضع قواعد تشغيليّة تمنع عدداً مفاجئاً من الحوادث.

6.1 فضّل UTF-8 لملفّات النصّ الجديدة

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

مجموعة قواعد عمليّة هي:

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

إن كانت القاعدة فقط «وحّدوا على UTF-8»، فإنّ نقاش BOM سيعود لاحقاً.

6.2 احفظ الملفّات القديمة الموجودة حتّى يكون الترحيل صريحاً

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

القاعدة الأكثر استقراراً هي:

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

كثير من حوادث الترميز تبدأ بـ «بما أنّني هنا، حوّلتُه إلى UTF-8» بنيّة حسنة.

6.3 تعامل مع الترميز بوصفه جزءاً من الواجهة

بالنسبة إلى ملفّات CP، وlogs، وملفّات الإعدادات، وبروتوكولات النصّ الخفيفة، فإنّ الترميز جزء من عقد الواجهة، لا تفصيل تجميليّ.

كحدّ أدنى، يجب أن يقول التوصيف:

• ما إذا كان الملفّ UTF-8 أو CP932 أو UTF-16LE
• ما إذا كانت ملفّات UTF-8 تشمل BOM
• ما إذا كانت نهايات الأسطر LF أو CRLF
• ما إذا كان Windows أو Linux هو المنتج أو المستهلك
• ما إذا كان أيّ ETL وسيط أو batch process يعيد كتابة الملفّ

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

6.4 لا تثق بالقيم الافتراضيّة عند الكتابة

سواء كنت في كود تطبيق أو في scripts، فإنّ الترميزات الصريحة أكثر أماناً من الافتراضات.

تبدو الافتراضات المحفوفة بالمخاطر هكذا:

• مسار الحفظ الافتراضيّ ينبغي أن يكون جيّداً
• سيختار الـ OS غالباً شيئاً معقولاً
• عرض الـ console كان صحيحاً، إذن الملفّ يجب أن يكون جيّداً
• سيكتشف الكشف التلقائيّ الأمر

تتفاوت الافتراضات عبر Windows وLinux وأنظمة التشغيل وقت التشغيل، والمحرّرات، وإصدارات PowerShell. إن لم تجعل مسار الكتابة صريحاً، فإنّ النجاح غالباً ما يكون عرضيّاً.

6.5 تحقّق من مسار الـ console ومسار الملفّ بشكل منفصل

هذه القاعدة بسيطة لكنّها فعّالة:

• تحقّق ممّا تعرضه الـ console
• أعد فتح الملفّ الفعليّ وتحقّق منه بشكل منفصل

حتّى إن بدا عرض الطرفيّة جيّداً، قد يظلّ الملفّ المحفوظ خاطئاً. وحتّى إن كان العرض مكسوراً، قد يظلّ الملفّ صحيحاً تماماً.

6.6 Git لا يصلح أخطاء الترميز بدلاً عنك

Git يتتبّع البايتات. لا ينقذك من البايتات السيّئة.

لذا إن رأيت أعراضاً مثل:

• diffs ضخمة رغم أنّ التغيير في منطق العمل كان صغيراً
• diffs غريبة تظهر فقط على الأسطر اليابانيّة
• يتغيّر السطر الأوّل فقط
• تحوّلات في الأسطر والترميز تحدث معاً

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

7. قائمة فحص دنيا

في العمل المختلط بين Windows وLinux، هذا نوع قائمة الفحص التي يستحقّ توحيدها مبكراً.

7.1 قبل التحرير

• ما الترميز الحاليّ لهذا الملفّ؟
• هل يوجد BOM؟
• هل نهايات الأسطر LF أو CRLF؟
• هل دوّنا سطرَين أو ثلاثة أسطر يابانيّة تمثيليّة؟
• هل نعرف ما إذا كان Windows أو Linux هو المستهلك النهائيّ؟

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

• هل نتجنّب مسارات الكتابة التي تخفي سلوك الترميز؟
• هل نتجنّب عمليّات الحفظ العمياء القائمة على الكشف التلقائيّ؟
• هل نحذر من إعادة توجيه الـ shell ومن إخراج PowerShell؟
• هل نتذكّر أنّ «يبدو قابلاً للقراءة» ليس الشيء نفسه «مخزّن بشكل صحيح»؟

7.3 بعد التحرير

• هل أعدنا فتح الملفّ المحفوظ؟
• هل لا تزال الأسطر اليابانيّة التمثيليّة تبدو صحيحة على الجانبَين؟
• هل ظهر ? أو � في الـ diff؟
• هل انكسر السطر الأوّل أو العمود الأوّل بشكل غير متوقّع؟
• هل تحوّل هذا إلى diff بنهايات أسطر فقط أو BOM فقط بلا سبب تجاريّ؟

7.4 المهامّ التي تستحقّ مسار ترحيل خاصّاً بها

• التحويل الجماعيّ من CP932 إلى UTF-8
• توحيد سياسة UTF-8 BOM
• مراجعة scripts التي لا تزال تعتمد على سلوك Windows PowerShell 5.1
• توثيق تدفّقات النصّ عبر CI، وحاويّات، وWSL، وSSH
• مواءمة إعدادات الحفظ عبر المحرّرات، وأدوات التنسيق، وأدوات الـ batch

8. الخلاصة

إن اختزلت مشكلة الترميز على Windows في جملة واحدة، فستكون هذه: سلوك حقبة Unicode وسلوك code pages القديمة لا يزالان يعيشان جنباً إلى جنب.

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

الأفكار الخمس التي تستحقّ التذكّر هي:

• mojibake عدم تطابق في تفسير البايتات
• انكسار العرض وفساد البيانات الدائم مرحلتان مختلفتان
• على Windows، يجب التعامل مع محتوى الملفّ، وسلوك المحرّر، وسلوك الـ console، وسلوك الـ API بوصفها طبقات منفصلة
• النصّ المتبادل مع Linux ينبغي أن يبدأ عادةً من عقليّة UTF-8 أوّلاً
• تحويل الملفّات القديمة الموجودة ينبغي فصله عن تحريرات الصيانة العاديّة

إن علقت، فعد إلى أربعة أسئلة:

• ما البايتات؟
• من كتبها؟
• من يقرؤها؟
• هل حُفِظ المحتوى المقروء خطأً بالفعل؟

قد يبدو عمل الترميز تفصيلاً ثانويّاً، لكن بين Windows وLinux فإنّه فعلاً جزء من عقد الـ I/O. جعل ذلك العقد صريحاً يمنع متاعب أكثر بكثير ممّا يمنعه محاولة التخمين الصحيح بعد فوات الأوان.

9. المراجع

Windows / Microsoft

• [Code Pages - Win32 apps

  Microsoft Learn](https://learn.microsoft.com/en-us/windows/win32/intl/code-pages)

• [Code Page Identifiers - Win32 apps

  Microsoft Learn](https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers)

• [Unicode in the Windows API - Win32 apps

  Microsoft Learn](https://learn.microsoft.com/en-us/windows/win32/intl/unicode-in-the-windows-api)

• [Console Code Pages - Windows Console

  Microsoft Learn](https://learn.microsoft.com/en-us/windows/console/console-code-pages)

• [chcp

  Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chcp)

• [Use UTF-8 code pages in Windows apps

  Microsoft Learn](https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page)

PowerShell / VS Code

• [about_Character_Encoding

  Microsoft Learn](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_character_encoding)

• [Understanding file encoding in VS Code and PowerShell

  Microsoft Learn](https://learn.microsoft.com/en-us/powershell/scripting/dev-cross-plat/vscode/understanding-file-encoding)

GNU / Linux locale

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

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

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

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

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

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

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

غو كومورا

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

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