应该使用什么代码页/字符集来解释来自MVS系统的数据到Java环境中？

Question

我遇到了一个有趣的问题（通常与遗留系统交互的情况）。我正在开发一个应用程序（目前在x86 Linux或Windows系统上运行），它可以接收来自各种系统的请求，其中一个是MVS系统。

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

在过去，我使用'cp500'（IBM-500）来解释z / OS系统的字节日期，但是我担心因为MVS有点遗留系统，而且因为IBM似乎关于使用什么编码（必须有数十个EBCDIC编码），一致地改变它的思想，cp500可能不是正确的编码。

我在Java中的字符集中找到的最佳资源是： http://mindprod.com/jgloss /编码。但是，从这个站点和IBM Infocenters，我一直无法得到明确的答案。

编辑：从我对Pax的回复中添加：

在我的问题中，请求数据的来源存在一个明显的漏洞。在这种情况下，数据的来源是通过Websphere MQ接口。 Websphere MQ确实具有转换为正确编码的功能，但这只是用于使用MQMessage.readString（）读取数据，而后者已被弃用。我更喜欢使用它，但是我使用的是专有的接口框架，我无法改变从MQQueue读取消息的方式，MQQueue直接从队列中读取字节，因此我处理了句柄翻译。

最终答案：我想跟进此事。事实证明，正确的字符集确实是cp500（IBM-500）。但是，我的印象是结果可能会有所不同。对于有同样问题的其他人的一些提示：

利用Charset.availableCharsets（）;.这将为您提供运行时支持的字符集的映射。我遍历这些集并打印出我的字节数据转换成该字符集。虽然它没有给我我想要的答案（主要是因为我无法读取数据），我想它可能对其他人有帮助。

请参阅： http://mindprod.com/jgloss/encoding 获取支持列表char sets。

最后，虽然我没有证实这一点，但确保您使用正确的JRE。我认为IBM Runtimes支持更多的EBCDIC字符集，然后是OpenJDK或Sun的Runtimes。

Answer 1

“MVS有点遗留系统”？哈！对于可靠性是头号问题的应用，它仍然是首选的操作系统。现在回答你的问题： - ）

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

主机上的EBCDIC本身有很多不同的编码，因此您至少需要告诉我们数据的来源。最新版本的DB2没有在数据库中存储Unicode的问题，这将减轻您的所有顾虑。

第一项任务，找出数据的来源并从SysProg获取编码（如果没有自动处理）。

<强>更新

安德鲁，根据您添加的文字，您声明无法使用提供的翻译，您将不得不使用手动方法。您需要识别数据的来源并从中获取CCSID。然后手动执行与Unicode（或您正在使用的任何代码页，如果不是Unicode）的转换。

CCSID 500是EBCDIC International（无欧元）的默认代码页，但这些机器遍布全球。 z / OS转换服务是您通常在大型机上进行转换的方式。

虽然此是iSeries页面，它列出了大量的CCSID及其字形，也适用于大型机。

您可能只需要弄清楚您是使用CCSID 500还是37（或其中一种外语版本）并使用Unicode CCSID 1208进行映射。您的SysProg将能够告诉您哪一个。如果您在美国公司工作，它可能 500或37，但IBM花费了大量精力支持多个代码页。我很高兴当他们的所有大型机软件都默认存储并使用Unicode时，它会让事情变得更容易。