الترميز مقابل التشفير: ما الفرق؟

أربع تحويلات يخلط الناس بينها

الترميز: البقاء لا السرية

يرسم الترميز البايتات أو النص إلى أبجدية آمنة للقناة. قيّدت أنظمة البريد تاريخياً الأسطر على ASCII؛ JSON وXML نصيان؛ الروابط تحجز أحرفاً مثل ? و& و= و# للبنية. الترميزات خوارزميات علنية — معرفة المخطط كافية للعكس.

Base64

يمثّل Base64 (RFC 4648) البيانات الثنائية بـ 64 حرف ASCII قابل للطباعة مع حشو. يكبّر الحجم بنحو الثلث لكنه يتيح تضمين صور أو رموز أو نص مشفر داخل سلاسل JSON. فك الترميز trivial بأي مكتبة أو أدوات base64-encoder وbase64-decoder في SmartKitio — ولهذا Base64 ليس خزنة.

Hello → SGVsbG8=
(JSON-safe string carrying the same bytes)

ترميز URL (بالنسبة المئوية)

تنقسم الروابط إلى مخطط وسلطة ومسار واستعلام وجزء. يجب ترميز الأحرف المحجوزة في قيم الاستعلام (%20 للمسافة، %26 لـ &) حتى لا يقرأ المحلّل مدخلات المستخدم خطأ. url-encoder في SmartKitio يطبّق القواعد نفسها التي تستخدمها المتصفحات عند بناء سلاسل الاستعلام — الترميز عن البنية لا إخفاء القيم عن المستخدم عند لوحة المفاتيح.

النظام الست عشري

يكتب hex كل بايت كـ nibbleين (0-9، a-f). يضاعف الحجم مثل Base64 لكنه يتجنب مشاكل الأبجدية والحالة. تراه في تجزئات Git commit وعناوين MAC وتفريغات تصحيح — لا لأن hex آمناً، بل لأنه غير مبهم عند النطق.

التشفير: السرية بالمفاتيح

يستخدم التشفير مفتاحاً وخوارزمية لإنتاج نص مشفر يجب أن يكون عديم الفائدة دون مادة مفتاح مصرح بها. المخططات المتماثلة مثل AES تستخدم سراً مشتركاً للبيانات الكبيرة؛ غير المتماثلة مثل RSA أو ECDH تفاوض مفاتيح أو توقّع رسائل. تفضّل الواجهات الحديثة التشفير الموثّق (مثل AES-GCM) حتى يُكتشف العبث لا مجرد تشويش النص الصريح.

AES في التطبيقات

يلاقي المطوّرون AES عند تشفير ملفات في الراحة أو أعمدة قواعد بيانات أو حمولات جلسات. الاستخدام الصحيح يتطلب IV أو nonce عشوائياً، وتدوير مفاتيح، وعدم ابتكار وضع تشفير خاص. مفتاح AES ثابت مدمج في تطبيق جوال ما زال سراً مضمناً في العميل — يستطيع المهاجمون استخراجه.

TLS على السلك

يُشفّر Transport Layer Security ويوثّق HTTP والبريد وبروتوكولات كثيرة بين العملاء والخوادم. يحمي TLS البايتات أثناء النقل من التنصّت السلبي وكثير من الهجمات النشطة عند التحقق من الشهادات. لا يعوّض الحاجة لتجزئة كلمات المرور في الراحة أو تجنّب وضع الأسرار في روابط تظهر في السجلات.

التجزئة: بصمات أحادية الاتجاه

تربط دوال التجزئة التشفيرية أي مدخل بملخص بطول ثابت. تغييرات صغيرة في المدخل تُحدث تغييراً جلّياً في المخرج. SHA-256 تجزئة عامة للسلامة وعنونة المحتوى؛ ليست خوارزمية تخزين كلمات مرور بذاتها لأن GPUs يمكنها brute-force كلمات قصيرة ما لم تُبطّأ وتُملّح.

تجزئة كلمات المرور

• استخدم تجزئات مخصصة لكلمات المرور: bcrypt وscrypt وArgon2 أو PBKDF2 بعوامل عمل عالية.
• خزّن ملحاً فريداً لكل مستخدم حتى تفشل جداول قوس قزح.
• فلفل اختياري (سر جانب الخادم) يضيف عمقاً دفاعياً عند إدارته جيداً.
• لا تشفّر كلمات المرور قابلة للعكس للتحقق من الدخول — قارن الملخصات بمساواة زمن ثابت.

أداة sha256-hash في SmartKitio توضّح SHA-256 للمجاميع والتعلّم. لتخزين كلمات مرور حقيقي، اتبع إرشاد OWASP ومكتبات المنصة — لا تجزئة سريعة واحدة.

الضغط محور آخر

gzip وBrotli يصغّران استجابات HTTP. JPEG وWebP يتخليان عن معلومات للصور. الضغط ليس ترميزاً لأمان النقل ولا تشفيراً. الأسرار المضغوطة ما زالت تسرّب أنماط الطول في بعض نماذج التهديد، ولا يجب ضغط ثم تشفير بساطة دون فهم هجمات CRIME/BREACH على ضغط HTTP.

مفاهيم خاطئة تنجو من التدقيق

1. «نرمّز مفتاح API بـ Base64، فهو آمن.» — أي شخص يستطيع فك الترميز.
2. «شفّرنا قاعدة البيانات، فTLS لا يهم.» — البيانات أثناء الحركة وفي الراحة ضوابط منفصلة.
3. «جزّأنا بـ SHA-256 مرة واحدة.» — التجزئات السريعة غير كافية لكلمات مرور منخفضة العشوائية.
4. «ترميز URL يخفي كلمة المرور في سلسلة الاستعلام.» — تبقى في سجل المتصفح والسجلات وترويسات Referer.
5. «JWT مُشفّر لأنه يبدو مشوّشاً.» — JWT غالباً موقّع فقط (JWS) أو يستخدم JWE حين يلزم التشفير.

أمثلة محلولة

أدوات Base64 وURL في SmartKitio تعمل في المتصفح لتحويلات سريعة؛ أدلة base64-encoding-vs-encryption توضّح متى تكون هذه التحويلات مناسبة. استخدمها للتعلّم والتصحيح — لا «تأمين» الأسرار.