لا توجد معلومات في أي مكان موثوقة مثل المعلومات الرسمية. لقد وجدت اليوم أخيرًا حلاً لمشكلة تشفير ASP من MSDN.
ما يلي هو مقطع من MSDN.
يؤثر إعداد @CODEPAGE بشكل واضح على السلاسل الحرفية في استجابة واحدة. يؤثر Response.CodePage على السلاسل الديناميكية في استجابة واحدة، ويؤثر Session.CodePage على السلاسل الديناميكية في جميع الاستجابات في الجلسة.
تشرح هذه الجملة بوضوح وظائف @CODEPAGE وResponse.CodePage وSession.CodePage على التوالي.
يعمل @CODEPAGE على جميع السلاسل الثابتة، مثل const blogname = "my home" في ملف.
Response.CodePage، يعمل Session.CodePage على جميع سلاسل الإخراج ديناميكيًا، مثل <%=blogname%>.
هذه الجملة هي المفتاح جدًا النقطة المهمة هي أن نطاق Response.CodePage هو استجابة واحدة، في حين أن نطاق Session.CodePage المعلن في SXNA هو كافة الاستجابات في الجلسة.
انظر إلى جملة أخرى.
إذا لم يتم تعيين Response.CodePage بشكل صريح في الصفحة، فسيتم تعيينه ضمنيًا بواسطة Session.CodePage، إذا تم تمكين الجلسات، إذا لم يتم تمكين الجلسات، فسيتم تعيين Response.CodePage بواسطة @CodePage، إذا كان @CodePage موجودًا في الصفحة. إذا لم يكن هناك @CodePage في الصفحة، فسيتم تعيين Response.CodePage بواسطة خاصية قاعدة التعريف AspCodePage. إذا لم يتم تعيين خاصية قاعدة التعريف AspCodePage، أو تم تعيينها على 0، فسيتم تعيين Response.CodePage بواسطة صفحة الرموز ANSI الخاصة بالنظام.
للوهلة الأولى، فهمت أن هذه الجملة تعني ما يلي: عند تمكين الجلسات، إذا لم يتم الإعلان عن Response.CodePage، فسيتم تعيين Response.CodePage بواسطة Session.CodePage. إذا لم يتم تمكين الجلسات، إذا تم الإعلان عن @CodePage، فسيتم تعيين Response.CodePage بواسطة @CodePage، وما إلى ذلك.......
تشرح هذه الجملة السبب بعد الخروج من SXNA، فمن السهل أن يكون لديك أحرف مشوهة عند إدخال بعض صفحات أخرى مثل oblog وz-blog وما إلى ذلك، لأن البرامج الأخرى لا تعلن عن Response.CodePage ويحدث SXNA للإعلان عن Session.CodePage. لذلك، بمجرد إدخال SXNA، يتم تعيين قيمة Session.CodePage على الفور (مختلفة الإصدارات، هناك بعض الإصدارات تم تعيينها 936، وبعض الإصدارات تم تعيينها 65001)، وبعد ذلك عند إدخال برامج أخرى، يتم تعيين Response.CodePage على الفور بواسطة Session.CodePage إذا كان رمز Response.CodePage مختلفًا عن رمز الصفحة نفسها ، سيتم تشويه الصفحة. لذا، عندما ظهرت أحرف مشوهة عند الدخول إلى مدونة z، تأكدت من أن قيمة كل من Session.CodePage وResponse.CodePage كانت 936، وعندما ظهرت أحرف مشوهة عند الدخول إلى oblog، كانت قيمة Session.CodePage وResponse.CodePage هي 65001. وهذا يعني، إذا كنت أرغب في التأكد من عدم وجود تعليمات برمجية مشوهة على سطح الورقة، فيجب الإعلان عن Response.CodePage، وإلا فسيتم تفسير صفحة الويب وفقًا لـ Session.CodePage (بدلاً من تفسير صفحة الويب وفقًا لـcodepage
فقط
).اتبع الشرح أعلاه، أنا في الواقع في حيرة من أمري، لأننا جميعًا هو نظام تشغيل صيني. يمكنك محاولة إخراج Session.CodePage في كل مرة تدخل فيها إلى المتصفح، ويمكنك أن ترى أنه 936! لماذا لم يقم بتعيين Session.CodePage 936 الافتراضي لـ Response.CodePage عند الدخول إلى Z-blog؟ بدلاً من ذلك، قم بإعطاء @CodePage إلى Response.CodePage؟ تحت أي ظروف يجب تعيين Session.CodePage إلى Response.CodePage؟ كيف يجب أن نفهم النص الأصلي "تم تمكين الجلسات"؟
ربما ينبغي فهم الكلمات المذكورة أعلاه بهذه الطريقة:
عندما يتم الإعلان عن Session.CodePage بواسطة أي برنامج، إذا لم يتم الإعلان عن Response.CodePage، فسيتم تعيين Response.CodePage بواسطة Session.CodePage. إذا لم يتم الإعلان عن Session.CodePage بواسطة أي برنامج، وإذا تم الإعلان عن @CodePage، فسيتم تعيين قيمة لـ Response.CodePage بواسطة @CodePage...، وسيتم تفسير الجزء الديناميكي النهائي من الصفحة وفقًا للقيمة من الاستجابة.CodePage.
نظرًا لأن كلاً من Zblog وOblog يعلنان عن @CodePage، فعندما يبدأ المستخدم تشغيل الجهاز للتو ثم يدخل إلى المتصفح لتصفح Zblog وOblog، سيتم تعيين قيمة Response.CodePage بواسطة @CodePage، وبالتالي فإن عرض الورقة طبيعي.
تشرح هذه الجملة أيضًا سبب الأحرف المشوهة.
إذا قمت بتعيين Response.CodePage أو Session.CodePage بشكل صريح، فقم بذلك قبل إرسال سلاسل غير حرفية إلى العميل. إذا كنت تستخدم سلاسل حرفية وغير حرفية في نفس الصفحة، فتأكد من ذلك تتطابق صفحة الرموز الخاصة بـ @CODEPAGE مع صفحة الرموز الخاصة بـ Response.CodePage، أو يتم ترميز السلاسل الحرفية بشكل مختلف عن السلاسل غير الحرفية ويتم عرضها بشكل غير صحيح.
إحدى الجمل الأكثر فائدة هي أنه إذا كان Response.CodePage و@CODEPAGE مختلفين، فسيتم إنشاء أحرف مشوهة. وهذا يعني أنه عندما يتم تعيين @CODEPAGE=65001 لـ Z-blog وResponse.CodePage لـ Z-blog 936 بواسطة Session.CodePage، ستظهر أحرف مشوهة، والعكس صحيح بالنسبة إلى oblog.
لا أعرف ما إذا كان الشرح أعلاه واضحًا بدرجة كافية -_-||.
دعني أشرح لماذا تقوم SXNA أحيانًا بتعيين Session.CodePage إلى 936. لدي إصدار يكتب مثل هذا:
<% OriginalCodePage=Session.CodePage %>
.. .....
<% Session.CodePage=OriginalCodePage %>
عندما يدخل المستخدم إلى المتصفح، يكون الإعداد الافتراضي لـ Session.CodePage هو 936. ولم يعلن البرنامج عن الرقم الافتراضي 936 في هذا الوقت، لذلك لن يتم تعيينه إلى Response.CodePage عند إدخال SXNA، يتم طرح Session.CodePage بواسطة ما سبق يتحول إلى Session.CodePage=936 المعلن عنه بواسطة البرنامج، لذلك عند الدخول إلى Zblog مرة أخرى، يتم إعطاء 936 إلى Response.CodePage.
وحتى الآن، تم تحليل جميع الأسباب بوضوح.
لذلك، يجب أن يكون الكود الذي يضمن عدم ظهور ورقة asp مشوهة كما يلي: (بافتراض أنها ورقة UTF-8)
<%@ CODEPAGE=65001 %>
<% Response.CodePage=65001%>
<% Response. مجموعة الأحرف = "UTF-8" %>
اشرح أيضًا سبب إضافة Response.Charset، لأن MSDN قال أنه يجب إضافته... هاها
إذا تم تعيين صفحة التعليمات البرمجية في صفحة، فيجب أيضًا تعيين Response.Charset.
بالإضافة إلى ذلك، يجب أن يكون تنسيق الملف الخاص
بصفحة الويب هو نفس تنسيق @CODEPAGE المستخدم في الصفحة.
ولهذا السبب تحتاج بعض البرامج، مثل zblog وpjblog، إلى حفظ الملفات بتنسيق ترميز UTF8.
باختصار، إذا أعلنت جميع البرامج عن Response.CodePage، فلن يتداخل معها Session.CodePage ويسبب أحرفًا مشوهة. لذلك لا يزال من غير الممكن استخدام Session.CodePage بسهولة!
المقالة المرجعية: