أدوات المطور · URL التشفير وفك التشفير
الزائد مقابل %20: تاريخ التطبيق/x-www-form-urlencoded
· خلفية
ترميز URL نماذج HTML معايير http
تقوم النماذج بتشفير مسافة كـ + بينما يشير المعيار URI إلى %20، والسبب تاريخي. يتتبع هذا المنشور التقليد من نماذج HTML المبكرة إلى تعريف WHATWG اليوم ويشرح سبب عدم اختفائه مطلقًا.
Plus مقابل %20 — لماذا تقوم النماذج وعناوين URI بتشفير المسافات بشكل مختلف
تقوم نماذج HTML المقدمة كـ GET بترميز المسافات كعلامات زائد في سلسلة الاستعلام. تصبح نفس المساحة %20 في عناوين URL التالية RFC 3986. كلاهما صحيح لأنهما يتبعان معايير مختلفة. تصبح حقول النموذج التي تحتوي على مسافات الاسم=القيمة+مع+مسافات في ترميز النموذج ولكن %20 في RFC 3986. تشير علامة التمييز زائد عشرين بالمائة إلى المعيار الذي ينطبق على بياناتك.
يستخدم ترميز النموذج علامة الجمع للمسافات كاتفاقية تاريخية من RFC 1866 (1995)، HTML 2.0 تعريف إرسال النموذج الأصلي. GET يطلب المسافات المشفرة كعلامات الجمع، مع حجز علامة الجمع للحرف + المشفر كـ %2B. تنطبق هذه القاعدة فقط على صيغة التطبيق /x-www-form-urlencoded, وليس بناء جملة URI العام. أصبحت المليارات من أطر عمل الخادم تعتمد على هذه الاتفاقية. يظهر اختبار كلاهما اختلافات واضحة: وضع النموذج ينتج علامة زائد؛ ينتج عن الوضع URI %20. يوفر برنامج التشفير ووحدة فك التشفير URL كلا الوضعين للمقارنة مباشرة.
نماذج HTML المبكرة وإرسال GET - كيف تم تعريف ترميز النموذج ولماذا تم اختيار +
RFC 1866 (1995) تعريف إرسال النموذج حيث تصبح المسافات علامة زائد وتصبح علامة الجمع الحرفية %2B. ينطبق هذا فقط على التطبيق /x-www-form-urlencoded. RFC 3986 المحدد %20 لبناء جملة URI العام. هناك معياران يتعايشان بشكل متعمد.
RFC 2396 مجموعات أحرف موضحة بشكل أكثر صرامة من المعايير السابقة. لقد أضفى الطابع الرسمي على الأحرف المحجوزة التي تخدم بنية URI مقابل البيانات غير المحفوظة كبيانات حرفية. تقوم هيئات المعايير بتدوين سلوك المتصفح والوكيل أثناء تطوره. RFC 3986 جاء لاحقًا دون تغيير سلوك التشفير، فقط توضيح الترميز. جميع المتصفحات الحالية موحدة على ترميز UTF-8. ترسل نماذج HTML عبر أزرار الإرسال طلبًا بتنسيق /x-www-form-urlencoded مع إضافة للمسافات. يستخدم البناء اليدوي URI %20. إن فهم كلا المعيارين يمنع مفاجآت التكامل.
RFC 1866 ومواصفات HTML الأحدث - حيث تم تدوين القاعدة وكيف اختلفت عن بناء جملة URI
WHATWG URL يحدد المعيار URLSearchParams.toString() وينتج إخراج application/x-www-form-urlencoded مع علامات الجمع للمسافات. URL يقوم المُنشئ بتشفير النسبة المئوية التالية RFC 3986. ينتقل المتصفح إلى URL مع ترميز المسافة %20؛ تم إرسال النموذج بالصيغة GET بترميز زائد. تخدم هذه الأدوات المختلفة بشكل أساسي أغراضًا مختلفة. يوفر التشفير اليدوي URIComponent %20 للمسافات—RFC نمط 3986. النماذج المرسلة إلى نفس URL ترسل بالإضافة إلى ذلك. تتوقع الخوادم التي تقوم بتحليل عمليات إرسال النماذج إضافة إلى ذلك؛ يؤدي تلقي %20 إلى فشل المعلمات الصامتة.
يكشف اختبار كلاهما عن الافتراضات التي تعتمد عليها من جانب الخادم. JavaScript يوفر URLSearchParams إخفاء تشفير نمط النموذج الآمن بالإضافة إلى التعقيد. قم بإنشاء URLSearchParams، وإلحاق الإدخالات، واستدعاء String() للحصول على application/x-www-form-urlencoded مع علامة الجمع المناسبة. وبدلاً من ذلك، أنشئ سلاسل استعلام باستخدام encodeURIComponent؛ تحصل على RFC 3986 %20. لا تخلط النهج أبدًا. سلاسل الاستعلام ذات الإضافة اليدوية وencodeURIComponent تخلق الغموض. لا يمكن للمستقبلات التمييز بين ما إذا كانت علامة الزائد تعني مساحة أو علامة زائد حرفية. يتم التعامل مع الأساليب القياسية باستمرار.
URL المعيار اليوم — تطبيق /x-www-form-urlencoded كمُسلسل منفصل بقواعده الخاصة
JSON ترفض واجهات برمجة التطبيقات عادةً علامة الجمع كمسافة، وتتوقع %20 لكل RFC 3986. يفشل العملاء الذين يرسلون Plus بصمت: تختفي المعلمات. يكشف اختبار واجهات برمجة التطبيقات (API) مع كلا التشفيرين عن المعيار الذي يقبلونه. يعالج URLSearchParams في JavaScript ترميز النموذج. URL ينتج برنامج التشفير ووحدة فك التشفير RFC 3986 %20.
HTML يقوم إرسال النموذج بمعالجة التشفير تلقائيًا. يقرر إطار عمل الخادم الخاص بك القواعد التي سيتم تطبيقها. Rails، Django، PHP جميعها تتعامل مع علامة الزائد كمساحة في بيانات النموذج المستلمة تلقائيًا. لكن إنشاء سلاسل استعلام يدويًا لنفس نقاط النهاية أمر بالغ الأهمية. الزائد الذي تم تحميله يخلق الغموض. يختلف الامتثال للمواصفات وسلوك الخادم الواقعي قليلاً. قم بتوثيق المعيار الذي تتوقعه نقاط النهاية الخاصة بك. اختبار كلا أنماط الترميز. يتعامل الكود الدفاعي مع كليهما بأمان.
مثال عملي: نفس حقل النموذج يُنظر إليه كسلسلة استعلام وكنص طلب - مع + في مكان واحد و%20 في مكان آخر
JavaScript يطبق URLSearchParams ترميز النموذج: تصبح المسافة علامة زائد، وليس %20. URLSearchParams الجديد ({q: "hello World"}) ينتج "q=hello+world"، وليس "q=hello%20world". هذه قاعدة تطبيق تاريخية /x-www-form-urlencoded مدمجة في JavaScript على وجه التحديد. لكن تمرير هذه السلسلة كاستعلام أولي إلى URL الجديد يظل زائدًا كعلامة زائد؛ فقط URLSearchParams يقوم بفك تشفيرها كمساحة. المنشئ مخلص لما يراه. يؤدي اختلاف علامة الزائد إلى حدوث أخطاء شائعة عند خلط الوظائف بشكل غير صحيح.
URL المُنشئ وencodeURIComponent أداتان مختلفتان. يقوم encodeURIComponent بتشفير كل شيء تقريبًا باستثناء الأحرف والأرقام غير المحفوظة و- _ . ! ~ * '( ). لا يفترض أي سياق. يقوم مُنشئ URL بتوزيع URL الفعلي ويطبق قواعد WHATWG لكل مكون. يقوم encodeURIComponent بتحويل "hello/world" إلى "hello%2Fworld"؛ يرى URL الجديد الخطوط المائلة كفواصل للمسار. نفس المدخلات، مخرجات مختلفة. استخدم encodeURIComponent عند إنشاء عناوين URL عن طريق تسلسل الأجزاء. استخدم URLSearchParams أو مُنشئ URL لعناوين URL الكاملة أو الجزئية.
لماذا لا يمكن إصلاح ذلك؟ عقود من الخوادم والعملاء تعتمد على السلوك الحالي
تطورت قواعد التشفير بالنسبة المئوية من RFC 1738 (1994) إلى RFC 2396 (1998) إلى RFC 3986 (2005). وأوضح كل جيل الغموض. RFC 1738 كان متحفظًا، حيث كان يتعامل مع الشخصيات بشكل غير آمن نظرًا لأن الويب المبكر كان له دعم محدود للشخصيات. تم توحيد عمليات النشر في UTF-8، وأصبحت عمليات التنفيذ متسقة. خففت المعايير اللاحقة القيود المفروضة على الشخصيات التي تثبت أمانها عبر الأنظمة. الإجماع الحديث: UTF-8 في كل مكان. تحافظ هيئات المعايير على التوافق مع الإصدارات السابقة بشدة. وسوف يتطلب الإصلاح تنسيقاً عالمياً، وهو أمر مستحيل بعد ثلاثة عقود من الزمن. هناك معياران يتعايشان عمدا.
يكشف الاختبار باستخدام علامة الجمع و%20 عن افتراضات الخادم. تُظهر سجلات الخادم ما يرسله العملاء. تستخدم النماذج بالإضافة إلى؛ تستخدم عناوين URL اليدوية %20. اختر حسب السياق واتبع وثائق API.
ما لا يغطيه هذا — الأجسام متعددة الأجزاء/form-data وJSON
يكشف اختبار كلا التشفيرين عن سلوك الخادم. أرسل a+b في كلا الاتجاهين. تتوقع العديد من خوادم الإنتاج تشفير النماذج؛ تتوقع واجهات برمجة التطبيقات الأحدث %20. يعتمد اختيارك على توقعات المتلقي. يعالج URLSearchParams ترميز النماذج؛ يتعامل encodeURIComponent مع ترميز RFC.
لا تجمع أبدًا بين طرق التشفير. القيمة المشفرة باستخدام encodeURIComponent %2B ثم تمريرها إلى URLSearchParams يتم ترميزها بشكل مزدوج كـ %252B. يؤدي فك التشفير مرة واحدة إلى %2B بدلاً من علامة الجمع. يصبح الحرف سلسلة حرفية مكونة من اثنين وستة بالمائة بدلاً من علامة الجمع. تحقق من الخطوات المتوسطة في عملية البناء الخاصة بك. يحدث الترميز مرة واحدة بالضبط لكل قيمة فقط. قم بتوثيق معيار الترميز الذي يستخدمه خط الأنابيب الخاص بك. اختبار باستخدام أحرف خاصة بما في ذلك علامة الزائد والمسافة وعلامة الضم.
الوجبات الجاهزة: معياران، كلاهما صحيح في سياقهما - كيف يمنحك برنامج التشفير ووحدة فك التشفير URL نموذج RFC 3986، مع %20 للمسافات، حتى تعرف أيهما تنظر إليه
لا يعد الانقسام الزائد مقابل العشرين خطأً يجب إصلاحه. إنها قطعة أثرية تاريخية للمعايير التي تحل المشكلات المتميزة بشكل مختلف. وسوف يتطلب الإصلاح تنسيقاً عالمياً، وهو أمر مستحيل بعد ثلاثين عاماً. لا تقوم هيئات المعايير بكسر الويب بأثر رجعي. RFC 3986، قواعد النموذج، بناء المتصفح URL لكل منهما معايير وأسباب. يخدم ترميز النموذج RFC 1866 وترميز RFC 3986 URI طبقات مختلفة. تشفير عمدا معرفة المعيار الخاص بك. اختبار ضد الحمولات واقعية.
اختر الترميز حسب السياق. تستخدم النماذج علامة زائد وفقًا لمعايير HTML. تستخدم معرفات URI اليدوية %20 لكل RFC 3986. تحدد واجهات برمجة التطبيقات ما يمكن توقعه؛ اتبع الوثائق أو اختبار كليهما. URL يظهر برنامج التشفير ووحدة فك التشفير RFC 3986. هل تحتاج إلى ترميز النموذج؟ URLSearchParams يفعل ذلك. الأداة لا تخلط بين الترميزات. فهم المعايير يمنع المفاجآت. يؤدي عدم تناسق التشفير بين الطبقات إلى فقدان المعلمات بشكل خفي، واقتطاعها، وتلف البيانات. كلا المعيارين صحيحان في مجالهما. تطبيق عمدا وتوثيق.