Eingehende Analyse der JSP- und Servlet-Verarbeitung von Chinesisch

Jede Region der Welt hat ihre eigene Landessprache. Regionale Unterschiede führen direkt zu Unterschieden im Sprachumfeld. Bei der Entwicklung eines internationalen Programms ist es wichtig, sich mit Sprachproblemen auseinanderzusetzen.

Da es sich hierbei um ein weltweit bestehendes Problem handelt, bietet Java eine weltweite Lösung. Die in diesem Artikel beschriebene Methode dient der Verarbeitung von Chinesisch, ist aber darüber hinaus auch auf die Verarbeitung von Sprachen aus anderen Ländern und Regionen der Welt anwendbar.

Chinesische Schriftzeichen sind Doppelbyte-Schriftzeichen. Das sogenannte Doppelbyte bedeutet, dass ein Doppelwort zwei BYTE-Positionen (also 16 Bit) einnimmt, die als High-Bits bzw. Low-Bits bezeichnet werden. Die in China festgelegte chinesische Zeichenkodierung ist GB2312, was derzeit obligatorisch ist. Derzeit unterstützen fast alle Anwendungen, die Chinesisch verarbeiten können, GB2312. GB2312 umfasst chinesische Zeichen der ersten und zweiten Ebene sowie 9 Bereichssymbole. Die hohen Bits reichen von 0xa1 bis 0xfe, und die niedrigen Bits reichen ebenfalls von 0xa1 bis 0xfe.

Es gibt eine andere Kodierung namens GBK, aber dies ist eine Spezifikation und nicht obligatorisch. GBK bietet 20902 chinesische Zeichen, die mit GB2312 kompatibel sind, und der Codierungsbereich liegt zwischen 0x8140 und 0xfefe. Alle Zeichen in GBK können einzeln auf Unicode 2.0 abgebildet werden.

In naher Zukunft wird China einen weiteren Standard veröffentlichen: GB18030-2000 (GBK2K). Es umfasst die Schriftarten tibetischer, mongolischer und anderer ethnischer Minderheiten und löst damit grundlegend das Problem unzureichender Zeichenpositionen. Hinweis: Es handelt sich nicht mehr um eine feste Länge. Der Zwei-Byte-Teil ist mit GBK kompatibel und der Vier-Byte-Teil besteht aus erweiterten Zeichen und Glyphen. Sein erstes und drittes Byte reichen von 0x81 bis 0xfe und sein zweites und viertes Byte reichen von 0x30 bis 0x39.

Dieser Artikel beabsichtigt nicht, Unicode vorzustellen. Interessierte können „http://www.unicode.org/“ durchsuchen, um weitere Informationen anzuzeigen. Unicode hat eine Besonderheit: Es umfasst alle Zeichenglyphen der Welt. Daher können Sprachen in verschiedenen Regionen Zuordnungsbeziehungen mit Unicode herstellen, und Java nutzt dies, um eine Konvertierung zwischen heterogenen Sprachen zu erreichen.

Im JDK sind die auf Chinesisch bezogenen Kodierungen wie folgt:

Tabelle 1 Liste der auf Chinesisch bezogenen Kodierungen im JDK

in der Praxis nur wenige JDKs unterstützt. Beim Programmieren komme ich eher mit GB2312 (GBK) und ISO8859-1 in Berührung.

Warum gibt es ein „?“-Zeichen.

Wie oben erwähnt, erfolgt die Konvertierung zwischen verschiedenen Sprachen über Unicode. Angenommen, es gibt zwei verschiedene Sprachen A und B. Die Konvertierungsschritte lauten: Konvertieren Sie zuerst A in Unicode und dann Unicode in B.

Nennen Sie Beispiele. In GB2312 gibt es ein chinesisches Zeichen „李“ und sein Code lautet „C0EE“, der in ISO8859-1-Code konvertiert werden muss. Die Schritte sind: Konvertieren Sie zuerst das Zeichen „李“ in Unicode, um „674E“ zu erhalten, und konvertieren Sie dann „674E“ in ISO8859-1-Zeichen. Diese Zuordnung wird natürlich nicht gelingen, da es in ISO8859-1 kein Zeichen gibt, das „674E“ entspricht.

Das Problem tritt auf, wenn die Zuordnung nicht erfolgreich ist! Wenn bei der Konvertierung von einer bestimmten Sprache in Unicode das Zeichen in einer bestimmten Sprache nicht vorhanden ist, ist das Ergebnis der Unicode-Code „uffffd“ („u“ bedeutet Unicode-Kodierung). Wenn bei der Konvertierung von Unicode in eine bestimmte Sprache eine bestimmte Sprache keine entsprechenden Zeichen hat, erhalten Sie „0x3f“ („?“). Daher kommt das „?“.

Beispiel: Führen Sie die neue String(buf, „gb2312“)-Operation für den Zeichenstrom buf = „0x80 0x40 0xb0 0xa1“ aus. Das Ergebnis lautet „ufffdu554a“. Drucken Sie es dann aus. Das Ergebnis lautet „ ?ah“, weil „0x80 0x40“ ein Zeichen in GBK ist, nicht in GB2312.

Führen Sie als weiteres Beispiel die neue String-Operation (buf.getBytes("GBK")) für die Zeichenfolge String="u00d6u00ecu00e9u0046u00bbu00f9" aus. Das Ergebnis ist "3fa8aca8a6463fa8b4", darunter: „u00d6 „Es gibt kein entsprechendes Zeichen in „GBK“, also erhalten wir „3f“, „u00ec“ entspricht „a8ac“, „u00e9“ entspricht „a8a6“ und „0046“ entspricht „46“ (da es sich um ein ASCII-Zeichen handelt), wurde „u00b“ nicht gefunden und „3f“ wurde erhalten. Schließlich entspricht „u00f9“ „a8b4“. Drucken Sie diese Zeichenfolge aus und das Ergebnis ist „?ìéF?ù“. Hast du das gesehen? Es sind hier nicht nur Fragezeichen, denn der zwischen GBK und Unicode abgebildete Inhalt umfasst neben chinesischen Schriftzeichen auch andere Zeichen. Dieses Beispiel ist der beste Beweis.

Daher kann es bei der Transkodierung chinesischer Schriftzeichen nicht zwangsläufig zu Fragezeichen kommen, wenn es zu Verwirrung kommt! Allerdings ist ein Fehler letztlich ein Fehler. Es gibt keinen qualitativen Unterschied zwischen 50 Schritten und 100 Schritten.

Oder Sie fragen sich vielleicht: Was wird das Ergebnis sein, wenn es im Quellzeichensatz, aber nicht in Unicode enthalten ist? Die Antwort ist: Ich weiß es nicht. Weil ich den Quellzeichensatz für diesen Test nicht zur Hand habe. Eines ist jedoch sicher: Der Quellzeichensatz ist nicht ausreichend standardisiert. In Java wird in diesem Fall eine Ausnahme ausgelöst.

Was ist UTF?

UTF ist die Abkürzung für Unicode Text Format, was Unicode-Textformat bedeutet. Für UTF ist es wie folgt definiert:

(1) Wenn die ersten 9 Bits eines Unicode-16-Bit-Zeichens 0 sind, wird es durch ein Byte dargestellt. Das erste Bit dieses Bytes ist „0“ und die restlichen 7 Bits

gleichen

wie das Originalzeichen, z. B. „u0034“ (0000 0000 0011 0100), dargestellt durch „34“ (0011 0100);

2) Wenn die ersten 5 der 16-Bit-Zeichen von Unicode 0 sind, werden sie durch 2 Bytes dargestellt. Das erste Byte beginnt mit „110“ und die folgenden 5 Bits sind mit den höchsten 5 Bits der Quelle identisch Zeichen nach Ausschluss der ersten 5 Nullen; das zweite Byte beginnt mit „10“. Zu Beginn sind die nächsten 6 Bits dieselben wie die unteren 6 Bits im Quellzeichen. Beispielsweise wird „u025d“ (0000 0010 0101 1101) in „c99d“ (1100 1001 1001 1101) konvertiert.

(3) Wenn es die beiden oben genannten Regeln nicht erfüllt, wird es durch drei Bytes dargestellt. Das erste Byte beginnt mit „1110“ und die letzten vier Bits sind die oberen vier Bits des Quellzeichens; das zweite Byte beginnt mit „10“ und die letzten sechs Bits sind die mittleren sechs Bits des Quellzeichens; Byte beginnt mit „10“. Die letzten sechs Ziffern sind die unteren sechs Ziffern des Quellzeichens. Beispielsweise wird „u9da7“ (1001 1101 1010 0111) in „e9b6a7“ (1110 1001 1011) umgewandelt 0110 1010 0111);

der Unterschied zwischen Unicode und Unicode in JAVA-Programmen kann wie folgt beschrieben werden: Die Beziehung zwischen UTF ist nicht absolut: Wenn eine Zeichenfolge im Speicher ausgeführt wird, erscheint sie als Unicode-Code, und wenn sie in einer Datei gespeichert wird oder anderen Medien wird UTF verwendet. Dieser Konvertierungsprozess wird durch writeUTF und readUTF abgeschlossen.

Okay, die grundsätzliche Diskussion ist fast abgeschlossen, kommen wir zur Sache.

Stellen Sie sich das Problem zunächst als eine Blackbox vor. Schauen wir uns zunächst die Darstellung der Blackbox auf der ersten Ebene an:

Eingabe (Zeichensatz A) -> Prozess (Unicode) -> Ausgabe (Zeichensatz B)

ist ein einfaches IPO-Modell, dh Eingabe, Verarbeitung und Ausgabe. Derselbe Inhalt muss von ZeichensatzA in Unicode und dann in ZeichensatzB konvertiert werden.

Schauen wir uns die sekundäre Darstellung an:

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

In dieser Abbildung ist zu sehen, dass es sich bei der Eingabe um JSP- und Java-Quelldateien handelt. Während der Verarbeitung wird die Klassendatei als Träger verwendet und dann ausgeben. Verfeinern Sie es dann auf die dritte Ebene:

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

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

. Die JSP-Datei generiert zunächst die Java-Zwischendatei und dann die Klasse. Servlets und gewöhnliche Apps werden direkt kompiliert, um eine Klasse zu generieren. Anschließend erfolgt die Ausgabe von der Klasse an den Browser, die Konsole oder die Datenbank usw.

JSP: Der Prozess von der Quelldatei zur Klasse

Die Quelldatei von Jsp ist eine Textdatei mit der Endung „.jsp“. In diesem Abschnitt wird der Interpretations- und Kompilierungsprozess von JSP-Dateien erläutert und die chinesischen Änderungen verfolgt.

1. Das von der JSP/Servlet-Engine bereitgestellte JSP-Konvertierungstool (jspc) sucht nach dem in <%@ page contentType ="text/html; charset=<Jsp-charset>"%> in der JSP-Datei angegebenen Zeichensatz. Wenn <Jsp-charset> nicht in der JSP-Datei angegeben ist, wird die Standardeinstellung file.encoding in der JVM verwendet. Unter normalen Umständen ist dieser Wert ISO8859-1.

jspc verwendet das Äquivalent von „javac –encoding <Jsp -charset> „Der Befehl interpretiert alle Zeichen, die in der JSP-Datei erscheinen, einschließlich chinesischer Zeichen und ASCII-Zeichen, und konvertiert diese Zeichen dann in Unicode-Zeichen, konvertiert sie dann in das UTF-Format und speichert sie als JAVA-Dateien. Bei der Konvertierung von ASCII-Zeichen in Unicode-Zeichen fügen Sie einfach „00“ voran, z. B. „A“, das in „u0041“ umgewandelt wird (es ist kein Grund erforderlich, so wird die Unicode-Codetabelle kompiliert). Dann, nach der Konvertierung in UTF, wurde es wieder auf „41“ geändert! Aus diesem Grund können Sie die von JSP 3 generierten JAVA-Dateien mit einem normalen Texteditor anzeigen.

Die Engine verwendet den Befehl „javac -encoding UNICODE“, um die JAVA-Dateien

zunächst

diese Prozesse Konvertierungssituation. Es gibt den folgenden Quellcode:

<%@ page contentType="text/html; charset=gb2312"%>
<html><body>
<%
String a="Chinesisch";
out.println(a);
%>
</body></html>

Dieser Code wurde in UltraEdit für Windows geschrieben. Nach dem Speichern lautet die hexadezimale Kodierung der beiden Zeichen „Chinesisch“ „D6 D0 CE C4“ (GB2312-Kodierung). Nach dem Nachschlagen der Tabelle lautet die Unicode-Kodierung des Wortes „Chinesisch“ „u4E2Du6587“, was in UTF „E4 B8 AD E6 96 87“ ist. Öffnen Sie die JAVA-Datei, die aus der von der Engine generierten JSP-Datei konvertiert wurde, und stellen Sie fest, dass das Wort „Chinesisch“ tatsächlich durch „E4 B8 AD E6 96 87“ ersetzt wurde. Überprüfen Sie dann die durch die JAVA-Dateikompilierung generierte CLASS-Datei und suchen Sie dass das Ergebnis dasselbe ist wie genau das gleiche wie in der JAVA-Datei.

Schauen wir uns die Situation an, in der der in JSP angegebene CharSet ISO-8859-1 ist.

<%@ page contentType="text/html; charset=ISO-8859-1"%>
<html><body>
<%
String a="Chinesisch";
out.println(a);
%>
</body></html>

Ebenso wird diese Datei mit UltraEdit geschrieben und die beiden Zeichen „Chinesisch“ werden auch als GB2312-Kodierung „D6 D0 CE C4“ gespeichert. Simulieren Sie zunächst den Prozess der Generierung von JAVA-Dateien und CLASS-Dateien: jspc interpretiert „Chinesisch“ mithilfe von ISO-8859-1 und ordnet es Unicode zu. Da ISO-8859-1 8-Bit ist und eine lateinische Sprache ist, besteht die Zuordnungsregel darin, vor jedem Byte „00“ hinzuzufügen, sodass die zugeordnete Unicode-Kodierung nach der Konvertierung in „u00D6u00D0u00CEu00C4“ lauten sollte UTF sollte es „C3 96 C3 90 C3 8E C3 84“ sein. Okay, öffnen Sie die Datei und schauen Sie nach. In der JAVA-Datei und der CLASS-Datei wird „Chinesisch“ tatsächlich als „C3 96 C3 90 C3 8E C3 84“ ausgedrückt.

Wenn <Jsp-charset> im obigen Code nicht angegeben ist, d. h. die erste Zeile wird als „<%@ page contentType="text/html" %>“ geschrieben, verwendet JSPC die Einstellung „file.encoding“, um das zu interpretieren JSP-Datei. Unter RedHat 6.2 ist das Verarbeitungsergebnis genau das gleiche wie bei der Angabe von ISO-8859-1.

Bisher wurde der Zuordnungsprozess chinesischer Schriftzeichen im Konvertierungsprozess von JSP-Dateien in CLASS-Dateien erläutert. Mit einem Wort: Von „JspCharSet über Unicode bis UTF“. Die folgende Tabelle fasst diesen Prozess zusammen:

Tabelle 2 „Chinesischer“ Konvertierungsprozess von JSP nach CLASS

Servlet: Der Prozess von der Quelldatei zur Klasse.

Die Servlet-Quelldatei ist eine Textdatei mit der Endung „.java“. In diesem Abschnitt wird der Servlet-Kompilierungsprozess erläutert und die chinesischen Änderungen verfolgt.

Verwenden Sie „javac“, um die Servlet-Quelldatei zu kompilieren. javac kann den Parameter „-encoding <Compile-charset>“ annehmen, was bedeutet: „Verwenden Sie die in <Compile-charset> angegebene Codierung, um die Serlvet-Quelldatei zu interpretieren.“

Wenn die Quelldatei kompiliert wird, verwenden Sie <Compile-charset>, um alle Zeichen zu interpretieren, einschließlich chinesischer Zeichen und ASCII-Zeichen. Konvertieren Sie dann die Zeichenkonstanten in Unicode-Zeichen und schließlich Unicode in UTF.

In Servlet gibt es eine weitere Möglichkeit, den CharSet des Ausgabestreams festzulegen. Normalerweise wird vor der Ausgabe des Ergebnisses die setContentType-Methode von HttpServletResponse aufgerufen, um den gleichen Effekt zu erzielen wie das Festlegen von <Jsp-charset> in JSP, das als <Servlet-charset> bezeichnet wird.

Beachten Sie, dass im Artikel insgesamt drei Variablen erwähnt werden: <Jsp-charset>, <Compile-charset> und <Servlet-charset>. Unter diesen beziehen sich JSP-Dateien nur auf <Jsp-charset>, während <Compile-charset> und <Servlet-charset> nur auf Servlet bezogen sind.

Schauen Sie sich das folgende Beispiel an:

import javax.servlet.*;

import

javax.servlet.http.*;

{
public void doGet(HttpServletRequest req,HttpServletResponse resp)
löst eine ServletException,java.io.IOException aus
{
resp.setContentType("text/html; charset=GB2312");
java.io.PrintWriter out=resp.getWriter();
out.println("<html>");
out.println("#中文#");
out.println("</html>");
}
}

Diese Datei wurde ebenfalls mit UltraEdit für Windows geschrieben und die beiden Zeichen „Chinesisch“ werden als „D6 D0 CE C4“ (GB2312-Kodierung) gespeichert.

Beginnen Sie mit dem Kompilieren. Die folgende Tabelle zeigt den Hexadezimalcode des Wortes „Chinese“ in der CLASS-Datei, wenn <Compile-charset> unterschiedlich ist. Während der Kompilierung hat <Servlet-charset> keine Auswirkung. <Servlet-charset> wirkt sich nur auf die Ausgabe der CLASS-Datei aus. Tatsächlich arbeiten <Servlet-charset> und <Compile-charset> zusammen, um den gleichen Effekt wie <Jsp-charset> in der JSP-Datei zu erzielen, da <Jsp- charset >Es wird Auswirkungen auf die Kompilierung und Ausgabe von CLASS-Dateien haben.

Tabelle 3 Der Transformationsprozess von „Chinesisch“ von der Servlet-Quelldatei in die Klasse