Impostazione della codifica dei caratteri Java predefinita

Come posso impostare correttamente la codifica dei caratteri predefinita utilizzata dalla JVM (1.5.x) a livello di codice?

Ho letto che -Dfile.encoding=whateverera la strada da percorrere per le JVM più vecchie. Non ho quel lusso per ragioni che non mi interessano.

Ho provato:

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

E la proprietà viene impostata, ma non sembra che l'ultima getByteschiamata in basso usi 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());

Sfortunatamente, la file.encodingproprietà deve essere specificata all'avvio di JVM; al momento String.getBytes()dell'inserimento del metodo principale, la codifica dei caratteri utilizzata da e i costruttori predefiniti di InputStreamReadered OutputStreamWriterè stata memorizzata nella cache in modo permanente.

Come sottolinea Edward Grech, in un caso speciale come questo, la variabile d'ambiente JAVA_TOOL_OPTIONS può essere utilizzata per specificare questa proprietà, ma normalmente viene eseguita in questo modo:

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

Charset.defaultCharset()rifletterà le modifiche alla file.encodingproprietà, ma la maggior parte del codice nelle librerie Java principali che devono determinare la codifica dei caratteri predefinita non utilizza questo meccanismo.

Durante la codifica o la decodifica, è possibile eseguire una query sulla file.encodingproprietà o Charset.defaultCharset()trovare la codifica predefinita corrente e utilizzare il metodo appropriato o il sovraccarico del costruttore per specificarlo.

Dalla documentazione dell'interfaccia dello strumento JVM ™ ...

Poiché non è sempre possibile accedere o modificare la riga di comando, ad esempio nelle VM incorporate o semplicemente nelle VM lanciate in profondità negli script, JAVA_TOOL_OPTIONSviene fornita una variabile in modo che gli agenti possano essere avviati in questi casi.

Impostando la variabile di ambiente (Windows) JAVA_TOOL_OPTIONSsu -Dfile.encoding=UTF8, la Systemproprietà (Java) verrà impostata automaticamente ogni volta che viene avviata una JVM. Saprai che il parametro è stato raccolto perché il seguente messaggio verrà pubblicato in System.err:

Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8

Ho un modo bizzarro che sicuramente funziona !!

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

In questo modo ingannerai JVM che penserebbe che il set di caratteri non sia impostato e lo farà reimpostare su UTF-8, in fase di esecuzione!

Penso che un approccio migliore rispetto all'impostazione del set di caratteri predefinito della piattaforma, specialmente se sembra che tu abbia restrizioni sull'impiego dell'applicazione, per non parlare della piattaforma, è chiamare il molto più sicuro String.getBytes("charsetName"). In questo modo l'applicazione non dipende da cose al di fuori del suo controllo.

Personalmente ritengo che String.getBytes()dovrebbe essere deprecato, in quanto ha causato seri problemi in una serie di casi che ho visto, in cui lo sviluppatore non ha tenuto conto del set di caratteri predefinito che potrebbe cambiare.

Non riesco a rispondere alla tua domanda originale, ma vorrei offrirti alcuni consigli, non dipendere dalla codifica predefinita di JVM. È sempre meglio specificare esplicitamente la codifica desiderata (ad esempio "UTF-8") nel codice. In questo modo, sai che funzionerà anche su diversi sistemi e configurazioni JVM.

Prova questo :

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

Avevamo gli stessi problemi. Abbiamo metodicamente provato diversi suggerimenti da questo articolo (e altri) senza alcun risultato. Abbiamo anche provato ad aggiungere il -Dfile.encoding=UTF8e nulla sembrava funzionare.

Per le persone che stanno avendo questo problema, il seguente articolo, infine, ci ha aiutato a rintracciare descrive come le impostazioni internazionali può rompere unicode/UTF-8inJava/Tomcat

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

Impostare correttamente le impostazioni internazionali nel ~/.bashrcfile ha funzionato per noi.

Ho provato molte cose, ma il codice di esempio qui funziona perfettamente. collegamento

Il punto cruciale del codice è:

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

Nel caso in cui si utilizzi Spring Boot e si desideri passare l'argomento file.encodingin JVM, è necessario eseguirlo in questo modo:

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

questo era necessario per noi poiché stavamo usando i JTwigtemplate e il sistema operativo aveva ANSI_X3.4-1968scopertoSystem.out.println(System.getProperty("file.encoding"));

Spero che questo aiuti qualcuno!

Sto usando Amazon (AWS) Elastic Beanstalk e l'ho cambiato con successo in UTF-8.

In Elastic Beanstalk, vai a Configurazione> Software, "Proprietà dell'ambiente". Aggiungi (nome) JAVA_TOOL_OPTIONS con (valore) -Dfile.encoding = UTF8

Dopo il salvataggio, l'ambiente verrà riavviato con la codifica UTF-8.

Non hai chiarito cosa fai e non hai il controllo a questo punto. Se è possibile interporre una diversa classe OutputStream sul file di destinazione, è possibile utilizzare un sottotipo di OutputStream che converte String in byte in un set di caratteri definito, ad esempio UTF-8. Se UTF-8 modificato è sufficiente per le tue esigenze, puoi utilizzare 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

Se questo approccio non è fattibile, può essere utile chiarire qui esattamente cosa è possibile e non è possibile controllare in termini di flusso di dati e ambiente di esecuzione (anche se so che a volte è più facile dirlo che determinarlo). In bocca al lupo.

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

Il comando ha funzionato con exec-maven-plugin per risolvere il seguente errore durante la configurazione di un'attività 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)

Abbiamo impostato due proprietà di sistema insieme e questo fa sì che il sistema prenda tutto in utf8

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

Dopo il commento di @Caspar sulla risposta accettata, il modo preferito per risolvere questo problema secondo Sun è:

"modifica le impostazioni internazionali della piattaforma sottostante prima di avviare il tuo programma Java."

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

Per la finestra mobile vedere:

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

Recentemente mi sono imbattuto nel sistema Notes 6.5 di un'azienda locale e ho scoperto che la webmail avrebbe mostrato caratteri non identificabili su un'installazione Windows localizzata non Zhongwen. Ho scavato per diverse settimane online, capito pochi minuti fa:

Nelle proprietà Java, aggiungere la seguente stringa ai parametri di runtime

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

In questo caso l'impostazione UTF-8 non funzionerebbe.

Il mio team ha riscontrato lo stesso problema nelle macchine con Windows .. quindi è riuscito a risolverlo in due modi:

a) Impostare la variabile di ambiente (anche nelle preferenze di sistema di Windows)

JAVA_TOOL_OPTIONS
-Dfile.encoding = UTF8

b) Introduci il seguente frammento nel tuo pom.xml:

 -Dfile.encoding=UTF-8 

ENTRO

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