Quale codepage / charset dovrebbe essere usato per interpretare i dati provenienti da un sistema MVS in un ambiente Java?

Question

Ho riscontrato un problema interessante (come spesso accade nell'interazione con i sistemi legacy). Sto lavorando a un'applicazione (che attualmente funziona su un sistema x86 Linux o Windows) che può ricevere richieste da una varietà di sistemi, uno dei quali è un sistema MVS.

Sto tentando di determinare quale codepage / charset dovrei usare per interpretare i dati di richiesta provenienti dal sistema MVS.

In passato, ho usato 'cp500' (IBM-500) per interpretare la data in byte in arrivo per i sistemi z / OS, tuttavia temo che dal momento che MVS sia un po 'un sistema legacy, e che dal momento che IBM sembrava cambia idea coerentemente rispetto a quale codifica usare (ci devono essere decine di codifiche EBCDIC), che cp500 potrebbe non essere la codifica corretta.

La migliore risorsa che ho trovato sui set di caratteri in Java è: http://mindprod.com/jgloss / codifica . Tuttavia, da questo sito e da IBM Infocenters, non sono stato in grado di ottenere una risposta chiara.

EDIT: aggiunto dalla mia risposta a Pax di seguito:

C'era un buco evidente nella mia domanda sull'origine dei dati della richiesta. In questo caso, l'origine dei dati è attraverso un'interfaccia Websphere MQ. Websphere MQ ha funzionalità per tradurre nella codifica corretta, tuttavia ciò è solo per la lettura dei dati utilizzando MQMessage.readString (), che da allora è stato deprecato. Preferirei usarlo, tuttavia sto usando un framework di interfaccia proprietario in cui non riesco a cambiare il modo in cui il messaggio viene letto da MQQueue, che legge i byte direttamente dalla coda e quindi mi rimane la traduzione dell'handle.

Risposta finale: volevo dare seguito a questo. Si scopre che il set di caratteri corretto era effettivamente cp500 (IBM-500). Tuttavia, ho l'impressione che i risultati possano variare. Alcuni consigli per chiunque abbia lo stesso problema:

Utilizza Charset.availableCharsets () ;. Questo ti darà una mappa dei set di caratteri supportati nel tuo tempo di esecuzione. Ho ripetuto questi set e stampato i miei dati byte tradotti in quel set di caratteri. Anche se non mi ha dato la risposta che volevo (principalmente perché non ero in grado di leggere i dati mentre stavano arrivando), immagino che potrebbe essere utile per gli altri.

Fare riferimento a http://mindprod.com/jgloss/encoding per un elenco dei supportati set di caratteri.

Infine, anche se non l'ho confermato, ma assicurati di utilizzare il JRE giusto. Sto pensando che IBM Runtimes supporta più set di caratteri EBCDIC rispetto a OpenJDK o Sun's Runtimes.

Answer 1

"MVS è un po 'un sistema legacy"? Ha! È ancora il sistema operativo scelto per le applicazioni in cui l'affidabilità è la principale preoccupazione. Passiamo ora alla tua domanda :-)

Dipende interamente da ciò che sta generando i dati. Ad esempio, se stai semplicemente scaricando file dall'host, la negoziazione FTP potrebbe gestirlo. Ma dal momento che menzioni Java, probabilmente si sta connettendo tramite JDBC a DB2 / z, e i driver JDBC lo gestiranno abbastanza bene (molto meglio se stai usando il JRE di IBM piuttosto che la versione Sun).

EBCDIC stesso sull'host ha alcune codifiche diverse, quindi è necessario almeno farci sapere da dove provengono i dati. Le versioni recenti di DB2 non hanno alcun problema con la memorizzazione di Unicode nel database, il che allevia tutte le preoccupazioni.

Prima attività, scopri da dove provengono i dati e ottieni la codifica da SysProg (se non viene gestita automaticamente).

Aggiornamento:

Andrew, in base al testo aggiunto in cui dichiari di non poter utilizzare le traduzioni fornite, dovrai utilizzare il metodo manuale. È necessario identificare la fonte dei dati e ricavarne il CCSID. Quindi esegui la traduzione da e verso Unicode (o qualunque altra tabella codici stai utilizzando se non Unicode) manualmente.

CCSID 500 è la codepage predefinita per EBCDIC International (no Euro) ma queste macchine sono utilizzate in tutto il pianeta. I servizi di conversione z / OS sono il modo in cui generalmente si esegue la conversione sul mainframe.

Sebbene questa è una pagina iSeries, elenca un numero enorme di CCSID e dei loro glifi, applicabile anche al mainframe.

Probabilmente devi solo capire se stai usando CCSID 500 o 37 (o una delle versioni in lingua straniera) e elaborare la mappatura con Unicode CCSID 1208. Il tuo SysProg sarà in grado di dirti quale. Se lavori per una società statunitense, probabilmente 500 o 37, ma IBM dedica molto impegno a supportare più tabelle di codici. Sarò felice quando tutti i loro software mainframe memorizzeranno e utilizzeranno Unicode per impostazione predefinita, renderà le cose molto più facili.