3

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

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

过去，我使用 'cp500' (IBM-500) 来解释 z/OS 系统的字节日期，但是我担心 MVS 有点像遗留系统，而且因为 IBM 似乎改变了主意对于要使用的编码（必须有数十个 EBCDIC 编码），cp500 可能不是正确的编码。

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

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

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

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

利用 Charset.availableCharsets();。这将为您提供运行时支持的字符集的地图。我遍历这些集合并打印出我的字节数据翻译成该字符集。虽然它没有给我想要的答案（主要是因为我无法在数据进入时读取数据），但我想它可能对其他人有所帮助。

请参阅：http ://mindprod.com/jgloss/encoding以获取支持的字符集列表。

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

4

1 回答 1

3

“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 时，我会很高兴，这会让事情变得更容易。

于 2009-05-04T04:33:51.037 回答