Quel codepage/charset doit être utilisé pour interpréter les données provenant d'un système MVS dans un environnement Java?

Question

J'ai rencontré un problème intéressant (comme c'est souvent le cas lors de l'interaction avec des systèmes hérités). Je travaille sur une application (qui fonctionne actuellement sur un système x86 Linux ou Windows) qui peut recevoir des demandes provenant de divers systèmes, l'un d'entre eux étant un système MVS.

Je tente de déterminer quelle page de codes/jeu de caractères je devrais utiliser pour interpréter les données de demande provenant du système MVS. Dans le passé, j'ai utilisé 'cp500' (IBM-500) pour interpréter la date d'octet à venir pour les systèmes z/OS, mais je crains que MVS soit un peu un système hérité, et que depuis IBM semblait pour changer son esprit de manière cohérente par rapport à l'encodage à utiliser (il doit y avoir des dizaines de codages EBCDIC), cp500 peut ne pas être le codage correct.

La meilleure ressource que j'ai trouvée sur les jeux de caractères en Java est: http://mindprod.com/jgloss/encoding. Cependant à partir de ce site, et IBM Infocenters, je n'ai pas été en mesure d'obtenir une réponse claire.

EDIT: Ajout de ma réponse à Pax ci-dessous:

Il y avait un trou flagrant dans ma question à l'origine des données de demande. Dans ce cas, l'origine des données se fait via une interface WebSphere MQ. Websphere MQ dispose de fonctionnalités pour la conversion au codage correct, mais uniquement pour la lecture des données à l'aide de MQMessage.readString(), qui a depuis été abandonné. Je préférerais utiliser ceci, cependant j'utilise un cadre d'interface propriétaire dans lequel je ne peux pas changer la façon dont le message est lu sur le MQQueue, qui lit directement les octets de la file d'attente et donc je suis laissé manipuler la traduction.

Réponse finale: Je voulais poursuivre sur ce sujet. Il s'avère que le jeu de caractères correct était en effet cp500 (IBM-500). Cependant, j'ai l'impression que les résultats peuvent varier. Quelques conseils pour toute personne ayant le même problème:

Utilisez Charset.availableCharsets() ;. Cela vous donnera une carte des jeux de caractères pris en charge dans votre temps d'exécution. J'ai itéré à travers ces ensembles et imprimé mes données d'octets traduites dans ce jeu de caractères. Bien qu'il ne m'ait pas donné la réponse que je voulais (surtout parce que je n'étais pas capable de lire les données au moment où il entrait), j'imagine que cela pourrait être utile pour les autres.

Reportez-vous à: http://mindprod.com/jgloss/encoding pour obtenir la liste des jeux de caractères pris en charge. Enfin, même si je n'ai pas confirmé cela, mais assurez-vous que vous utilisez le bon JRE. Je pense que les IBM Runtimes supportent plus de jeux de caractères EBCDIC que OpenJDK ou Sun Runtimes.

Answer 1

"MVS est un peu un système hérité"? Ha! C'est toujours l'OS de choix pour les applications où la fiabilité est la préoccupation numéro un. Maintenant à votre question :-)

Cela dépend entièrement de ce qui génère les données. Par exemple, si vous ne faites que télécharger des fichiers depuis l'hôte, la négociation FTP peut le gérer. Mais puisque vous mentionnez Java, il se connecte probablement via JDBC à DB2/z, et les pilotes JDBC le géreront très bien (beaucoup mieux si vous utilisez le propre JRE d'IBM plutôt que la version Sun). EBCDIC lui-même sur l'hôte a un certain nombre de codages différents, vous devez donc au moins nous faire savoir d'où proviennent les données. Les versions récentes de DB2 n'ont aucun problème avec le stockage Unicode dans la base de données, ce qui soulagerait toutes vos préoccupations.

Première tâche, savoir d'où proviennent les données et obtenir le codage de votre SysProg (si ce n'est pas géré automatiquement).

Mise à jour:

Andrew, en fonction de votre texte ajouté où vous déclarez que vous ne pouvez pas utiliser les traductions fournies, vous allez devoir utiliser la méthode manuelle. Vous devez identifier la source des données et obtenir le CCSID à partir de cela. Ensuite, effectuez manuellement la traduction depuis et vers Unicode (ou toute autre page de code que vous utilisez si ce n'est Unicode).

CCSID 500 est la page de code par défaut pour EBCDIC International (pas d'Euro) mais ces machines sont utilisées partout dans le monde. Les services de conversion z/OS sont la manière dont vous effectuez généralement la conversion sur l'ordinateur central.

Bien que this soit une page iSeries, elle répertorie un grand nombre de CCSID et leurs glyphes, également applicables au mainframe.

Vous avez probablement juste besoin de savoir si vous utilisez CCSID 500 ou 37 (ou l'une des versions en langue étrangère) et élaborer le mappage avec Unicode CCSID 1208. Votre SysProg sera en mesure de vous dire lequel. Si vous travaillez pour une entreprise américaine, il est probable que soit 500 ou 37, mais IBM consacre beaucoup d'efforts à la prise en charge de plusieurs pages de codes. Je serai heureux quand tous leurs logiciels mainframe stocke et utilise Unicode par défaut, ça va rendre les choses beaucoup plus faciles.