Beispielanalyse der Java-Zeichenkodierung

1. Die Java-Datei wird zu einer Klasse kompiliert

Die Kodierung der Java-Datei kann hier unterschiedlich sein, aber der Java-Compiler liest diese Kodierungen automatisch entsprechend dem Kodierungsformat der Java-Datei und generiert eine Klassendatei . Die Klasse hier Die Dateikodierung ist Unicode-Kodierung (insbesondere UTF-16-Kodierung).

Definieren Sie also eine Zeichenfolge im Java-Code:

String s="Chinesische Zeichen";

Egal welche Codierung die Java-Datei vor der Kompilierung verwendet, nach der Kompilierung in eine Klasse sind sie dieselbe --- -Unicode-Codierung Darstellung.

2. Codierung in JVM

Wenn JVM Klassendateien lädt und liest, wird die ursprünglich definierte Zeichenfolge s="Chinesische Zeichen" im Speicher ausgedrückt.

Wenn Sie String.getBytes() aufrufen, haben Sie tatsächlich die Ursache für verstümmelte Zeichen erkannt. Da diese Methode den Standardzeichensatz der Plattform verwendet, um das der Zeichenfolge entsprechende Byte-Array abzurufen. Wenn Sie die Prinzipien in der chinesischen Version von Windows nicht verstehen, führt dies leicht zu verstümmeltem Code. Daher ist es in einem System notwendig, die Codierung von Zeichenfolgen zu vereinheitlichen. Diese Vereinheitlichung wird vage als externe Vereinheitlichung bezeichnet. Beispiel: Methodenzeichenfolgenparameter, E/A-Streams. In chinesischen Systemen können Sie GBK, GB13080, UTF-8, UTF-16 usw. verwenden. Sie müssen jedoch einige größere Zeichensätze auswählen, um sicherzustellen, dass alle Zeichen verwendet werden können Alle können normal angezeigt werden, um das Problem verstümmelter Zeichen zu vermeiden. (Vorausgesetzt, dass für alle Dateien ASCII-Codes verwendet werden) Dann ist eine bidirektionale Konvertierung nicht möglich.

Es ist wichtig zu beachten, dass UTF-8 nicht alle chinesischen Zeichensatzkodierungen unterstützt. Daher kann es bei der Konvertierung von UTF-8 zu GB18030 unter bestimmten Umständen zu verstümmelten Zeichen kommen Arbeiten an chinesischen Systemen mit UTF-8-Kodierung, ohne zu erklären, warum! Das Dümmste ist, dass mehrere Leute an einem System arbeiten. Einige Leute verwenden GBK-Codierung für Quellcodedateien, andere verwenden UTF-8 und andere verwenden GB18030. FK, sie sind alle Chinesen und es ist kein Outsourcing-Projekt. Warum UTF-8 verwenden? Es ist in Ordnung, GBK18030 für alle Quellcodes zu verwenden, um eine nicht erkennbare Zeichenkodierung beim Kompilieren des ANT-Skripts zu vermeiden.

Daher ist es für das chinesische System am besten, die Kodierung GBK oder GB18030 zu wählen (tatsächlich ist GBK eine Teilmenge von GB18030), um verstümmelte Zeichen weitestgehend zu vermeiden.

3. Zeichenketten im Speicher

Zeichenketten im Speicher sind nicht nur auf Zeichenketten beschränkt, die direkt aus dem Klassencode geladen werden, sondern einige Zeichenketten werden auch aus Textdateien gelesen, andere können erstellt werden aus Byte-Arrays sind jedoch grundsätzlich nicht Unicode-codiert. Der Grund ist die einfache Speicheroptimierung.

Daher müssen vor der Verarbeitung verschiedene Kodierungsprobleme gelöst werden, die Kodierung der „Quelle“ muss klar sein und dann mithilfe der angegebenen Kodierungsmethode korrekt in den Speicher eingelesen werden. Wenn es sich um einen Methodenparameter handelt, müssen Sie tatsächlich die Codierung des String-Parameters klären, da dieser Parameter möglicherweise von einem anderen japanischen System übergeben wird. Wenn die Zeichenfolgenkodierung klar ist, kann die Zeichenfolge nach Bedarf korrekt verarbeitet werden, um verstümmelte Zeichen zu vermeiden. Beim Dekodieren und Kodieren einer Zeichenfolge sollte die folgende Methode aufgerufen werden:

public class Test {   public static void main(String[] args) {   System.out.println("当前JRE：" + System.getProperty("java.version"));   System.out.println("当前JVM的默认字符集：" + Charset.defaultCharset());   }   }

Das obige ist der detaillierte Inhalt vonBeispielanalyse der Java-Zeichenkodierung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!