ไม่มีข้อมูลใดที่น่าเชื่อถือเท่ากับข้อมูลที่เป็นทางการ วันนี้ในที่สุดฉันก็พบวิธีแก้ไขปัญหาการเข้ารหัส 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 จะถูกตั้งค่าโดยคุณสมบัติ metabase ของ AspCodePage หากไม่ได้ตั้งค่าคุณสมบัติ metabase ของ 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-blog ฉันตรวจสอบว่า 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... และส่วนเนื้อหาไดนามิกสุดท้ายของเพจจะถูกตีความตามค่า ของ Response.CodePage
เนื่องจากทั้ง Zblog และ Oblog ประกาศ @CodePage เมื่อผู้ใช้เพิ่งเริ่มต้นเครื่องแล้วเข้าสู่เบราว์เซอร์เพื่อเรียกดู Zblog และ Olog Response.CodePage จะถูกกำหนดค่าโดย @CodePage ดังนั้นการแสดงผลแบบ leaf จึงเป็นเรื่องปกติ
ประโยคนี้จะอธิบายเพิ่มเติมถึงสาเหตุของอักขระที่อ่านไม่ออก
หากคุณตั้งค่า 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 จะถูกโยนทิ้งตามข้างต้น code. กลายเป็น Session.CodePage=936 ที่โปรแกรมประกาศไว้ ดังนั้นเมื่อเข้า Zblog อีกครั้ง จะมีการให้ 936 ให้กับ Response.CodePage
จนถึงขณะนี้มีการวิเคราะห์เหตุผลทั้งหมดอย่างชัดเจนแล้ว
ดังนั้น โค้ดเพื่อให้แน่ใจว่า ASP Leaf จะไม่อ่านไม่ออกควรเป็นดังนี้: (สมมติว่าเป็น UTF-8 Leaf)
<%@ CODEPAGE=65001 %>
<% Response.CodePage=65001%>
<% Response ชุดอักขระ ="UTF-8" %>
อธิบายเพิ่มเติมว่าทำไมจึงควรเพิ่ม Response.Charset เพราะ MSDN บอกว่าควรเพิ่ม... ฮ่าฮ่า
หากโค้ดเพจถูกตั้งค่าในเพจ ก็ควรตั้งค่า Response.Charset ด้วย
นอกจากนี้ รูปแบบไฟล์ของ
เว็บเพจจะต้องเหมือนกับ @CODEPAGE ที่ใช้ในเพจ
นี่คือสาเหตุที่บางโปรแกรม เช่น zblog และ pjblog จำเป็นต้องบันทึกไฟล์ในรูปแบบการเข้ารหัส UTF8
โดยสรุป หากโปรแกรมทั้งหมดประกาศ Response.CodePage โปรแกรมเหล่านั้นจะไม่ถูกรบกวนโดย Session.CodePage และทำให้เกิดอักขระที่อ่านไม่ออก ดังนั้น Session.CodePage จึงยังไม่สามารถใช้งานได้ง่าย!
บทความอ้างอิง: