مقدمة

يقوم ملايين الأشخاص يوميًا بالنقر على روابط مختصرة مثل lix.li/a1B2c3 دون التفكير أبدًا فيما يحدث بين لحظة النقر وتحميل الصفحة. في الواقع، يحدث الكثير خلال تلك اللحظة السريعة: يجب على الخادم تحديد الرابط الطويل الصحيح فورًا، إعادة توجيه المتصفح، وتسجيل بيانات النقرة — كل ذلك خلال أجزاء من الثانية. في هذا المقال، سنشرح كيف تعمل مختصرات الروابط من الداخل: ما هي التقنيات التي تعتمد عليها، وكيف يتم توليد الأكواد المختصرة، ومن أين تأتي بيانات التحليلات، ولماذا هذا الأمر أكثر تعقيدًا مما يبدو للوهلة الأولى.

ما هي خدمة اختصار الروابط

خدمة اختصار الروابط هي خدمة تحوّل رابطًا طويلاً (مثل https://example.com/products/category/electronics/smartphones?ref=newsletter&utm_campaign=summer2026) إلى رابط مختصر مثل lix.li/xY7z9Q. عند نقر المستخدم على الرابط المختصر، يتم توجيهه تلقائيًا إلى الرابط الأصلي الطويل. يبدو الأمر بسيطًا، لكن خلفه بنية تحتية كاملة: قاعدة بيانات، خوارزميات لتوليد معرّفات فريدة، نظام لإعادة التوجيه، ومحرك تحليلات.

الآلية الأساسية: إعادة التوجيه عبر HTTP

في قلب كل خدمة اختصار روابط تكمن إعادة التوجيه عبر HTTP — وهي آلية قياسية في بروتوكول الويب تُخبر المتصفح: "المحتوى الذي تبحث عنه موجود في عنوان آخر". عندما ينقر شخص ما على رابط مختصر، يحدث ما يلي:

  1. يرسل المتصفح طلبًا إلى خادم خدمة الاختصار (مثل lix.li/xY7z9Q).
  2. يبحث الخادم في قاعدة البيانات عن الرابط الطويل المقابل للكود xY7z9Q.
  3. يستجيب الخادم برمز حالة HTTP إما 301 أو 302، مع ترويسة Location تشير إلى الرابط الأصلي.
  4. يرسل المتصفح تلقائيًا طلبًا جديدًا إلى الرابط الطويل ويقوم بتحميل الصفحة المقصودة. تتم هذه العملية بأكملها خلال أجزاء من الثانية، ولا يلاحظها المستخدم إطلاقًا.

الفرق بين 301 و302

اختيار رمز إعادة التوجيه قرار تقني مهم يؤثر في سلوك المتصفحات ومحركات البحث:

  • 301 (Moved Permanently) — إعادة توجيه دائمة. تقوم المتصفحات ومحركات البحث بتخزينها مؤقتًا (cache)، وقد تبدأ لاحقًا بطلب العنوان النهائي مباشرة. هذا يقلل قليلًا من الحمل على خادم خدمة الاختصار، لكنه يجعل تتبع النقرات بدقة أصعب، لأن الزيارات المتكررة قد لا تمر عبر الخادم بعد ذلك.
  • 302 (Found / Temporary Redirect) — إعادة توجيه مؤقتة. يجب أن تمر كل نقرة عبر خادم خدمة الاختصار، مما يتيح تتبعًا دقيقًا وكاملًا للنقرات. لهذا السبب تعتمد معظم الخدمات الموجهة نحو التحليلات — بما فيها Lix.li — على 302.

كيف يتم توليد الأكواد المختصرة

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

1. عداد تصاعدي مع ترميز base62

من أكثر الطرق استخدامًا. يُخصَّص لكل رابط جديد رقم تسلسلي (1، 2، 3...) من عداد تلقائي التزايد في قاعدة البيانات. يتم بعد ذلك تحويل هذا الرقم من النظام العشري إلى base62 — وهو نظام عد يستخدم 62 رمزًا: a–z، A–Z، 0–9. لماذا 62 رمزًا؟ لأنها جميعًا آمنة للاستخدام في الروابط وتنتج نتيجة مختصرة. على سبيل المثال، الرقم 125000 يتحول إلى 4 أحرف فقط في base62. هذا يبقي الأكواد قصيرة مع نموها بشكل يمكن توقعه كلما زاد العداد.

2. التجزئة (Hashing)

طريقة أخرى تعتمد على حساب قيمة تجزئة (hash) للرابط الأصلي (مثل MD5 أو SHA-256)، واستخدام الأحرف الأولى من هذه القيمة ككود مختصر. هذه الطريقة مريحة لأنها لا تتطلب عدادًا مركزيًا، لكنها تحمل خطر التعارض — أي تطابق قيم التجزئة لروابط مختلفة — مما يتطلب منطقًا إضافيًا للتعامل مع هذه الحالات.

3. التوليد العشوائي مع التحقق من التفرد

تقوم الخدمة بتوليد سلسلة عشوائية بطول ثابت (عادة 6 إلى 8 أحرف)، وتتحقق في قاعدة البيانات مما إذا كان هذا الكود مستخدمًا