149 votes

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

Comment puis-je définir correctement le codage des caractères par défaut utilisé par la JVM (1.5.x) par voie programmatique ?

J'ai lu que -Dfile.encoding=whatever était la solution pour les anciennes JVM... Je n'ai pas ce luxe pour des raisons que je n'aborderai pas.

J'ai essayé :

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

Et la propriété est définie, mais cela ne semble pas provoquer l'utilisation de UTF8 dans l'appel final getBytes ci-dessous :

    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());

116voto

erickson Points 127945

Malheureusement, le file.encoding doit être spécifiée au démarrage de la JVM ; au moment où votre méthode principale est introduite, le codage des caractères utilisé par la propriété String.getBytes() et les constructeurs par défaut de InputStreamReader et OutputStreamWriter a été mis en cache de façon permanente.

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

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

Charset.defaultCharset() reflètera les changements apportés à la file.encoding mais la plupart des codes des bibliothèques Java de base qui doivent déterminer le codage des caractères par défaut n'utilisent pas ce mécanisme.

Lorsque vous êtes en train de coder ou de décoder, vous pouvez interroger le fichier file.encoding propriété ou Charset.defaultCharset() pour trouver l'encodage par défaut actuel, et utiliser la méthode appropriée ou la surcharge du constructeur pour le spécifier.

97voto

Edward Grech Points 1071

De la Interface de l'outil JVM™ la documentation

Étant donné qu'il n'est pas toujours possible d'accéder à la ligne de commande ou de la modifier, par exemple dans les VM embarquées ou simplement dans les VM lancées au cœur de scripts, une fonction JAVA_TOOL_OPTIONS est fournie afin que des agents puissent être lancés dans ces cas.

En définissant la variable d'environnement (Windows) JAVA_TOOL_OPTIONS à -Dfile.encoding=UTF8 le (Java) System sera définie automatiquement à chaque fois qu'une JVM est démarrée. Vous saurez que le paramètre a été pris en compte car le message suivant sera affiché dans le fichier System.err :

Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8

28voto

Dov Wasserman Points 1538

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 de l'application, sans parler de la plate-forme, est d'appeler la méthode beaucoup plus sûre String.getBytes("charsetName"). De cette façon, votre application ne dépend pas de facteurs indépendants de sa volonté.

Je pense personnellement que String.getBytes() devrait être déprécié, car il a causé de sérieux problèmes dans un certain nombre de cas que j'ai vus, où le développeur n'a pas tenu compte du changement possible du jeu de caractères par défaut.

17voto

naskoos Points 171

J'ai un moyen détourné qui fonctionne définitivement ! !!

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 la JVM qui pensera que le charset n'est pas défini et le fera redéfinir en UTF-8, au moment de l'exécution !

11voto

Marc Novakowski Points 22611

Je ne peux pas répondre à votre question initiale mais j'aimerais vous donner un conseil : 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 qu'il fonctionnera même sur différents systèmes et configurations JVM.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X