Ich teste die Kompatibilität meiner Anwendung mit i18n. Ich habe eine englische Version von Windows 7, was bedeutet, dass die Anzeigesprache des Systems Englisch ist. Und ich habe das Systemgebietsschema für Nicht-Unicode-Anwendungen als Chinesisch festgelegt.
Meine Anwendung hat beim Exportieren von HTML-Dateien mit chinesischem Zeichen unter jdk1.6 Probleme festgestellt, funktioniert aber unter jdk1.7 einwandfrei.
Ich habe es ausgepackt und festgestellt, dass der direkte Grund dafür war, dass Charset.defaultCharset() unterschiedliche Werte zurückgegeben hat.
Unter jdk1.7 Charset.defaultCharset() gab GBK zurück, was der Zeichensatz für Chinesisch ist.
Unter jdk1.6 Charset.defaultCharset() hat window_1252 zurückgegeben, welches Zeichensatz für lateinische Sprache ist.
Ich weiß, dass das Problem gelöst werden kann, indem Sie charset, sagen wir utf-8 , im Code angeben.
Aber ich möchte wissen, warum Charset.defaultCharset() unterschiedliche Werte unter JDK1.7 und JDK 1.6 zurückgibt.
Charset.defaultCharset() gibt den Zeichensatz von JVM an, so dass es nicht immer den gleichen Wert hat. Wenn Sie beispielsweise Ihre Programme mit Netbeans ausführen, wird immer UTF-8 zurückgegeben, da dies die Standardcodierung für Java-Projekte in Netbeans ist.
Ich habe eine ähnliche Konfiguration wie deine. Mein Windows ist Englisch (Menüs, Dialoge sind Englisch) und ich verwende Türkisch für Nicht-Unicode-Anwendungen. Wenn ich JVM ohne Flag oder Systemparameter starte, geben Java 7 und Java 6 Laufzeiten "CP1254", wenn Charset.defaultCharset() aufgerufen wird. System.getProperty("file.encoding") und Standard-IO-Codierung sind ebenfalls identisch. (Das Gebietsschema des Systems ist in diesen beiden Java-Versionen anders, aber das ist eine andere Geschichte.)
Ich schätze, Ihr Problem besteht entweder darin, wie Sie Ihre JVM starten, oder darauf, wie JVM entscheidet, die Standardcodierung zu verwenden, die es verwenden soll. Wenn Sie sicher sind, dass das Problem nicht das vorherige Problem ist (Sie führen JVM ohne Codierungsparameter aus, und Sie versuchen nicht, den Standardzeichensatz an einer beliebigen Stelle in Ihrem Programm zu ändern), ruft JVM die Standardcodierung fälschlicherweise ab.
Der technische Java 7 sagt:
Die unterstützten Kodierungen variieren zwischen verschiedenen Implementierungen der Java-Plattform, Standard Edition 7 (Java SE 7).
Das Charset-Dokument lautet:
Jede Instanz der Java Virtual Machine hat einen Standardzeichensatz, Das kann oder darf nicht einer der Standard-Zeichensatz sein. Der Standard charset wird beim Start der virtuellen Maschine und in der Regel bestimmt hängt davon ab, welches Gebietsschema und welcher Zeichensatz vom Basiswert verwendet werden Betriebssystem.
Außerdem habe ich einen "Fehler" gefunden, der -Dfile.encoding verwendet Abschlussbewertung:
Dies ist kein Fehler. Die Eigenschaft "file.encoding" wird nicht benötigt die J2SE-Plattformspezifikation; Es ist ein inneres Detail von Suns Implementierungen und sollte nicht durch Benutzercode überprüft oder geändert werden. Es soll auch schreibgeschützt sein; es ist technisch unmöglich unterstützt das Setzen dieser Eigenschaft auf beliebige Werte auf der Befehlszeile oder zu jeder anderen Zeit während der Programmausführung.
Die bevorzugte Methode zum Ändern der Standardcodierung, die von der VM und Das Laufzeitsystem soll das Gebietsschema der zugrunde liegenden Plattform ändern bevor Sie Ihr Java-Programm starten.
Tags und Links java windows-7 character-encoding encoding internationalization