ترميز Base64 في الفاتورة الإلكترونية

عندما تصدر فاتورة إلكترونية في السعودية، يحمل رمز QR على الفاتورة سلسلة طويلة من الحروف والأرقام تبدو بلا معنى للوهلة الأولى: شيء مثل AQ1mYXR1cmEgQVNQ.... هذه السلسلة ليست عشوائية، ولا هي نص يقرأه الإنسان. إنها بيانات ثنائية (Binary) جرى تحويلها إلى نص آمن قابل للنقل عبر ترميز اسمه Base64. هذا الترميز هو الجسر الذي يسمح بحمل بيانات تقنية دقيقة، مثل بصمة التجزئة والختم المشفّر ومحتوى رمز QR، داخل ملفات نصية و XML دون أن تتلف.

في هذا التوثيق التقني نركّز على ترميز Base64 وحده: ما هو، لماذا نحتاجه أصلًا، كيف تتكوّن أبجديته من 64 رمزًا، كيف يحوّل البيانات الثنائية إلى نص، وما دور حشو الإكمال (Padding). نشرح كذلك أين يظهر Base64 تحديدًا داخل الفوترة الإلكترونية في السعودية، ونمرّ بمثال ترميز كامل خطوة بخطوة. أما بنية حمولة QR بترميز TLV فنفصّلها في توثيق «TLV»، وحقول رمز QR نفسها في توثيق «QR Structure». هنا ينصبّ التركيز على آلية الترميز نفسها وسلوكها على البيانات.

ما المقصود بترميز Base64؟

Base64 هو نظام لتمثيل البيانات الثنائية في صيغة نصية تعتمد على 64 رمزًا فقط من رموز ASCII المطبوعة. الفكرة بسيطة في جوهرها: تأخذ بيانات خامًا مكوّنة من بايتات (Bytes)، وتعيد التعبير عنها باستخدام مجموعة محدودة وآمنة من الحروف والأرقام التي تنتقل بأمان عبر أي وسيط نصي، سواء كان ملف XML أو رسالة بريد أو حقلًا داخل قاعدة بيانات.

المصطلح نفسه يصف آلية العمل: «Base» تعني الأساس العددي، و«64» تعني عدد الرموز المتاحة. تمامًا كما يستخدم النظام العشري عشرة أرقام (0 إلى 9)، والنظام الست عشري ستة عشر رمزًا، يستخدم Base64 أربعة وستين رمزًا للتعبير عن البيانات. كل رمز من هذه الأربعة والستين يمثّل ستة بتات (Bits) من البيانات الأصلية.

من المهم إدراك أن Base64 ليس تشفيرًا (Encryption) ولا ضغطًا (Compression). إنه ترميز (Encoding) فقط. الترميز عملية قابلة للعكس بالكامل وبلا مفتاح سري: أي طرف يملك السلسلة المرمّزة يستطيع فكّها واسترجاع البيانات الأصلية. لذلك لا يضيف Base64 أي حماية للسرية. وظيفته الوحيدة جعل البيانات الثنائية قابلة للنقل في بيئة نصية دون أن تتعرّض للتلف.

الفرق بين الترميز والتشفير والضغط

يخلط كثيرون بين هذه المفاهيم الثلاثة لأنها جميعًا تحوّل شكل البيانات. لكن الغرض مختلف تمامًا في كل حالة، والخلط بينها يؤدي إلى أخطاء في التصميم والتنفيذ.

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

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

لماذا نحتاج Base64 أصلًا؟

تتعامل الأنظمة الرقمية مع نوعين من البيانات: بيانات نصية وبيانات ثنائية. البيانات النصية مكوّنة من حروف وأرقام ورموز يفهمها الإنسان والأنظمة على حد سواء. أما البيانات الثنائية فهي تسلسل خام من البايتات قد يحوي أي قيمة من 0 إلى 255، بما في ذلك قيم لا تقابلها رموز نصية مطبوعة على الإطلاق.

المشكلة تظهر عند نقل بيانات ثنائية عبر قناة صُمّمت للنص. كثير من القنوات والصيغ، مثل XML و JSON والبريد الإلكتروني وعناوين URL، تفترض أن المحتوى نص نظيف. إذا حقنت بايتات ثنائية خامًا داخلها، فقد تصطدم ببايت يطابق رمز تحكّم (Control character) أو رمزًا يحمل معنى خاصًا في تلك الصيغة، فيتلف الملف أو يُفسَّر تفسيرًا خاطئًا.

خذ ملف XML للفاتورة مثالًا. الختم المشفّر للفاتورة بيانات ثنائية خام. لو وضعته كما هو داخل عنصر XML، فقد يحوي بايتًا يطابق رمز «أصغر من» أو «أكبر من» أو علامة الاقتباس، وهي رموز لها معنى بنيوي في XML. عندها ينكسر تحليل الملف. الحل أن نحوّل الختم إلى نص Base64 آمن، فلا يحوي إلا حروفًا وأرقامًا لا تتعارض مع بنية XML.

هنا تكمن قيمة Base64 العملية: يضمن أن البيانات الثنائية تصل سليمة عبر أي وسيط نصي. أبجديته مختارة بعناية بحيث تخلو من أي رمز يحمل معنى خاصًا في معظم الصيغ النصية الشائعة. هذا يجعله الخيار القياسي لحمل المرفقات والمفاتيح والتواقيع والبصمات داخل ملفات نصية منظّمة.

تخيّل ملف XML للفاتورة كأنبوب صُمّم لنقل النص فقط. البيانات الثنائية الخام تشبه سائلًا قد يتفاعل مع جدار الأنبوب فيتلفه. Base64 يغلّف هذا السائل في عبوة نصية متوافقة، فيمرّ بأمان من طرف إلى طرف. هذا التشبيه يفسّر لماذا صار Base64 معيارًا عالميًا تتبنّاه أنظمة الفوترة والبريد والشهادات الرقمية على حد سواء.

أبجدية Base64: الرموز الأربعة والستون

جوهر الترميز هو جدول ثابت من 64 رمزًا، يُعرف بأبجدية Base64 القياسية. كل قيمة من 0 إلى 63 تقابل رمزًا واحدًا في هذا الجدول. الأبجدية القياسية، كما عرّفها معيار RFC 4648، تتكون من أربع مجموعات مرتبة.

المجموعة الأولى هي الحروف الكبيرة من A إلى Z، وتمثّل القيم من 0 إلى 25. المجموعة الثانية هي الحروف الصغيرة من a إلى z، وتمثّل القيم من 26 إلى 51. المجموعة الثالثة هي الأرقام من 0 إلى 9، وتمثّل القيم من 52 إلى 61. أما القيمتان الأخيرتان، 62 و63، فيمثّلهما الرمزان + و/ على الترتيب.

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

يمثّل الجدول التالي خريطة الأبجدية كاملة، حيث يقابل كل رقم القيمة الست بتية التي يحملها رمزه:

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

الأبجدية القياسية مقابل أبجدية URL الآمنة

توجد صيغة أخرى من الأبجدية تُسمى Base64URL، صُمّمت خصيصًا لتظهر داخل عناوين URL وأسماء الملفات بأمان. الفرق محصور في الرمزين الأخيرين: تستبدل هذه الصيغة الرمز + بالرمز –، والرمز / بالرمز _. السبب أن + و/ يحملان معنى خاصًا داخل عناوين URL، فاستبدالهما يمنع تلف الرابط.

في سياق الفوترة الإلكترونية في السعودية، الأبجدية المستخدمة هي القياسية، لأن قيم Base64 تظهر داخل ملفات XML وحقول بيانات وليس داخل عناوين URL. لذلك ينبغي للمطوّر أن ينتبه إلى الأبجدية الصحيحة عند الترميز والفك، فاستخدام الأبجدية الخطأ يولّد سلسلة لا تطابق ما تتوقعه أنظمة الهيئة.

كيف يعمل الترميز خطوة بخطوة؟

الفكرة المحورية في Base64 هي إعادة تجميع البتات. البيانات الأصلية مخزّنة في بايتات، وكل بايت ثمانية بتات. لكن Base64 لا يعمل بوحدة الثمانية بتات، بل بوحدة الستة بتات، لأن ستة بتات يكفيان للتعبير عن 64 قيمة مختلفة، وهي بالضبط حجم الأبجدية.

لذلك تبدأ العملية بأخذ كل ثلاثة بايتات من البيانات الأصلية معًا. ثلاثة بايتات تساوي 24 بتًا. ثم يُعاد تقسيم هذه الأربعة والعشرين بتًا إلى أربع مجموعات، كل مجموعة ستة بتات. كل مجموعة سداسية تعطي قيمة من 0 إلى 63، تُترجم إلى رمز واحد من أبجدية Base64. النتيجة أن كل ثلاثة بايتات تتحول إلى أربعة رموز.

هذه النسبة الثابتة، ثلاثة بايتات مقابل أربعة رموز، هي سبب أن النص المرمّز أكبر حجمًا من الأصل. تزيد كمية البيانات النصية بنحو الثلث مقارنة بالبيانات الثنائية الأصلية. هذه الزيادة هي الثمن المقبول مقابل ضمان النقل الآمن عبر القنوات النصية.

نلخّص خطوات الترميز في تسلسل واضح:

1. قسّم البيانات الأصلية إلى مجموعات، كل مجموعة ثلاثة بايتات (24 بتًا).
2. أعد ترتيب الأربعة والعشرين بتًا في أربع مجموعات، كل مجموعة ستة بتات.
3. احسب القيمة العشرية لكل مجموعة سداسية (من 0 إلى 63).
4. استبدل كل قيمة بالرمز المقابل لها في أبجدية Base64.
5. أضف حشو الإكمال إن لم تكن البيانات قابلة للقسمة على ثلاثة بايتات تمامًا.

لماذا ثلاثة بايتات بالضبط؟

اختيار ثلاثة بايتات وحدةً للمعالجة ليس اعتباطيًا، بل نتيجة حسابية أنيقة. البايت ثمانية بتات، ورمز Base64 يمثّل ستة بتات. أصغر عدد مشترك بين الثمانية والستة هو أربعة وعشرون. أي أن أربعة وعشرين بتًا تنقسم تمامًا إلى ثلاثة بايتات (3 × 8) من جهة، وإلى أربعة رموز سداسية (4 × 6) من جهة أخرى.

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

الحشو (Padding) وعلامة المساواة

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

القاعدة بسيطة. إذا تبقّى بايتان (16 بتًا) في المجموعة الأخيرة، فإنهما يولّدان ثلاثة رموز فعلية، ثم تُضاف علامة مساواة واحدة = لإكمال المجموعة إلى أربعة رموز. وإذا تبقّى بايت واحد فقط (8 بتات) في المجموعة الأخيرة، فإنه يولّد رمزين فعليين، ثم تُضاف علامتا مساواة == لإكمال المجموعة.

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

يمكن تلخيص قاعدة الحشو في ثلاث حالات:

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

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

مثال ترميز كامل خطوة بخطوة

لنطبّق ما سبق على كلمة قصيرة. سنرمّز الكلمة الإنجليزية Sun المكوّنة من ثلاثة أحرف، أي ثلاثة بايتات بالضبط، وهي حالة مثالية لا تحتاج حشوًا.

الخطوة الأولى: نحوّل كل حرف إلى قيمته في جدول ASCII، ثم إلى ثمانية بتات.

S  =  83  =  01010011
u  = 117  =  01110101
n  = 110  =  01101110

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

01010011 01110101 01101110
=> 010100110111010101101110

الخطوة الثالثة: نعيد تقسيم الأربعة والعشرين بتًا إلى أربع مجموعات، كل مجموعة ستة بتات، ثم نحسب القيمة العشرية لكل مجموعة.

010100 110111 010101 101110
010100 = 20
110111 = 55
010101 = 21
101110 = 46

الخطوة الرابعة: نترجم كل قيمة إلى رمزها في أبجدية Base64. القيمة 20 تقابل U، والقيمة 55 تقابل 3، والقيمة 21 تقابل V، والقيمة 46 تقابل u.

20 -> U
55 -> 3
21 -> V
46 -> u

"Sun"  =>  "U3Vu"

النتيجة أن الكلمة Sun تتحول بترميز Base64 إلى U3Vu. لاحظ أن المُدخل ثلاثة بايتات والمُخرج أربعة رموز، تمامًا كما تنبّأت القاعدة، ولا حاجة إلى حشو لأن الطول مضاعف للثلاثة.

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

كيف يتم الفك العكسي؟

فك ترميز Base64 يسير في الاتجاه المعاكس تمامًا. يأخذ النظام كل أربعة رموز من السلسلة، ويحوّل كل رمز إلى قيمته العشرية باستخدام الأبجدية نفسها، ثم يكتب كل قيمة في ستة بتات. تتجمّع الأربع قيم في أربعة وعشرين بتًا، تُعاد قراءتها على هيئة ثلاثة بايتات كاملة. بهذا يستعيد النظام البيانات الأصلية بايتًا بايتًا.

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

أين يظهر Base64 في الفوترة الإلكترونية في السعودية؟

في المرحلة الثانية من الفوترة الإلكترونية، تفرض هيئة الزكاة والضريبة والجمارك (ZATCA) متطلبات تقنية دقيقة تتضمن بيانات ثنائية متعددة. هذه البيانات لا يمكن حملها كما هي داخل الصيغ النصية، فيأتي Base64 ليحوّلها إلى نص آمن. نستعرض المواضع الرئيسية التي يظهر فيها.

يجمع كل موضع من هذه المواضع بين خاصيتين: أن البيانات فيه ثنائية الأصل، وأنها تنتقل داخل قناة نصية مثل ملف XML أو رمز QR. لذلك تتكرّر الحاجة إلى Base64 في كل مكان تلتقي فيه بيانات تقنية ثنائية بصيغة نصية منظّمة تفرضها الهيئة.

حمولة رمز QR

رمز QR على الفاتورة المبسّطة يحمل مجموعة من الحقول مرتّبة بصيغة TLV ثنائية. هذه الحمولة الثنائية تُرمّز كاملة بـ Base64 لتصبح سلسلة نصية واحدة، ثم تُحوَّل إلى صورة رمز QR. أي ماسح للرمز يقرأ السلسلة النصية، ثم يفكّ ترميز Base64 ليستعيد الحقول الثنائية ويتحقق منها. بنية هذه الحقول نفصّلها في توثيق «TLV».

قيمة التجزئة (Hash)

بصمة التجزئة الناتجة عن خوارزمية SHA-256 قيمة ثنائية بطول 256 بت. تُكتب هذه القيمة داخل الفاتورة بترميز Base64 لتكون سلسلة نصية مدمجة بدل صيغة طويلة. القيمة نفسها تدخل في سلسلة ربط الفواتير. تفاصيل الخوارزمية في توثيق «SHA-256»، وآلية الربط في توثيق «PIH».

الختم المشفّر والشهادة

الختم المشفّر (Cryptographic Stamp) للفاتورة بيانات ثنائية ناتجة عن التوقيع الرقمي. كذلك معرّف الختم المشفّر للالتزام (CSID) ومحتوى الشهادة الرقمية المرتبطة به. كل هذه القيم تُمثَّل بترميز Base64 لتُكتب داخل ملف XML للفاتورة وفق صيغة UBL 2.1 دون أن تتعارض مع بنية الملف. ملف XML نفسه وعناصره نفصّلها في توثيق «XML Invoice».

القاسم المشترك بين كل هذه المواضع واحد: بيانات ثنائية حسّاسة تحتاج إلى الانتقال عبر صيغ نصية، فيؤدي Base64 دور الجسر الآمن الذي يحملها دون تلف.

أخطاء شائعة عند التعامل مع Base64

أول خطأ متكرر هو اختيار الأبجدية الخطأ. استخدام أبجدية Base64URL حيث تطلب الهيئة الأبجدية القياسية يولّد سلسلة تختلف في الرمزين الأخيرين، فتُرفض عند التحقق. القاعدة أن تتحقق من الأبجدية المطلوبة في كل حقل قبل الترميز.

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

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

ماذا يعني هذا للمطوّر والمحاسب؟

بالنسبة للمطوّر الذي يبني تكاملًا مع الفوترة الإلكترونية، فهم Base64 شرط لقراءة وكتابة الحقول التقنية بدقة. الأخطاء الشائعة معروفة: استخدام أبجدية URL الآمنة بدل القياسية، أو إهمال الحشو، أو الخلط بين الترميز والتشفير. أي خطأ من هذه يولّد سلسلة لا تطابق ما تنتظره أنظمة الهيئة، فترفض الفاتورة.

أما المحاسب أو صاحب المنشأة فلا يحتاج إلى ترميز أي شيء يدويًا. هذه التفاصيل التقنية يتولاها نظام الفوترة المعتمد آليًا. تظهر قيمة الفهم هنا في القدرة على قراءة محتوى الفاتورة الإلكترونية ومعرفة أن السلاسل الطويلة في رمز QR وملف XML بيانات تقنية سليمة، وليست خطأً أو تلفًا.

يتولى قيود توليد كل هذه القيم بالترميز الصحيح ضمن إصدار الفاتورة الإلكترونية المتوافق مع المرحلة الثانية. يُولّد النظام رمز QR بحمولته المرمّزة، ويحسب بصمة التجزئة ويكتبها بترميز Base64، ويدير الختم المشفّر والشهادة داخل ملف XML وفق صيغة UBL 2.1، كل ذلك دون تدخّل يدوي من المستخدم.

خلاصة عملية

Base64 ترميز يحوّل البيانات الثنائية إلى نص قابل للنقل بأمان عبر القنوات النصية، باستخدام أبجدية من 64 رمزًا تمثّل القيم من 0 إلى 63، مع علامة مساواة للحشو. يعمل بتجميع كل ثلاثة بايتات في 24 بتًا، ثم إعادة تقسيمها إلى أربعة رموز سداسية، فيزيد حجم النص نحو الثلث مقابل ضمان سلامة النقل.

في الفوترة الإلكترونية في السعودية، يظهر Base64 في حمولة رمز QR وقيمة التجزئة والختم المشفّر والشهادة داخل ملف XML. ليس تشفيرًا ولا ضغطًا، بل جسر نصي آمن للبيانات الثنائية. متى أدرك المطوّر أبجديته القياسية وقاعدة الحشو والفرق بينه وبين التشفير، أمكنه قراءة الحقول التقنية وكتابتها بدقة تطابق متطلبات الهيئة.