Pregunta

En mi aplicación Java, estoy archivando mensajes TIBCO RV en un archivo en forma de bytes.

Estoy escribiendo una pequeña aplicación de utilidad que reproducirá los mensajes.De esta manera puedo crear un objeto TibrvMsg a partir de bytes sin tener que analizar el archivo y construir el objeto manualmente.

El problema que tengo es que estoy leyendo un archivo que se creó en una máquina Linux e intento ejecutar mi aplicación en una máquina con Windows.Recibo un error debido al diferente juego de caracteres en el que se escribió el archivo.

Ahora, lo que quiero hacer es registrar cada mensaje en un conjunto de caracteres específico (UTF-8), para que no me importe en qué plataforma ejecuto mi aplicación de reproducción.La aplicación debería simplemente leer el archivo sabiendo de antemano en qué juego de caracteres está escrito el archivo.Estoy pensando en utilizar paquetes java.nio para esto, para transformar los bytes de un conjunto de caracteres a otro.

¿Necesito saber en qué juego de caracteres están codificados los bytes del mensaje TIBRV para realizar la transformación?Si es así, ¿cómo puedo saberlo?

¿Fue útil?

Solución

Está tomando datos opacos y, al parecer, está intentando escribirlos en un archivo como datos textuales sin escapar de las partes no textuales (alternativamente, los está escribiendo como bytes sin formato y luego tratando de leerlos como si estuvieran basados ​​en caracteres). que es prácticamente el mismo problema).Esto es erróneo desde el principio.

Los datos opacos deben tratarse como si no tuvieran sentido y simplemente almacenarse sin modificaciones para devolvérselo a una API que sepa cómo manejarlos.Si los datos deben almacenarse en forma textual, entonces debe sin pérdidas convertir los bytes en texto.Las codificaciones apropiadas son cosas como base64.La codificación en el sentido de codificación de juego de caracteres NO es sin pérdidas si la aplica a datos binarios sin formato.

Simplemente almacenando los bytes en un archivo como bytes (no caracteres) junto con un prefijo de longitud fija que indica la longitud del mensaje y el asunto en el que se envió es suficiente para reproducir mensajes RV a través del sistema.

En relación con cualquier campo basado en texto dentro del mensaje, si la codificación es importante (recomiendo encarecidamente evitar esta cuestión en general al diseñar la aplicación), entonces tendrá el mismo problema en la reproducción que habría tenido en el momento de la recepción original, que es convertir desde la codificación fuente hasta la codificación deseada (con suerte, usando exactamente el mismo código), por lo que esto no debería ser un problema en relación con la reproducción.

Otros consejos

Como esto (la verdad es bastante antiguo) mensaje de lista de correo indica, poco se sabe acerca de la estructura interna de ese protocolo de red. Esto puede hacer que sea todo un reto para hacer lo que está buscando.

Dicho esto, si los mensajes son sólo bloques de datos binarios (como se refleja desde la red), no deberían incluso tener un conjunto de caracteres. Juegos de caracteres es para datos de texto, donde importa ya que un solo carácter puede codificarse de muchas maneras diferentes. Los datos binarios no está compuesto de caracteres, por lo que no puede ser una codificación en ese sentido.

Esto está probablemente relacionado con Java serie de codificación, no TIBRV. Aunque existe esta en la documentación:

Strings and Character Encodings 

--------------------------------------------------------------------------------

Rendezvous software uses strings in several roles: 

* String data inside message fields
* Field names
* Subject names (and other associated strings that are not
  strictly inside the message)
* Certified delivery correspondent names
* Group names (fault tolerance)

All these strings (both in C and in wire format) use the character
encoding appropriate to the ISO locale of the sender. For example,
the United States is locale en_US, and uses the Latin-1 character
encoding (also called ISO 8859-1); Japan is locale ja_JP, and uses
the Shift-JIS character encoding. 

When two programs exchange messages within the same locale, strings
are always correct. However, when a message sender and receiver use
different character encodings, the receiving program must convert
between encodings as needed. Rendezvous software does not convert
automatically. 

EBCDIC 
For information about string encoding in EBCDIC environments,
see tibrv_SetCodePages() . 

Así que es posible que desee ver en la configuración regional de las máquinas.

¿Necesito saber en qué charset se codifican los bytes del mensaje TIBRV para hacer la transformación?

Sí.Un juego de caracteres es un método para transformar texto en un flujo de bytes y viceversa.Los datos de su red son un flujo de bytes, por lo que cuando interpreta partes de ellos como texto, ESTÁ (implícita o explícitamente) usando un juego de caracteres; la pregunta es si es el correcto.

Transformar bytes de un juego de caracteres a otro básicamente significa convertirlos en texto usando un juego de caracteres y luego volver a bytes usando otro.Tenga en cuenta que esto puede provocar que cambie la longitud de los datos, ya que muchos conjuntos de caracteres utilizan más de 1 byte para algunos caracteres.En el contexto de los mensajes de red, esto podría resultar problemático cuando invalida los campos de longitud o hace que los campos de texto se desborden.Probablemente sea mejor no realizar ninguna transformación y, en cambio, enseñarle a la aplicación de lectura cómo manejar diferentes conjuntos de caracteres.

Si es así, ¿cómo puedo saberlo?

Mire la especificación del protocolo.

Lea todo lo inte un byte [] de una flujoEntrada, escribir el byte [] a un un FileOutputStream.

Ningún lector o escritor deben participar, que hacen la conversión de caracteres y que está mal.

Manténgase alejado de java.nio hasta que entienda java.io.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top