1. يتم استخدام GET للحصول على بيانات من الخادم ، بينما يتم استخدام POST لتمرير البيانات إلى الخادم.
2. احصل على إضافة البيانات في النموذج إلى عنوان URL الذي يشير إليه الإجراء في شكل متغير = قيمة ، ويستخدم؟ الاتصال بين الاثنين ، في حين أن & الاتصال بين كل متغير ؛ POST هو وضع البيانات في النموذج في هيئة البيانات ، ونقلها إلى عنوان URL الذي يشير إليه بواسطة الإجراء بالطريقة التي يتوافق بها المتغير والقيمة مع القيمة.
3. الحصول على غير آمن لأنه أثناء عملية الإرسال ، يتم وضع البيانات في عنوان URL المطلوب. في الوقت الحاضر ، ستقوم العديد من الخوادم الحالية أو خوادم الوكيل أو وكلاء المستخدم بتسجيل عنوان URL المطلوب في ملف السجل ثم وضعه في مكان ما ، بحيث يمكن رؤية بعض معلومات الخصوصية من قبل أطراف ثالثة. بالإضافة إلى ذلك ، يمكن للمستخدمين أيضًا رؤية البيانات المقدمة مباشرة على المتصفح ، وسيتم عرض بعض رسائل النظام الداخلي أمام المستخدم. جميع عمليات البريد غير مرئية للمستخدم.
4. كمية البيانات المرسلة بواسطة GET صغيرة ، ويرجع ذلك أساسًا إلى الحد من طول عنوان URL ؛ ويمكن للنشر نقل كمية كبيرة من البيانات ، بحيث يمكنك فقط استخدام Post عند تحميل الملفات (بالطبع هناك سبب آخر ، سيتم ذكره لاحقًا).
5. الحصول على تقييد قيمة مجموعة بيانات نماذج النماذج لتكون أحرف ASCII ؛ بينما يدعم Post مجموعة أحرف ISO10646 بالكامل. بشكل افتراضي ، تشفير ISO-8859-1
6. الحصول على الطريقة الافتراضية للنموذج.
المقارنة التالية مفيدة للغاية:
لقد كنت أعمل على تطوير الويب Java لفترة من الوقت ، وهناك مشكلة تزعجني دائمًا ، وهي مشكلة التشويش. في الأساس ، أبحث عن حلول عبر الإنترنت (هناك بالفعل الكثير من المعلومات عبر الإنترنت) ، وكلهم يقدمون كيفية حل مثل هذه المشكلات المشوهة ، لكن القليل منها يشرح القصة الكاملة للمشكلة بوضوح. في بعض الأحيان ، بعد قراءة بعض المقالات ، أعتقد أنني أفهمها ، ولكن في التطوير ، تظهر المشكلة المشوهة مثل شبح وهي حقًا مشكلة كبيرة! هذه المقالة عبارة عن تراكم لبعض الفهم لنضاعي على المدى الطويل مع الرموز المشوهة ، وآمل أن يقدم لي المزيد من الأصدقاء بعض النصائح والمكملات الغذائية.
هناك طريقتان لنموذج لإرسال البيانات إلى الخادم ، دعنا نتحدث عن GET والنشر على التوالي.
(ط) الحصول على الخضوع
1. أولاً ، دعنا نتحدث عن كيفية تشفير البيانات وإرسالها إلى الخادم باستخدام طريقة GET.
لطريقة الحصول ، يتم تسلسل البيانات بعد عنوان URL المطلوب كمعلمات ، مثل: http: // localhost: 8080/servlet؟ msg = abc
(ستظهر مشكلة شائعة جدًا من الكود المشوهة. إذا ظهرت أحرف صينية أو أخرى خاصة في عنوان URL ، مثل: http: // localhost: 8080/servlet؟ msg = Hangzhou ، يسهل الحصول على رمز مشوه على الخادم) ، بعد اكتمال ربط عنوان URL ، سيقوم المستعرض بترحيل URL وترسله إلى الخادم. تتمثل عملية الترميز في عنوان URL في تشفير جزء من عنوان URL كأحرف وترميزه في رمز البايت الثنائي وفقًا لطريقة تشفير معينة (مثل: UTF-8 ، GBK ، وما إلى ذلك) ، ثم يتم تمثيل كل بايت بواسطة سلسلة ٪ XY التي تحتوي على 3 أحرف ، حيث يكون XY التمثيل السوسيقي ثنائي البت. ما قلته هنا قد لا يكون واضحا. للحصول على التفاصيل ، يرجى الاطلاع على مقدمة فئة Java.net.urlencoder هنا. بعد فهم عملية ترميز عنوان URL ، يمكننا أن نرى سؤالين مهمان للغاية. أولاً: الأحرف التي تتطلب تشفير URL هي أحرف غير ASCII بشكل عام (بشكل عام). بعبارات بسيطة ، باستثناء الحروف الإنجليزية (مثل الصينية واليابانية ، وما إلى ذلك) ، يجب على جميعها أن تؤدي عن عنوان URL. لذلك ، بالنسبة لنا ، لن يتم تشفير عنوان URL عندما يحصل الخادم على رمز مشوه. الرمز المشتعلة ناتج عن عنوان URL الذي يحتوي على أحرف صينية أو خاصة في عنوان URL ؛ ثانياً: في أي طريقة تشفير يقوم عنوان URL بتشفير الأحرف؟ هذا هو عمل المتصفح ، والمتصفحات المختلفة لها ممارسات مختلفة. تستخدم الإصدارات الصينية من المتصفحات عمومًا GBK افتراضيًا. يمكن أيضًا استخدام UTF-8 عن طريق ضبط المتصفح. قد يكون لدى المستخدمين المختلفين إعدادات متصفح مختلفة ، مما يؤدي إلى طرق تشفير مختلفة. لذلك ، تقوم العديد من مواقع الويب بعمليات URL أولاً باستخدام JavaScript للأحرف الصينية أو الخاصة في عنوان URL ، ثم ربط عنوان URL بإرسال البيانات ، أي جعل عنوان URL يشفر للمتصفح. الميزة هي أن موقع الويب يمكنه توحيد طريقة الترميز لتقديم البيانات. بعد الانتهاء من ترميز عنوان URL ، يصبح عنوان URL الحالي حرفًا داخل نطاق ASCII ، ثم يحوله إلى ثنائي في طريقة الترميز لـ ISO-8859-1 ويتم إرسالها مع رأس الطلب. أود أن أقول أكثر من ذلك بقليل أنه بالنسبة لطريقة GET ، لا يوجد كيان طلب ، وعنوان URL يحتوي على البيانات كلها في رأس الطلب. السبب في استخدام URL Encode هو: بالنسبة لرأس الطلب ، يجب ترميز البيانات الخالصة لرأس الطلب في 101010 ثنائية ... في النهاية ، يجب نقل البيانات الخالصة لرأس الطلب على الإنترنت. إذا قمت بترميز أحرفًا خاصة مباشرة مثل الأحرف الصينية والأحرف الأخرى ISO-8859-1 ، فستفقد المعلومات ، لذلك من الضروري القيام بعملية URL أولاً.
2. كيف يحصل جانب الخادم (tomcat) على بيانات فك التشفير.
الخطوة الأولى هي فك تشفير البيانات باستخدام ISO-8859-1. بالنسبة لطريقة GET ، يحصل Tomcat على أحرف رأس البيانات في نطاق ASCII ، ويحتوي عنوان URL للطلب على بيانات المعلمة. إذا كانت هناك أحرف خاصة مثل الصينية في المعلمة ، فسيظل حالة ٪ xy بعد ترميز عنوان URL. توقف أولاً ، دعنا نتحدث عن العملية العامة للحصول على البيانات من قبل المطورين. عادة ما يحصل الجميع على بيانات المعلمة. يتم فك تشفير كائن الطلب أو البيانات التي نحصل عليها ، لكن لا يمكن للبرنامج تحديده أثناء عملية فك التشفير. هنا يجب أن نقول أن العديد من المبتدئين يقولون إن استخدام request.setcharacterencoding (مجموعة الأحرف) يمكن أن يحدد طريقة فك التشفير ، لكن هذا غير ممكن بالفعل . بالنظر إلى واجهة برمجة التطبيقات الرسمية للخدمة ، هناك تفسير لهذه الطريقة: يتجاوز اسم تشفير الأحرف المستخدم في نص هذا الطلب. يجب استدعاء هذه الطريقة قبل قراءة معلمات طلب أو قراءة الإدخال باستخدام getReader (). يمكن أن نرى أنه عاجز عن فعل أي شيء حيال طريقة الحصول على. إذن ما هي طريقة الترميز المستخدمة لفك تشفير البيانات؟ هذا هو عمل Tomcat. الافتراضي الافتراضي هو ISO-8859-1 ، حتى نتمكن من العثور على سبب وجود طلب GET معلمات صينية ولماذا يتم الحصول على الرمز المشتعلة على جانب الخادم. والسبب هو أن UTF-8 أو GBK عادة ما يتم استخدامه لتشفير ترميز عنوان URL للبيانات. هنا ، من الواضح أن وحدة فك ترميز عنوان URL غير ممكن. في البرنامج ، يمكننا مباشرة
كود جافا
1. سلسلة جديدة (request.getParameter (name) .getBytes (ISO-8859-1) ، طريقة تشفير عنوان URL المحدد من قبل العميل)
استعادة مرة أخرى إلى رمز bytecode وفك تشفير البيانات بالطريقة الصحيحة. عادة ما تصنع المقالات عبر الإنترنت تكوينًا في Tomcat
رمز XML
1. <منفذ الموصل = 8080 بروتوكول = http/1.1 maxThreads = 150 connectionTimeOut = 20000 redirectport = 8443 uriencoding = gbk/>
هذا يسمح لـ Tomcat باستخدام الطريقة المحددة لاسترداد البيانات. إدخال وحدة فك ترميز عنوان URL هنا
(ط) بعد التقديم
1. كيفية تشفير البيانات وإرسالها إلى الخادم باستخدام طريقة النشر للعميل (المتصفح).
يجب أن تكون البيانات التي سيتم نقلها في طريقة POST أيضًا تشفير URL ، فما هي طريقة الترميز التي تستخدمها؟
إذا كان هناك شريحة <meta http-equiv = محتوى نوع المحتوى = text/html ؛ charset = مجموعة الأحرف (GBK ، UTF-8 ، إلخ) في ملف HTML حيث يوجد النموذج ، سيتم تشفير المنشور في طريقة الترميز المحددة هنا. بشكل عام ، يعتقد الجميع أن هذا الرمز هو السماح للمتصفح بمعرفة أي حرف تم تعيينه لتفسير صفحة الويب ، وبالتالي سيضعها موقع الويب في الواجهة الأمامية لرمز HTML وحاول ألا تظهر رمزًا مشويًا. في الواقع ، لديها أيضًا وظيفة أخرى لتحديد طريقة تشفير عنوان URL لطريقة نشر النموذج لإرسال البيانات . من هنا ، يمكننا أن نرى أنه من أجل حساب GET ، يتم تحديد طريقة تشفير عنوان URL للمتصفح بواسطة إعدادات المتصفح (يمكن تحديدها في JS للمواصفات الموحدة) ، ويمكن تحديد طريقة النشر بواسطة المطور.
2. كيف يحصل جانب الخادم (tomcat) على بيانات فك التشفير.
إذا كنت تستخدم الإعدادات الافتراضية لـ Tomcat ولم يتم إجراء أي إعدادات ترميز مثل المرشحات ، فسيتم فك تشفيرها أيضًا مع ISO-8859-1 ، ولكن طلب.
لقد وجدت أن فرضية ما يفعله Tomcat أعلاه هو أنه لا يوجد طريقة ترميز محددة في رأس الطلب. إذا كانت طريقة الترميز المحددة في رأس الطلب ، فسيتم ترميزها بهذه الطريقة.هناك مقالان موصى بهما ، والعناوين موجودة
url in-depth and Easy-tostand url الترميز: http://www.cnblogs.com/yencain/articles/1321386.html ؛
مشكلة رمز القمامة عند إرسال البيانات باستخدام طريقة النشر: http://wanghuan8086.javaeye.com/blog/173869
من المهم استخدام Post. إذا كان هناك شريحة في ملف HTML حيث يوجد النموذج. <meta http-equiv = content-type content = text/html ؛ charset = مجموعة الأحرف (GBK ، UTF-8 ، إلخ.)/>
موصى به للغاية لتقديم المنشور