==================================
Bei der Entwicklung von Java-Anwendungen kommt es sehr häufig vor, dass Unicode derzeit nicht weit verbreitet ist. In einem System, das gb2312 (einschließlich gbk vereinfacht und big5 traditionell) verwendet,
ist dies die grundlegendste Voraussetzung für die korrekte Implementierung von chinesischer Anzeige Datenbankspeicher.
==============================
1. Zunächst muss der Entwickler verstehen, warum er auf verstümmelten Code stößt und auf welche Art von verstümmeltem Code er stößt (bedeutungslose Symbole, eine Reihe von Fragezeichen oder etwas anderes).
Anfänger sind normalerweise ratlos, wenn sie auf eine Reihe unordentlicher Zeichen stoßen. Die direkteste Reaktion besteht darin, Google zu öffnen, nach „Java-Chinesisch“ zu suchen (diese Zeichenfolge wird häufig in Suchmaschinen abgefragt)
und sich dann nacheinander die Zeichen anderer Personen anzusehen eine. Lösung. Daran ist nichts auszusetzen, aber aus den unten genannten Gründen ist es schwierig, das Ziel zu erreichen.
Kurz gesagt, es gibt viele Gründe für verstümmelte Zeichen und die Lösungen sind völlig unterschiedlich. Um das Problem zu lösen, müssen Sie zunächst Ihren eigenen „Kontext“ analysieren.
============================
2. Welche Informationen werden insbesondere benötigt, um die Quelle des verstümmelten Codes im Projekt zu ermitteln?
a. Das vom Entwickler verwendete Betriebssystem
b, der Name und die Version des j2ee-Containers
c, Datenbankname, Version (genaue Version) und JDBC-Treiberversion
d. Der Quellcode ist verstümmelt (er stammt beispielsweise aus dem System oder befindet sich auf einer JSP-Seite. Wenn er sich auf einer JSP-Seite befindet, ist auch die Header-Deklaration sehr wichtig)
========== === ===========================================
3. Wie man zunächst die Ursachen für verstümmelte Zeichen analysiert.
Mit den oben genannten Informationen können Sie grundsätzlich um Hilfe bitten, wenn Sie sie in Foren wie Javaworld veröffentlichen, werden Experten bald effektive Lösungen für Sie finden.
Natürlich können Sie sich nicht immer darauf verlassen, dass Ihnen durch einen Beitrag geholfen wird, aber Sie sollten auch versuchen, das Problem selbst zu lösen. Wie fange ich an?
a. Analysieren Sie, welche Codierung Ihr „verstümmelter Code“ hat. Das ist zum Beispiel eigentlich nicht schwierig
System.out.println(testString);
Da in diesem Absatz verstümmelter Code vorhanden ist, können Sie genauso gut die erschöpfende Methode verwenden, um das tatsächliche Codierungsformat zu erraten.
System.out.println(new String(testString.getBytes(“ISO-8859-1″),”gb2312″));
System.out.println(new String(testString.getBytes(“UTF8″),”gb2312″));
System.out.println(new String(testString.getBytes(“GB2312″),”gb2312″));
System.out.println(new String(testString.getBytes("GBK"),"gb2312"));
System.out.println(new String(testString.getBytes("BIG5"),"gb2312"));
Warten Sie, der obige Code bedeutet, das angegebene Codierungsformat zu verwenden, um den „verstümmelten Code“ von testString zu lesen und in gb2312 zu konvertieren (hier wird nur Chinesisch als Beispiel verwendet).
Dann sehen Sie, welches konvertierte Ergebnis in Ordnung ist, das war's. . .
b. Wenn Sie mit den oben genannten Schritten das richtige Chinesisch erhalten, bedeutet das, dass Ihre Daten zwar vorhanden sind, aber in der Benutzeroberfläche einfach nicht korrekt angezeigt werden. Dann ist der zweite Schritt die Korrektur Ihres Ansichtsteils
. Normalerweise muss überprüft werden, ob in der JSP die richtige Seitenkodierung ausgewählt ist.
Ich möchte auf etwas hinweisen, das von vielen Menschen missverstanden wurde, nämlich die Direktive <%@ page contentType="text/html; charset=GB2312″ %> und <META http-equiv=Content-Type
content="text /html; charset= gb2312″>Der Unterschied zwischen den beiden. Wenn viele Artikel im Internet chinesische Probleme erwähnen, heißt es normalerweise, dass die Auswahl von Unicode- oder GB2312-Speicher in der Datenbank
durch die Verwendung
der Seitenanweisung in JSP zum Deklarieren der Codierung gelöst werden kann .Aber ich halte diese Aussage für sehr unverantwortlich und habe dazu geführt, dass ich viel Zeit damit verbracht habe, über verstümmelte Codes deprimiert zu sein, die überhaupt nicht existierten. Tatsächlich
besteht die Rolle der Seite darin, eine Codierungsmethode für Java bereitzustellen, um den String im Ausdruck während des Kompilierungsprozesses von JSP in HTML zu „lesen“ (etwas ähnlich der Rolle der dritten Anweisung oben) und die
Rolle von Meta ist bekannt dafür, Codierungsoptionen für IE-Browser bereitzustellen, die zum „Anzeigen“ der endgültigen Daten verwendet werden. Aber ich habe niemanden gesehen, der mich daran erinnert hat. Ich habe die Seite immer als Meta verwendet,
was dazu führte, dass die Daten, die ursprünglich iso-8859 waren, vom Seitenbefehl als gb2312 gelesen wurden, sodass sie verstümmelt waren, also habe ich eine Codierung hinzugefügt Konvertierungsfunktion zum Konvertieren aller String-Daten. Sie haben sich alle von iso8859 in gb2312 geändert (
warum
ich es so geändert habe, darüber habe ich damals nicht so viel nachgedacht, weil es normal angezeigt werden kann, also habe ich es so geändert, haha , ich hatte damals wirklich keine Zeit, das Problem langsam zu beheben.=============================================== =============
4. Welche Kodierung ist für die Datenbank besser?
Zu den derzeit beliebten Datenbanken gehören hauptsächlich SQL Server, MySQL, Oracle, DB2 usw. Unter diesen ist MySQL der Spitzenreiter unter den kostenlosen Datenbanken. Seine Leistung und Funktionen sind relativ einfach zu installieren und zu konfigurieren, und der
entsprechende
Treiber ist ebenfalls relativ Komplett. Das Preis-/Leistungsverhältnis ist absolutok. Nehmen Sie also MySQL als Beispiel.
Ich persönlich empfehle die Verwendung der Standardkodierung von MySQL für die Speicherung, nämlich ISO-8859-1 (entspricht Latin-1 in den MySQL-Optionen). Dafür gibt es mehrere Hauptgründe: Erstens bietet ISO-8859-1 eine gute Unterstützung für
Chinesisch
. Zweitens stimmt es mit der Standardkodierung in Java überein, was zumindest die Probleme bei der Konvertierung der Kodierung an vielen Stellen beseitigt Stabil und kompatibelist auch die Stabilität, da
bestimmte DB-Produkte Multi-Codierung unterstützen, ganz zu schweigen von der Inkompatibilität mit anderen DBs, selbst bei unterschiedlichen Versionen kann es zu Kompatibilitätsproblemen kommen.
In Produkten vor MySQL 4.0 verwenden beispielsweise viele chinesische Lösungen das Feld „characterEncoding“ in der Verbindung, um die Codierung festzulegen, z. B. gb2312 oder etwas Ähnliches. Dies ist in Ordnung,
da die Originaldaten ISO8859_1-codiert sind und der JDBC-Treiber die angegebene verwendet in der URL wird der Zeichensatz zur Codierung verwendet und resultSet.getString(*) entnimmt die codierte
Zeichenfolge. Auf diese Weise können Sie die Daten von gb2312 direkt abrufen.
Der Start von MySQL 4.1 hat jedoch vielen Datenbankadministratoren große Probleme bereitet, da MySQL 4.1 den Zeichensatz auf Spaltenebene unterstützt.
Wenn nicht angegeben, ist es ISO8895_1, also entfernt JDBC Daten werden auf der Grundlage des Zeichensatzes für die Codierung verwendet, anstatt einen globalen Parameter zum Abrufen aller Daten zu verwenden.
Dies zeigt auch unter einem anderen Aspekt, dass das Problem der verstümmelten Zeichen wirklich kompliziert ist und zu viele Gründe hat. Ich biete nur einige Lösungen für die tatsächliche Situation an, auf die ich gestoßen bin. Wenn es
Fehler
gibt, senden Sie bitte eine E-Mail an [email protected] . Ich hoffe, mehr Artikel des Meisters zu sehen, anstatt eine Menge falscher Kopien.
Nur für den internen Gebrauch.
Bei Fragen wenden Sie sich bitte an [email protected]
=============================================== ==============
Endlich die perfekteste Lösung für das chinesische Problem gefunden. . . Vielen Dank an den Autor dieses Online-Artikels. . .
Mein ursprünglicher Artikel basiert auf meiner eigenen Erfahrung. Obwohl nichts falsch war, konnte die eigentliche Ursache des Problems nie gefunden werden. Nachdem ich diesen Artikel gelesen hatte, wurde mir plötzlich klar, haha,
———————————————————————————————————————————— ———— ——————-
Da das chinesische Problem in der Java-Programmierung ein alltägliches Problem ist, stellte ich nach dem Lesen vieler Lösungen für chinesische Java-Probleme in Kombination mit der Programmierpraxis des Autors fest, dass viele der in der Vergangenheit besprochenen Methoden dies nicht klar erklären können Problem und Lösung des Problems, insbesondere des chinesischen Problems, wenn es plattformübergreifend ist.
Deshalb habe ich diesen Artikel veröffentlicht, der meine Analyse und Lösungsvorschläge für chinesische Probleme in Klassen, Servelets, JSP- und EJB-Klassen enthält, die auf der Konsole ausgeführt werden. Ich hoffe, Sie können mir einen Rat geben.
Zusammenfassung: Dieser Artikel analysiert den Kodierungs-/Dekodierungsprozess von Java-Quelldateien durch den Java-Compiler und Klassendateien durch die JVM in der Java-Programmierung. Durch die Analyse dieses Prozesses wird schließlich die Ursache für chinesische Probleme in der Java-Programmierung aufgedeckt gegeben Die vorgeschlagene optimale Methode zur Lösung chinesischer Java-Probleme.
1. Die Ursache des chinesischen Problems
: Die vom ursprünglichen Betriebssystem des Computers unterstützte Kodierung war die Einzelbyte-Zeichenkodierung. Daher wurden alle Verarbeitungsprogramme im Computer zunächst in Englisch mit Einzelbyte-Kodierung verarbeitet.
Mit der Entwicklung von Computern wurde zur Anpassung an die Sprachen anderer Nationen der Welt (einschließlich natürlich unserer chinesischen Schriftzeichen) die UNICODE-Kodierung vorgeschlagen, die Doppelbyte-Kodierung verwendet und mit englischen Schriftzeichen kompatibel ist und Doppelbyte-Zeichenkodierungen anderer Nationen. Daher verwendet die meiste internationale Software intern die UNICODE-Kodierung. Wenn die Software ausgeführt wird, erhält sie standardmäßig das vom lokalen Unterstützungssystem (meistens das Betriebssystem) unterstützte Kodierungsformat ) und konvertiert dann den UNICODE innerhalb der Software in das vom lokalen System standardmäßig unterstützte Format.
Dies ist bei Javas JDK und JVM der Fall. Das JDK, von dem ich hier spreche, bezieht sich auf die internationale Version des JDK. Die meisten unserer Programmierer verwenden die internationalisierte JDK-Version. Unsere chinesischen Schriftzeichen sind eine Doppelbyte-Kodierungssprache. Damit Computer Chinesisch verarbeiten können, haben wir unsere eigenen Standards wie gb2312, GBK und GBK2K entwickelt, um den Anforderungen der Computerverarbeitung gerecht zu werden.
Um uns an unsere Anforderungen an die Verarbeitung von Chinesisch anzupassen, verfügen die meisten Betriebssysteme über angepasste chinesische Betriebssysteme. Sie verwenden die Kodierungsformate GBK und GB2312, um unsere chinesischen Schriftzeichen korrekt anzuzeigen. Beispiel: Chinesisches Windows verwendet standardmäßig GBK-Kodierung für die Anzeige. Beim Speichern von Dateien in chinesischem Windows 2000 wird standardmäßig auch GBK zum Speichern von Dateien verwendet. Das heißt, die interne Kodierung aller in chinesischem Windows 2000 gespeicherten Dateien verwendet GBK Kodierung standardmäßig. Hinweis: GBK wird auf Basis von GB2312 erweitert.
Da die Java-Sprache intern die UNICODE-Codierung verwendet, besteht beim Ausführen des Java-Programms ein Problem bei der Konvertierung der Eingabe und Ausgabe aus der UNICODE-Codierung und dem entsprechenden vom Betriebssystem und Browser unterstützten Codierungsformat. Dieser Konvertierungsprozess umfasst eine Reihe von Schritten. Wenn in einem der Schritte ein Fehler auftritt, werden die angezeigten chinesischen Zeichen verstümmelt. Dies ist unser häufiges Java-Chinesischproblem.
Gleichzeitig ist Java eine plattformübergreifende Programmiersprache, was bedeutet, dass die von uns geschriebenen Programme nicht nur auf chinesischen Windows-Systemen, sondern auch auf chinesischen Linux-Systemen und anderen Systemen ausgeführt werden können. Wir sehen oft, dass jemand ein auf chinesischem Windows 2000 geschriebenes Java-Programm transplantiert hat, um es auf englischem Linux auszuführen. Diese Transplantationsoperation wird auch chinesische Probleme mit sich bringen.
Einige Leute verwenden außerdem englische Betriebssysteme und englische Browser wie den IE, um Programme mit chinesischen Schriftzeichen auszuführen und chinesische Webseiten zu durchsuchen. Sie unterstützen Chinesisch selbst nicht und verursachen auch Probleme mit Chinesisch.
Fast alle Browser übergeben Parameter standardmäßig im UTF-8-Kodierungsformat anstelle der chinesischen Kodierung. Daher kommt es auch bei der Übergabe chinesischer Parameter zu Problemen, was zu verstümmelten Zeichen führt.
Kurz gesagt, die oben genannten Aspekte sind die Hauptursachen für chinesische Probleme in Java. Wir nennen die Probleme, die dadurch verursacht werden, dass das Programm aus den oben genannten Gründen nicht ordnungsgemäß ausgeführt wird: Java-chinesische Probleme.
2. Detaillierter Prozess der Java-Codierungskonvertierung.
Unsere gängigen Java-Programme umfassen die folgenden Kategorien:
*Klassen, die direkt auf der Konsole ausgeführt werden (einschließlich visueller Schnittstellenklassen)
*JSP-Codeklassen (Hinweis: JSP ist eine Variante der Servlets-Klasse)
*Servelets Klasse
* EJB-Klasse
* Andere unterstützende Klassen, die nicht direkt ausgeführt werden können.
Diese Klassendateien enthalten möglicherweise chinesische Zeichenfolgen. Wir verwenden häufig die ersten drei Arten von Java-Programmen, um direkt mit Benutzern für Ausgabe- und Eingabezeichen zu interagieren, z. B.: Wir verwenden JSP und Das Servlet ruft die vom Client gesendeten Zeichen ab, und diese Zeichen umfassen auch chinesische Zeichen. Unabhängig von der Rolle dieser Java-Klassen sieht der Lebenszyklus dieser Java-Programme wie folgt aus:
* Programmierer wählen eine geeignete Bearbeitungssoftware auf einem bestimmten Betriebssystem aus, um den Quellprogrammcode zu implementieren und ihn mit der Erweiterung .Java im Betriebssystem zu speichern Beispielsweise verwenden wir Notepad, um ein Java-Quellprogramm in Chinesisch Windows 2000 zu bearbeiten.
*Programmierer verwenden Javac.exe im JDK, um diese Quellcodes zu kompilieren, um .class-Klassen zu bilden (JSP-Dateien werden vom Container kompiliert, der JDK aufruft).
*Führen Sie diese Klassen direkt aus oder stellen Sie sie im WEB-Container bereit, um die Ergebnisse auszuführen und auszugeben.
Wie kodieren, dekodieren und führen JDK und JVM diese Dateien während dieser Prozesse aus?
Hier nehmen wir das chinesische Betriebssystem Windows 2000 als Beispiel, um zu veranschaulichen, wie Java-Klassen kodiert und dekodiert werden.
Der erste Schritt besteht darin, mit Bearbeitungssoftware wie Notepad eine Java-Quellprogrammdatei (einschließlich der oben genannten fünf Arten von Java-Programmen) in chinesischem Windows 2000 zu schreiben. Beim Speichern der Programmdatei verwendet die Programmdatei das von unterstützte GBK-Codierungsformat Standardmäßig wird das Betriebssystem vom Betriebssystem unterstützt (das Format ist file.encoding). Es wird eine .Java-Datei erstellt, das heißt, bevor das Java-Programm kompiliert wird, wird unsere Java-Quellprogrammdatei in der Datei file.encoding gespeichert Das vom Betriebssystem standardmäßig unterstützte Kodierungsformat enthält chinesische Informationszeichen und englische Programmcodes. Sie können den folgenden Code verwenden:
öffentliche Klasse ShowSystemDefaultEncoding
{
public static void main(String[] args)
{
String-Kodierung =
System.getProperty("file.encoding");
System.out.println(encoding);
}
}
Im zweiten Schritt verwenden wir die Datei Javac.exe von JDK, um unser Java-Quellprogramm zu kompilieren. Da es sich bei JDK um eine internationale Version handelt, verwenden wir beim Kompilieren nicht den Parameter -encoding, um das Codierungsformat unserer Java-Quelle anzugeben Wenn wir ein Java-Programm kompilieren und das Codierungsformat der Quellprogrammdatei nicht angeben, erhält JDK zunächst den Parameter file.encoding B. Windows2000, sein Wert ist GBK), und dann konvertiert JDK unser Java-Quellprogramm vom Dateikodierungsformat file.encoding in das interne Standard-UNICODE-Format von Java und legt es im Speicher ab.
Dann kompiliert Javac die konvertierte Unicode-Formatdatei in eine .class-Klassendatei. Zu diesem Zeitpunkt wird die .class-Datei UNICODE-codiert und dann vorübergehend im Speicher abgelegt wird in unserem Betriebssystem gespeichert, um die .class-Datei zu bilden, die wir sehen.
Für uns ist die .class-Datei, die wir schließlich erhalten haben, eine Klassendatei, deren Inhalt im UNICODE-Codierungsformat gespeichert ist. Sie enthält die chinesische Zeichenfolge in unserem Quellprogramm, wurde jedoch zu diesem Zeitpunkt über das file.encoding-Format in das UNICODE-Format konvertiert. .
In diesem Schritt ist die JSP-Quellprogrammdatei wie folgt: Das heißt, der JSP-Compiler prüft zunächst, ob das Dateicodierungsformat in der JSP-Datei festgelegt ist Die JSP-Datei enthält kein Dateicodierungsformat. Um das Codierungsformat der JSP-Datei festzulegen, ruft der JSP-Compiler JDK auf, um die JSP-Datei zunächst unter Verwendung des Standardzeichencodierungsformats der JVM (d. h. der Standardeinstellung) in eine temporäre Servlet-Klasse zu konvertieren (Dateikodierung des Betriebssystems, auf dem sich der WEB-Container befindet) und dann wird es in eine UNICODE-Formatklasse kompiliert und in einem temporären Ordner gespeichert.
Beispiel: Unter chinesischem Windows 2000 konvertiert der WEB-Container die JSP-Datei vom GBK-Codierungsformat in das UNICODE-Format und kompiliert sie dann in eine vorübergehend gespeicherte Servlet-Klasse, um auf die Anfrage des Benutzers zu reagieren.
Der dritte Schritt besteht darin, die im zweiten Schritt kompilierte Klasse auszuführen, die in drei Situationen unterteilt ist:
A. Klassen, die direkt auf der Konsole ausgeführt werden.
B. EJB-Klassen und Unterstützungsklassen, die nicht direkt ausgeführt werden können (z. B. JavaBean-Klassen).
C. JSP-Code und Servlet-Klassen.
D. Zwischen Java-Programmen und Datenbanken.
Schauen wir uns die folgenden vier Situationen an.
A. Im Fall einer Klasse, die direkt auf der Konsole ausgeführt wird
, erfordert die Ausführung dieser Klasse zunächst JVM-Unterstützung, d. h. JRE muss im Betriebssystem installiert sein. Der laufende Prozess ist wie folgt: Zuerst startet Java die JVM. Zu diesem Zeitpunkt liest die JVM die im Betriebssystem gespeicherte Klassendatei und liest den Inhalt in den Speicher. Zu diesem Zeitpunkt ist der Speicher eine Klasse im UNICODE-Format. und dann führt die JVM sie aus. Wenn diese Klasse zu diesem Zeitpunkt Benutzereingaben empfangen muss, verwendet die Klasse standardmäßig das Codierungsformat file.encoding, um die vom Benutzer eingegebenen Zeichenfolgen zu codieren, in Unicode zu konvertieren und im Speicher zu speichern (Der Benutzer kann das Codierungsformat des Eingabestreams festlegen).
Nachdem das Programm ausgeführt wurde, wird die generierte Zeichenfolge (UNICODE-codiert) an die JVM zurückgegeben. Schließlich konvertiert die JRE die Zeichenfolge in das Dateicodierungsformat (der Benutzer kann das Codierungsformat des Ausgabestreams festlegen) und übergibt sie an das Betriebssystem Anzeigeschnittstelle und gibt sie an die Schnittstelle aus. Jeder der oben genannten Konvertierungsschritte erfordert eine korrekte Konvertierung des Codierungsformats, damit am Ende keine verstümmelten Zeichen angezeigt werden. B. EJB-Klassen und Unterstützungsklassen, die nicht direkt ausgeführt werden können (z. B. JavaBean-Klassen)
, da EJB-Klassen und Unterstützungsklassen im Allgemeinen nicht direkt mit Benutzern für die Eingabe und Ausgabe interagieren. Sie interagieren häufig mit anderen Klassen für die Eingabe und Ausgabe, sodass sie nach der Kompilierung im zweiten Schritt eine Klasse bilden, deren Inhalt UNICODE-kodiert ist, und die im Betriebssystem gespeichert werden, solange die Interaktion zwischen ihr und anderen Klassen nicht erfolgt Wenn ein Parameter während der Parameterübergabe verloren geht, wird er ordnungsgemäß ausgeführt.
C.
Nach dem zweiten Schritt des JSP-Codes und der Servlet-Klasse wird die JSP-Datei ebenfalls in eine Servlets-Klassendatei konvertiert, sie ist jedoch nicht wie die Standard-Servlets im temporären Verzeichnis des WEB-Containers vorhanden , also betrachten wir es in diesem Schritt auch als Servlets.
Bei Servlets ruft der WEB-Container seine JVM auf, um das Servlet auszuführen. Zuerst liest die JVM die Servlet-Klasse aus dem System und lädt sie in den Speicher UNICODE. Wenn das Servlet ausgeführt wird, muss es Zeichen vom Client akzeptieren, z. B. die im Formular eingegebenen Werte und die in der URL übergebenen Werte Zeit, wenn das Programm nicht auf „Akzeptieren“ eingestellt ist Wenn das Codierungsformat als Parameter verwendet wird, verwendet der WEB-Container standardmäßig das ISO-8859-1-Codierungsformat, um den eingehenden Wert zu akzeptieren und ihn in der JVM in das UNICODE-Format zu konvertieren Speichern Sie es im Speicher des WEB-Containers.
Nachdem das Servlet ausgeführt wurde, generiert es eine Ausgabe und die Ausgabezeichenfolge liegt im UNICODE-Format vor. Anschließend sendet der Container die von der Servlet-Ausführung generierte Zeichenfolge im UNICODE-Format (z. B. HTML-Syntax, Benutzerausgabezeichenfolge usw.) direkt an den Client Browser und gibt es an Wenn der Benutzer zu diesem Zeitpunkt beim Senden das Codierungsformat für die Ausgabe angibt, wird es im angegebenen Codierungsformat an den Browser ausgegeben. Wenn nicht angegeben, wird es im ISO-8859-Format an den Browser des Kunden gesendet. 1 Kodierung standardmäßig.
D. Zwischen Java-Programm und Datenbank
Für fast alle Datenbank-JDBC-Treiber ist das Standardcodierungsformat für die Datenübertragung zwischen Java-Programm und Datenbank ISO-8859-1. Daher überträgt unser Programm Daten in die Datenbank Im Programm konvertiert JDBC zunächst die Daten im UNICODE-Kodierungsformat innerhalb des Programms in das ISO-8859-1-Format und übergibt sie dann an die Datenbank. Wenn die Datenbank die Daten speichert, wird standardmäßig ISO-8859-1 gespeichert. Aus diesem Grund sind die chinesischen Daten, die wir oft in der Datenbank auslesen, verstümmelt.
3. Mehrere Prinzipien, die bei der Analyse häufiger Java-Chinesisch-Probleme verstanden werden müssen
. Nach der obigen detaillierten Analyse können wir zunächst deutlich erkennen, dass der Schlüsselprozess der Codierungskonvertierung im Lebenszyklus jedes Java-Programms darin besteht, zunächst in eine Klasse zu kompilieren Datei Die Ausgabe der Transkodierung und des endgültigen Transkodierungsprozesses an den Benutzer.
Zweitens müssen wir verstehen, dass die folgenden häufig verwendeten Kodierungsformate, die von Java zur Kompilierungszeit unterstützt werden, sind:
*ISO-8859-1, 8-Bit, dasselbe wie 8859_1, ISO-8859-1, ISO_8859_1 und andere Kodierungen
*Cp1252, amerikanisch Englische Kodierung, das gleiche wie die ANSI-Standardkodierung
*UTF-8, das gleiche wie die Unicode-Kodierung
*GB2312, das gleiche wie gb2312-80, gb2312-1980 und andere Kodierungen
*GBK, das gleiche wie MS936, es ist eine Erweiterung von gb2312 und andere Kodierungen wie Koreanisch, Japanisch, traditionelles Chinesisch usw. . Gleichzeitig sollten wir auf die Kompatibilitätsbeziehung zwischen diesen Codierungen wie folgt achten:
Unicode und UTF-8-Codierung weisen eine Eins-zu-Eins-Entsprechung auf. GB2312 kann als Teilmenge von GBK betrachtet werden, das heißt, die GBK-Codierung wird auf gb2312 erweitert. Gleichzeitig enthält die GBK-Kodierung 20902 chinesische Zeichen und der Kodierungsbereich ist: 0×8140-0xfefe. Alle Zeichen können eins zu eins auf UNICODE2.0 abgebildet werden.
Drittens können wir für die im Betriebssystem abgelegte .Java-Quellprogrammdatei während der Kompilierung das Codierungsformat ihres Inhalts angeben, insbesondere mithilfe von -encoding. Hinweis: Wenn das Quellprogramm chinesische Zeichen enthält und Sie -encoding verwenden, um andere Kodierungszeichen anzugeben, tritt offensichtlich ein Fehler auf.
Verwenden Sie -encoding, um die Kodierungsmethode der Quelldatei als GBK oder gb2312 anzugeben, unabhängig davon, auf welchem System wir das Java-Quellprogramm mit chinesischen Zeichen kompilieren, es wird kein Problem geben, Chinesisch in UNICODE zu konvertieren und im zu speichern Klassendatei.
Dann müssen wir uns darüber im Klaren sein, dass das Standard-Zeichenkodierungsformat fast aller WEB-Container ISO-8859-1 als Standardwert verwendet. Gleichzeitig verwenden fast alle Browser standardmäßig UTF-8, wenn sie Parameter übergeben .
Obwohl unsere Java-Quelldatei beim Ein- und Ausstieg die richtige Codierungsmethode angibt, wird sie daher bei der Ausführung im Container immer noch als ISO-8859-1 verarbeitet.
4. Klassifizierung chinesischer Probleme und ihre empfohlenen optimalen Lösungen
Nachdem wir die oben genannten Prinzipien der Java-Dateiverarbeitung verstanden haben, können wir eine Reihe optimaler Lösungsvorschläge für chinesische Schriftzeichenprobleme vorschlagen. Unser Ziel ist: Die von uns im chinesischen System bearbeiteten Java-Quellprogramme, die chinesische Zeichenfolgen oder chinesische Verarbeitungen enthalten, können nach der Kompilierung auf jedes andere Betriebssystem migriert werden, um ordnungsgemäß ausgeführt zu werden, oder sie können in anderen Betriebssystemen korrekt ausgeführt werden Übergeben Sie chinesische und englische Parameter und können Sie chinesische und englische Zeichenfolgen korrekt mit der Datenbank kommunizieren. Unsere konkrete Idee besteht darin, die Codierungsmethode einzuschränken, um sie am Eingang und Ausgang der Java-Programmtranscodierung und an der Stelle, an der das Java-Programm eine Eingabe- und Ausgabekonvertierung mit dem Benutzer durchführt, korrekt zu machen.
Die spezifischen Lösungen lauten wie folgt:
1. Für Klassen, die direkt auf der Konsole ausgeführt werden
. In diesem Fall empfehlen wir, dass Sie beim Schreiben eines Programms Eingaben vom Benutzer erhalten müssen, die möglicherweise Chinesisch enthalten, oder Ausgaben, die möglicherweise Chinesisch enthalten. Das Programm sollte Zeichenströme verwenden, um die Eingabe und Ausgabe zu verarbeiten. Insbesondere werden die folgenden zeichenorientierten Knotenstromtypen angewendet:
Für Dateien: FileReader, FileWrieter,
seine byteorientierten Knotenstromtypen sind: FileInputStream, FileOutputStream
Für Speicher (Array). ): CharArrayReader,
CharArrayWriter Die Knoten-Stream-Typen sind: ByteArrayInputStream, ByteArrayOutputStream.
Pipes
:
PipedReader,PipedWriter
.
Es sollten orientierte Verarbeitungsströme verwendet werden:
BufferedWriter, BufferedReader,
seine Byte-Verarbeitungsströme sind: BufferedInputeStream, BufferedOutputStream
InputStreamReader, OutputStreamWriter,
seine Byte-Verarbeitungsströme sind: DataInputStream,
DataOutputStream Byte-Stream gemäß dem angegebenen Zeichencodierungssatz, z. B.:
InputStreamReader in = new InputStreamReader(System.in, "GB2312"); Beispiel: Die folgende Beispiel-Java-Codierung kann die Anforderungen erfüllen:
//Read.Java
import Java.io.*;
öffentliche Klasse Lesen
{
public static void main(String[] args)
wirft eine IOException aus
{
String str =
„nChinesischer Test, dies ist die interne fest codierte Zeichenfolge „+“ntest englisches Zeichen“;
String string = "";
BufferedReader stdin =
neuer BufferedReader(neu
InputStreamReader(System.in,“gb2312″));
//Stellen Sie die Eingabeschnittstelle so ein, dass sie auf Chinesisch codiert wird
BufferedWriter stdout =
neuer BufferedWriter(neu
OutputStreamWriter(System.out,“gb2312″));
//Stellen Sie die Ausgabeschnittstelle so ein, dass sie auf Chinesisch codiert wird
stdout.write("Bitte eingeben:");
stdout.flush();
strin = stdin.readLine();
stdout.write("Dies ist die vom Benutzer eingegebene Zeichenfolge:"+strin);
stdout.write(str);
stdout.flush();
}}
Gleichzeitig verwenden wir beim Kompilieren des Programms die folgende Methode:
Javac -encoding gb2312 Read.Java
2. Für EJB-Klassen und Unterstützungsklassen, die nicht direkt ausgeführt werden können (z. B. die JavaBean-Klasse),
da diese Klassen selbst werden von anderen Klassen verwendet Der Aufruf interagiert nicht direkt mit dem Benutzer. Daher empfehlen wir für diesen Typ die Verarbeitungsmethode, dass das interne Programm Zeichenströme verwenden sollte, um die chinesischen Zeichenfolgen innerhalb des Programms zu verarbeiten (insbesondere wie im obigen Abschnitt). und gleichzeitig beim Kompilieren der Klasse den Parameter -encoding gb2312 verwenden, um anzugeben, dass die Quelldatei im chinesischen Format codiert ist.
3. Für die Servlet-Klasse
empfehlen wir die folgende Methode:
Verwenden Sie beim Kompilieren des Quellprogramms der Servlet-Klasse -encoding, um die Codierung als GBK oder GB2312 anzugeben, und verwenden Sie den setContentType ("text" des Antwortobjekts in der Codierung Teil bei der Ausgabe an den Benutzer /html;charset=GBK“); oder gb2312, um das Ausgabecodierungsformat festzulegen. In ähnlicher Weise verwenden wir request.setCharacterEncoding(“GB2312“); Unsere Servlet-Klasse wird nur auf den Client übertragen. Wenn Ihr Browser die chinesische Anzeige unterstützt, wird sie korrekt angezeigt. Hier ist ein korrektes Beispiel:
//HelloWorld.Java
Paket hallo;
import Java.io.*;
import Javax.servlet.*;
import Javax.servlet.http.*;
öffentliche Klasse HelloWorld
erweitert HttpServlet
{
public void init()
löst eine ServletException aus
{
}
öffentliche Leere doGet
(HttpServletRequest-Anfrage,
HttpServletResponse-Antwort)
löst IOException, ServletException aus
{
request.setCharacterEncoding("GB2312");
//Eingabekodierungsformat festlegen
Antwort.setContentType
("text/html;charset=GB2312");
//Legen Sie das Ausgabekodierungsformat fest
PrintWriter out = Response.getWriter();
//Es wird empfohlen, die PrintWriter-Ausgabe zu verwenden
out.println(“<hr>“);
out.println("Hallo Welt!
Dies wird von Servlet!Test Chinese erstellt!");
out.println(“<hr>“);
}
public void doPost(HttpServletRequest request,
HttpServletResponse-Antwort)
löst IOException, ServletException aus
{
request.setCharacterEncoding("GB2312");
//Eingabekodierungsformat festlegen
Antwort.setContentType
("text/html;charset=GB2312");
//Legen Sie das Ausgabekodierungsformat fest
String name = request.getParameter("name");
String id = request.getParameter("id");
if(name==null) name="";
if(id==null) id="";
PrintWriter out = Response.getWriter();
//Es wird empfohlen, die PrintWriter-Ausgabe zu verwenden
out.println(“<hr>“);
out.println("Die von Ihnen übergebene chinesische Zeichenfolge lautet: " + Name);
out.println("<hr>Die von Ihnen eingegebene ID lautet: " + id);
out.println(“<hr>“);
}
öffentliche Leere zerstören()
{
}
}
Bitte verwenden Sie Javac -encoding gb2312 HelloWorld.Java, um dieses Programm zu kompilieren.
Das Programm zum Testen dieses Servlets lautet wie folgt:
< %@page contentType="text/html;
charset=gb2312″%>
<%request.setCharacterEncoding("GB2312");%>
<html><head><title></title>
<Skriptsprache="JavaScript">
Funktion Submit()
{
// Übergeben Sie den chinesischen Zeichenfolgenwert über die URL an das Servlet
document.base.action =
"./HelloWorld?name=中文";
document.base.method = „POST“;
document.base.submit();
}
</Script>
</head>
<body bgcolor=“#FFFFFF“
text=“#000000″ topmargin=“5″>
<form name="base" method =
„POST“ target=“_self“>
<Eingabename="id" type="text"
value=““ size=“30″>
<a href = „JavaScript:Submit()“>
An Servlet übergeben</a>
</form></body></html>
4.
Um verstümmelte Daten bei der Datenübertragung zwischen dem Java-Programm und der Datenbank zu vermeiden, empfehlen wir die folgenden optimalen Methoden zur Verarbeitung:
1. Das Java-Programm sollte gemäß der von uns angegebenen Methode verarbeitet werden.
2. Ändern Sie das von der Datenbank standardmäßig unterstützte Kodierungsformat in GBK oder GB2312.
Beispiel: In MySQL können wir die folgende Anweisung zur Konfigurationsdatei my.ini hinzufügen, um dies zu erreichen:
add:default-character-set=gbk
im Bereich [mysqld]
und hinzufügen:
[client]
default-character-set=gbk
In SQL Server2K können wir die Standardsprache der Datenbank auf vereinfachtes Chinesisch festlegen, um den Zweck zu erreichen.
5. Da JSP für JSP-Code
zur Laufzeit dynamisch vom WEB-Container kompiliert wird, erhält der JSP-Compiler den file.encoding-Wert des Serverbetriebssystems, um ihn zu kompilieren, wenn wir das Codierungsformat der JSP-Quelldatei nicht angeben Ja, es ist am wahrscheinlichsten, dass es beim Transplantieren zu Problemen kommt. Beispielsweise funktioniert eine JSP-Datei, die unter chinesischem Windows 2000 gut läuft, nicht unter englischem Linux. Das liegt daran, dass der Container identisch ist Die JSP-Datei wird beim Kompilieren durch unterschiedliche Codierungen der Betriebssysteme verursacht (file.encoding auf Chinesisch unterscheidet sich von file.encoding auf Englisch unter Linux, und file.encoding auf Englisch unterstützt Linux kein Chinesisch, daher wird es Probleme mit dem geben kompilierte JSP-Klasse).
Die meisten im Internet diskutierten Probleme sind solche Probleme, vor allem weil die JSP-Datei beim Transplantieren auf die Plattform nicht korrekt angezeigt werden kann. Für diese Art von Problem verstehen wir das Prinzip der Programmkodierungskonvertierung in Java, und es ist viel einfacher löse es. Unsere Lösungsvorschläge lauten wie folgt:
1. Wir müssen sicherstellen, dass die JSP bei der Ausgabe an den Client in chinesischer Kodierung ausgegeben wird. Das heißt, egal was passiert, wir fügen zuerst die folgende Zeile zu unserem JSP-Quellcode hinzu:
< %@page contentType =“ text/html;
charset=gb2312″%>
2. Damit JSP die eingehenden Parameter korrekt abrufen kann, fügen wir den folgenden Satz zum JSP-Quelldatei-Header hinzu:
<%request.setCharacterEncoding(”GB2312″);
%>
3. Damit der JSP -Compiler unsere JSP -Dateien mit chinesischen Zeichen korrekt dekodieren, müssen wir das Codierungsformat unserer JSP -Quelldateien in den JSP -Quelldateien angeben. Quelldateien im JSP -Quelldateiheader
.
Oder < %@ pageSencoding = "gbk" %>
Dies ist eine neu hinzugefügte Anweisung in der JSP -Spezifikation 2.0.
Wir empfehlen diese Methode, um chinesische Probleme in JSP -Dateien zu lösen
.
< %@ pageCoding = ”GB2312 ″ %>
< %@page contentType = "text/html;
charSet = gb2312 ″%>
<%request.setcharacterencoding ("gb2312");
%>
<%
String action = request.getParameter ("action");
String name = "";
String str = "";
if (action! = null && action.equals ("gesendet"))
{
name = request.getParameter ("Name");
str = request.getParameter ("str");
}
%>
<html>
<Kopf>
<title></title>
<Script Language = "JavaScript">
Funktion subjekt ()
{
document.base.action =
"? Action = gesendet & str = eingehender Chinesisch";
document.base.method = "post";
document.base.submit ();
}
</Script>
</head>
<Body Bgcolor = "#ffffff"
text = "#000000" Topmargin = ”5 ″>
<form name = "base" -Methode =
"Post" target = "_ self”>
<Eingabe type = "text" name = "Name"
value = ”” size = ”30 ″>
<a href = "javaScript: subjekt ()"> subine </a>
</form>
<%
if (action! = null && action.equals ("gesendet"))
{
out.println ("<br> Die von Ihnen eingegebenen Zeichen sind:"+Name);
out.println ("<br> Die Charaktere, die Sie durch die URL übergeben haben, sind:"+str);
}
%>
</body>
</html>