การวิเคราะห์เชิงลึกของการประมวลผล JSP และ Servlet ของภาษาจีน

ทุกภูมิภาคในโลกมีภาษาท้องถิ่นของตนเอง ความแตกต่างในระดับภูมิภาคนำไปสู่ความแตกต่างในสภาพแวดล้อมทางภาษาโดยตรง ในกระบวนการพัฒนาหลักสูตรนานาชาติ สิ่งสำคัญคือต้องจัดการกับปัญหาทางภาษา

นี่เป็นปัญหาที่มีอยู่ทั่วโลก ดังนั้น Java จึงมีวิธีแก้ปัญหาทั่วโลก วิธีการที่อธิบายไว้ในบทความนี้มีไว้สำหรับการประมวลผลภาษาจีน แต่โดยการขยายยังสามารถใช้ได้กับการประมวลผลภาษาจากประเทศและภูมิภาคอื่น ๆ ในโลกด้วย

ตัวอักษรจีนเป็นแบบไบต์คู่ สิ่งที่เรียกว่าไบต์คู่หมายความว่าคำคู่ครอบครองตำแหน่งไบต์สองตำแหน่ง (นั่นคือ 16 บิต) ซึ่งเรียกว่าบิตสูงและบิตต่ำตามลำดับ การเข้ารหัสอักขระภาษาจีนที่ระบุในประเทศจีนคือ GB2312 ซึ่งเป็นข้อบังคับ ในปัจจุบัน แอปพลิเคชันเกือบทั้งหมดที่สามารถประมวลผลภาษาจีนรองรับ GB2312 GB2312 ประกอบด้วยอักขระภาษาจีนระดับที่หนึ่งและสองและสัญลักษณ์พื้นที่ 9 บิต ช่วงบิตสูงตั้งแต่ 0xa1 ถึง 0xfe และบิตต่ำก็มีช่วงตั้งแต่ 0xa1 ถึง 0xfe ในหมู่พวกเขา ช่วงการเข้ารหัสของอักขระจีนคือ 0xb0a1 ถึง 0xf7fe

มีการเข้ารหัสอื่นที่เรียกว่า GBK แต่นี่เป็นข้อกำหนด ไม่ใช่ข้อบังคับ GBK มีอักขระจีน 20902 ตัว ซึ่งเข้ากันได้กับ GB2312 และช่วงการเข้ารหัสคือ 0x8140 ถึง 0xfefe อักขระทั้งหมดใน GBK สามารถแมปกับ Unicode 2.0 ได้ทีละตัว

ในอนาคตอันใกล้นี้ จีนจะประกาศใช้มาตรฐานอื่น: GB18030-2000 (GBK2K) รวมถึงแบบอักษรของทิเบต มองโกเลีย และชนกลุ่มน้อยอื่นๆ ซึ่งเป็นการแก้ปัญหาตำแหน่งตัวละครที่ไม่เพียงพอโดยพื้นฐาน หมายเหตุ: ไม่มีความยาวคงที่อีกต่อไป ส่วนแบบสองไบต์เข้ากันได้กับ GBK และส่วนแบบสี่ไบต์เป็นอักขระขยายและสัญลักษณ์ ไบต์ที่หนึ่งและสามมีตั้งแต่ 0x81 ถึง 0xfe และไบต์ที่สองและสี่มีตั้งแต่ 0x30 ถึง 0x39

บทความนี้ไม่ได้ตั้งใจจะแนะนำ Unicode ผู้ที่สนใจสามารถเรียกดู "http://www.unicode.org/" เพื่อดูข้อมูลเพิ่มเติม Unicode มีลักษณะเฉพาะ: ประกอบด้วยอักขระร่ายมนตร์ทั้งหมดในโลก ดังนั้นภาษาในภูมิภาคต่างๆ จึงสามารถสร้างความสัมพันธ์ในการแมปกับ Unicode ได้ และ Java ใช้ประโยชน์จากสิ่งนี้เพื่อให้เกิดการแปลงระหว่างภาษาที่ต่างกัน

ใน JDK การเข้ารหัสที่เกี่ยวข้องกับภาษาจีนคือ:

ตารางที่ 1 รายการการเข้ารหัสที่เกี่ยวข้องกับภาษาจีนใน JDK

ในทางปฏิบัติ เมื่อเขียนโปรแกรม สิ่งที่ฉันใช้เพิ่มเติมคือ GB2312 (GBK) และ ISO8859-1

เหตุใดจึงมีเครื่องหมาย "?"

ดังที่กล่าวไว้ข้างต้น การแปลงระหว่างภาษาต่างๆ จึงเสร็จสิ้นผ่าน Unicode สมมติว่ามีสองภาษา A และ B ที่แตกต่างกัน ขั้นตอนการแปลงคือ: ขั้นแรกให้แปลง A เป็น Unicode จากนั้นจึงแปลง Unicode เป็น B

ยกตัวอย่าง. GB2312 มีตัวอักษรจีน "李" และรหัสคือ "C0EE" ซึ่งจำเป็นต้องแปลงเป็นรหัส ISO8859-1 ขั้นตอนคือ: ขั้นแรกให้แปลงอักขระ "李" เป็น Unicode เพื่อให้ได้ "674E" จากนั้นจึงแปลง "674E" เป็นอักขระ ISO8859-1 แน่นอนว่าการแมปนี้จะไม่สำเร็จ เนื่องจากไม่มีอักขระที่ตรงกับ "674E" ใน ISO8859-1

ปัญหาเกิดขึ้นเมื่อการแมปไม่สำเร็จ! เมื่อแปลงจากภาษาใดภาษาหนึ่งเป็น Unicode หากไม่มีอักขระในภาษาใดภาษาหนึ่ง ผลลัพธ์จะเป็นโค้ด Unicode "uffffd" ("u" หมายถึงการเข้ารหัส Unicode) เมื่อแปลงจาก Unicode เป็นภาษาใดภาษาหนึ่ง หากภาษาใดภาษาหนึ่งไม่มีอักขระที่สอดคล้องกัน คุณจะได้รับ "0x3f" ("?") นี่คือที่มาของ "?"

ตัวอย่างเช่น: ดำเนินการสตริงใหม่ (buf, "gb2312") บนสตรีมอักขระ buf = "0x80 0x40 0xb0 0xa1" ผลลัพธ์จะเป็น "ufffdu554a" จากนั้นพิมพ์ออกมา ผลลัพธ์จะเป็น " ?ah" เนื่องจาก "0x80 0x40" เป็นอักขระใน GBK ไม่ใช่ใน GB2312

สำหรับตัวอย่างอื่น ให้ดำเนินการสตริงใหม่ (buf.getBytes("GBK")) บนสตริง String="u00d6u00ecu00e9u0046u00bbu00f9" และผลลัพธ์คือ "3fa8aca8a6463fa8b4" ซึ่งในจำนวนนั้น "u00d6 "ไม่มีอักขระที่สอดคล้องกันใน "GBK" ดังนั้นเราจึงได้ "3f", "u00ec" ตรงกับ "a8ac", "u00e9" ตรงกับ "a8a6" และ "0046" ตรงกับ "46" (เนื่องจากนี่คืออักขระ ASCII ) ไม่พบ "u00bb" และได้รับ "3f" ในที่สุด "u00f9" ก็สอดคล้องกับ "a8b4" พิมพ์สตริงนี้และผลลัพธ์คือ "?ìéF?ù" คุณเห็นสิ่งนั้นไหม? ไม่ใช่เครื่องหมายคำถามทั้งหมดที่นี่ เนื่องจากเนื้อหาที่แมประหว่าง GBK และ Unicode มีอักขระนอกเหนือจากอักขระภาษาจีน ตัวอย่างนี้เป็นข้อพิสูจน์ที่ดีที่สุด

ดังนั้น เมื่อแปลงรหัสตัวอักษรจีน หากเกิดความสับสน คุณอาจไม่จำเป็นต้องได้รับเครื่องหมายคำถาม! อย่างไรก็ตาม ความผิดพลาดก็คือความผิดพลาด ไม่มีความแตกต่างเชิงคุณภาพระหว่าง 50 ขั้นตอนและ 100 ขั้นตอน

หรือคุณอาจถามว่า: จะเกิดอะไรขึ้นหากรวมอยู่ในชุดอักขระต้นฉบับแต่ไม่อยู่ใน Unicode? คำตอบคือฉันไม่รู้ เพราะฉันไม่มีชุดอักขระต้นฉบับที่จะทำการทดสอบนี้ แต่มีสิ่งหนึ่งที่แน่นอน นั่นคือ ชุดอักขระต้นฉบับไม่ได้มาตรฐานเพียงพอ ใน Java หากสิ่งนี้เกิดขึ้น ข้อยกเว้นจะถูกส่งออกไป

UTF คืออะไร

UTF เป็นตัวย่อของ Unicode Text Format ซึ่งหมายถึงรูปแบบข้อความ Unicode สำหรับ UTF จะมีการกำหนดไว้ดังนี้:

(1) หาก 9 บิตแรกของอักขระ Unicode 16 บิตเป็น 0 ก็จะถูกแทนด้วยไบต์ บิตแรกของไบต์นี้คือ "0" และส่วนที่เหลืออีก 7 บิต เหมือนกับอักขระดั้งเดิม ตัวเลข 7 หลักสุดท้ายเหมือนกัน เช่น "u0034" (0000 0000 0011 0100) แสดงด้วย "34" (0011 0100) (เหมือนกับอักขระ Unicode ต้นฉบับ

) 2) หากอักขระ 16 บิต 5 ตัวแรกของ Unicode หากบิตเป็น 0 จะแสดงด้วย 2 ไบต์ ไบต์แรกเริ่มต้นด้วย "110" และ 5 บิตต่อไปนี้จะเหมือนกับ 5 บิตสูงสุดของแหล่งที่มา อักขระหลังจากไม่รวมศูนย์ 5 ตัวแรก ไบต์ที่สองเริ่มต้นด้วย "10" ที่จุดเริ่มต้น 6 บิตถัดไปจะเหมือนกับ 6 บิตล่างในอักขระต้นทาง ตัวอย่างเช่น "u025d" (0000 0010 0101 1101) จะถูกแปลงเป็น "c99d" (1100 1001 1001 1101)

(3) หากไม่เป็นไปตามกฎสองข้อข้างต้น ก็จะแสดงเป็นสามไบต์ ไบต์แรกเริ่มต้นด้วย "1110" และสี่บิตสุดท้ายคือสี่บิตสูงของอักขระต้นทาง ไบต์ที่สองเริ่มต้นด้วย "10" และหกบิตสุดท้ายคือหกบิตตรงกลางของอักขระต้นทาง ไบต์เริ่มต้นด้วย "10" ตัวเลขหกหลักสุดท้ายคือตัวเลขหกหลักล่างของอักขระต้นทาง เช่น "u9da7" (1001 1101 1010 0111) จะถูกแปลงเป็น "e9b6a7" (1110 1001 1011 0110 1010 0111)

ความแตกต่างระหว่าง Unicode และ Unicode ในโปรแกรม JAVA สามารถอธิบายได้เช่นนี้ ความสัมพันธ์ระหว่าง UTF ไม่แน่นอน: เมื่อสตริงทำงานในหน่วยความจำ จะปรากฏเป็นโค้ด Unicode และเมื่อบันทึกลงในไฟล์ หรือสื่ออื่นๆ จะใช้ UTF กระบวนการแปลงนี้เสร็จสมบูรณ์โดย writeUTF และ readUTF

เอาล่ะ การสนทนาพื้นฐานใกล้จะเสร็จสิ้นแล้ว เรามาเข้าประเด็นกันดีกว่า

ขั้นแรกให้คิดถึงปัญหาเหมือนกล่องดำ ก่อนอื่น มาดูการแสดงระดับแรกของกล่องดำกันก่อน:

input(charsetA)->process(Unicode)->output(charsetB)

นั้นเรียบง่าย นี่คือโมเดล IPO นั่นคือ อินพุต การประมวลผล และเอาต์พุต เนื้อหาเดียวกันจะต้องถูกแปลงจาก charsetA เป็น unicode จากนั้นเป็น charsetB

มาดูการแสดงรอง:

SourceFile(jsp,java)->class->output

ในรูปนี้ จะเห็นได้ว่าอินพุตเป็นไฟล์ต้นฉบับ jsp และ java ในระหว่างการประมวลผล ไฟล์ Class จะถูกใช้เป็นพาหะ แล้วส่งออก จากนั้นปรับแต่งเป็นระดับที่สาม:

jsp->temp file->class->browser,os console,db

app,servlet->class->browser,os console,

db ไฟล์ Jsp จะสร้างไฟล์ Java ระดับกลางก่อน จากนั้นจึงสร้าง Class เซิร์ฟเล็ตและแอปทั่วไปได้รับการคอมไพล์โดยตรงเพื่อสร้างคลาส จากนั้น ส่งออกจาก Class ไปยังเบราว์เซอร์ คอนโซล หรือฐานข้อมูล ฯลฯ

JSP: กระบวนการจากไฟล์ต้นฉบับไปจนถึงคลาส

ไฟล์ต้นฉบับของ Jsp เป็นไฟล์ข้อความที่ลงท้ายด้วย ".jsp" ในส่วนนี้ จะอธิบายกระบวนการตีความและรวบรวมไฟล์ JSP และจะติดตามการเปลี่ยนแปลงภาษาจีน

1. เครื่องมือการแปลง JSP (jspc) จัดทำโดยเอ็นจิ้น JSP/Servlet จะค้นหาชุดอักขระที่ระบุใน <%@ page contentType ="text/html; charset=<Jsp-charset>"%> ในไฟล์ JSP หากไม่ได้ระบุ <Jsp-charset> ในไฟล์ JSP ระบบจะใช้ file.encoding การตั้งค่าเริ่มต้นใน JVM ภายใต้สถานการณ์ปกติ ค่านี้คือ ISO8859-1;

jspc จะใช้ค่าเทียบเท่ากับ "javac –encoding <Jsp -charset> " คำสั่งตีความอักขระทั้งหมดที่ปรากฏในไฟล์ JSP รวมถึงอักขระจีนและอักขระ ASCII จากนั้นแปลงอักขระเหล่านี้เป็นอักขระ Unicode จากนั้นแปลงเป็นรูปแบบ UTF และบันทึกเป็นไฟล์ JAVA เมื่อแปลงอักขระ ASCII เป็นอักขระ Unicode คุณเพียงเพิ่ม "00" ไว้ข้างหน้า เช่น "A" ซึ่งจะถูกแปลงเป็น "u0041" (ไม่จำเป็นต้องมีเหตุผล นี่คือวิธีการรวบรวมตารางโค้ด Unicode) จากนั้นหลังจากแปลงเป็น UTF ก็เปลี่ยนกลับเป็น "41"! นี่คือเหตุผลที่คุณสามารถใช้โปรแกรมแก้ไขข้อความธรรมดาเพื่อดูไฟล์ JAVA ที่สร้างโดย JSP

3. เอ็นจิ้นใช้คำสั่งที่เทียบเท่ากับ "javac -encoding UNICODE" เพื่อรวบรวมไฟล์ JAVA ให้เป็นไฟล์ CLASS

ก่อนดูตัวอักษรจีนใน สถานการณ์การแปลงกระบวนการเหล่านี้ มีซอร์สโค้ดต่อไปนี้:

<%@ page contentType="text/html; charset=gb2312"%>
<html><ร่างกาย>
-
สตริง a="จีน";
out.println(ก);
-
</body></html>

โค้ดนี้เขียนบน UltraEdit สำหรับ Windows หลังจากบันทึก การเข้ารหัสเลขฐานสิบหกของอักขระสองตัว "จีน" คือ "D6 D0 CE C4" (การเข้ารหัส GB2312) หลังจากค้นหาตารางแล้ว การเข้ารหัส Unicode ของคำว่า "ภาษาจีน" คือ "u4E2Du6587" ซึ่งใน UTF คือ "E4 B8 AD E6 96 87" เปิดไฟล์ JAVA ที่แปลงจากไฟล์ JSP ที่สร้างโดยเอ็นจิ้น และพบว่าคำว่า "ภาษาจีน" ถูกแทนที่ด้วย "E4 B8 AD E6 96 87" จากนั้นตรวจสอบไฟล์ CLASS ที่สร้างโดยการคอมไพล์ไฟล์ JAVA แล้วค้นหา ผลลัพธ์จะเหมือนกับทุกประการเหมือนกับในไฟล์ JAVA

มาดูสถานการณ์ที่ CharSet ที่ระบุใน JSP คือ ISO-8859-1

<%@ หน้า contentType="text/html; charset=ISO-8859-1"%>
<html><ร่างกาย>
-
สตริง a="จีน";
out.println(ก);
-
</body></html>

ในทำนองเดียวกัน ไฟล์นี้เขียนด้วย UltraEdit และอักขระสองตัว "ภาษาจีน" จะถูกจัดเก็บเป็นการเข้ารหัส GB2312 "D6 D0 CE C4" ขั้นแรกให้จำลองกระบวนการสร้างไฟล์ JAVA และไฟล์ CLASS: jspc ใช้ ISO-8859-1 เพื่อตีความ "ภาษาจีน" และแมปกับ Unicode เนื่องจาก ISO-8859-1 เป็นแบบ 8 บิตและเป็นภาษาละติน กฎการแมปคือการเพิ่ม "00" ก่อนแต่ละไบต์ ดังนั้นการเข้ารหัส Unicode ที่แมปควรเป็น "u00D6u00D0u00CEu00C4" หลังจากแปลงเป็น UTF ควรเป็น "C3 96 C3 90 C3 8E C3 84" โอเค เปิดไฟล์แล้วลองดู ในไฟล์ JAVA และไฟล์ CLASS จริงๆ แล้ว "ภาษาจีน" จะแสดงเป็น "C3 96 C3 90 C3 8E C3 84"

หากไม่ได้ระบุ <Jsp-charset> ในโค้ดด้านบน นั่นคือ บรรทัดแรกเขียนเป็น "<%@ page contentType="text/html" %>" JSPC จะใช้การตั้งค่า file.encoding เพื่อตีความ ไฟล์ JSP บน RedHat 6.2 ผลลัพธ์การประมวลผลจะเหมือนกับการระบุ ISO-8859-1 ทุกประการ

จนถึงขณะนี้ กระบวนการแมปของอักขระภาษาจีนในกระบวนการแปลงจากไฟล์ JSP เป็นไฟล์ CLASS ได้รับการอธิบายแล้ว ในคำ: จาก "JspCharSet ถึง Unicode ถึง UTF" ตารางต่อไปนี้สรุปกระบวนการนี้:

ตารางที่ 2 กระบวนการแปลง "ภาษาจีน" จาก JSP เป็น CLASS

Servlet: กระบวนการจากไฟล์ต้นฉบับไปจนถึงคลาส

ไฟล์ต้นฉบับของ Servlet เป็นไฟล์ข้อความที่ลงท้ายด้วย ".java" ส่วนนี้จะกล่าวถึงกระบวนการคอมไพล์ Servlet และติดตามการเปลี่ยนแปลงภาษาจีน

ใช้ "javac" เพื่อรวบรวมไฟล์ต้นฉบับของ Servlet javac สามารถใช้พารามิเตอร์ "-encoding <Compile-charset>" ซึ่งหมายความว่า "ใช้การเข้ารหัสที่ระบุใน <Compile-charset> เพื่อตีความไฟล์ต้นฉบับ Serlvet"

เมื่อไฟล์ต้นฉบับถูกคอมไพล์ ให้ใช้ <Compile-charset> เพื่อแปลอักขระทั้งหมด รวมถึงอักขระจีนและอักขระ ASCII จากนั้นแปลงค่าคงที่อักขระเป็นอักขระ Unicode และสุดท้ายแปลง Unicode เป็น UTF

ใน Servlet มีอีกที่หนึ่งสำหรับตั้งค่า CharSet ของสตรีมเอาท์พุต โดยปกติก่อนที่จะส่งออกผลลัพธ์ เมธอด setContentType ของ HttpServletResponse จะถูกเรียกเพื่อให้ได้ผลเช่นเดียวกับการตั้งค่า <Jsp-charset> ใน JSP ซึ่งเรียกว่า <Servlet-charset>

โปรดทราบว่ามีการกล่าวถึงตัวแปรทั้งหมดสามตัวในบทความ: <Jsp-charset>, <Compile-charset> และ <Servlet-charset> ในบรรดาไฟล์เหล่านั้น ไฟล์ JSP เกี่ยวข้องกับ <Jsp-charset> เท่านั้น ในขณะที่ <Compile-charset> และ <Servlet-charset> เกี่ยวข้องกับ Servlet เท่านั้น

ดูตัวอย่างต่อไปนี้:

import javax.servlet.*;

import

javax.servlet.http.*;

-
โมฆะสาธารณะ doGet (คำขอ HttpServletRequest, การตอบสนอง HttpServletResponse)
พ่น ServletException,java.io.IOException
-
resp.setContentType("text/html; charset=GB2312");
java.io.PrintWriter ออก=resp.getWriter();
out.println("<html>");
out.println("#中文#");
out.println("</html>");
-
}

ไฟล์นี้เขียนด้วย UltraEdit สำหรับ Windows และอักขระสองตัว "ภาษาจีน" จะถูกบันทึกเป็น "D6 D0 CE C4" (การเข้ารหัส GB2312)

เริ่มเรียบเรียง. ตารางต่อไปนี้แสดงรหัสเลขฐานสิบหกของคำว่า "ภาษาจีน" ในไฟล์ CLASS เมื่อ <Compile-charset> แตกต่างกัน ในระหว่างการคอมไพล์ <Servlet-charset> ไม่มีผลกระทบ <Servlet-charset> ส่งผลต่อเอาต์พุตของไฟล์ CLASS เท่านั้น ที่จริงแล้ว <Servlet-charset> และ <Compile-charset> ทำงานร่วมกันเพื่อให้ได้เอฟเฟกต์แบบเดียวกับ <Jsp-charset> ในไฟล์ JSP เพราะ <Jsp- ชุดอักขระ > มันจะมีผลกระทบต่อการคอมไพล์และเอาต์พุตของไฟล์ CLASS

ตารางที่ 3 กระบวนการแปลง "ภาษาจีน" จากไฟล์ต้นฉบับ Servlet เป็นคลาส