أدوات المطور · URL التشفير وفك التشفير
Punycode مقابل ترميز النسبة المئوية: كيفية التعامل مع المجالات والمسارات غير ASCII
· خلفية
تدويل punycode ترميز URL
يستخدم URL مع اسم مضيف غير ASCII ومسار غير ASCII ترميزين مختلفين تمامًا. يشرح هذا المنشور IDNA وpunycode للمضيف، وترميز النسبة المئوية لكل شيء آخر، وسبب وجود الانقسام.
العنوان الذي يعرض "münchen.example" في أحد المتصفحات و"xn--mnchen-3ya.example" في متصفح آخر - مضيف واحد، وكتابتان إملائيتان
تظهر مدينة München في اسم المجال الألماني. في شريط العناوين بالمتصفح الخاص بك، قد ترى münchen.example معروضًا بشكل طبيعي. انسخ العنوان من تطبيق مختلف، وسيظهر على هيئة xn--mnchen-3ya.example، وهي سلسلة ASCII فقط ولا تشبه النص الألماني على الإطلاق. واحد URL، هجاءان، كلاهما صالح تمامًا. لا يوجد خطأ. إنهم يمثلون نفس المجال باستخدام مجموعات أحرف مختلفة تمامًا. يعكس الاختلاف قيدًا أساسيًا على كيفية عمل DNS وكيف تتوقع البنية التحتية للإنترنت أن يتم نقل أسماء المضيفين.
تحتاج مقاطع المسار مثل /café/ إلى التشفير ولكنها تستخدم نظامًا مختلفًا. غير ASCII é يصبح %C3%A9 في المسارات. لماذا الفرق؟ تتطلب قيود DNS رمز Punycode لأسماء المضيفين.
لماذا لا يمكن لأسماء المضيفين استخدام ترميز النسبة المئوية - DNS التسميات والأحرف المسموح بها وحدود الطول
تسميات DNS، وهي الأجزاء الفردية لاسم المضيف مفصولة بالنقاط، لها قواعد صارمة للغاية. يمكن أن تحتوي فقط على ASCII أحرف وأرقام وواصلات وشرطات سفلية. لها حدود للطول: يمكن أن يكون كل تصنيف على الأكثر 63 ثمانية، ولا يمكن أن يتجاوز اسم المضيف الكامل 255 ثمانية. هذه قيود صارمة من بروتوكول DNS نفسه، والذي تم تعريفه منذ عقود قبل أن تصبح أسماء النطاقات الدولية مجرد مفهوم. لا يمكن أن يعمل التشفير بالنسبة المئوية لأسماء المضيفين لأن السلسلة الناتجة من المحتمل أن تتجاوز حدود التسمية للكلمات الأطول.
والأهم من ذلك، أن DNS هو نظام عالمي يتم تشغيله بواسطة أجهزة التوجيه والخوادم في جميع أنحاء العالم. لا يفهم جميعهم UTF-8 أو Unicode. لا يزال الحرف المرمز بنسبة مئوية مثل %C3%A9 يتكون من ثلاثة أحرف ASCII، لذا فهو يناسب قيود DNS. لكن هذا الأسلوب يعني أن كل عملية بحث يجب أن يتم تشفيرها بنسبة مئوية عند الدخول وفك التشفير عند الخروج، مما يضيف تعقيدًا إلى طبقة البروتوكول نفسها. كانت هناك حاجة إلى حل أفضل لأسماء المضيفين على وجه التحديد.
IDNA وpunycode في المخطط التفصيلي - البادئة xn-- وخوارزمية سلسلة التمهيد، الموصوفة نوعيًا
IDNA، أسماء النطاقات الدولية في مواصفات التطبيقات، تحل مشكلة اسم المضيف عن طريق ترميز أسماء النطاقات غير ASCII إلى ASCII التي يمكن لـ DNS التعامل معها. الترميز المستخدم يسمى punycode، وهو خوارزمية ضغط تحول نص Unicode إلى ASCII باستخدام البادئة xn-- متبوعة بتمثيل مشفر بسلسلة التشغيل. الخوارزمية حتمية: münchen تصبح دائمًا xn--mnchen-3ya في كل مرة. يجب تحويل أي اسم مضيف غير ASCII بهذه الطريقة قبل أن يتم حل DNS.
تشير البادئة xn-- إلى DNS وإلى برنامج IDNA- الذي يعلم أن الأحرف التالية هي رموز punycode، وليست أحرف ASCII حرفية. من المفهوم أن النطاق مثل example.xn--mnchen-3ya.com يعني example.münchen.com بواسطة برنامج يعرف IDNA. يستخدم Punycode فقط ASCII من الحروف والأرقام والواصلات، لذا فهو يتناسب بشكل واضح مع التسميات DNS دون مشاكل. تقوم الخوارزمية بضغط المعلومات غير ASCII في تمثيل ASCII هذا.
تظل المسارات والاستعلامات والأجزاء مشفرة بنسبة مئوية - UTF-8 بايت إلى %XX، كما هو الحال في أي مكان آخر
كل شيء آخر في URL — المسار، سلسلة الاستعلام، الجزء — يستخدم ترميز النسبة المئوية بدلاً من ذلك. يتم أولاً تحويل الحرف غير ASCII إلى UTF-8 بايت، ثم تتم كتابة كل بايت كـ %HH حيث يكون HH سداسي عشري. المسار /café/ يصبح /caf%C3%A9/. تصبح سلسلة الاستعلام ?name=josé ?name=jos%C3%A9. يعد التشفير بالنسبة المئوية أمرًا قياسيًا في كل مكان على الويب: في HTTP عناوين URL للطلبات، وفي نماذج HTML، وفي واجهات برمجة التطبيقات. ولا يحتاج إلى معالجة خاصة بواسطة DNS أو أجهزة التوجيه.
يسمح التشفير المئوي أيضًا بتمثيل الأحرف الخاصة الأخرى بأمان. تصبح المسافة %20، والشرطة المائلة (إذا كان يجب أن تظهر داخل قيمة) تصبح %2F، وهكذا. المخطط ثابت وعالمي. ولا يتم استخدامه لأسماء المضيفين لأن DNS لا يفهم عناوين URL أو ترميز النسبة المئوية؛ فهو يفهم فقط التصنيفات ASCII.
مثال عملي: URL واحد مع كليهما - تم تحويل المضيف إلى Punycode، والمسار مشفر بنسبة مئوية، جنبًا إلى جنب
خذ URL "https://münchen.example/café?city=münchen". يجب تحويل اسم المضيف münchen إلى Punycode قبل البحث DNS: https://xn--mnchen-3ya.example/café?city=münchen. لكن انتظر - المسار والاستعلام لا يحتويان أيضًا على ASCII. قم بتحويلهما أيضًا: https://xn--mnchen-3ya.example/caf%C3%A9?city=m%C3%BCnchen. الآن اسم المضيف هو punycode، والمسار والاستعلام هما مشفر بنسبة مئوية يعرض المتصفح إصدار Unicode الأصلي لسهولة القراءة؛ ويحمل الطلب HTTP الإصدار المشفر.
في أداة التشفير وفك التشفير URL، الصق مسارًا يحتوي على نص غير ASCII وقارن وضع القيمة الفردية (المسار فقط) بوضع العنوان بالكامل (URL الكامل). تعرض لك الأداة النتيجة المشفرة بالنسبة المئوية للمسار. ومع ذلك، يتطلب اسم المضيف تحويلاً منفصلاً لـpunycode؛ معظم أدوات التشفير لا تتعامل مع ذلك في السطر، لذا اقرأه من وثائق الأداة.
هجمات Homograph ولماذا تعرض المتصفحات أحيانًا رمز Punycode - المنطق الأمني وراء قواعد العرض
يمكن لممثل خبيث تسجيل نطاق باستخدام الحروف السيريلية التي تبدو متطابقة بصريًا مع الحروف اللاتينية، مثل "https://xn--80akhbyknj4f.example" (إصدار سيريلي من "example.example" في لغة punycode). إذا عرض المتصفح أنه تم فك تشفيره كنص سيريلي، فقد لا يلاحظ المستخدمون الفرق. لمنع هجمات التماثل المتماثل، تعرض المتصفحات أحيانًا إصدار punycode بدلاً من فك تشفيره. يظهر تحذير: هذا النطاق هو كل أو معظمه غير ASCII، وقد لا تتعرف على الأحرف.
يعد برنامج التشفير ووحدة فك التشفير URL أداة للتشفير وفك التشفير، وليس لتقييم الأمان. إذا كنت تعمل مع أسماء النطاقات الدولية، فاعلم أن تمثيل Punycode هو ما تراه الشبكة.
ما لا يغطيه هذا - تشغيل خوارزمية Punycode يدويًا أو الاختلافات IDNA 2003 مقابل 2008
لقد مر IDNA بإصدارات متعددة بمرور الوقت: IDNA 2003 وIDNA 2008 يتعاملان مع حالات حافة معينة بشكل مختلف، خاصة فيما يتعلق بالتطبيع وأحرف Unicode المسموح بها بموجب المواصفات. لا تزال بعض الأنظمة القديمة تستخدم IDNA 2003 بينما انتقلت أنظمة أخرى إلى IDNA 2008 لتحقيق امتثال أفضل. الاختلافات مهمة بشكل كبير إذا كنت تقوم بإنشاء أنظمة يجب أن تكون متوافقة عبر إصدارات متعددة. تحقق من متطلبات النظام الخاص بك بعناية دائمًا.
يستخدم Punycode ضغط التمهيد. تتوفر عمليات التنفيذ باللغات الشائعة، ولكن تحقق من سياسة IDNA باستخدام نظام اسم المضيف الخاص بك. اختبار الدقة وسلوك العرض بدلاً من الافتراض.
الوجبات الجاهزة: ترميزان لمهمتين - كيف يتعامل برنامج التشفير ووحدة فك التشفير URL مع الأجزاء المشفرة بنسبة مئوية، ولماذا يعد برنامج تشفير النسبة المئوية أداة خاطئة لاسم المضيف
تحتاج أسماء المضيفين إلى رمز punycode لأن DNS هو بروتوكول قديم لا يفهم سوى تسميات ASCII ولديه قيود صارمة على الطول والأحرف. تستخدم المسارات والاستعلامات والأجزاء ترميز النسبة المئوية لأنه عالمي على الويب ولا يحتوي على تلك القيود. إنهما حلان منفصلان لمشكلتين مختلفتين تمامًا. عندما تواجه ASCII URL، يحصل اسم المضيف على تحويل punycode أولاً، ثم يستخدم الباقي ترميز النسبة المئوية.
بالنسبة لمعظم أعمال التطوير، يتعامل إطار العمل أو المكتبة الخاصة بك مع هذا التحويل خلف الكواليس تلقائيًا. لكن فهم سبب وجود ترميزين مختلفين يمنع حدوث ارتباك عند تصحيح أخطاء عناوين URL الدولية أو تنفيذ كود التعامل URL الخاص بك بنجاح.