عدد الكلمات: ~٢٦٠٠ · مدة القراءة: ١٤ دقيقة

عزل النصوص وحلول بيدي: المعالجة الجذرية للنصوص الهجينة

من التشخيص إلى العلاج البرمجي: كيف نستخدم ترسانة الـ HTML5 ومتحكمات اليونيكود غير المرئية لفرض جدران الحماية البصرية وحماية الرموز من الانكسار.

تمهيد: من تشخيص الأزمة إلى هندسة العلاج (ما وراء محركات الرندرة)

في المقالين السابقين من هذه السلسلة على منصة ذي يزن، شرحنَا المنظومة الرقمية للنصوص؛ بدءًا بـ معيار اليونيكود الذي يمنح الحروف هويتها الرقمية الخفية، ثم خوارزمية ثنائية الاتجاه (BiDi) التي تتحكم في ترتيب الحروف والكلمات خلف الكواليس. ورأينا كيف يؤدي غياب تحديد اتجاه الفقرة الأساسي إلى كوارث بصرية تُخلّط علامات الترقيم وتكسر اتساق الأسطر.

لكن المشهد لا يكتمل هنا. كل هذه البيانات المنطقية تبقى حبيسة النظام حتى يستدعيها محرك الرندرة (Rendering Engine) — المكون المسؤول عن تحويل الأكواد إلى بكسلات مرئية على الشاشة (التصيير البصري). معرفة سبب المشكلة لا تكفي لبناء منصات مرنة؛ فالمطور لا يستطيع الاكتفاء بإضافة dir="rtl" على العناصر الثابتة، لأن واجهات الويب الحديثة مليئة بالبيانات الديناميكية من مستخدمين متعددين وقواعد بيانات هجينة.

تظهر المشكلة الحقيقية عند إدخال مصطلحات أجنبية أو أسماء مستخدمين أو رموز تقنية (مثل @ و/ والأقواس) داخل جمل عربية خالصة، مما يربك محرك الرندرة ويؤدي إلى تصيير خاطئ. هنا نحتاج إلى هندسة علاجية تعتمد على مبدأين أساسيين: عزل النصوص ثنائية الاتجاه (BiDi Isolation) على مستوى واجهة المستخدم (UI)، وزرع متحكمات اليونيكود غير المرئية على مستوى الباك اند وقواعد البيانات، لإجبار محركات الرندرة على التصيير الصحيح.

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

أولاً: عزل بيدي (BiDi Isolation): مفهوم جدار الحماية البصري

لكي ندرك معنى “العزل” في معالجة النصوص، دعونا نتخيل سياقاً برمجياً شائعاً: منصة تواصل اجتماعي تعرض قائمة بأسماء المستخدمين متبوعة بعدد تعليقاتهم. الترتيب المنطقي للجملة في قالب الـ HTML يكون كالتالي:

إذا كان اسم المستخدم عربياً خالصاً مثل “سامي”، ستعرض الواجهة الجملة بسلاسة من اليمين إلى اليسار. لكن، ماذا لو كان اسم المستخدم ديناميكياً ومكتوباً بالإنجليزية أو يبدأ برقم، مثل “99Alex“؟

في غياب العزل، عندما يقرأ محرك النصوص المتصفح السلسلة، سيتأثر سياق اسم المستخدم بالحواف المحيطة به؛ فالأرقام في بداية الاسم قد تتداخل مع الكلمات العربية السابقة لها، أو قد تقفز علامات الترقيم المجاورة للاسم وتتشابك مع الحروف اللاتينية القوية، مما يسبب انكساراً كاملاً للتدفق البصري للجملة. تسمى هذه الظاهرة بـ “التلوث الاتجاهي المتبادل” (Directional Coloration Spillover).

هنا يأتي دور عزل بيدي (BiDi Isolation). المبدأ البرمجي يعتمد على إخبار متصفح الويب بما يلي: “قم بمعالجة هذه الكتلة النصية الديناميكية داخل صندوق معزول تماماً عن محيطه البصري. احسب اتجاهها الداخلي بشكل مستقل، واحمِ الكلمات الخارجية من التأثر باتجاهها، واحمِ محتواها الداخلي من الانهيار بسبب اتجاه الفقرة العام”. هذا الصندوق المعزول يمنع تسرب القوة الاتجاهية للمحارف، ويضمن بقاء النص الهجين مستقراً مهما كانت طبيعة الحروف المحشورة داخله.

ثانياً: ترسانة الـ HTML5 للعزل البرمجي في الواجهات

قدمت مواصفات لغة الـ HTML5 للمطورين أدوات ثورية للتحكم في هذا العزل دون الحاجة لكتابة أكواد جافا سكريبت معقدة أو استخدام حيل تنسيقية عقيمة. هذه الترسانة تضم وسوماً وسمات متخصصة علينا فهم فروقاتها الجوهرية:

١- وسم العزل التلقائي <bdi> (Bidirectional Isolation)

يعتبر هذا الوسم هو طوق النجاة الأوحد عند التعامل مع بيانات مجهولة الهوية مستدعاة من قاعدة البيانات. عندما تغلف أي نص بوسم <bdi>، فإنك تفرض على المتصفح أمرين تلقائيين:

• تطبيق خاصية العزل ثنائي الاتجاه على النص الداخلي فلا يؤثر على اتجاه الكلمات التي تسبقه أو تلوه في السطر.
• قيام المتصفح تلقائياً بمسح النص الداخلي بناءً على قاعدة “أول محرف قوي” لتحديد اتجاهه داخلياً (سواء كان RTL أو LTR) دون أن يتأثر باتجاه العنصر الأب المحيط به.

مثال تطبيقي: لنفرض أننا نعرض لوحة الصدارة للمستخدمين في موقعنا:

<ul dir="rtl">
  <li>المركز الأول: <bdi>Sami</bdi> - ١٥٠٠ نقطة.</li>
  <li>المركز الثاني: <bdi>ياسين</bdi> - ١٢٠٠ نقطة.</li>
  <li>المركز الثالث: <bdi>2026Developer</bdi> - ٩٠٠ نقطة.</li>
</ul>

بفضل وسم <bdi>، ستعرض المتصفحات الأسماء الثلاثة بشكل مستقر تماماً؛ فاسم “Sami” سيُعزل ويُقرأ كلاتيني، واسم “2026Developer” لن يتسبب رقمه الأولي في قلب ترتيب السطر العربي المحيط به، وستبقى علامات الترقيم والفواصل في مواضعها الصحيحة تماماً.

٢- وسم الفرض الصارم <bdo> (Bidirectional Override)

على النقيض من وسم العزل المسالم، فإن وسم <bdo> هو أداة دكتاتورية صارمة. هو لا يعزل النص ولا يحسب اتجاهه تلقائياً، بل يقوم بـ “إلغاء وفصل خوارزمية بيدي بالكامل” ويجبر المتصفح على عرض الحروف بترتيب فيزيائي قسري تمليه عليه سمة الاتجاه الإجبارية التي يجب أن ترافق هذا الوسم دائماً.

إذا كتبت <bdo dir="ltr">العربية</bdo>، فإن المتصفح سيقوم بقلب الحروف بصرياً لتعرض حرفاً إثر حرف من اليسار لليمين فتظهر هكذا: “ة ي ب ر ع ل ا”. يُستخدم هذا الوسم في حالات نادرة جداً، مثل عرض النصوص المشفرة، أو الأكواد البرمجية العكسية، أو عند الرغبة في فرض عرض تسلسلات رقمية معينة ترفض الخوارزمية القياسية تنسيقها كما يريد التصميم.

٣- الفارق الجوهري بين dir="auto" ووسم <bdi>

يلجأ كثير من المطورين كحيلة سريعة إلى وضع السمة dir="auto" على عناصر مثل الفقرات <p dir="auto"> أو حقول الإدخال <input dir="auto">. هذه السمة ممتازة وتجعل العنصر بأكمله يقلب اتجاهه (يمين أو يسار) بناءً على أول حرف قوي يتم إدخاله.

لكن الفارق الجوهري يكمن في مساحة التأثير؛ فالسمة dir="auto" تقوم بتبديل اتجاه العنصر بالكامل ككتلة (Block Level)، وتغير محاذاة النص وإحداثيات الواجهة قفزاً بين اليمين واليسار.

بالمقابل، يعمل وسم <bdi> على مستوى السطر المضمن (Inline Level)؛ فهو لا يحرك الفقرة من مكانها ولا يقلب الواجهة، بل يصنع غلافاً غير مرئي يحمي تتابع الكلمات داخلياً ويمنع الرموز من إفساد السطر.

القاعدة الذهبية إذن: استخدم dir="auto" للحقول والفقرات الديناميكية الكاملة، واستخدم <bdi> للكلمات والأسماء المتداخلة وسط السطور الثابتة.

ثالثاً: متحكمات اليونيكود غير المرئية: حسم معارك الأقواس والرموز الخاصة

في كثير من الأحيان، تظهر مشكلة انكسار الخطوط الهجينة خارج نطاق متصفحات الويب؛ فقد تظهر المشكلة داخل العناوين المرسلة في رسائل البريد الإلكتروني، أو في التنبيهات الفورية للهواتف، أو في ملفات النص البسيط (Plain Text) حيث لا يوجد وسم <bdi> لإنقاذنا. هنا، يتوجب علينا تفعيل السلاح السري لمعيار يونيكود: متحكمات الاتجاه غير المرئية.

هذه المحارف هي قيم رقمية (Code Points) حقيقية تُخزن في ذاكرة الحاسوب وتنتقل مع النص، لكنها لا تمتلك أي رسم بصري (Glyph)؛ أي أنها تختفي تماماً أمام عين القارئ، لكن مفعولها البرمجي أشبه بمغناطيس يفرض قوته الاتجاهية على الخوارزمية لحسم خيارات المحارف المحايدة كالأقواس والرموز مثل (@, /).

١. علامات التحكم التقليدية (LRM & RLM)

• علامة اليسار إلى اليمين LRM (Left-to-Right Mark): تحمل القيمة الرقمية U+200E وفي كود الويب تُكتب ‎. تتصرف هذه العلامة المخفية كأنها حرف لاتيني قوي أصيل.
• علامة اليمين إلى اليسار RLM (Right-to-Left Mark): تحمل القيمة الرقمية U+200F وفي كود الويب تُكتب ‏. تتصرف كأنها حرف عربي قوي أصيل.

كيف تحل كابوس قلب الأقواس والرموز البرمجية؟
لنأخذ مثالاً شهيراً ينكسر في آلاف المواقع: كتابة مسار مجلد برمجى أو رابط موقع يحتوي على الخط المائل (/) وسط سياق عربي. إذا كتبنا الجملة التالية منطقياً في الذاكرة:

بما أن السلسلة محكومة باتجاه عربي عام، والخط المائل (/) محرف محايد يقع بين كلمتين لاتينيتين (config و settings)، فإن الخوارزمية قد ترتبك وتعتبر الخط المائل فاصلاً يتبع التدفق العربي الكلي، فتقوم بقلب الترتيب البصري ليظهر المجلد الفرعي قبل المجلد الأب، وتتحول العبارة إلى settings/config بصرياً، مما يدمر المسار التقني ويضلل المطور.

العلاج البرمجي بـ LRM: لحل هذه المعضلة، نقوم بحقن علامة ‎ مباشرة قبل وبعد الرموز الخاصة أو الأقواس المحصورة لتأكيد السياق اللاتيني. عند زرع هذه العلامة غير المرئية، يرى محرك بيدي أن الرمز المحايد محاط من الجهتين بمحارف قوية يسارية (الحرف اللاتيني الحقيقي وعلامة الLRM المخفية)، فيستقر الرمز في مكانه الصحيح دون انقلاب. وينطبق الأمر تماماً على علامة البريد الإلكتروني @ عندما تتداخل مع أسماء مستخدمين عربية وأجنبية؛ حيث إن زرع ‏ أو ‎ بناءً على اتجاه المعرف يضمن عدم قفز العلامة من اليمين إلى اليسار بشكل عشوائي.

٢. الفاصل غير المتصل ZWNJ (Zero-Width Non-Joiner)

يحمل هذا المحرف الفريد القيمة الرقمية U+200C، ويُعرف في كود الويب بـ ‌. وظيفته الأساسية في أنثروبولوجيا الخطوط الرقمية هي كسر الاتصال البصري الإجباري بين الحروف المتصلة (مثل الحروف العربية أو الفارسية) دون إحداث مسافة أفقية فاصلة.

لكن في سياق النصوص الهجينة، يمتلك ZWNJ قوة مزدوجة خطيرة؛ فهو يعمل كـ “مصدّ بنيوي” يمنع تداخل السياقات البصرية للأقواس والرموز الخاصة المحايدة. عندما تضع ZWNJ بين نهاية كلمة عربية وبداية قوس يحتوي على مصطلح إنجليزي، فإنك تمنع محرك صيرورة النصوص من محاولة دمج أو معالجة الحرف الأخير مع القوس بصرياً، مما يحمي القوس من الانقلاب ويحافظ على شكله المعنوي ثابتاً في مكانه، خاصة عند التعامل مع نصوص مشكلة أو خطوط مخصصة تعاني من مشاكل في تصفية الحسابات الهندسية للحواف.

٣. الانتقال الشامل: عزل النصوص على مستوى الـ Backend باستخدام (FSI & PDI)

حتى الآن، كل الحلول الجراحية السابقة (مثل LRM و ZWNJ) كانت تُعالج حالاتٍ موضعيةٍ محددةٍ في واجهة المستخدم. لكن عندما تتطور الأنظمة وننتقل لمعالجة البيانات الضخمة والنصوص الديناميكية على مستوى الخادم (Backend) قبل إرسالها للمتصفح، نحتاج إلى ترسانةٍ أقوى وأكثر أوتوماتيكية.

هنا يوفر لنا معيار يونيكود جيلاً أحدث من متحكمات العزل الشامل. هذه المحارف تعمل تماماً مثل وسم <bdi> الذي شرحناه في الواجهات، لكنها تأتي على هيئة محارف نصيةٍ مجردةٍ ومخفية، وأبرزها:

• FSI (First Strong Isolate – U+2068): محرفٌ مخفيٌ يوضع في بداية النص الديناميكي ليجبر النظام على عزله وتخمين اتجاهه داخلياً بشكل مستقل تماماً.
• PDI (Pop Directional Isolate – U+2069): محرف إغلاق العزل المخفي، ويوضع في نهاية النص الديناميكي لإنهاء مفعول العزل وإغلاق الصندوق البصري.

لتطبيق ذلك عملياً دون عناءٍ يدوي، يمكننا الاستعانة بلغات الخادم مثل بايثون (Python)؛ حيث نكتب دالةً برمجيةً بسيطةً تحقن هذه المحارف تلقائياً حول أي متغيرٍ هجينٍ مستدعى من قاعدة البيانات لحمايته وتجهيزه قبل رندرته في قالب الـ HTML النهائي. مثال:

def isolate_hybrid_text(text):
    FSI = "\u2068"
    PDI = "\u2069"
    return f"{FSI}{text}{PDI}"

# النتيجة ستكون نصاً محصناً ومحاطاً بجدار عزل يونيكود غير مرئي

رابعاً- جدول المقارنة التطبيقية: متى نستخدم كل أداة؟

لتسهيل اتخاذ القرار الهندسي أثناء عملية التطوير والتوطين، يوضح الجدول التالي السيناريو الأمثل لاستخدام كل أداة من أدوات حلول بيدي وعزل النصوص التي قمنا بتفكيكها:

خلاصة: العبور إلى هندسة المظهر

بامتلاكنا لمهارات عزل النصوص ثنائي الاتجاه، والقدرة على زرع متحكمات اليونيكود غير المرئية لحماية الأقواس والرموز التقنية من الانكسار، نكون قد أحكمنا القبضة بالكامل على “منطق وعلم” معالجة النصوص الهجينة داخل الذاكرة العشوائية للآلة وداخل شيفرات الـ HTML5 التأسيسية. لقد انتقلنا من مرحلة المعاناة والمحاولات العشوائية لتنسيق الأسطر، إلى مرحلة السيادة والتحكم المطلق المستند لقوانين اليونيكود الصارمة.

ومع ذلك، فإن المعالجة المنطقية للنصوص لا تكتمل إلا إذا رافقتها “مرونة بصرية” على مستوى المظهر والتصميم الخارجي للموقع. فالمطور لا يمكنه العيش في جلباب الحسابات الرياضية فقط، بل يجب عليه تسييل هذه الحلول داخل ملفات التنسيق الشاملة لضمان نمو واجهات المستخدم وثبات أبعاد القوالب دون انحياز.

في المقال القادم (المقال الرابع) من سلسلتنا التعليمية، سنعبر جسراً تقنياً هاماً لنكتشف “الخصائص المنطقية في CSS (CSS Logical Properties)“؛ سنفتح ملفات الستايل لنلغي التفكير التقليدي المنحاز القائم على اليمين واليسار الفيزيائي، ونتعلم كيف نبني واجهات برمجية ثنائية الاتجاه تقلب نفسها وأبعادها وهندسة قوالبها (Flexbox & Grid) ذاتياً وتلقائياً دون كتابة سطر كود واحد مكرر، ودون الحاجة لملفات الـ rtl.css المرهقة تاريخياً.

المراجع والمصادر:

1. توثيق منظمة الويب العالمية حول استخدام وسوم العزل الحديثة: W3C: Inline markup for images and bidirectional text in HTML
2. دليل شبكة مطوري موزيلا الرسمي لوسم العزل التلقائي: MDN Web Docs: The Bidirectional Isolate element (<bdi>)
3. المعيار التقني ليونيكود الخاص بمحارف التحكم بالاتجاهية المتقدمة: Unicode Bidirectional Algorithm: Bidirectional Control Characters

منصة ذي يزن © ٢٠٢٦