¿Qué página de códigos / conjunto de caracteres se debe usar para interpretar los datos provenientes de un sistema MVS en un entorno Java?

Question

Me he encontrado con un problema interesante (como suele ser el caso al interactuar con sistemas heredados). Estoy trabajando en una aplicación (que actualmente se ejecuta en un sistema x86 Linux o Windows) que puede recibir solicitudes de una variedad de sistemas, uno de ellos es un sistema MVS.

Estoy intentando determinar qué página de códigos / conjunto de caracteres debo usar para interpretar los datos de solicitud provenientes del sistema MVS.

En el pasado, he usado 'cp500' (IBM-500) para interpretar la fecha de byte que viene para los sistemas z / OS, sin embargo, me temo que, dado que MVS es un sistema heredado, parece que desde IBM cambiar es coherente con respecto a la codificación que se debe utilizar (debe haber decenas de codificaciones EBCDIC), por lo que cp500 puede no ser la codificación correcta.

El mejor recurso que he encontrado en los juegos de caracteres en Java es: http://mindprod.com/jgloss / codificación . Sin embargo, desde este sitio, y los Infocenters de IBM, no he podido obtener una respuesta clara.

EDITAR: Agregado de mi respuesta a Pax a continuación:

Hubo un agujero evidente en mi pregunta en el origen de los datos de la solicitud. En este caso, el origen de los datos es a través de una interfaz Websphere MQ. Websphere MQ tiene facilidades para traducir a la codificación adecuada, sin embargo, eso es solo para leer los datos utilizando MQMessage.readString (), que desde entonces ha quedado en desuso. Preferiría usar esto, sin embargo, estoy usando un marco de interfaz propietario en el que no puedo cambiar la forma en que se lee el mensaje de la MQQueue, que está leyendo bytes directamente de la cola y, por lo tanto, me quedo con la traducción de la manija.

Respuesta final: quería hacer un seguimiento de esto. Resulta que el conjunto de caracteres correcto era de hecho cp500 (IBM-500). Sin embargo, tengo la impresión de que los resultados pueden variar. Algunos consejos para cualquier otra persona con el mismo problema:

Utilizar Charset.availableCharsets () ;. Esto le dará un mapa de los Conjuntos de caracteres compatibles en su tiempo de ejecución. Recorrí estos conjuntos e imprimí mis datos de bytes traducidos a ese conjunto de caracteres. Si bien no me dio la respuesta que quería (principalmente porque no pude leer los datos cuando los recibí), me imagino que podría ser útil para otros.

Consulte: http://mindprod.com/jgloss/encoding para obtener una lista de conjuntos de caracteres.

Por último, aunque no lo he confirmado, asegúrate de estar usando el JRE correcto. Estoy pensando que los tiempos de ejecución de IBM admiten más juegos de caracteres EBCDIC, luego OpenJDK o los tiempos de ejecución de Sun.

Answer 1

" MVS es un poco un sistema heredado " ;? ¡Decir ah! Sigue siendo el sistema operativo elegido para las aplicaciones en las que la fiabilidad es la principal preocupación. Ahora en tu pregunta :-)

Depende completamente de lo que está generando los datos. Por ejemplo, si solo está descargando archivos desde el host, la negociación de FTP puede manejarlo. Pero como menciona Java, es probable que se conecte a través de JDBC a DB2 / z, y los controladores JDBC lo manejarán bastante bien (mucho mejor si está utilizando el JRE de IBM en lugar de la versión de Sun).

El propio EBCDIC en el host tiene varias codificaciones diferentes, por lo que necesita al menos informarnos de dónde provienen los datos. Las versiones recientes de DB2 no tienen problemas con el almacenamiento de Unicode en la base de datos, lo que aliviaría todas sus inquietudes.

Primera tarea, averigüe de dónde provienen los datos y obtenga la codificación de su SysProg (si no se maneja automáticamente).

Actualización :

Andrew, en función del texto agregado en el que indique que no puede usar las traducciones proporcionadas, tendrá que usar el método manual. Debe identificar la fuente de los datos y obtener el CCSID de eso. Luego, realice la traducción ay desde Unicode (o la página de códigos que esté utilizando, si no es Unicode) manualmente.

CCSID 500 es la página de códigos predeterminada para EBCDIC International (sin euro) pero estas máquinas se utilizan en todo el planeta. Los servicios de conversión de z / OS es la forma en que normalmente realiza la conversión en el mainframe.

Aunque esta es una página de iSeries, enumera una gran cantidad de CCSID y sus glifos, aplicables también al mainframe.

Probablemente solo necesite averiguar si está utilizando CCSID 500 o 37 (o una de las versiones en otro idioma) y elaborar el mapeo con Unicode CCSID 1208. Su SysProg podrá decirle cuál. Si está trabajando para una empresa de EE. UU., Es probable que sea 500 o 37, pero IBM dedica muchos esfuerzos a admitir varias páginas de códigos. Me alegraré cuando todos sus programas de mainframe almacenen y utilicen Unicode de forma predeterminada, hará las cosas mucho más fáciles.