JSON وBase64 وURL والتعبيرات النمطية والطوابع الزمنية وJWT وتعبيرات Cron ومقارنة النصوص في صفحة واحدة. كل المعالجة تحدث داخل متصفحك، فلا يُرسل ما تلصقه إلى أي خادم.
المسافات البادئة أثر جانبي لا أكثر. القيمة العملية هي أن تعرف أين انكسر التركيب النحوي؛ فحين يردّ الخادم بعبارة «JSON غير صالح» دون تفصيل، معرفة رقم الحرف الذي توقف عنده التحليل تكشف السبب في الحال.
ثلاثة أسباب تفسّر معظم الحالات: فاصلة زائدة بعد آخر عنصر، وعلامات اقتباس مفردة (وJSON لا يقبل سوى المزدوجة)، والتعليقات (ولا وجود لها في JSON أصلًا). من يكتب JSON بعقلية ملفات الإعداد يقع في هذه الثلاثة.
ترتيب المفاتيح أبجديًا يجعل مقارنة استجابتين ممكنة. فالبيانات نفسها إذا اختلف ترتيب مفاتيحها تظهر في أدوات المقارنة وكأن كل سطر فيها تغيّر.
Base64 ترميز يحوّل البيانات الثنائية إلى نص كي تمر البايتات عبر قنوات لا تنقل سوى الحروف، مثل البريد الإلكتروني أو حقول JSON.
لا يوجد فيه مفتاح على الإطلاق، وأي شخص يعكسه في لحظة. كلمة المرور «المخفية» بترميز Base64 هي كلمة مرور مكشوفة بالكامل.
كما أنه يزيد حجم البيانات بنحو 33%، إذ تتحول كل ثلاث بايتات إلى أربعة أحرف، وهو فارق ملموس عند تضمين الصور أو الملفات داخل النص.
في الروابط يسبب الحرفان + و/ مشكلات، لذلك تستبدلهما صيغة base64url بالحرفين - و_. وهذه هي الصيغة التي تعتمدها رموز JWT.
الدالة encodeURIComponent ترمّز أيضًا & و= و? و/، وهي المناسبة لقيم معاملات الاستعلام.
أما encodeURI فتترك تلك الرموز كما هي، وهي المخصصة للرابط كاملًا لا لأجزائه.
استعمال encodeURI على قيمة يجعل علامة & داخلها تُقرأ فاصلًا بين المعاملات فتُبتر البيانات عند تلك النقطة. والعكس صحيح: استعمال encodeURIComponent على رابط كامل يرمّز :// فيتحول الرابط إلى نص لا يعمل.
ظهور المسافة أحيانًا %20 وأحيانًا + ليس تناقضًا بل اختلاف سياق: الأولى في مسارات الروابط، والثانية عرف إرسال النماذج بصيغة application/x-www-form-urlencoded.
رمز JWT ثلاثة أجزاء تفصلها نقطتان: الترويسة التي تحمل اسم الخوارزمية، والحمولة التي تحمل البيانات، والتوقيع.
الجزآن الأولان مجرد base64url. ليسا مشفّرين ويستطيع أي شخص قراءتهما، ولهذا لا مكان للأسرار داخل حمولة JWT مهما بدت الحمولة غير مفهومة للوهلة الأولى.
التحقق من التوقيع يتطلب المفتاح السري أو العام. وهذه الأداة تفك وتعرض فقط، وذلك عن قصد: مطالبتك بلصق مفتاح توقيع في صفحة ويب هي نفسها المشكلة الأمنية التي نتجنبها.
الحقول exp وiat وnbf مقيسة بثواني يونكس. تحويلها إلى وقت مقروء يفسّر عادةً رسالة «انتهت صلاحية الرمز» من النظرة الأولى.
الحقول خمسة بالترتيب: الدقيقة والساعة واليوم من الشهر والشهر واليوم من الأسبوع. فالتعبير 0 3 * * * يعمل يوميًا عند الساعة 03:00.
الفخ الكلاسيكي: تحديد اليوم من الشهر واليوم من الأسبوع معًا يعطي «أو» لا «و». فالتعبير 0 0 1 * 1 يعني «اليوم الأول من كل شهر، وكذلك كل يوم اثنين»، لا «الأول إذا صادف اثنين».
التعبير */15 يعني كل خمس عشرة دقيقة ابتداءً من الدقيقة صفر أي 0 و15 و30 و45، لا كل ربع ساعة من لحظة عشوائية تختارها أنت.
كثير من التطبيقات يقبل 0 و7 معًا للدلالة على الأحد، فتحقق من سلوك النظام الذي تعمل عليه قبل الاعتماد على أحدهما.
تأكّد من المنطقة الزمنية. إذا كان الخادم يعمل بتوقيت UTC فإن 0 9 * * * يقابل الساعة 12:00 بتوقيت الخليج، لا التاسعة صباحًا كما تتوقع.
في 192.168.1.0/24 تعني /24 أن أول 24 بت تحدد الشبكة، وتبقى 8 بتات للأجهزة، أي 256 عنوانًا في المجموع.
الصالح منها للاستخدام 254 عنوانًا، لأن الأول محجوز لعنوان الشبكة والأخير للبث العام.
كلما صغر الرقم اتسع المجال: فـ/16 تعطي 65,536 عنوانًا، و/24 تعطي 256، و/32 تعني جهازًا واحدًا. عكس هذا الاتجاه هو أكثر الأخطاء شيوعًا.
في قواعد الجدار الناري ومجموعات الأمان يعني 0.0.0.0/0 كل عنوان على الإنترنت. وفتح منفذ SSH على هذا النطاق هو النقطة التي تبدأ منها الحوادث الأمنية.
كل عمليات التحويل والفحص تجري داخل المتصفح، ولا يُرسل أي طلب إلى خادم.
وهذا فارق عملي لا شكلي: رمز JWT الذي تريد فك ترميزه يحمل جلسة دخول حقيقية، وملف JSON الذي تريد تنسيقه يحمل بيانات عملاء. لصق هذه المحتويات في أداة على الإنترنت ينشئ مسار تسريب فعليًا.
هذه الصفحة لا تنشئ ذلك المسار. افتح تبويب الشبكة في أدوات المطور وراقب أثناء الاستخدام لتتأكد بنفسك.
تنسيق JSON، وترميز Base64 وURL، واختبار التعبيرات النمطية، وتحويل الطوابع الزمنية، وفك JWT، وCron، وCIDR، ومقارنة النصوص.
لا. كل المعالجة داخل المتصفح، فلا تُخرج بيانات داخلية إلى خدمة أخرى.
لا. يفك الترويسة والحمولة ويعرضهما فقط دون التحقق من التوقيع.