عند عرض ملف diff يحتوي نصًا عربيًا في طرفية (terminal) عادية، يمكن أن يبدو الترتيب مربكًا: خوارزمية bidi في Unicode تعيد ترتيب كل سطر عربي بصريًا من اليمين إلى اليسار، بينما تبقى علامتا + و- في أقصى يسار السطر كما هي — فيبدو أن العلامة "تخص" كلمة مختلفة عن التي غيّرت السطر فعليًا.
أطول تتابع مشترك
يعتمد نهج الديف الكلاسيكي على إيجاد أطول تتابع مشترك (LCS) من الأسطر بين نسختي النص. الأسطر التي تكون جزءًا من هذا التتابع تُعتبر غير متغيرة؛ والباقي يُوسَم كمحذوف من النسخة القديمة أو مضاف إلى الجديدة. هذا يمنح أصغر مجموعة تغييرات ممكنة، لا أي تسلسل عشوائي من الحذف والإضافة.
كيف تُقرأ النتيجة
عادة تُوسَم الأسطر المحذوفة برمز - باللون الأحمر، والمضافة برمز + باللون الأخضر. السطر الذي "تغيّر" بالمعنى اليومي يُعرض تقنيًا كحذف للسطر القديم زائد إضافة سطر جديد — فمفهوم "تعديل سطر في مكانه" غير موجود أصلًا في الديف.
لماذا لا تكون المقارنة سطرًا بسطر بديهية دائمًا
إدراج سطر واحد جديد في منتصف نص قد يجعل المقارنة سطرًا بسطر تُظهر كل الأسطر التالية وكأنها "تغيّرت"، لأن الخوارزمية لا تميّز دائمًا الإدراج عن الاستبدال الجماعي. مع النصوص العربية تزداد الحيرة حين يُعرض هذا الإخراج في أداة لا تدعم bidi بشكل صحيح، فيختلط اتجاه القراءة باتجاه رموز الديف نفسها.
لماذا نحتاج هذا
- معرفة ما تغيّر بالضبط بين نسختين من ملف إعداد أو مستند.
- مراجعة الكود بفهم منطق خوارزمية إيجاد الفروقات.
- مقارنة نتائج سكربت قبل وبعد إعادة الهيكلة للتأكد من عدم وجود انحدار.
الديف على مستوى السطر مقابل مستوى الحرف
المقارنة سطرًا بسطر مناسبة للكود وملفات الإعداد، لكن بالنسبة لنص نثري أو جملة طويلة تغيّرت فيها كلمة واحدة فقط، ستُظهر السطر بأكمله كمحذوف ومضاف من جديد. الديف على مستوى الكلمة أو الحرف داخل السطر يُظهر بدقة أكبر الكلمة التي تغيّرت فعليًا — على حساب تعقيد حسابي أعلى في النصوص الكبيرة.