Définition du codage de caractères Java par défaut

Comment définir correctement l'encodage de caractères par défaut utilisé par la JVM (1.5.x) par programme?

J'ai lu que -Dfile.encoding=whateverc'était la voie à suivre pour les anciennes machines virtuelles Java. Je n'ai pas ce luxe pour des raisons que je n'entrerai pas.

J'ai essayé:

System.setProperty("file.encoding", "UTF-8");

Et la propriété est définie, mais il ne semble pas que l' getBytesappel final ci-dessous utilise UTF8:

System.setProperty("file.encoding", "UTF-8");

byte inbytes[] = new byte[1024];

FileInputStream fis = new FileInputStream("response.txt");
fis.read(inbytes);
FileOutputStream fos = new FileOutputStream("response-2.txt");
String in = new String(inbytes, "UTF8");
fos.write(in.getBytes());

Malheureusement, la file.encodingpropriété doit être spécifiée au démarrage de la JVM; au moment où votre méthode principale est entrée, le codage de caractères utilisé par String.getBytes()et les constructeurs par défaut de InputStreamReaderet OutputStreamWritera été mis en cache en permanence.

Comme le souligne Edward Grech, dans un cas spécial comme celui-ci, la variable d'environnement JAVA_TOOL_OPTIONS peut être utilisée pour spécifier cette propriété, mais cela se fait normalement comme ceci:

java -Dfile.encoding=UTF-8 … com.x.Main

Charset.defaultCharset()reflétera les modifications apportées à la file.encodingpropriété, mais la plupart du code des bibliothèques Java de base qui doivent déterminer le codage de caractères par défaut n'utilise pas ce mécanisme.

Lorsque vous codez ou décodez, vous pouvez interroger la file.encodingpropriété ou Charset.defaultCharset()rechercher le codage par défaut actuel, et utiliser la méthode appropriée ou la surcharge du constructeur pour le spécifier.

Dans la documentation de l' interface de l'outil JVM ™ …

Étant donné que la ligne de commande n'est pas toujours accessible ou modifiable, par exemple dans les VM intégrées ou simplement les VM lancées en profondeur dans les scripts, une JAVA_TOOL_OPTIONSvariable est fournie afin que les agents puissent être lancés dans ces cas.

En définissant la variable d'environnement (Windows) JAVA_TOOL_OPTIONSsur -Dfile.encoding=UTF8, la Systempropriété (Java) sera définie automatiquement à chaque démarrage d'une machine virtuelle Java . Vous saurez que le paramètre a été récupéré car le message suivant sera envoyé à System.err:

Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8

J'ai une méthode hacky qui fonctionne vraiment !!

System.setProperty("file.encoding","UTF-8");
Field charset = Charset.class.getDeclaredField("defaultCharset");
charset.setAccessible(true);
charset.set(null,null);

De cette façon, vous allez tromper JVM qui penserait que le jeu de caractères n'est pas défini et faire en sorte qu'il soit à nouveau défini sur UTF-8, lors de l'exécution!

Je pense qu'une meilleure approche que de définir le jeu de caractères par défaut de la plate-forme, d'autant plus que vous semblez avoir des restrictions sur le déploiement d'applications, sans parler de la plate-forme, est d'appeler le plus sûr String.getBytes("charsetName"). De cette façon, votre application ne dépend pas de choses indépendantes de sa volonté.

String.getBytes()Personnellement, je pense que cela devrait être déconseillé, car cela a causé de graves problèmes dans un certain nombre de cas que j'ai vus, où le développeur ne tenait pas compte du changement de jeu de caractères par défaut.

Je ne peux pas répondre à votre question initiale mais je voudrais vous offrir quelques conseils - ne dépendez pas de l'encodage par défaut de la JVM. Il est toujours préférable de spécifier explicitement l'encodage souhaité (c'est-à-dire "UTF-8") dans votre code. De cette façon, vous savez que cela fonctionnera même sur différents systèmes et configurations JVM.

Essaye ça :

    new OutputStreamWriter( new FileOutputStream("Your_file_fullpath" ),Charset.forName("UTF8"))

Nous avions les mêmes problèmes. Nous avons méthodiquement essayé plusieurs suggestions de cet article (et d'autres) en vain. Nous avons également essayé d'ajouter le -Dfile.encoding=UTF8et rien ne semblait fonctionner.

Pour les personnes qui éprouvent ce problème, l'article suivant finalement nous a aidés à traquer décrit comment la configuration locale peut briser unicode/UTF-8enJava/Tomcat

http://www.jvmhost.com/articles/locale-breaks-unicode-utf-8-java-tomcat

La définition correcte des paramètres régionaux dans le ~/.bashrcfichier a fonctionné pour nous.

J'ai essayé beaucoup de choses, mais l'exemple de code ici fonctionne parfaitement. Lien

Le nœud du code est:

String s = "एक गाव में एक किसान";
String out = new String(s.getBytes("UTF-8"), "ISO-8859-1");

Dans le cas où vous utilisez Spring Boot et souhaitez passer l'argument file.encodingdans JVM, vous devez l'exécuter comme ça:

mvn spring-boot:run -Drun.jvmArguments="-Dfile.encoding=UTF-8"

cela était nécessaire pour nous car nous utilisions des JTwigmodèles et le système d'exploitation ANSI_X3.4-1968que nous avons découvert par le biaisSystem.out.println(System.getProperty("file.encoding"));

J'espère que cela aide quelqu'un!

J'utilise Amazon (AWS) Elastic Beanstalk et l'ai changé avec succès en UTF-8.

Dans Elastic Beanstalk, accédez à Configuration> Logiciel, "Propriétés d'environnement". Ajoutez (nom) JAVA_TOOL_OPTIONS avec (valeur) -Dfile.encoding = UTF8

Après l'enregistrement, l'environnement redémarrera avec l'encodage UTF-8.

Pas clair sur ce que vous faites et n'avez pas de contrôle sur ce point. Si vous pouvez interposer une classe OutputStream différente sur le fichier de destination, vous pouvez utiliser un sous-type de OutputStream qui convertit les chaînes en octets sous un jeu de caractères que vous définissez, par exemple UTF-8 par défaut. Si l'UTF-8 modifié est suffisant pour vos besoins, vous pouvez utiliser DataOutputStream.writeUTF(String):

byte inbytes[] = new byte[1024];
FileInputStream fis = new FileInputStream("response.txt");
fis.read(inbytes);
String in = new String(inbytes, "UTF8");
DataOutputStream out = new DataOutputStream(new FileOutputStream("response-2.txt"));
out.writeUTF(in); // no getBytes() here

Si cette approche n'est pas réalisable, il peut être utile de clarifier ici exactement ce que vous pouvez et ne pouvez pas contrôler en termes de flux de données et d'environnement d'exécution (même si je sais que c'est parfois plus facile à dire qu'à déterminer). Bonne chance.

mvn clean install -Dfile.encoding=UTF-8 -Dmaven.repo.local=/path-to-m2

La commande a fonctionné avec exec-maven-plugin pour résoudre l'erreur suivante lors de la configuration d'une tâche jenkins.

Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
Error occurred during initialization of VM
java.nio.charset.IllegalCharsetNameException: "UTF-8"
    at java.nio.charset.Charset.checkName(Charset.java:315)
    at java.nio.charset.Charset.lookup2(Charset.java:484)
    at java.nio.charset.Charset.lookup(Charset.java:464)
    at java.nio.charset.Charset.defaultCharset(Charset.java:609)
    at sun.nio.cs.StreamEncoder.forOutputStreamWriter(StreamEncoder.java:56)
    at java.io.OutputStreamWriter.<init>(OutputStreamWriter.java:111)
    at java.io.PrintStream.<init>(PrintStream.java:104)
    at java.io.PrintStream.<init>(PrintStream.java:151)
    at java.lang.System.newPrintStream(System.java:1148)
    at java.lang.System.initializeSystemClass(System.java:1192)

Nous y avons défini deux propriétés système ensemble et le système prend tout en utf8

file.encoding=UTF8
client.encoding.override＝UTF-8

Après le commentaire de @Caspar sur la réponse acceptée, la manière préférée de résoudre ce problème selon Sun est:

"modifiez les paramètres régionaux de la plate-forme sous-jacente avant de démarrer votre programme Java."

http://bugs.java.com/view_bug.do?bug_id=4163515

Pour docker, voir:

http://jaredmarkell.com/docker-and-locales/

Récemment, je suis tombé sur le système Notes 6.5 d'une entreprise locale et j'ai découvert que le webmail afficherait des caractères non identifiables sur une installation Windows non Zhongwen. J'ai creusé pendant plusieurs semaines en ligne, je l'ai compris il y a quelques minutes:

Dans les propriétés Java, ajoutez la chaîne suivante aux paramètres d'exécution

-Dfile.encoding=MS950 -Duser.language=zh -Duser.country=TW -Dsun.jnu.encoding=MS950

Le réglage UTF-8 ne fonctionnerait pas dans ce cas.

Mon équipe a rencontré le même problème sur les machines avec Windows .. puis a réussi à le résoudre de deux manières:

a) Définir la variable d'environnement (même dans les préférences système de Windows)

JAVA_TOOL_OPTIONS
-Dfile.encoding = UTF8

b) Introduisez l'extrait suivant dans votre pom.xml:

 -Dfile.encoding=UTF-8 

DANS

 <jvmArguments>
 -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8001
 -Dfile.encoding=UTF-8
 </jvmArguments>