عناوين URL موجودة في كل مكان ، لكن يبدو أن المطورين لا يفهمونهم حقًا ، لأنني غالبًا ما أرى أشخاصًا يسألون عن كيفية إنشاء عنوان URL بشكل صحيح على فائض المكدس. إذا كنت تريد معرفة كيفية عمل بناء جملة URL ، فيمكنك قراءة هذه المقالة بواسطة Lunatech ، وهو أمر جيد جدًا.
لن تقدم هذه المقالة بناء جملة URL بالكامل بعمق (إذا كنت ترغب في فهم عناوين URL تمامًا ، فيمكنك قراءة RFC 3986 و RFC 1738 والمقالة المذكورة أعلاه ، وكذلك الوثائق المذكورة أعلاه W3). أريد هنا أن أتحدث عن بعض المكتبات الشائعة في عناوين URL العاملة وكيفية استخدامها بشكل صحيح من خلال بناء عنوان URL. هذه مكتبة Java التي نشرناها لإنشاء عناوين URL بشكل صحيح.
السؤال 1: urlencoder من جافا
لا يقتصر هذا الفصل على اسم الفئة سيئة ، ولكن الجملة الأولى في المستند ليست صحيحة للغاية.
فئة الأداة المساعدة لتشفير نموذج HTML.
قد تتساءل لماذا يطلق عليه urlencoder ، لكنك عاجز عن الكلام تمامًا عندما ترى هذا الخط.
إذا كنت قد قرأت منشور مدونة Lunatech ، فيجب عليك الآن أن تفهم أنه لا يمكنك تحويل سلسلة عناوين URL بأعجوبة إلى كائن URL آمن مشفر بشكل صحيح من خلال هذه الفئة. بالطبع ، إذا لم تكن قد فعلت ما يكفي من الواجبات المنزلية ، فإليك مثالًا صغيرًا لمساعدتك على الفهم.
افترض أن لديك نقطة نهاية خدمة HTTP http://foo.com/search ، والتي تقبل معلمة استعلام p ، وقيمة p هي السلسلة التي سيتم البحث عنها. إذا بحثت عن السلسلة "You & i" ، فقد يكون عنوان URL للبحث الذي أنشأته لأول مرة على هذا النحو: http://foo.com/search؟q=you you & I. إذا حصلت على سلسلة URL الفوضوية هذه ، فأنت عاجز لأنه أولاً ، لا يمكنك تحليله بشكل صحيح.
حسنًا ، دعنا نستخدم urlencoder. urlencoder.encode ("you & i" ، "utf-8") هي النتيجة التي تقوم بها+٪ 26+i. بعد فك تشفير هذا ٪ 26 ، It & ، وتمثل علامة + مسافات في سلسلة الاستعلام ، بحيث يمكن أن يعمل عنوان URL هذا بشكل طبيعي.
افترض الآن أنك تريد استخدام سلسلة الاستعلام الخاصة بك لتصحيح مسار عنوان URL بدلاً من وضعه في معلمات URL. من الواضح ، http://foo.com/search/you & I مخطئ. لسوء الحظ ، فإن نتيجة urlencoder.encode () خاطئة أيضًا. http://foo.com/search/you+٪26+ سيحصل/البحث/you+&+i ، لأن علامة+لن تحل على المسافات في مسار عنوان URL.
قد يرضي urlencoder بعض السيناريوهات الخاصة بك. لسوء الحظ ، فإن اسمها العام المفرط يجعل من السهل على المطورين إساءة استخدامه. لذلك ، فإن أفضل طريقة هي عدم استخدامه ، بحيث يرتكب المطورون الآخرون أخطاء عند استخدام وظائف أخرى على أساسك (إلا إذا كنت تفعل حقًا "تشفير نموذج HTML").
السؤال 2: Groovy Httpbuilder و Java's Uri
HTTP Builder هي مكتبة عميل HTTP من Groovy.
إن إنشاء طلب الحصول على طلب عادي بسيط للغاية:
جديد httpbuilder ("http: // localhost: 18080") .request (method.get) {uri.path = "/foo"}سيتم إرسال هذا الرمز GET /FOO HTTP /1.1 إلى الخادم (يمكنك تشغيل NC -L -P 18080 ثم تنفيذ هذا الرمز للتحقق منه).
لنجرب عنوان URL الذي يحتوي على مساحات.
httpbuilder جديد ("http: // localhost: 18080") .request (method.get) {uri.path = "/foo bar"}هذا يرسل GET /FOO ٪ 20BAR HTTP /1.1 ، والذي يبدو جيدًا.
لنفترض الآن أن هناك قسمًا في طريقنا يسمى Foo/Bar. لا يمكن القيام بذلك ببساطة عن طريق إرسال FOO/BAR ، لأن هذا سيعتبر قسطين في المسار ، FOO و BAR. لنجرب foo ٪ 2fbar (استبدل / بالترميز المقابل).
جديد httpbuilder ('http: // localhost: 18080') .request (method.get) {uri.path = '/foo ٪ 2fbar'}هذا يرسل GET /FOO ٪ 252FBAR HTTP /1.1. هذا ليس جيدًا جدًا. يتم تشفير ٪ في ٪ 2F مرارًا وتكرارًا ، وبالتالي فإن المسار الذي تم الحصول عليه بعد فك التشفير هو Foo ٪ 2fbar بدلاً من Foo/Bar. الشيء الحقيقي الذي يجب إلقاء اللوم عليه هنا هو java.net.uri ، لأن فئة uribuilder في httpbuilder تستخدمه.
نوع خاصية URI المكشوفة في إغلاق التكوين في الكود أعلاه هو uribuilder. إذا قمت بتحديث خاصية PATH الخاصة بـ URI من خلال uri.path = ... ، فسوف تستدعي في النهاية مُنشئًا لـ URI. تصف هذه الطريقة خاصية المسار الواردة على النحو التالي:
إذا تم توفير معلمة المسار ، يتم إلحاقها بعنوان URL. يتم ترميز الشخصيات في المسار طالما أنها غير محسوبة ، وترقيم ، هربت وغيرها من الفئات (ملاحظة المترجم: يتم تفصيل هذه الفئات في RFC 2396) ، وليست/أو أرقام @.
هذا النهج ليس ذا معنى كبير ، لأنه إذا يحتوي النص قبل الترميز على أحرف خاصة ، فإنه لا يمكن أن ينشئ شريحة مسار مشفرة بشكل صحيح. بمعنى آخر ، "سأقوم بتشفير هذه السلسلة ، وبعد ترميزها صحيحة" ، وهي بالطبع مغالطة ، ويصادف أن تكون ضحية هذه المغالطة. إذا تم ترميز السلسلة بشكل صحيح ، فلا توجد مشكلة. إذا لم يكن الأمر كذلك ، فسيتم ذلك لأنه لا يمكن تحليل السلسلة. في الواقع ، ما تقوله الوثائق لا يفلت من / يعني أنه يفترض أن سلسلة المسار قد تم ترميزها بشكل صحيح (أي ، يتم استخدامها بشكل صحيح لفصل المسارات) ، ولم يتم ترميزها بشكل صحيح (الأجزاء الأخرى باستثناء / لا تزال بحاجة إلى تشفيرها).
سيكون من الرائع أن يستخدم HTTPBuilder هذه الوظيفة المعيبة لفئة URI. بالطبع ، سيكون من الأفضل أن يكون URI نفسه على ما يرام.
الطريقة الصحيحة للقيام بذلك
لقد كتبنا باني عنوان URL هذا ، والذي يمكن أن يساعد المطورين بسهولة على لصق أنواع مختلفة من عناوين URL. يتبع مواصفات الترميز في المواد المرجعية في بداية المقالة ، كما يوفر واجهة برمجة تطبيقات تدفق. يمكن أن يغطي مثال الاستخدام التالي جميع سيناريوهات الاستخدام تقريبًا:
urlbuilder.forhost ("http" ، "foo.com") .PathSegress ("مع المساحات") .pathsegments ("path" ، "with" ، "varargs") .pathsegress ("&؟/"/"). .tourlstring ()والنتيجة هي: http://foo.com/with٪20spaces/path/with/varargs/&=٪3f٪2f؛matrix=param٪3f؟fancy٪20٪2B٪20Name=Fancy؟٪3Dvalue#٪23؟===
يوضح هذا المثال قواعد تشفير مختلفة لكل جزء من عنوان URL. على سبيل المثال ، يُسمح بالترميز غير المشفر و = في المسار ، بينما يجب ترميزه ، ولكن يجب تشفير = معلمات الاستعلام ، ولكن؟ الرقم لا يحتاج إليه ، لأن هذا جزء من سلسلة الاستعلام بالفعل (ملاحظة المترجم: تبدأ سلسلة الاستعلام برقم؟ ، بحيث يمكن أن تتضمن رقمًا بعد ذلك).
شكرا لك على القراءة ، آمل أن تساعدك. شكرا لك على دعمك لهذا الموقع!