أدوات المطور · URL التشفير وفك التشفير
من RFC 1738 إلى URL المعيار: كيف تطورت قواعد التشفير المئوية
· خلفية
ترميز URL rfc-التاريخ معايير الويب
تمت إعادة كتابة قواعد الهروب من الأحرف في عناوين URL عدة مرات منذ 1994. يتبع هذا المنشور RFC 1738، RFC 2396، RFC 3986 ومعيار WHATWG URL ويشرح ما يتغير في كل مرة.
من RFC 1738 إلى URL المعيار - كيف تطورت قواعد التشفير بالنسبة المئوية
تمثل التلدة (~) مثالاً على كيفية تغير قواعد التشفير عبر أجيال المعايير وعمليات النشر. RFC 1738 (1994) مطلوب %7E في كل مكان؛ RFC 2396 (1998) نقل التلدة إلى غير محجوز مما يسمح بإلغاء التشفير. RFC 3986 (2005) تم تأكيد الحالة غير المحجوزة. تظل عناوين URL القديمة ذات %7E صالحة؛ الناتج بناة جديدة ~. يعكس التطور دروس النشر مع نضج الويب وتوحيد البنية التحتية. RFC 1738 كانت محافظة لأن البنية التحتية المبكرة كانت غير متجانسة ومتنوعة.
RFC 1738 سلوك المتصفح المقنن 1994. تم توحيد عمليات النشر في UTF-8؛ ثبت أن القيود غير ضرورية. خففت المعايير اللاحقة القيود المفروضة على الشخصية. RFC 3986 يسمح بفك التشفير الآمن للأحرف غير المحجوزة.
RFC 1738 (1994): الأحرف "غير الآمنة" وقواعد الهروب الأولى - ما الذي يعتبر خطيرًا ولماذا
RFC 1738 عرّف الأحرف "غير الآمنة" بأنها تلك التي تتعارض مع بناء جملة URI (مسافة، شرطة مائلة)، المستخدمة تاريخيًا في البروتوكولات (أحرف التحكم)، أو تلك الأنظمة التي لا يمكنها الإرسال بأمان. القائمة المحافظة مشفرة بنسبة مئوية أكثر بكثير مما هو ضروري للإنترنت الحديث. العديد من الأنظمة المبكرة سبقت RFC؛ لقد نظمت سلوكهم. كانت أحرف التحكم خطيرة حقًا في البروتوكولات؛ كانت المسافات عبارة عن مشكلات في الإرسال لعملاء HTTP الذين يقرؤون من أسطر الأوامر. تتعامل الأنظمة الحديثة مع هذه الحالات بشكل أكثر رشاقة من خلال التشفير الصريح.
يكشف الاختبار ضد RFC 1738 ما كانت تتوقعه الأنظمة القديمة. قم بتشفير شخصية من مواصفات التسعينيات URL ومقارنتها بالمواصفات الحديثة RFC 3986. والاختلاف يدل على ما استرخى. تم توسيع المجموعة غير المحجوزة بمرور الوقت. كانت الواصلة والنقطة والشرطة السفلية آمنة دائمًا. احتاجت تيلدا إلى RFC 2396 لتصبح آمنة. النهج المحافظ يعني التوافق مع الإصدارات السابقة. تظل عناوين URL القديمة التي تم إنشاؤها بموجب قواعد RFC 1738 صالحة اليوم. التسوية في RFC 3986 القسم 6 تسمح بفك تشفير الأحرف غير المحجوزة المشفرة بنسبة مئوية غير ضرورية بأمان.
RFC 2396 (1998) - محجوز مقابل غير محجوز، وبناء الجملة العام، وإعادة تأهيل التلدة
RFC 2396 (1998) توضح مجموعات الأحرف بشكل أكثر صرامة من RFC 1738. لقد قام بإضفاء الطابع الرسمي على الأحرف المحجوزة التي تخدم بنية URI مقابل البيانات غير المحفوظة كبيانات حرفية. موسعة غير محجوزة بما في ذلك الواصلة، والنقطة، والشرطة السفلية، والتيلدا. لقد اعترف ببناء جملة URI العام المنفصل عن القواعد الخاصة بالمخطط. RFC 2396 قدم تمييزًا بين المحددات العامة (:، /, ?، #، [، ]، @) والحدود الفرعية (!، $، &، '، (، ) ، *، +، ,، ;، =). توضح التسمية تقسيم الأحرف المحجوزة إلى مجموعتين لهما أدوار هيكلية مختلفة.
RFC 2396 قدم إرشادات التسوية التي تحدد النسبة المئوية للأحرف المشفرة التي يمكن فك تشفيرها دون تغيير المعنى. يتم تطبيع فك تشفير الأحرف غير المحفوظة. العصي ترميز الأحرف المحجوزة. RFC 3986 تدوين مبسط أكثر. تحافظ المعايير على التوافق مع الإصدارات السابقة بشدة.
RFC 3986 (2005) —! * ' ( ) ينتقل إلى المحددات الفرعية، وتتم تسمية المحددات العامة، ويصل إرشادات التسوية
RFC 3986 (2005) هو معيار مرجعي حديث لتشفير النسبة المئوية. لقد احتفظ بالتمييز المحفوظ /unreserved ولكنه قام بتبسيط التدوين وإضافة إرشادات التطبيع. تحركت تيلدا بشكل لا لبس فيه دون تحفظ. يمكن فك تشفير الأحرف القياسية غير المحجوزة والمشفرة بنسبة مئوية دون تغيير المعنى. RFC 3986 القسم 3 يصف بناء الجملة URI بدقة. يحدد القسم 2 فئات الأحرف. يخصص القسم 6 القواعد الرسمية للتطبيع النحوي. تعتبر التسوية القائمة على المقارنة أن معرفات URI متطابقة إذا تطابقت النماذج التي تمت تسويتها. تتم إزالة مقطع النقطة من المسارات دون تغيير المعنى.
التطبيع مهم للتحليلات والتخزين المؤقت ومتابعة الارتباط. يجب أن تكون عناوين URL التي تختلف فقط في حالة الأرقام السداسية (RFC 3986 تفضل الأحرف الكبيرة) متطابقة في الممارسة العملية. يؤدي التطبيع إلى منع إدخالات السجل المكررة وإخفاقات ذاكرة التخزين المؤقت. تخدم ذاكرات التخزين المؤقت المرتبطة بعناوين URL المقيسة المحتوى بغض النظر عن تفضيلات تشفير الطالب. RFC 3986 تتيح إرشادات التسوية للأنظمة اتخاذ قرارات متسقة. لكن التنفيذ الصارم يعطل عمل عناوين URL بشكل جيد في الإنترنت الحالي.
معيار WHATWG URL: تحليل ما تستقبله المتصفحات فعليًا - مجموعات التشفير والمخططات الخاصة والتسامح مع الأخطاء
WHATWG URL المعيار (2016–الآن) ظهر من تجربة المتصفح مع عناوين URL التي لا تتبع RFC 3986 بشكل مثالي. واجهت المتصفحات مساحات غير مشفرة، وترميزات مختلطة، ومراوغات. يصف WHATWG التحليل الحقيقي للمتصفح، وليس القواعد النحوية النظرية. لقد طورت متصفحات العالم الحقيقي قواعد عملية لتحمل المسافات، والتعامل مع الأحرف الهاربة، والتعافي من المدخلات المشوهة. RFC 3986 وصل إلى 2005 وحدد القواعد النحوية الرسمية، لكن المتصفحات في الممارسة العملية قد تباينت قليلاً بالفعل.
يحدد WHATWG تسع مجموعات تشفير بقواعد خاصة بالسياق. المسافة في المسار تصبح %20؛ الشرطة المائلة في معلومات المستخدم تصبح %2F. يطبق المتصفح معيارًا أضيق للويب. RFC 3986 يوفر خط الأساس؛ WHATWG يعتمد عليه.
مثال عملي: URL واحد مع علامة تيلدا ومسافة وحرف غير ASCII - كيف يقوم كل جيل من القواعد بتشفيرها
تستخدم النطاقات الدولية تشفير Punycode (München يصبح xn--mnchen-3ya). لا تزال المسارات والاستعلامات تستخدم ترميز النسبة المئوية. يستخدم جزء المجال Punycode؛ تستخدم أجزاء المسار والاستعلام ترميز النسبة المئوية. الطبقات لا تختلط ولا تتداخل.
IDNA (أسماء النطاقات الدولية في التطبيقات) يحل مشكلة اسم المضيف. يقوم Punycode بترميز غير ASCII إلى ASCII من أجل التوافق DNS. تشير البادئة xn-- إلى ترميز Punycode. الخوارزمية حتمية: münchen تصبح دائمًا xn--mnchen-3ya. يجب تحويل الأحرف غير ASCII قبل دقة DNS. لا يعمل التشفير بالنسبة المئوية لأسماء المضيفين بسبب قيود DNS وحدود التصنيفات. كل نهج يحل مشكلة مختلفة بشكل صحيح. تطورت المعايير بشكل منفصل لأسباب وجيهة.
ما لا يغطيه هذا — IRIs وأسماء النطاقات الدولية، التي لها تاريخها الخاص
يعتمد اختيار المعايير على السياق. إنشاء عناوين URL للمتصفحات؟ اتبع RFC 3986؛ تطبق المتصفحات WHATWG. الأنظمة الأقدم؟ تطبيقات الاختبار. فهم التطور يمنع الارتباك.
يجب أن يتبع المنشئون المعاصرون RFC 3986 أو WHATWG سياقيًا. تتواجد عناوين URL القديمة والجديدة معًا مما يتطلب تفكيرًا دقيقًا في التوافق. URL يتبع برنامج التشفير ووحدة فك التشفير RFC 3986 طوال الوقت، مما يوفر مرجعًا ثابتًا منفصلاً عن سلوك المتصفح. يضيف WHATWG مجموعات ترميز خاصة بالمكونات تتجاوز RFC الأساسيات. إن معرفة ما تغير ومتى يساعد على فهم سبب اختلاف الأنظمة. يكشف اختبار URL بكلا المعيارين عن عناصر التحكم القياسية في بيئتك. كلا المعيارين صحيحان.
الوجبات الجاهزة: تعرف على كتاب القواعد الذي تتبعه التعليمات البرمجية الخاصة بك - كيف يمنحك برنامج التشفير ووحدة فك التشفير URL سلوك RFC 3986 كنقطة مرجعية ثابتة
RFC 3986 تسمح التسوية بفك تشفير الأحرف غير المحجوزة المشفرة بنسبة مئوية غير ضرورية بشكل آمن. %41 يتم تطبيعه إلى A. الأحرف المحجوزة المشفرة مثل %2F لا يتم فك تشفيرها مطلقًا؛ تغيير المعنى يكسر البنية. تحافظ هيئات المعايير على التوافق مع الإصدارات السابقة بشدة. وسيتطلب الإصلاح تنسيقاً عالمياً مستحيلاً بعد عقود من الزمن. كتب المعايير لا تكسر الويب بأثر رجعي. يؤدي تغيير قرارات التشفير إلى كسر مليارات الأنظمة الموجودة في وقت واحد.
يمتد التشفير بالنسبة المئوية لثلاثة عقود من التطور الدقيق: من RFC 1738 إلى RFC 2396 وRFC 3986 إلى WHATWG URL القياسي الحديث. يجب أن يتبع الكود الحديث RFC 3986 خط الأساس. تظل عناوين URL القديمة ذات التشفير السابق صالحة. يضمن اختبار الرحلات ذهابًا وإيابًا الصحة والتوافق.