Establecer la codificación de caracteres Java predeterminada

¿Cómo configuro correctamente la codificación de caracteres predeterminada utilizada por JVM (1.5.x) mediante programación?

He leído que -Dfile.encoding=whateversolía ser el camino a seguir para las JVM más antiguas. No tengo ese lujo por razones en las que no me involucraré.

Yo he tratado:

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

Y la propiedad se establece, pero no parece causar que la última getBytesllamada a continuación use 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());

Desafortunadamente, la file.encodingpropiedad tiene que especificarse cuando se inicia la JVM; en el momento en que se ingresa su método principal, la codificación de caracteres utilizada por String.getBytes()y los constructores predeterminados de InputStreamReadery OutputStreamWriterse ha almacenado en caché de forma permanente.

Como señala Edward Grech, en un caso especial como este, la variable de entorno JAVA_TOOL_OPTIONS se puede usar para especificar esta propiedad, pero normalmente se hace así:

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

Charset.defaultCharset()reflejará los cambios en la file.encodingpropiedad, pero la mayoría del código en las bibliotecas principales de Java que necesitan determinar la codificación de caracteres predeterminada no utiliza este mecanismo.

Cuando está codificando o decodificando, puede consultar la file.encodingpropiedad o Charset.defaultCharset()encontrar la codificación predeterminada actual y utilizar el método apropiado o la sobrecarga del constructor para especificarla.

De la documentación de la interfaz de la herramienta JVM ™ ...

Dado que no siempre se puede acceder o modificar la línea de comandos, por ejemplo, en máquinas virtuales integradas o simplemente máquinas virtuales lanzadas dentro de scripts, JAVA_TOOL_OPTIONSse proporciona una variable para que los agentes se puedan iniciar en estos casos.

Al establecer la variable de entorno (Windows) JAVA_TOOL_OPTIONSen-Dfile.encoding=UTF8 , la Systempropiedad (Java) se establecerá automáticamente cada vez que se inicie una JVM. Sabrá que el parámetro se ha seleccionado porque se publicará el siguiente mensaje en System.err:

Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8

¡Tengo una manera hacky que definitivamente funciona!

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

De esta manera, engañará a JVM, que pensaría que el conjunto de caracteres no está configurado y lo configurará nuevamente en UTF-8, en tiempo de ejecución.

Creo que un mejor enfoque que establecer el conjunto de caracteres predeterminado de la plataforma, especialmente porque parece tener restricciones para afectar el despliegue de la aplicación, y mucho menos la plataforma, es llamar a los más seguros String.getBytes("charsetName") . De esa forma, su aplicación no depende de cosas que escapan a su control.

Personalmente, creo que String.getBytes()debe ser desaprobado, ya que ha causado serios problemas en una serie de casos que he visto, en los que el desarrollador no tuvo en cuenta el posible cambio del juego de caracteres predeterminado.

No puedo responder a su pregunta original, pero me gustaría ofrecerle algunos consejos: no dependa de la codificación predeterminada de la JVM. Siempre es mejor especificar explícitamente la codificación deseada (es decir, "UTF-8") en su código. De esa manera, sabrá que funcionará incluso en diferentes sistemas y configuraciones JVM.

Prueba esto :

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

Teníamos los mismos problemas. Probamos metódicamente varias sugerencias de este artículo (y otras) en vano. También intentamos agregar el -Dfile.encoding=UTF8y nada parecía estar funcionando.

Para las personas que están teniendo este problema, el siguiente artículo, finalmente, ayudó a localizar describe cómo la configuración local puede romper unicode/UTF-8enJava/Tomcat

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

Establecer la configuración regional correctamente en el ~/.bashrcarchivo funcionó para nosotros.

He intentado muchas cosas, pero el código de muestra aquí funciona perfecto. Enlace

El quid del código es:

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

En caso de que esté utilizando Spring Boot y quiera pasar el argumento file.encodingen JVM, debe ejecutarlo así:

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

esto era necesario para nosotros ya que estábamos usando JTwigplantillas y el sistema operativo teníaANSI_X3.4-1968 que descubrimos a través deSystem.out.println(System.getProperty("file.encoding"));

¡Espero que esto ayude a alguien!

Estoy usando Amazon (AWS) Elastic Beanstalk y lo cambié con éxito a UTF-8.

En Elastic Beanstalk, vaya a Configuración> Software, "Propiedades del entorno". Agregue (nombre) JAVA_TOOL_OPTIONS con (valor) -Dfile.encoding = UTF8

Después de guardar, el entorno se reiniciará con la codificación UTF-8.

No está claro lo que haces y no tienes control sobre esto en este momento. Si puede interponer una clase OutputStream diferente en el archivo de destino, podría usar un subtipo de OutputStream que convierta las cadenas en bytes bajo un conjunto de caracteres que defina, por ejemplo, UTF-8. Si el UTF-8 modificado es suficiente para sus necesidades, puede usar 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 este enfoque no es factible, puede ayudar si aclara aquí exactamente lo que puede y no puede controlar en términos de flujo de datos y entorno de ejecución (aunque sé que a veces es más fácil decirlo que determinarlo). Buena suerte.

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

El comando trabajó con exec-maven-plugin para resolver el siguiente error al configurar una tarea 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)

Establecimos dos propiedades del sistema juntas y hace que el sistema tome todo en utf8

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

Siguiendo el comentario de @Caspar sobre la respuesta aceptada, la forma preferida de solucionar esto según Sun es:

"cambie la configuración regional de la plataforma subyacente antes de iniciar su programa Java".

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

Para la ventana acoplable ver:

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

Recientemente me topé con el sistema Notes 6.5 de una empresa local y descubrí que el correo web mostraría caracteres no identificables en una instalación de Windows no localizada en Zhongwen. He cavado durante varias semanas en línea, lo descubrí hace unos minutos:

En las propiedades de Java, agregue la siguiente cadena a los parámetros de tiempo de ejecución

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

La configuración de UTF-8 no funcionaría en este caso.

Mi equipo encontró el mismo problema en máquinas con Windows ... luego logró resolverlo de dos maneras:

a) Establecer la variable de entorno (incluso en las preferencias del sistema de Windows)

JAVA_TOOL_OPTIONS
-Dfile.encoding = UTF8

b) Introduce el siguiente fragmento en tu pom.xml:

 -Dfile.encoding=UTF-8 

DENTRO

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