Ibm midrange 解包为400压缩十进制（BCD）-可能是EBCDIC转换造成的？

我正在通过FTP将文件从AS/400传输到我们的Windows（SBS2003）。这些文件是固定宽度的数据。文本看起来很好，但有些字段是压缩的小数，解包时会给出错误的值。我的假设是，有一个隐式的EBCDIC->ASCII转换正在发生，它也在转换压缩字节。然而，进行反向转换和解包仍然会产生不好的值…有时

我猜他们使用的代码页略有不同（所以当我转换回EBCDIC时就不太一样了），但我不知道如何找出他们使用的是什么代码页（他们的it人员……有点固执……否则他们可以在二进制模式下进行FTP，跳过所有这些问题）

这里是一些示例数据-这些数据应该解包为8位数字，实际上是YYYYMMDD格式的日期

Received:
2,0,216,202,164
2,0,144,22,177
2,0,16,176,172
2,0,16,176,172
2,0,16,176,172
2,0,16,176,172
1,114,176,160,124
2,0,248,32,63
2,0,144,226,164
2,0,144,226,164
2,0,144,226,164
2,0,144,202,124
2,0,144,202,124
2,0,144,176,172
2,0,144,176,172
2,0,32,22,63
2,0,38,248,172
2,0,38,248,172
2,0,38,98,164
2,0,233,1,15
2,0,45,107,172
1,114,176,226,26
1,114,176,38,177
1,114,176,97,164
2,0,0,17,124
2,0,128,129,31
2,0,128,129,31
2,0,128,129,31
2,0,128,129,31
2,0,128,129,31
2,0,128,129,31
2,0,216,17,63
2,0,160,17,31
2,0,160,128,34
2,0,160,129,26
2,0,38,128,31
2,0,38,144,26
1,114,97,16,124
1,114,97,16,124
2,0,38,234,26
2,0,38,201,172
2,0,45,38,124
2,0,45,216,164
2,0,45,107,177
2,0,248,234,124
2,0,248,202,34
2,0,248,18,172
2,0,97,128,172
2,0,248,18,7
2,0,248,233,15
2,0,201,2,15
2,0,176,16,7
2,0,106,0,31
2,0,216,22,34
2,0,216,160,63
2,0,38,107,7
2,0,233,0,63
2,0,38,107,164
2,0,233,0,26
2,0,38,107,34
2,0,233,0,164
2,0,233,17,15
2,0,45,202,177
2,0,45,106,7
2,0,45,97,177
2,0,47,16,31
2,0,248,216,177
2,0,201,0,172
2,0,176,201,63
2,0,248,97,34
2,0,176,202,26
2,0,248,97,34
2,0,201,2,172
2,0,201,17,164
2,0,176,129,164
2,0,201,17,172
2,0,176,144,7
2,0,145,2,164
2,0,32,145,15
2,0,38,45,26
2,0,38,38,63
2,0,38,233,26
2,0,38,248,34
2,0,45,202,164
2,0,45,107,124
2,0,47,17,15
2,0,47,16,31
2,0,47,130,34
2,0,248,45,177
2,0,106,0,31
2,0,248,22,31
2,0,248,202,172
2,0,248,97,172
2,0,47,128,177
2,0,201,2,164
2,0,216,201,164
2,0,176,16,34
2,0,216,201,34

下面是要转换回ebcdic的代码页，该代码页不太正常：

---

尝试使用程序员工具包（Access for Windows的一部分）提供的VB可用的转换例程和代码页查询与转换函数

这些是ActiveX对象。不太难从VB中使用

(long) AS400System.HostCodePage  // tells you the host's code page  
(object) PackedConverter         // convert between numeric strings and  byte arrays  
(object) CodePageConverter       // convert text data between iSeries and PC code pages

---

尝试使用程序员工具包（Access for Windows的一部分）提供的VB可用的转换例程和代码页查询与转换函数

这些是ActiveX对象。不太难从VB中使用

(long) AS400System.HostCodePage  // tells you the host's code page  
(object) PackedConverter         // convert between numeric strings and  byte arrays  
(object) CodePageConverter       // convert text data between iSeries and PC code pages

---

对不起，我对VB了解不多，对iSeries FTP了解更多。iSeries FTP确实在进行从EBCDIC到ASCII的自动转换。FTP正在为此使用系统表QEBCDIC和QASCII。您可以使用命令WRKTBL找到这些表

我建议您检查这些表中的值，并检查它们是否与您的文件匹配。如果不是，我认为VB也在做一些转换

重要提示：如果问题出在iSeries上，那么您可以使用其他翻译表以及其他字符集。您可以在FTP命令中更改这些值（如果您从iSeries发送到Windows或FTP服务器（如果允许您这样做）

您永远不应该做的是更改系统表本身（只有在您没有胆怯的情况下…）。复制这些表，更改任何您想要的，并指向这些新表

此外，在FTP会话中学习服务器端命令可能是值得的。在本地FTP会话中，您可以要求iSeries为您做很多事情。这些命令不是标准的FTP命令，而是iSeries特有的命令

---

希望这有帮助。

对不起，我不太了解VB，更不了解iSeries FTP。iSeries FTP确实在自动将EBCDIC转换为ASCII。FTP为此使用系统表QEBCDIC和QASCII。您可以使用命令WRKTBL找到这些表

我建议您检查这些表中的值，并检查它们是否与您的文件匹配。如果不匹配，我认为VB也在进行一些转换

重要提示：如果问题出在iSeries上，那么您可以使用其他翻译表以及其他字符集。您可以在FTP命令中更改这些值（如果您从iSeries发送到Windows或FTP服务器（如果允许这样做）

您永远不应该做的是更改系统表本身（只有在您没有胆怯的情况下…）。复制这些表，更改任何您想要的，并指向这些新表

此外，在FTP会话中学习服务器端命令可能是值得的。在本地FTP会话中，您可以要求iSeries为您做很多事情。这些命令不是标准的FTP命令，而是iSeries特有的命令

希望这能有所帮助。

是的，EBCDIC-->ASCII转换将破坏压缩十进制字段，因为压缩十进制中的某些字节将转换为ASCII

正如您发现的那样，执行EBCDIC-->ASCII-->ASCII将不起作用，因为多个EBCDIC字符可以映射到一个ASCII字符，而多个ASCII字符可以映射到一个EBCDIC字符。通常，在压缩十进制字段中找不到显示字符时，会发生此转换错误

解决办法是 1） 在AS400和trnsmit上打开包装 2） 进行二进制传输。您可以使用RecordEditor（）来查看该文件。然后，您应该能够将数据剪切并粘贴到文本编辑器中

注：对于EBCDIC，请使用CP037（编码页37或您使用的任何编码页）。 RecordEditor将允许您定义压缩十进制字段 如果你有一本Cobol文案；您可以尝试将副本作为大型机导入 copybook（可能有用？

是的，EBCDIC-->ASCII转换将破坏压缩十进制字段，因为压缩十进制中的某些字节将转换为ASCII

正如您发现的那样，执行EBCDIC-->ASCII-->ASCII将不起作用，因为多个EBCDIC字符可以映射到单个ASCII字符，而多个ASCII字符可以映射到单个EBCDIC字符。通常，在压缩十进制字段中找不到显示字符时，会发生此转换错误

解决办法是 1） 在AS400和trnsmit上打开包装 2） 进行二进制传输。您可以使用RecordEditor（）来查看该文件。然后，您应该能够将数据剪切并粘贴到文本编辑器中

注：对于EBCDIC，请使用CP037（编码页37或您使用的任何编码页）。 RecordEditor将允许您定义压缩十进制字段 如果你有一本Cobol文案；您可以尝试将副本作为大型机导入

---

copybook（可能有用？）

您使用什么语言编写代码来转换它们？根据语言的不同，有不同的解决方案。很抱歉这么晚才收听；你把这个问题解决了吗？如果没有，有哪些成功获得的数字数据和有问题的数字数据？（你说的只是部分结果。）