我遇到了一个有趣的问题(与遗留系统进行交互时通常是这种情况).我正在开发一个可以接收来自各种系统的请求的应用程序(当前在x86 Linux或Windows系统上运行),其中一个是MVS系统.

我试图确定应该使用哪个代码页/字符集来解释来自MVS系统的请求数据.

过去,我曾使用’cp500′(IBM-500)来解释z / OS系统的字节日期,但是我担心由于MVS有点遗留系统,而且由于IBM似乎改变了主意,对于要使用的编码方式(必须有数十种EBCDIC编码),如果保持一致,则cp500可能不是正确的编码.

在Java字符集上找到的最佳资源是：http://mindprod.com/jgloss/encoding.但是,从该站点以及IBM Infocenters,我无法获得明确的答案.

编辑：从我对Pax的回复中添加以下内容：

在我的问题中,请求数据的来源存在一个明显的漏洞.在这种情况下,数据的起源是通过Websphere MQ接口实现的. Websphere MQ确实具有转换为正确编码的功能,但是仅用于使用MQMessage.readString()读取数据,此功能已被弃用.我更喜欢使用它,但是我使用的是专有的接口框架,在该接口框架中,我无法更改从MQQueue读取消息的方式,该方法直接从Queue读取字节,因此我只能处理句柄.

最终答案：我想跟进此事.原来正确的字符集确实是cp500(IBM-500).但是,我觉得结果可能会有所不同.给其他遇到相同问题的人的提示：

利用Charset.availableCharsets();.这将为您提供运行时支持的字符集的映射.我遍历了这些集合,并打印出我的字节数据,并将其转换为该字符集.尽管它没有给我我想要的答案(主要是因为传入的数据无法读取),但我认为它可能对其他人有所帮助.

有关支持的字符集的列表,请参阅：http://mindprod.com/jgloss/encoding.

最后,尽管我尚未确认这一点,但请确保您使用的是正确的JRE.我认为IBM Runtimes比OpenJDK或Sun的Runtimes支持更多的EBCDIC字符集.

解决方法:

“ MVS有点旧系统”？哈！对于可靠性是首要考虑因素的应用,它仍然是首选的操作系统.现在开始您的问题:-)

这完全取决于生成数据的内容.例如,如果您只是从主机下载文件,则FTP协商可能会处理它.但是,既然您提到Java,它可能是通过JDBC连接到DB2 / z,并且JDBC驱动程序将很好地处理它(如果使用的是IBM自己的JRE而不是Sun版本,那就更好了).

主机上的EBCDIC本身具有许多不同的编码,因此您至少需要让我们知道数据来自何处. DB2的最新版本在将Unicode存储在数据库中没有问题,这可以减轻您的所有麻烦.

第一项任务,找出数据来自何处,并从SysProg获取编码(如果未自动处理).

更新：

安德鲁,根据您添加的文字(您声明无法使用提供的翻译),您将不得不使用手动方法.您需要标识数据源并从中获取CCSID.然后手动进行Unicode(如果不是Unicode,则使用您正在使用的任何代码页)之间的转换.

CCSID 500是EBCDIC International的默认代码页(无欧元),但这些机器在全球范围内使用. z / OS转换服务是您通常在大型机上进行转换的方式.

尽管this是iSeries页面,但是它列出了大量CCSID及其字形,它们也适用于大型机.

您可能只需要弄清楚您使用的是CCSID 500还是37(或外语版本之一),并使用Unicode CCSID 1208进行映射.您的SysProg就能告诉您哪个.如果您在一家美国公司工作,则可能是500或37,但是IBM花费了大量精力来支持多个代码页.当他们所有的大型机软件默认都存储并使用Unicode时,我会感到很高兴,它将使事情变得更加轻松.