【问题标题】:caret ^ is converting to some special symbol插入符号 ^ 正在转换为一些特殊符号
【发布时间】:2022-06-17 11:49:27
【问题描述】:

我正在将具有如下内容的文件从大型机系统传输到 Unix 实例。我在文件中有一个分隔符^&*。我在大型机中发送相同的内容,但是当我们在 unix 中收到文件时,我们收到的是Ø&*

我正在使用直接连接将文件从一个系统传输到另一个系统。

文件类型:平面文件,文件传输:CD(直接连接)

文件内容

H^&*20220407^&*160009^&*2006
T^&*1

但是当我在 unix 服务器中收到文件时,我可以更改文件内容。主要是^转换成Ø

HØ&*20220407Ø&*160009Ø&*2006
TØ&*1

【问题讨论】:

  • 我建议您使用反引号来显示特殊字符(显然,当您的特殊字符是反引号时,您需要以另一种方式工作)。星号在本网站中用作格式化字符(一个星号表示 italic 字体,两个星号表示 bold 字体)。
  • transferring 怎么样?使用什么协议?什么介质?什么格式? the file什么文件?文件的内容究竟是什么?请发布一个sn-p。 from mainframe system到底是什么系统?什么架构?该系统上正在运行什么?什么程序以什么方式发送数据? to a open system 究竟是什么系统?什么架构? is on Unix什么unix版本?你在 PDP-7 上运行吗?是Linux吗?如果是这样,什么分布?什么程序正在接收数据?
  • I'm sending the same 你是如何准确检查的? when we receive the file 你是如何准确检查的?你用过什么工具?如果您使用了任何命令,您究竟使用了什么命令?请发布minimal reproducible example,指定您正在使用的工具和版本,指定您正在使用的环境。您标记了ebcdicascii - 它们与您的问题有什么关系?请在两个系统上发布locale 输出(如果有)。系统是否与 POSIX 兼容?这些系统上的locale 输出(如果有)是什么?他们使用的是什么 C 标准库(如果有的话)?等等
  • 我真的很想在十六进制中看到这个,以防它们真的是 ¬ 字符。还有你的 3270 模拟器的代码页。

标签: linux unix mainframe


【解决方案1】:

这肯定是代码页问题。

大型机上文件中的数据(很可能)在某些 EBCDIC 代码页中。当将文件发送到该 UNIX 系统时,ConnectDirect 正在执行代码页转换。这就是XLATE(YES) 的含义。

但是,配置了一些默认代码页“from”-“to”对,与XLATE(YES) 一起使用。但这可能不是正确的配对。你需要

  • 找出大型机上的数据编码在哪个EBCDIC代码页中。是IBM-037、IBM-1047、IBM-500、IBM-273等。有很多。
  • 找出数据在 UNIX 端的代码页:UTF-8、ISO8859-1、437 等。有很多。
  • 确保 ConnectDirect 将使用正确的源代码页和目标代码页进行转换。

请您的 ConnectDirect 支持人员帮助您解决此问题。

【讨论】:

    【解决方案2】:

    确实如你所说。我们大型机 SP 团队中的某个人也做出了同样的回应,并且现在显然已由 Linux SA 解决,并带有一些定制的 xlt。

    尽管 Linux/Unix 也应该遵循 m/f 作为发送端和接收端 xlt 的“不可更改”平台有点不公平。

    事实上,我们现在非常需要你们团队的全方位专业知识。 非常感谢您的慷慨建议。 ?

    最好, 威尔逊 L.

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2015-09-29
      • 1970-01-01
      • 1970-01-01
      • 2017-08-12
      • 2017-08-15
      • 1970-01-01
      • 1970-01-01
      • 2016-01-05
      相关资源
      最近更新 更多