Server.UrlEncode مقابل.HttpUtility.UrlEncode

Question

هل هناك فرق بين Server.UrlEncode وHttpUtility.UrlEncode؟

Answer 1

وHttpServerUtility.UrlEncode سوف تستخدم HttpUtility.UrlEncode داخليا. لا يوجد فرق محددة. والسبب في وجود Server.UrlEncode هو التوافق مع ASP الكلاسيكية.

Answer 2

لقد عانيت من صداع كبير مع هذه الأساليب من قبل، أنا أوصيك يتجنب أي بديل من UrlEncode, ، واستخدام بدلا من ذلك Uri.EscapeDataString - على الأقل هذا الشخص لديه سلوك مفهوم.

دعنا نرى...

HttpUtility.UrlEncode(" ") == "+" //breaks ASP.NET when used in paths, non-
                                  //standard, undocumented.
Uri.EscapeUriString("a?b=e") == "a?b=e" // makes sense, but rarely what you
                                        // want, since you still need to
                                        // escape special characters yourself

لكن مفضلتي الشخصية يجب أن تكون HttpUtility.UrlPathEncode - هذا الشيء غير مفهوم حقًا.يشفر:

• " " ==> "%20"
• "100% صحيح" ==> "100%%20صحيح" (حسنًا، عنوان URL الخاص بك معطل الآن)
• "اختبار A.aspx#anchor B" ==> "test%20A.aspx# مرساة٪ 20B"
• "اختبار A.aspx?hmm#anchor B" ==> "test%20A.aspx?hmm#المرساة ب" (لاحظ الفرق مع تسلسل الهروب السابق!)

كما أنه يحتوي على وثائق MSDN محددة "ترميز جزء المسار لسلسلة URL لإرسال HTTP الموثوق من خادم الويب إلى عميل." - دون شرح ما يفعله بالفعل.من غير المرجح أن تطلق النار على قدمك باستخدام عوزي...

باختصار، التمسك بها Uri.EscapeDataString.

Answer 3

تقدم سريعًا بعد ما يقرب من 9 سنوات منذ طرح هذا السؤال لأول مرة، وفي عالم .NET Core و.NET Standard، يبدو أن الخيارات الأكثر شيوعًا المتوفرة لدينا لتشفير URL هي WebUtility.UrlEncode (تحت System.Net) و Uri.EscapeDataString.إذا حكمنا من خلال الإجابة الأكثر شيوعًا هنا وفي أماكن أخرى، Uri.EscapeDataString يبدو أنه الأفضل.ولكن هل هو كذلك؟لقد أجريت بعض التحليلات لفهم الاختلافات وإليك ما توصلت إليه:

• WebUtility.UrlEncode يشفر الفضاء كما +; Uri.EscapeDataString يشفرها كما %20.
• Uri.EscapeDataString ترميز النسبة المئوية !, (, ), ، و *; WebUtility.UrlEncode لا.
• WebUtility.UrlEncode ترميز النسبة المئوية ~; Uri.EscapeDataString لا.
• Uri.EscapeDataString يلقي أ UriFormatException وعلى سلاسل أطول من 65,520 حرفًا؛ WebUtility.UrlEncode لا.(إنها مشكلة أكثر شيوعًا مما قد تعتقد، خاصة عند التعامل مع بيانات النموذج المرمزة بعنوان URL.)
• Uri.EscapeDataString يلقي أ UriFormatException على ال شخصيات بديلة عالية; WebUtility.UrlEncode لا.(هذا شيء يتعلق بـ UTF-16، وربما يكون أقل شيوعًا.)

لأغراض ترميز عنوان URL، تندرج الأحرف ضمن إحدى الفئات الثلاث التالية:غير متحفظ (قانوني في عنوان URL)؛محجوز (قانوني ولكن له معنى خاص، لذلك أنت قد تريد تشفيره)؛وكل شيء آخر (يجب تشفيره دائمًا).

بحسب ال RFC, ، الأحرف المحجوزة هي: :/?#[]@!$&'()*+,;=

والحروف غير المحفوظة هي أبجدية رقمية و -._~

الحكم

Uri.EscapeDataString تحدد بوضوح مهمتها:%-تشفير جميع الأحرف المحجوزة وغير القانونية. WebUtility.UrlEncode أكثر غموضا في كل من التعريف والتنفيذ.الغريب أنه يشفر بعض الأحرف المحجوزة ولكن ليس غيرها (لماذا الأقواس وليس الأقواس؟؟)، والغريب أنه لا يزال يشفر ذلك ببراءة دون تحفظ ~ شخصية.

لذلك، أتفق مع النصيحة الشعبية - استخدم Uri.EscapeDataString عندما يكون ذلك ممكنا، وفهم أن الشخصيات المحجوزة مثل / و ? سيتم ترميزها.إذا كنت بحاجة إلى التعامل مع سلاسل كبيرة محتملة، خاصة مع محتوى النموذج المشفر بعنوان URL، فستحتاج إما إلى الرجوع إلى WebUtility.UrlEncode وقبول مراوغاته، أو حل المشكلة بطريقة أخرى.

---

يحرر: لدي حاول لتصحيح جميع المراوغات المذكورة أعلاه في فلورل عبر Url.Encode, Url.EncodeIllegalCharacters, ، و Url.Decode أساليب ثابتة.هذه هي في الحزمة الأساسية (وهو برنامج صغير الحجم ولا يتضمن جميع عناصر HTTP)، أو لا تتردد في نسخها من المصدر.أرحب بأي تعليقات/ملاحظات لديك على هذه.

---

إليك الكود الذي استخدمته لاكتشاف الأحرف التي تم ترميزها بشكل مختلف:

var diffs =
    from i in Enumerable.Range(0, char.MaxValue + 1)
    let c = (char)i
    where !char.IsHighSurrogate(c)
    let diff = new {
        Original = c,
        UrlEncode = WebUtility.UrlEncode(c.ToString()),
        EscapeDataString = Uri.EscapeDataString(c.ToString()),
    }
    where diff.UrlEncode != diff.EscapeDataString
    select diff;

foreach (var diff in diffs)
    Console.WriteLine($"{diff.Original}\t{diff.UrlEncode}\t{diff.EscapeDataString}");

Answer 4

ونضع في اعتبارنا أن كنت ربما لا ينبغي أن تستخدم أي واحد من هذه الأساليب. مكافحة الصليب برمجة الموقع مكتبة مايكروسوفت يتضمن بدائل ل HttpUtility.UrlEncode وHttpUtility.HtmlEncode التي هي متوافقة مع المعايير على حد سواء أكثر، وأكثر أمنا. على سبيل المكافأة، يمكنك الحصول على طريقة JavaScriptEncode كذلك.

Answer 5

وServer.UrlEncode () هناك لتوفير التوافق مع الإصدارات السابقة مع كلاسيك ASP،

Server.UrlEncode(str);

هل ما يعادل:

HttpUtility.UrlEncode(str, Response.ContentEncoding);

Answer 6

ويدعو نفسه، Server.UrlEncode() HttpUtility.UrlEncode()