Quelle page de codes / jeu de caractères doit être utilisé pour interpréter les données provenant d'un système MVS dans un environnement Java?

Question

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

J'essaie de déterminer la page de codes / le jeu de caractères que je devrais utiliser pour interpréter les données de requête provenant du système MVS.

Auparavant, j’utilisais cp500 (IBM-500) pour interpréter la date sur les octets à venir sur les systèmes z / OS. Cependant, je crains que, comme MVS soit un peu un système hérité, et que depuis IBM semble changez d'avis systématiquement en ce qui concerne le codage à utiliser (il doit y avoir des dizaines de codages EBCDIC), cp500 n'est peut-être pas le codage correct.

La meilleure ressource que j'ai trouvée sur les jeux de caractères en Java est: http://mindprod.com/jgloss / encodage . Cependant, à partir de ce site et des centres de documentation IBM, je n'ai pas pu obtenir de réponse claire.

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

Il y avait un vide criant dans ma question dans l'origine des données de la demande. Dans ce cas, l’origine des données se fait via une interface Websphere MQ. Websphere MQ dispose de fonctionnalités permettant de convertir en un codage correct. Toutefois, il s’agit uniquement de lire les données à l’aide de MQMessage.readString (), qui est depuis déconseillé. Je préférerais utiliser ceci, mais j'utilise un framework d'interface propriétaire dans lequel je ne peux pas changer la façon dont le message est lu dans MQQueue, qui lit directement des octets dans la file d'attente et me laisse donc gérer la traduction.

Réponse finale: Je voulais faire un suivi à ce sujet. Il s'avère que le bon jeu de caractères était bien cp500 (IBM-500). Cependant, j'ai l'impression que les résultats peuvent varier. Quelques conseils pour ceux qui ont 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 jeux et imprimé mes données d'octet traduites dans ce jeu de caractères. Même si cela ne m'a pas donné la réponse que je voulais (principalement parce que je ne pouvais pas lire les données car elles arrivaient), j'imagine que cela pourrait être utile pour les autres.

Consultez la page http://mindprod.com/jgloss/encoding pour obtenir la liste des supports pris en charge. jeux de caractères.

Enfin, même si je n’ai pas confirmé cela, assurez-vous d’utiliser le bon JRE. Je pense que les IBM Runtimes prennent en charge davantage de jeux de caractères EBCDIC que OpenJDK ou les Runtimes de Sun.

Answer 1

"MVS est un peu un système hérité" Ha! C'est toujours le système d'exploitation de choix pour les applications où la fiabilité est la principale préoccupation. Passons maintenant à votre question: -)

Cela dépend entièrement de ce qui génère les données. Par exemple, si vous ne téléchargez que des fichiers à partir de l'hôte, la négociation FTP peut le gérer. Mais puisque vous parlez de Java, il s’agit probablement d’une connexion JDBC à DB2 / z, et les pilotes JDBC s’en tireront très bien (bien mieux si vous utilisez le JRE d’IBM plutôt que la version Sun).

EBCDIC lui-même sur l'hôte a plusieurs encodages différents, vous devez donc au moins nous dire d'où proviennent les données. Les versions récentes de DB2 n’ont aucun problème à stocker Unicode dans la base de données, ce qui atténuerait toutes vos préoccupations.

Première tâche, recherchez l’origine des données et obtenez l’encodage de votre SysProg (s’il n’est pas automatiquement traité).

Mise à jour:

Andrew, en fonction de votre texte ajouté dans lequel vous indiquez que vous ne pouvez pas utiliser les traductions fournies, vous devrez utiliser la méthode manuelle. Vous devez identifier la source des données et en extraire le CCSID. Effectuez ensuite la traduction vers et depuis Unicode (ou la page de code que vous utilisez si ce n’est pas Unicode) manuellement.

Le CCSID 500 est la page de code par défaut d’EBCDIC International (pas d’Euro), mais ces machines sont utilisées dans le monde entier. Les services de conversion z / OS sont la méthode habituelle de conversion sur l’ordinateur central.

Bien que cette soit une page iSeries, il répertorie un grand nombre de CCSID et leurs glyphes, applicables également à l’ordinateur central.

Vous avez probablement juste besoin de savoir si vous utilisez le CCSID 500 ou 37 (ou l’une des versions en langue étrangère) et de définir le mappage avec Unicode CCSID 1208. Votre SysProg pourra vous dire laquelle. Si vous travaillez pour une entreprise américaine, cela probablement 500 ou 37, mais IBM déploie beaucoup d’efforts pour prendre en charge plusieurs pages de code. Je serai heureux lorsque tous leurs logiciels mainframe enregistrent et utilisent Unicode par défaut, cela facilitera grandement les choses.