تحليل متعمق لمعالجة JSP وServlet للغة الصينية

كل منطقة في العالم لها لغتها المحلية الخاصة. تؤدي الاختلافات الإقليمية بشكل مباشر إلى اختلافات في البيئة اللغوية. في عملية تطوير برنامج دولي، من المهم التعامل مع قضايا اللغة.

هذه مشكلة موجودة في جميع أنحاء العالم، لذلك توفر Java حلاً عالميًا. الطريقة الموضحة في هذه المقالة مخصصة لمعالجة اللغة الصينية، ولكنها تنطبق أيضًا على معالجة اللغات من بلدان ومناطق أخرى في العالم.

الأحرف الصينية مزدوجة البايت. ويعني ما يسمى بالبايت المزدوج أن الكلمة المزدوجة تشغل موضعين من BYTE (أي 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" ("؟"). هذا هو المكان الذي يأتي من "؟"

على سبيل المثال: قم بإجراء عملية String(buf, "gb2312") الجديدة على تدفق الأحرف buf = "0x80 0x40 0xb0 0xa1"، وستكون النتيجة "ufffdu554a"، ثم قم بطباعتها، وستكون النتيجة " ?ah"، لأن "0x80 0x40" هو حرف في GBK، وليس في GB2312.

للحصول على مثال آخر، قم بإجراء عملية String الجديدة (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، وهو ما يعني تنسيق نص Unicode. بالنسبة لـ UTF، يتم تعريفه على النحو التالي:

(1) إذا كانت أول 9 بتات من حرف Unicode 16 بت هي 0، فسيتم تمثيلها بواسطة بايت. أول بت من هذا البايت هو "0"، والبتات السبعة المتبقية هي نفس الحرف الأصلي. الأرقام السبعة الأخيرة هي نفسها، مثل "u0034" (0000 0000 0011 0100)، ويمثلها "34" (0011 0100)

؛ 2) إذا كانت أول 5 أحرف من 16 بت في Unicode إذا كانت البتة 0، فسيتم تمثيلها بـ 2 بايت، ويبدأ البايت الأول بـ "110"، والبتات الخمس التالية هي نفس أعلى 5 بتات من المصدر. الحرف بعد استبعاد الأصفار الخمسة الأولى؛ يبدأ البايت الثاني بـ "10" في البداية، تكون البتات الستة التالية هي نفس البتات الستة السفلية في الحرف المصدر. على سبيل المثال، سيتم تحويل "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.

حسنًا، لقد انتهت المناقشة الأساسية تقريبًا، فلننتقل إلى صلب الموضوع.

فكر أولاً في المشكلة باعتبارها صندوقًا أسود. دعونا نلقي نظرة أولاً على تمثيل المستوى الأول للصندوق الأسود:

الإدخال (charsetA) -> العملية (Unicode) -> الإخراج (charsetB)

بسيط. هذا هو نموذج الاكتتاب العام، أي الإدخال والمعالجة والإخراج. يجب تحويل نفس المحتوى من 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. يتم تجميع Servlets والتطبيقات العادية مباشرة لإنشاء Class. ثم، قم بالإخراج من الفصل إلى المتصفح أو وحدة التحكم أو قاعدة البيانات، وما إلى ذلك.

JSP: العملية من الملف المصدر إلى Class

الملف المصدر لـ Jsp هو ملف نصي ينتهي بـ ".jsp". في هذا القسم، سيتم شرح عملية تفسير وتجميع ملفات JSP، وسيتم تتبع التغييرات الصينية.

1. تبحث أداة تحويل JSP (jspc) التي يوفرها محرك JSP/Servlet عن مجموعة الأحرف المحددة في <%@ page contentType ="text/html; charset=<Jsp-charset>"%> في ملف JSP. إذا لم يتم تحديد <Jsp-charset> في ملف JSP، فسيتم استخدام الإعداد الافتراضي file.encoding في JVM، في ظل الظروف العادية، تكون هذه القيمة هي ISO8859-1.

2. يستخدم jspc ما يعادل "javac –encoding <Jsp يقوم الأمر -charset> " بتفسير جميع الأحرف التي تظهر في ملف JSP، بما في ذلك الأحرف الصينية وأحرف ASCII، ثم يقوم بتحويل هذه الأحرف إلى أحرف Unicode، ثم يحولها إلى تنسيق UTF، ويحفظها كملفات JAVA. عند تحويل أحرف ASCII إلى أحرف Unicode، ما عليك سوى إضافة "00" في المقدمة، مثل "A"، والذي يتم تحويله إلى "u0041" (لا توجد حاجة إلى سبب، هذه هي الطريقة التي يتم بها تجميع جدول رموز Unicode). وبعد التحويل إلى UTF، تغير مرة أخرى إلى "41"! هذا هو السبب في أنه يمكنك استخدام محرر نص عادي لعرض ملفات JAVA التي تم إنشاؤها بواسطة JSP؛

المحرك

الأمر المكافئ لـ "javac -encoding UNICODE" لتجميع ملفات JAVA في ملفات CLASS؛

حالة تحويل هذه العمليات. يوجد الكود المصدري التالي:

<%@ page contentType="text/html; charset=gb2312"%>
<html><الجسم>
<%
سلسلة = "الصينية"؛
println(a);
%>
</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.

<%@ page contentType="text/html; charset=ISO-8859-1"%>
<html><الجسم>
<%
سلسلة = "الصينية"؛
println(a);
%>
</body></html>

وبالمثل، هذا الملف مكتوب باستخدام UltraEdit، ويتم أيضًا تخزين الحرفين "Chinese" بترميز 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 لتفسير ملف جي اس بي. في RedHat 6.2، تكون نتيجة المعالجة مماثلة تمامًا لتحديد ISO-8859-1.

حتى الآن، تم شرح عملية تعيين الأحرف الصينية في عملية التحويل من ملفات JSP إلى ملفات CLASS. باختصار: من "JspCharSet إلى Unicode إلى UTF". يلخص الجدول التالي هذه العملية:

جدول 2 عملية التحويل "الصينية" من JSP إلى CLASS

Servlet: العملية من الملف المصدر إلى Class.

ملف 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 req، HttpServletResponse resp)
يلقي ServletException،java.io.IOException
{
resp.setContentType("text/html; charset=GB2312");
java.io.PrintWriter out=resp.getWriter();
println("<html>");
println("#中文#");
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- charset > سيكون له تأثير على تجميع وإخراج ملفات CLASS.

الجدول 3: عملية تحويل "الصينية" من ملف مصدر Servlet إلى Class