أدوات المطور · URL التشفير وفك التشفير
المسافات في روابط تنزيل الملفات: لماذا %20 و+ والمسافة الأولية ليست متماثلة
· لماذا يهم
ترميز URL http سير عمل المطور
يمكن ربط ملف يسمى "تقرير Q3 (نهائي).pdf" بثلاث طرق مختلفة، وواحدة فقط صحيحة بشكل موثوق. يشرح هذا المنشور سبب كسر أسماء الملفات لروابط التنزيل وكيفية تشفيرها بحيث يوافق كل عميل.
التنزيل الذي يفشل بالنسبة لبعض المستخدمين ويعمل مع آخرين - اسم ملف به مسافات وعلامة الجمع
تعمل ملفات مثل "Q3 report.pdf" بشكل جيد عند تخزينها محليًا ولكنها تفشل عبر روابط التنزيل لبعض المستخدمين بينما ينجح الآخرون دون مشكلة. المسافات الأولية غير صالحة في عناوين URL وفقًا لمواصفات RFC 3986. وتتسامح المتصفحات معها في أشرطة العناوين ولكن عملاء HTTP يرفضونها تمامًا. يعد فهم %20، بالإضافة إلى العلامات والمساحات الأولية أمرًا ضروريًا للغاية للتوزيع الموثوق. يؤثر التمييز بين طرق التشفير بشكل مباشر على معدلات نجاح التنزيل عبر الأنظمة الأساسية المختلفة، وأدوات التشغيل الآلي المتنوعة، وعمليات تنفيذ العميل HTTP في جميع أنحاء العالم. يجب على المطورين فهم هذا التمييز عند إنشاء أنظمة التنزيل. السياق مهم لخيارات التشفير وتوافق النظام.
يجب على المطورين الاختيار بين المسافات الأولية، %20، أو علامات الجمع عند إنشاء روابط التنزيل. يكشف الاختبار باستخدام curly وwget وPython عن العملاء الذين يفرضون الامتثال RFC. تنجح تنزيلات المتصفح نتيجة لاسترداد الأخطاء، ولكن تفشل عمليات التكامل API عند مواجهة مسافات غير مشفرة.
لماذا تكون المساحة الأولية غير صالحة في URL - ولماذا تسمح بها المتصفحات في شريط العناوين ولكن عملاء HTTP لا تسمح بذلك
المسافات الأولية في عناوين URL لها جذور تاريخية في تصميم البروتوكول. تعبر عناوين URL الأنظمة التي تتعامل مع المسافات كمحددات بين الرموز المميزة. يمكن إساءة تفسير المسافة الموجودة في URL على أنها فاصل لها. يتم اقتطاع عملاء HTTP الذين يقرأون من أسطر الأوامر عند المسافات الأولى. يبقى هذا التصميم الأساسي في تطبيقات البروتوكول ومن غير المرجح أن يتغير.
تتحمل المتصفحات المسافات الأولية من خلال التحويل الصامت إلى %20 قبل إرسال HTTP الطلبات. يخفي هذا السلوك سهل الاستخدام متطلبات البروتوكول عن المستخدمين النهائيين الذين يقومون بلصق عناوين URL في أشرطة العناوين. تفتقر الأنظمة الآلية إلى طبقة الاسترداد هذه. تفشل البرامج النصية في عناوين URL التي تحتوي على مسافات أولية. يواجه عملاء البريد الإلكتروني فشلاً في فتح مثل هذه الروابط.
%20 مقابل + في مقطع المسار - اصطلاح ترميز النموذج الذي لا ينطبق على المسارات
تمثل %20 مقابل علامات الجمع تمييزًا أساسيًا في سياقات ترميز URL. في مقاطع المسار، يجب تشفير المسافات كـ %20 لكل RFC 3986. علامة الجمع ليست ترميز مسافة في المسارات. نشأت هذه الاتفاقية في ترميز النموذج HTML حيث تعمل بمثابة ترميز مسافة في سلاسل الاستعلام. غالبًا ما يقوم المطورون بتطبيق قواعد النموذج على المسارات بشكل غير صحيح.
لا تنطبق اصطلاحات ترميز النماذج التي تسمح بعلامات الجمع على المسارات ذات المتطلبات الهيكلية المختلفة. في سلاسل الاستعلام، علامات العطف ويساوي تحدد المعلمات. لا يؤدي استخدام علامة الجمع للمسافات في قيم الاستعلام إلى أي غموض نظرًا لأن علامة الجمع ليست محددًا. في المسارات، الزائد ليس له معنى خاص. يؤدي خلط الاصطلاحات إلى إنشاء روابط تنزيل معطلة.
أسماء ملفات غير ASCII — UTF-8 مفاتيح ترميز النسبة المئوية وتخزين الكائنات التي تخزن الاسم الأولي
تتطلب أسماء الملفات غير ASCII ترميزًا بنسبة UTF-8 قبل النقل الآمن في عناوين URL. اسم ملف مثل "Über report.pdf" يحتوي على "Ü" (U+00DC) خارج النطاق ASCII. يقوم ترميز UTF-8 بتحويل هذا إلى بايت C3 9C. يتم تشفير نسبة البايت هذه كـ %C3%9C في عناوين URL. كل UTF-8 بايت تحصل على ثلاثية خاصة بها، مما ينتج أسماء ملفات مشفرة أطول.
تقدم خدمات تخزين الكائنات مثل Amazon S3 حالات مثيرة للاهتمام لأسماء ملفات غير ASCII. تسمح بعض الأنظمة بـ UTF-8 بايت خام في المفاتيح بينما تتطلب أنظمة أخرى تشفيرًا بنسبة مئوية. تعتمد استراتيجية التشفير على موفري التخزين واستخدام URL. يتطلب الوصول المستند إلى URL ترميزًا بنسبة مئوية UTF-8. يجب على المطورين تنسيق طبقات التخزين وطبقات الجيل URL.
مثال عملي: ترميز "تقرير Über Q3 (نهائي)+notes.pdf" للمسار - الإخراج الدقيق ولماذا يجب أن يصبح + %2B
مثال عملي: يوضح الترميز "تقرير Über (النهائي)+notes.pdf" الترميز الكامل. يحتوي اسم الملف على مسافات وأحرف غير ASCII وعلامة زائد حرفية. ينتج عن ترميز UTF-8 لـ "Ü" %C3%9C. في تشفير المسار، تصبح المسافات %20 (على عكس تشفير النماذج باستخدام علامة الجمع). تصبح علامة الجمع الحرفية %2B. يتم ترميز الأقواس كـ %28 و%29. النتيجة: %C3%9CberQ3%20report%20%28final%29%2Bnotes.pdf.
يُظهر الاختبار باستخدام برنامج التشفير ووحدة فك التشفير URL التحول الدقيق. يؤدي لصق اسم الملف في وضع القيمة المفردة إلى إنتاج مقاطع صحيحة مشفرة بنسبة مئوية باستخدام قواعد المسار. تحافظ الأداة على محددات المسار أثناء تشفير مكونات اسم الملف فقط. المقارنة المرئية للمدخلات والمخرجات تجعل القواعد واضحة وقابلة للتحقق قبل الإنتاج. قارن ذلك بوضع النموذج لترى اختلافات السياق.
ترتيب المحتوى ومعلمة اسم الملف* — ترميز منفصل لمطالبة التنزيل، مذكور للاكتمال
تمثل معلمات Content-Disposition وfilename* طبقات ترميز بديلة لمطالبات التنزيل. تتضمن الخوادم رؤوس ترتيب المحتوى التي تحدد أسماء الملفات لمربعات حوار التنزيل. تستخدم معلمة اسم الملف ترميز RFC 2183 بينما يستخدم اسم الملف* RFC 5987 مع ترميز النسبة المئوية. تقوم المتصفحات بتفسير هذه الرؤوس لتحديد أسماء ملفات الحفظ. يتم ترميز اسم الملف نفسه مرتين بأنظمة مختلفة.
تخلق طبقتا التشفير فرصًا لأخطاء تحويل الشفرة. URL- قد لا يتم إرسال أسماء الملفات المشفرة والمشفرة رأسيًا بشكل صحيح إذا لم توافق الخوادم والعملاء. لتحقيق أقصى قدر من التوافق، يجب على المطورين تشفير أسماء الملفات في مسارات URL باستخدام ترميز النسبة المئوية %20 وUTF-8، وتعيين رؤوس ترتيب المحتوى مع أسماء الملفات التي تم فك تشفيرها. وهذا يضمن أن جميع عملاء ومتصفحات HTTP تعمل بشكل صحيح.
ما لا يغطيه هذا هو أسماء الملفات المحجوزة على أنظمة تشغيل محددة ومراوغات موفر التخزين
تضيف أسماء الملفات المحجوزة على أنظمة تشغيل معينة تعقيدًا إلى تشفير URL. يحتفظ Windows بأسماء مثل CON، وPRN، وAUX للأجهزة. لا يمكن أن توجد الملفات التي تحمل الاسم الحرفي "CON.pdf" على NTFS. يحتوي macOS على اصطلاحات تسمية وقواعد سمات موسعة. Linux حساس لحالة الأحرف. قد لا تكون أسماء الملفات الصالحة ذات الترميز URL صالحة للتخزين على أنظمة معينة.
تضيف مراوغات موفر التخزين تعقيدًا إلى التوزيع عبر الأنظمة الأساسية. يقبل Amazon S3 مفاتيح UTF-8 وهو حساس لحالة الأحرف. يتصرف Google Cloud Storage بشكل مشابه مع القيود الإضافية. يحتوي Azure Blob Storage على قواعد أحرف مختلفة. قد تفشل أسماء الملفات التي تعمل على S3 على Azure. يجب على المهندسين المعماريين التحقق من وثائق الموفر واختبار أسماء الملفات الحقيقية غير ASCII.
الوجبات الجاهزة: تشفير المقطع، وليس URL - كيف ينتج وضع القيمة الفردية لبرنامج التشفير ووحدة فك التشفير URL اسم ملف آمن للمسار
الخلاصة: قم بتشفير المقطع، وليس URL — حيث ينتج وضع القيمة الفردية لبرنامج التشفير ووحدة فك التشفير URL أسماء ملفات آمنة للمسار. تقبل الأداة أسماء الملفات الأولية وتنتج مقاطع مشفرة بنسبة مئوية. وهذا يمنع السياقات المزدوجة الترميز والخلط. يؤدي استخدام وضع القيمة المفردة إلى تجنب موازنة قواعد المسار والاستعلام وترميز الأجزاء. الأجزاء التي تم إنشاؤها آمنة لإدراجها في عناوين URL.
أفضل الممارسات هي ترميز أسماء الملفات حيث تدخل في بناء URL. لا تفترض أن المتصفحات تقوم بإصلاح مشكلات الترميز. اختبر مع عملاء HTTP الفعليين الذين يستخدمهم المستخدمون المستهدفون: curl، وwget، وPython، وJava httplib، وواجهات برمجة التطبيقات لجلب المتصفح. تحقق من أن أسماء الملفات تبقى على قيد الحياة أثناء التنقل ذهابًا وإيابًا عبر الأنظمة بأكملها. URL جهاز التشفير ووحدة فك التشفير هو نقطة البداية لضمان الصحة.