ibm-mq - 不同平台上 MQ 管理器上的 CCSID

Question

如果基于 Solaris 的 MQ 管理器将消息发送到中间的 Windows MQ 管理器，然后再将消息发送到 Linux MQ 管理器，是否需要将它们的 CCSID 都更改为相同？我不这么认为，但我被迫这样做......

我遇到一个问题，客户端通过 Windows 上的中间 MQ 管理器从 Solaris 上的应用程序发送消息，但基于 Linux MQ 管理器最终目标的应用程序收到的消息带有它无法处理的 CR/LF 行结束字符.接收端组要不要写一个转换导出程序？还是 MCA？

Answer 1

IBM MQ 不处理换行。它不像使用 ftp 传输文件并使用 ascii 模式，其中 ftp 将从 Unix LF 行尾转换为 Window CR 和 LF 行尾。对于 MQ，它只是要翻译的字符集中的另一个字符。如果发送应用程序正在发送包含 CR/LF 字符的数据，MQ 会将它们视为数据中的任何其他字符。如果接收应用程序希望将带有行尾的文件作为 MQ 消息发送，则需要处理行尾。

---

在 Solaris 服务器上运行的 Java 应用程序的 MQ 类默认为 CCSID 819，在 Solaris 上运行的 IBM MQ 队列管理器也将默认为 CCSID 819。CCSID 819被描述为 ISO 8859-1 ASCII。

我创建了一个名为 test.txt 的文件，其中包含单个单词“test”并对该文件运行了 unix2dos。

下面的输出将 ASCII 字符显示为十六进制值:

$cat test.txt | hexdump -C
00000000  74 65 73 74 0d 0a                                 |test..|
00000006

请注意，在上面的输出中，ASCII 十六进制值 0d 是 CR 而 0a 是 LF ，这些是常见的 Windows 行尾。

如果我们假设默认的 CCSID 819 用于 Solaris MQ Classes for Java 应用程序和 Solaris 队列管理器，那么我们可以开始假设以上两个十六进制值表示末尾的 CR/LF每行。

您声明您的 Windows 队列管理器具有 CCSID 437，这对于美国的 Windows 服务器来说是典型的。 CCSID 437被描述为 USA PC-DATA 并且也是 ASCII。

Linux 队列管理器通常默认为 CCSID 1208。CCSID 1208被描述为 UTF-8 with IBM PUA 并且是一个可变字节字符集，每个字符可以有 1 到 4 个字节。这可以表示超过一百万个字符，包括所有 ASCII 字符。所有 127 个 ASCII 字符在 UTF-8 中表示为与 ASCII 中相同的单字节十六进制值。

从 ASCII 到 UTF-8 的损失较少，如果使用非 ASCII 字符，从 UTF-8 到 ASCII 可能会有损失，因为 ASCII 中没有等效字符，MQ 将其​​转换为默认替换字符十六进制值 1A。例如，我已经看到这个带有欧元符号。大多数(如果不是全部)UTF-8 的前 255 个字符与 CCSID 819 相同。

鉴于上述 CCSID 假设，转换将如下所示:

用于在 Solaris 上运行的 Java 应用程序的原始 IBM MQ 类发送带有 CR/LF 行尾字符的数据:

$cat test.txt | hexdump -C
00000000  74 65 73 74 0d 0a                                 |test..|
00000006

带有 CONVERT(YES) 的 Solaris 队列管理器发送 channel 发送到带有 CCSID 437 的 Windows 队列管理器:

cat test.txt | iconv -f IBM819 -t IBM437 | hexdump -C
00000000  74 65 73 74 0d 0a                                 |test..|
00000006

正如预期的那样，输出是相同的，因为 819 和 437 都是 ASCII 字符集，并且数据不代表前 127 个 ASCII 字符以上的任何内容。

带有 CONVERT(YES) 的 Solaris 队列管理器发送器 channel ，使用 CCSID 437 发送到 Windows 队列管理器 带有 CONVERT(YES) 的发送器 channel ，使用 CCSID 1208 发送到 Linux 队列管理器:

cat test.txt | iconv -f IBM819 -t IBM437 | iconv -f IBM437 -t UTF-8 | hexdump -C
00000000  74 65 73 74 0d 0a                                 |test..|
00000006

正如预期的那样，输出是相同的，因为 819 和 437 都是 ASCII 字符集，而 UTF-8 (1208) 的前 127 个字符是普通的 ASCII 字符。

---

总结:如果发送应用程序在数据中发送 CR/LF，MQ 消息转换不会改变这一点，如果使用的 CCSID 是上面列出的 CCSID，它甚至不会改变实际的十六进制字符值。发送应用程序需要更改它们发送的内容，或者接收应用程序需要容纳这些字符。

---

可以在文章“Unicode, UTF8 & Character Sets: The Ultimate Guide”中找到关于 ASCII、UNICODE、UTF-8 等的很好的引用。