عندما لا تفهم البرمجيات اللغة العربية

const text = “سَلَام”;
console.log(text.length); // 6
الكلمة أمامنا تتكون من أربعة حروف: سين ولام وألف وميم. ومع ذلك، يعطي JavaScript النتيجة 6.
السبب هو الفتحتان فوق السين واللام.
في هذا المثال، لا يحسب البرنامج ما نراه حروفًا فقط. إنه يحسب وحدات تخزين النص، وتدخل علامات التشكيل في هذا الحساب.
قد يبدو الأمر تفصيلًا صغيرًا، لكنه يصبح مهمًا إذا كنت تصمم موقعًا يحدد عدد الأحرف المسموح بها، أو محرر نصوص يتعامل مع المؤشر والحذف، أو تطبيقًا تعليميًا يعرض كلمات عربية مشكولة.
أين جاءت الستة؟
تستخدم JavaScript نظام UTF-16 لتمثيل النصوص. وتعطي الخاصية length عدد وحدات UTF-16، لا عدد الحروف كما يراها الإنسان.

كيف يحسب البرنامج الحروف؟

في المثال السابق لدينا:
– س
– َ
– ل
– َ
– ا
– م
ستة عناصر في التمثيل المستخدم، لكن القارئ يرى أربعة حروف وعلامتي تشكيل مرتبطتين بحرفين منها.
لا يحدث هذا في العربية وحدها. توجد لغات أخرى تستخدم علامات مركبة، وقد يتكون الرمز الظاهر من أكثر من عنصر في ترميز Unicode. والرموز التعبيرية قد تكون أعقد من ذلك.
لكن العربية تقدم مثالًا واضحًا لأن التشكيل جزء مألوف من النص، خصوصًا في الكتب التعليمية والمصاحف.
المشكلة ليست أن JavaScript لا يستطيع قراءة العربية. إنه يستطيع تخزينها وعرضها والتعامل معها. المشكلة أننا قد نطرح على البرنامج سؤالًا غير دقيق، ثم نستغرب إجابته.
عندما نسأل عن length، فنحن لا نسأله بالضرورة: «كم حرفًا يراه القارئ؟».
نسأله عن طول السلسلة بوحدات UTF-16.
حل مختلف لسؤال مختلف
تتيح JavaScript أداة اسمها Intl.Segmenter. يمكن استخدامها لتقسيم النص بحسب ما يسمى العناقيد الكتابية أو Grapheme Clusters، وهي وحدات تقترب مما يتعامل معه المستخدم بوصفه رمزًا واحدًا.
جرب هذا:
const text = “سَلَام”;

const segmenter = new Intl.Segmenter(“ar”, {
granularity: “grapheme”
});

const characters = […segmenter.segment(text)];

console.log(text.length); // 6
console.log(characters.length); // 4
في التجربة، أعطى السطر الأخير النتيجة 4.
فالفتحة تبقى مرتبطة بالحرف الذي تظهر فوقه بدل أن تُحسب حرفًا مرئيًا مستقلًا.
ومن اللافت أن تغيير الطريقة لم يغيّر النص نفسه. لم نحذف التشكيل، ولم نستبدل الحروف العربية بحروف إنجليزية، ولم نطلب من المستخدم كتابة شيء آخر.
كل ما تغير هو تعريف الوحدة التي نريد عدّها.
هذا الحل مناسب هنا لعدّ الوحدات التي يتعامل معها المستخدم باعتبارها رموزًا ظاهرة، لكنه ليس حلًا عامًا لكل مسائل اللغة العربية. فهو لا يحدد بالضرورة عدد الحروف الهجائية الأساسية في أي نص معقد، ولا يعرف معنى الكلمة أو طريقة نطقها.
كما أنه لا يحل مشكلة عدّ الكلمات العربية، التي تحتاج إلى طريقة مختلفة لتحديد حدود الكلمات.
لماذا يهم الفرق؟

متى يصبح الاختلاف مشكلة؟

تخيل أن موقعًا تعليميًا يطلب من الطالب كتابة إجابة قصيرة لا تتجاوز 50 حرفًا.
إذا كان الموقع يستخدم text.length بوصفه عدد الحروف المرئية، فقد تستهلك علامات التشكيل جزءًا من الحد المسموح به.
يمكن لطالب كتابة كلمة دون تشكيل، وكتابة الكلمة نفسها مشكولة، ثم الحصول على عدد مختلف رغم أن عدد الحروف الأساسية لم يتغير.
وقد تكون هذه مشكلة في واجهة الاستخدام إذا كان المقصود فعلًا تحديد عدد الرموز التي يراها المستخدم.
لكن إذا كان الهدف قياس حجم البيانات أو تطبيق قيد تقني يتعلق بالتخزين، فقد يكون حساب وحدات التمثيل مطلوبًا لأسباب أخرى.
لهذا لا ينبغي أن نستبدل length بـIntl.Segmenter في كل برنامج دون فهم ما نريد قياسه.
الأمر يعتمد على السؤال الذي نحاول الإجابة عنه.
ليست المشكلة في العربية وحدها
هناك طريقة سهلة للوقوع في خطأ برمجي: تجربة البرنامج على أمثلة بسيطة، ثم افتراض أنه سيعطي النتيجة نفسها مع كل اللغات.
قد يعمل عدّ الأحرف كما نتوقع مع كلمة إنجليزية عادية بلا علامات خاصة. وعندما ننتقل إلى نص عربي مشكول، تظهر فجأة الفروق بين الرمز المخزّن والحرف الذي نراه.
لهذا يستحق اختبار البرمجيات نصوصًا من لغات مختلفة، بما فيها النصوص التي تحتوي على تشكيل وعلامات ورموز غير مألوفة للمبرمج.
ولا نحتاج إلى بناء تطبيق كبير لرؤية المشكلة. يكفي فتح وحدة تحكم JavaScript وتشغيل المثالين.
النتيجتان صحيحتان بالنسبة إلى ما تقيسه كل طريقة: الأولى تعد وحدات UTF-16، والثانية تعد العناقيد الكتابية.
الخطأ الحقيقي يحدث عندما نستخدم إحدى النتيجتين للإجابة عن سؤال كانت الطريقة الأخرى أقرب إليه.