1
votes

CICS TS (DFHJS2LS): les caractères chinois sont corrompus lorsqu'ils sont reçus dans MAINFRAME à partir de l'outil POSTMAN

Nous avons développé un service Web ayant CICS comme serveur HTTP (fournisseur de services). Ce Webservice prend l'entrée JSON (qui a à la fois des caractères anglais et chinois) de n'importe quel outil client / POSTMAN et sera traitée dans Mainframe (CICS).

DFHJS2LS: schéma JSON en conversion de langage de haut niveau pour les services de requête-réponse

Nous utilisons ce processus - DFHJS2LS pour activer les services Web dans Mainframe. Cette procédure fournie par I BM effectue la conversion du cahier JSON en MF et vice-versa. En outre, il convertit l'unité de code UTF-8 en UTF-16 lorsqu'il atteint le cahier de l'ordinateur central.

Le problème auquel nous sommes confrontés actuellement concerne les caractères chinois. Les caractères chinois que nous transmettons dans JSON ne sont pas convertis correctement et ils sont corrompus lorsqu'ils sont reçus dans le mainframe. La conversion de UTF-8 en UTF-16 ne se produit pas (c'est mon suspect).

市 - c'est le caractère chinois passé en JSON (POSTMAN).

La valeur attendue dans le cahier Mainframe est 5E02 (UTF-16 - valeur hexadécimale) mais nous avons 00E5 00B8 0082 (valeur hexadécimale UTF-8)

nous avons essayé toutes les valeurs d'en-tête et toujours pas de chance ..... type de contenu = application / json jeu de caractères = UTF-8 / UTF-16

Vos contributions sont très appréciées pour résoudre ce problème de caractères DBCS / unicode / chinois.


2 commentaires

Quels sont les résultats du fait que votre programmeur de systèmes CICS exécute une trace montrant le contenu de votre message?


Salut cschneid, merci d'avoir répondu ... Même nos programmeurs de systèmes CICS n'en ont aucune idée. La trace ne montre aucun signe d'erreur. La conversion de UTF-8 -> UTF-16 est ce qui ne se passe pas


3 Réponses :


0
votes

Dans le COBOL, déclarez-vous le fichier qui recevra les caractères chinois comme Pic G:

01 China-Test-Message. 03 Msg-using-pic-x Pic X (10). 03 Msg-using-pic-g Pic G (4) Affichage d'utilisation-1.


1 commentaires

la procédure DFHJS2LS fournit la structure du cahier avec tous les champs en tant que type de données national. et nous avons utilisé la même chose. 05 test-CHNNEL-LEN PIC S9999 COMP-5 VALEUR SYNC 0. 05 test-CHNNEL-NM PIC N (20) UTILISATION DES ESPACES DE VALEUR NATIONALE.



0
votes

Essayez "USAGE NATIONAL" qui doit être converti en UTF-16 qui est probablement la page de code du caractère chinois.

RTFM ici: - https://www.ibm.com/support/ knowledgecenter / SS6SG3_6.3.0 / pg / concepts / cpuni01.html


1 commentaires

oui, nous avons utilisé le même James. le problème est que la variable cible du cahier est de la clause PIC - NATIONAL. Mais notre soupçon est que la procédure - DFHJS2LS ne charge pas les champs du cahier après l'avoir converti en UTF-16



0
votes

La conversion chinoise est résolue une fois que nous avons changé notre en-tête HTTP en ceci -

Content-Type = application / json; charset = UTF-8

Merci à tous pour le soutien.


0 commentaires