Définir le codage de caractères Java par défaut?

Malheureusement, la propriété file.encoding doit être spécifiée au démarrage de la JVM; Au moment de la saisie de la méthode principale, le codage de caractères utilisé par Ssortingng.getBytes() et les constructeurs par défaut de InputStreamReader et OutputStreamWriter ont été mis en cache de manière permanente.

Comme le souligne Edward Grech, dans un cas particulier 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 apscopes à la propriété file.encoding , mais la plupart des codes des bibliothèques Java principales qui doivent déterminer le codage de caractères par défaut n’utilisent pas ce mécanisme.

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

A partir de la documentation JVM ™ Tool Interface …

Comme la ligne de commande ne peut pas toujours être accédée ou modifiée, par exemple dans les machines virtuelles embarquées ou simplement les machines virtuelles lancées profondément dans les scripts, une variable JAVA_TOOL_OPTIONS est fournie pour que les agents puissent être lancés dans ces cas.

En définissant la variable d’environnement (Windows) JAVA_TOOL_OPTIONS sur -Dfile.encoding=UTF8 , la propriété (Java) System sera définie automatiquement à chaque démarrage d’une JVM. Vous saurez que le paramètre a été sélectionné car le message suivant sera envoyé à System.err :

Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8

J’ai un moyen de piratage 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 pense que le jeu de caractères n’est pas défini et le redéfinit sur UTF-8, à l’exécution!

Je pense qu’une meilleure approche que la définition du jeu de caractères par défaut de la plate-forme, d’autant plus que vous semblez avoir des ressortingctions sur le déploiement des applications, sans parler de la plate-forme, consiste à appeler Ssortingng.getBytes("charsetName") . De cette façon, votre application ne dépend pas de choses indépendantes de sa volonté.

Ssortingng.getBytes() j’estime que Ssortingng.getBytes() devrait être obsolète, car cela a causé de sérieux problèmes dans un certain nombre de cas que j’ai vus, où le développeur ne tenait pas compte du changement du jeu de caractères par défaut.

Je ne peux pas répondre à votre question initiale, mais je voudrais vous proposer 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é (par exemple “UTF-8”) dans votre code. De cette façon, vous savez que cela fonctionnera même sur différents systèmes et configurations de 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’append le fichier -Dfile.encoding = UTF8 et rien ne semblait fonctionner.

Pour les personnes qui rencontrent ce problème, l’article suivant nous a finalement aidés à déterminer comment les parameters régionaux peuvent casser unicode / UTF-8 dans Java / Tomcat

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

Définir correctement les parameters régionaux dans le fichier ~ / .bashrc a fonctionné pour nous.

Si vous utilisez Spring Boot et que vous voulez passer l’argument file.encoding dans JVM, vous devez l’exécuter comme ceci:

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

c’était nécessaire pour nous puisque nous JTwig modèles JTwig et que le système d’exploitation était ANSI_X3.4-1968 que nous avons découvert par System.out.println(System.getProperty("file.encoding"));

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

Pas clair sur ce que vous faites et ne contrôlez pas à ce stade. 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 UTF-8 modifié est suffisant pour vos besoins, vous pouvez utiliser DataOutputStream.writeUTF(Ssortingng) :

 byte inbytes[] = new byte[1024]; FileInputStream fis = new FileInputStream("response.txt"); fis.read(inbytes); Ssortingng in = new Ssortingng(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 stream 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.

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

Le nœud du code est le suivant:

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

 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.(OutputStreamWriter.java:111) at java.io.PrintStream.(PrintStream.java:104) at java.io.PrintStream.(PrintStream.java:151) at java.lang.System.newPrintStream(System.java:1148) at java.lang.System.initializeSystemClass(System.java:1192) 

Nous mettons ensemble deux propriétés du système et cela fait que le système prend tout en utf8

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

Suite au 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 la suivante:

“modifiez les parameters 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 la messagerie Web afficherait des caractères non identifiables sur une installation Windows non Zhongwen localisée. Avez-vous creusé pendant plusieurs semaines en ligne, l’a compris il y a quelques minutes:

Dans les propriétés Java, ajoutez la chaîne suivante aux parameters 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.

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

Dans Elastic Beanstalk, accédez à Configuration> Logiciels, “Propriétés de l’environnement”. Ajouter (name) JAVA_TOOL_OPTIONS avec (value) -Dfile.encoding = UTF8

Après la sauvegarde, l’environnement redémarrera avec le codage UTF-8.