Saludos, tocayo

Tu último párrafo me hizo dudar y he comprobado que sí es como tú dices, corrijo el post.

Muchas gracias por “ponerte tozudo” para hacerme entrar en razón

De todas formas, al leer (constructor) no se cambia la codificacion de los bytes, se cambia la forma de interpretarlos. Y al escribir (getBytes) no se cambia la cadena, se cambia la forma de transformar la cadena en bytes.

El ejemplo, asi como está, hace:
.- El String esta declarado como constante, crea un String y se codifica internamente en UTF-16
.- El .getBytes(…UTF-8″) devuelve la ristra en bytes, segun se codifica en UTF-8, de la cadena.
.- El new String(bytes,”ISO-8859-1″) interpreta la ristra de bytes como si codificaran unos caracteres en ISO, y los convierte en un String (internamente con UTF16).
.- Como los caracteres que he puesto, a conciencia, no se representan igual en UTF-8 y LATIN1, pues se el constructor los interpreta mal.

Haciendo una burda analogia, supongamos que UTF8 codifica las letras en numeros normales y LATIN1 en numeros romanos.

“ABC”.getBytes(UTF-8) = 1,2,3
“ABC”.getBytes(LATIN1) = I,II,III

new String({1,2,3},UTF-8) = “ABC”
new String({I,II,II},LATIN1) = “ABC”

new String(“ABC”.getBytes(UTF-8),LATIN1) daria error por que el 1 en LATIN1 no es la A, el 2 no… etc.

La transformacion que dices que hay que hacer a veces es cuando tienes que leer unos bytes que representan una cadena y estan codificados en un charset, llamemosle charsetX, distinto del de por defecto (usas new String(bytes,charsetX) o cuando tu tienes que esribir unos bytes en una codificacion diferente de la por defecto, que usas getBytes(charsetX) y escribes los bytes.

S!

Y sí, toda la razón, se modifica la codificación de los bytes y no la del String en sí que siempre será UTF-16 y como han cambiado los bytes cambia el contenido del String.

La cuestión es que en alguna ocasión he tenido que forzar esa transformación de codificación, por no abstraerme de eso las interfaces.

Todo lo que trata sobre estos cambios de codificaciones en el javadoc de la clase String es un poco confuso… al menos para mi:

String(byte[] bytes, String charsetName)
“Constructs a new String by decoding the specified array of bytes using the specified charset”
¿Un nuevo String decodificando el array de bytes usando el charset especificado?
Se puede entender de las dos maneras…

getBytes(String charsetName)
“Encodes this String into a sequence of bytes using the named charset, storing the result into a new byte array.”
¿Codifica este String en una secuencia de bytes usando el charset nombrado, guardando el resultado en un array de bytes?
Lo mismo…

(Seguramente las traducciones dejan bastante que desear XD)

Y por mi experiencia, quizás me equivoque haciéndolo de memoria pero estoy convencido de esto, el código de ejemplo viene a hacer:
- El array de bytes lo leemos con codificación Latin1 para que el contenido del String “no se vea raro”, con getBytes(“ISO-8859-1″).
- Y ese array lo decodificamos a UTF-8 en la creación del String para que en el destino se guarde “sin verse raro”.

GreenEyed, a ver si llegamos a un acuerdo jejeje

Sobre el problema, pasa exactamente lo mismo con getBytes. Con getBytes(codificacion), el parametro codificacion no se refiere a como esta codificado internamente el String, que SIEMPRE esta codificado en UTF-16, se refiere a como quieres que codifique los bytes de salida. Asi que si obtienes los bytes codificados segun ISO y se los pasas a un constructor diciendole que estan codificados en UTF, estas pasandole argumentos incorrectos y te dara un error con algunos caracteres.

Espero que asi quede mas claro .

Prueba esto a ver si te aclara a lo que me refiero:

System.err.println(“Prueba: ”
+ new String(“áéíóú@”.getBytes(“UTF-8″),”ISO-8859-1″))

Verás que el resultado no es “áéíóú@”.

S!

Las dos cadenas al final son la misma, pero en mi caso sí me interesa saber como lo guarda (o más bien forzar cómo lo guarda), prefiero hacerlo en la interfaz de entrada que en la de salida, ya que quién sabe si un día se modifica esa interfaz de entrada (por ejemplo para leer de un fichero de texto en UTF-8) mientras que la codificación de salida no cambiará.

Sobre los posibles problemas, no acabo de entender a qué te refieres, la transformación es de Latin1 a UTF-16 en el getBytes y en el constructor del nuevo String es de UTF-16 a UTF-8.

Sobre el tag y establecer el contentType, es redundante pero como dices, cualquiera se fía de los navegadores .

Es más, supuestamente si haces un getBytes() y luego creas un String con esos bytes con encodings differentes, podrias tener un error ya que estas generando la interpretacion en bytes como ISO-LATIN1 y la estas leyendo como si los bytes fuera UTF-8…
Lo importante son los interfaces, y ahi el emisor y el receptor han de ponerse de acuerdo, como se guarde internamente la informacion deberia dar igual.

Otro tema interesante y largamente comentado pero que aun “muerde” es el de los navegadores y su envio de parametros. Por cierto, el tag http-equiv=”content-type” y el response.setContentType son redundantes, aunque se suelen poner ambos por si acaso, el problema es que si te equivocas y no concuerdan… el resultado es imprevisible, por que cada navegador hace lo que le pasa por…

Es un tema interesante.

No conocía esta librería, le pegaré un repaso tranquilamente.

Y lo bueno es que sé que es Joaquin Cuenca, pero parece que no soy dueño de mis dedos XD.

Gracias por ambos apuntes.

http://code.google.com/p/gettext-commons/

por cierto, el autor del post de programa con google es “Joaquin Cuenca” no Joaquin Cuesta.

Saludos