ฉันศึกษาการเข้ารหัส UTF-8 มาสองสามวันแล้ว และฉันรู้สึกสับสนมาก ฉันจะหารือเกี่ยวกับความคิดเห็นของฉันกับคุณ ยินดีอนุมัติครับ. ต่อไปนี้เป็นความคิดของฉัน หากมีอะไรผิดปกติโปรดให้ความกระจ่างแก่ฉันและช่วยฉันชี้ให้เห็น
การพูดนอกเรื่องที่เกี่ยวข้อง:
1. ระบบปฏิบัติการ
ระบบหน้าต่างเป็นแบบยูนิโค้ดทั้งหมดภายใน ชื่อโฟลเดอร์ ชื่อไฟล์ ฯลฯ ล้วนเป็น Unicode และสามารถแสดงผลได้ตามปกติในทุกระบบภาษา
2. วิธีการป้อนข้อมูล:
เอาต์พุตพินอินของ Microsoft เป็น Unicode และเอาต์พุต Smart ABC เป็นภาษาจีนตัวย่อ (ดังนั้น Smart ABC จึงไม่สามารถใช้ในระบบที่ไม่ใช่ภาษาจีนตัวย่อได้เลย และสามารถพิมพ์ได้เฉพาะภาษาอังกฤษเท่านั้น)
3. พื้นที่ข้อความของหน้าเว็บ
พื้นที่ข้อความของหน้าเว็บจะแสดงเป็น Unicode ดังนั้นสิ่งที่คุณพิมพ์ลงไปก็จะปรากฏขึ้น แต่กล่องอินพุตบางกล่องที่สร้างด้วยแฟลชจะไม่ทำงาน
4. แอคเซส2000
ข้อมูลที่บันทึกไว้ในการเข้าถึงเป็นยูนิโค้ดและสามารถแสดงในระบบภาษาใดก็ได้
หากอักขระบางตัวไม่ปกติเมื่อดูในมุมมองข้อมูล อาจเป็นเพราะแบบอักษรที่ใช้แสดงผลไม่ใช่แบบอักษร Unicode
เปลี่ยนเป็นฟอนต์ Arial Unicode MS เพื่อแสดงทุกอย่าง (เข้าถึงวิธีใช้ ค้นหา ป้อน Unicode มีคำแนะนำ)
5. คำพูด
การแปลงระหว่างภาษาจีนตัวเต็มและภาษาจีนตัวย่อใน Word หลังจากแปลงจากภาษาจีนตัวย่อเป็นภาษาจีนตัวเต็มแล้ว รหัสภายในยังคงเป็นภาษาจีนตัวย่อ
6. ASP เป็นแบบ Unicode ภายใน และข้อความทั้งหมดจะถูกจัดเก็บไว้ใน Unicode แปลงเป็นชุดอักขระที่ระบุเมื่อจำเป็น
ก่อนอื่นเรามาสรุปกันก่อน:
<%@ codepage=936%>จีนตัวย่อ
<%@ codepage=950%>ภาษาจีนตัวเต็ม
<%@ โค้ดเพจ=65001%>UTF-8
เพจรหัสระบุการเข้ารหัสที่ IIS อ่านสตริงที่ส่งผ่าน (การส่งแบบฟอร์ม การส่งแถบที่อยู่ ฯลฯ)
ยังระบุการเข้ารหัสที่ตัวแปรข้อความทั้งหมดจะถูกแปลงจาก Unicode
นอกจากนี้ยังระบุการเข้ารหัสที่ข้อมูลที่ดึงมาจากฐานข้อมูลถูกแปลงจาก Unicode (โปรดทราบสิ่งนี้สำคัญมาก)
คำสำคัญ:
การอ่าน: สตริง หากอ่านในภาษาจีนตัวย่อจะเป็นอักขระบางตัว หากอ่านในภาษาจีนตัวเต็มจะเป็นอักขระบางตัว การเข้ารหัสของสตริงนั้นไม่มีการเปลี่ยนแปลง
การแปลง: ระบบจะแปลงอย่างกระตือรือร้น เช่น จากอักขระ "化" ของ Unicode ไปเป็นอักขระ "化" ของ Big5 รหัสภายในจะกลายเป็นของ Big5 หากไม่มีคำที่สอดคล้องกันใน Big5 แบบฟอร์ม Unicode จะยังคงอยู่ (&#xxxx;)
จีนตัวย่อ: หกข้อสรุป
รูปแบบเลขฐานสิบหก Unicode: หกข้อสรุป
รูปแบบทศนิยม Unicode: หกข้อสรุป
ต่อไปนี้เป็นกระบวนการแปลงการเข้ารหัสที่ฉันคาดเดา:
ไคลเอนต์: วิธีการป้อนข้อมูล Unicode - ยูนิโค้ดกล่องอินพุต - แปลงจาก Unicode เป็นการเข้ารหัสที่เกี่ยวข้องด้วยชุดอักขระ () - การเข้ารหัสการส่งแบบฟอร์ม
ฝั่งเซิร์ฟเวอร์: IIS ถอดรหัสแบบฟอร์ม - อ่านตามการเข้ารหัสที่ระบุโดยเพจโค้ด - แปลงเป็น Unicode ที่เกี่ยวข้อง - สามารถอ่านได้ด้วยการร้องขอ ("") - ดำเนินการประมวลผลบางอย่าง - บันทึกลงในฐานข้อมูลในการเข้ารหัส Unicode
ฝั่งเซิร์ฟเวอร์: อ่านข้อมูล Unicode จากฐานข้อมูลและแปลงเป็นการเข้ารหัสที่ระบุโดยเพจโค้ด --- สร้างซอร์สโค้ด - IE อ่านและแสดงตามชุดอักขระ
นี่คือตัวอย่างบางส่วน:
ตัวอย่างที่ 1:
สมมติว่ามีเพจ asp สามเพจ ซึ่งเป็นเพจข้อความทั่วไป:
1.write.asp เป็นรูปแบบการป้อนข้อมูลที่เรียบง่ายและถูกส่งไปยัง add.asp
<META http-equiv="Content-Type" content="text/html; charset=big5">
2.add.asp รับข้อความและบันทึกลงในฐานข้อมูล
<%@ โค้ดเพจ=936%>
3.read.asp รับข้อความจากฐานข้อมูลและแสดงข้อความเหล่านั้น
<%@ codepage=936%> charset=GB2312 หรือ
<%@ รหัสเพจ=950%> ชุดอักขระ=big5
คุณสามารถเดาได้ ฉันใช้วิธีการป้อนข้อมูล Microsoft Pinyin เพื่อป้อน "Hua Liu Discussion" ใน write.asp ในที่สุดสิ่งที่จะปรากฏใน read.asp?
คุณเวียนหัวหรือเปล่า? มาวิเคราะห์ตั้งแต่ต้นกันดีกว่า
ตัวอย่างที่ 2:
จะเกิดอะไรขึ้นถ้าเราเปลี่ยน <%@ codepage=936%> ใน add.asp ในตัวอย่างที่ 1 เป็น <%@ codepage=950%>?
คุณพบอะไรที่นี่?
1. หากข้อความที่ป้อนแตกต่างจากชุดอักขระที่สอดคล้องกัน เมื่อแปลงแล้ว อักขระในรูปแบบ Unicode อาจปรากฏขึ้น นี่คือเหตุผล กระบวนการทั้งหมดจะยังคงอยู่ต่อจากนี้ไป
2. โค้ดเพจใน Add.asp จะกำหนดข้อความที่บันทึกไว้ในฐานข้อมูลและภาษาใดที่สอดคล้องกับ Unicode ตัวอย่างเช่น โค้ดเพจ=936
จากนั้นฐานข้อมูลจะบันทึก Unicode จีนตัวย่อ (ฐานข้อมูลกลับคืนสู่ระบบจีนตัวย่อ ทุกอย่างเป็นปกติ)
Codepage=950 บันทึก Unicode ภาษาจีนตัวเต็ม (การนำระบบภาษาจีนตัวย่อกลับคืนมาถือเป็นเรื่องผิด)
3. ให้ความสนใจกับกระบวนการเปลี่ยนสตริง:
1) วิธีการป้อนข้อมูล --- CharsetUnicode ---- ระบุการจับคู่ชุดอักขระ
2) Charset ---- สตริงการเข้ารหัสรูปแบบการเข้ารหัสแบบง่าย
3) กระบวนการย้อนกลับของขั้นตอนก่อนหน้าของการถอดรหัสแบบฟอร์ม สองขั้นตอนจะถูกชดเชย
4) สตริงàกดเพจรหัสเพื่ออ่านสตริงและสตริงไม่มีการเปลี่ยนแปลงขั้นตอนนี้อาจทำให้เกิด "ความเข้าใจผิดในการอ่าน"
5) แปลงเป็นชุดอักขระที่ระบุ Unicode Codepage ที่สอดคล้องกัน ---- การแมป Unicode
6) การประมวลผลระดับกลาง ไม่มีการเปลี่ยนแปลงในฐานข้อมูล ป้อนโดยตรงในรูปแบบ Unicode
7) กดเพจรหัสเพื่ออ่านฐานข้อมูล Unicode ---- เพจโค้ดระบุการแมปชุดอักขระ
8) แสดงว่าสตริงที่อ่านจากชุดอักขระที่ระบุโดย Charset ไม่มีการเปลี่ยนแปลง
เรามาอธิบายด้วยตัวอย่างที่ 1:
ตัวอย่างที่ 2:
วิงเวียน. ทีนี้เรามานำความรู้ไปใช้กัน
กรณีที่ 1
รหัสที่ทำงานได้ดีภายใต้ระบบภาษาจีนตัวย่อจะถูกอ่านไม่ออกในฐานข้อมูลเมื่อวางไว้ในพื้นที่ต่างประเทศ และข้อมูลต้นฉบับก็อ่านไม่ออกเช่นกัน
วิเคราะห์: เนื่องจากคนส่วนใหญ่มักจะใช้ระบบภาษาจีนตัวย่อ โค้ดเพจเริ่มต้น=936 ดังนั้นจึงไม่สำคัญว่าทุกคนจะไม่เขียนมันหรือไม่
แต่เมื่อเราไปต่างประเทศปัญหาเรื่องพื้นที่ก็เกิดขึ้น Unicode ในฐานข้อมูลถูกแปลงเป็นการเข้ารหัสภาษาอังกฤษ ดังนั้นหลังจากภาษาจีนตัวย่อดั้งเดิมในฐานข้อมูลถูกแปลงเป็นภาษาอังกฤษแล้ว จอแสดงผล GB จะถูกอ่านไม่ออกตามธรรมชาติ
ดังที่แสดงในภาพ ข้อความที่ป้อนใหม่จะแสดงตามปกติ แต่ Unicode ภาษาอังกฤษจะถูกบันทึกไว้ในฐานข้อมูล
วิธีแก้ไข: เพิ่ม <%@codepage=936%> ให้กับทั้งหมด
กระบวนการทั้งหมดเกี่ยวข้องกับการแปลงระหว่างภาษาจีนตัวย่อและ Unicode ที่เกี่ยวข้องเท่านั้น
กรณีที่ 2:
ฉันควรทำอย่างไรหากต้องการแปลงรหัสและข้อมูลภาษาจีนตัวย่อเป็นภาษาจีนตัวเต็มเวอร์ชันเต็ม
การวิเคราะห์: 1. การเข้ารหัสไฟล์โค้ดทั้งหมดจะเปลี่ยนเป็น Big5 และตัวไฟล์นั้นจะถูกบันทึกเป็นภาษาจีนตัวเต็ม
2. <%@ โค้ดเพจ=936 %>
3.ชุดอักขระ=big5
4. เวอร์ชันการเข้าถึงไม่สำคัญ เนื่องจากข้อมูลในการเข้าถึงเป็น Unicode
5. ตกลง รหัสสามารถทำงานได้ภายใต้ระบบภาษาจีนดั้งเดิมล้วนๆ
6. ปัญหาที่เหลืออยู่: จะมีเครื่องหมายคำถามอยู่บ้างเมื่ออ่านข้อมูลภาษาจีนตัวย่อต้นฉบับ เอฟเฟกต์จะเหมือนกับการอ่านค่า 950 ในตัวอย่างที่ 1, จอแสดงผล big5 เนื่องจาก Unicode ของภาษาจีนตัวย่อถูกแปลงเป็นภาษาจีนตัวเต็ม อักขระบางตัวจึงไม่ใช่ภาษาจีนตัวเต็ม ดังนั้นเครื่องหมายคำถามจึงจะปรากฏขึ้น
7. วิธีแก้ไข: ใช้เพจ asp ชั่วคราว codepage=65001 อ่านเป็น Unicode จีนตัวย่อ ใช้ฟังก์ชัน Unicode->Big5 เพื่อแปลงเป็นภาษาจีนตัวเต็ม แล้วเขียนกลับไปยังฐานข้อมูล วิธีนี้น่าจะได้ผลใช่ไหม
ฉันอนุมานทั้งสองกรณีได้อย่างสมบูรณ์ตามทฤษฎีและยังไม่ได้รับการยืนยัน
ยินดีรับคำวิจารณ์และการแก้ไขหากคุณมีประสบการณ์คล้ายกัน