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

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

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

在过去，我曾使用“cp500”（IBM-500）来解释z/OS系统的字节日期，但我担心，由于MVS有点像一个遗留系统，而且由于IBM似乎在使用哪种编码（必须有几十种EBCDIC编码）方面始终如一地改变主意，cp500可能不是正确的编码

我在Java中找到的关于字符集的最佳资源是：。然而，从这个网站和IBM信息中心，我还没有得到一个明确的答案

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

在我的问题中，请求数据的来源有一个明显的漏洞。在本例中，数据的来源是通过WebSphereMQ接口。Websphere MQ确实具有转换为正确编码的功能，但是，这仅用于使用MQMessage.readString（）读取数据，而MQMessage.readString（）已被弃用。我更愿意使用它，但是我使用的是一个专有接口框架，在这个框架中，我无法更改从MQQueue读取消息的方式，MQQueue直接从队列读取字节，因此我只能处理转换

最后的回答：我想跟进这件事。事实证明，正确的字符集确实是cp500（IBM-500）。然而，我的印象是，结果可能会有所不同。给其他有同样问题的人的一些提示：

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

有关支持的字符集的列表，请参阅

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

“MVS有点像遗留系统”？哈对于可靠性是首要考虑的应用程序来说，它仍然是首选的操作系统。现在谈谈你的问题：-）

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

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

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

更新：

Andrew，根据您添加的文本，您声明无法使用提供的翻译，您必须使用手动方法。您需要标识数据源并从中获取CCSID。然后手动执行与Unicode的转换（如果不是Unicode，也可以执行您正在使用的任何代码页）

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

虽然是iSeries页面，但它列出了大量CCSID及其图示符，也适用于大型机

---

您可能只需要确定您使用的是CCSID 500还是37（或外语版本之一），然后使用Unicode CCSID 1208计算映射。您的SysProg将能够告诉您是哪一个。如果你在一家美国公司工作，它可能是500或37，但是IBM花费了大量精力来支持多个代码页。我很高兴他们所有的大型机软件都默认存储并使用Unicode，这会让事情变得更简单。

Andrew，availableCharsets（）会告诉您可以处理什么，但不会给出您应该为特定数据集使用哪个。你仍然需要发现，否则你的转换将返回垃圾。但是关于IBMs JRE，您是对的-它为z/OS.Pax提供了额外的内容，您完全正确，CCSID 500（IBM-500，cp500）是正确的代码页，再次感谢您的支持。