Linux 环境使用 rz 命令上传中文文件乱码

2018/06/06 Linux

最近遇到用 rz 命令上传中文文件的时候出现中断,然后在接收端中打印乱码。按照以往的经验,这时候加上 -be 参数就解决了。
事实是确实解决了,但是总是不知道原理也挺难受的,所以花了点时间查了一下。

rz 的手册里可以看到:

-b, --binary
	Binary (tell it like it is) file transfer override.
-e, --escape
	Force sender to escape all control characters; normally XON, XOFF, DLE, CR-@-CR, and Ctrl-X are escaped.

-b 选项表示以二进制形式传输,-e 表示发送过程中要转译所有的控制符。这跟传输中断和乱码有什么关系呢?

由于拖延症时间隔得比较久了,找不到当时的文件,只能结合网上的资料猜想一下。

当时是在 Windows 环境用 Xshell 向 Linux 服务器传输文件,默认可能是 ASCII 模式传输。ASCII 模式下,会尝试对行尾符号做转换。众所周知的 Window 和 Unix 的换行符是不一样的。所以可能是在转换的过程中失败退出了。

而二进制传输,不会做任何转换,因此就不存在因为特殊符号失败退出的问题。

不过这样一来,那么不加 -e 参数应该也能传输成功?下次遇到的时候验证一下。

ASCII type is used to transfer text files. The problem with text files is that different platforms have different kinds of line endings. Microsoft Windows for example uses a CR+LF pair (carriage return and line feed), while Unix(-like) systems, including Linux and MacOS X, only use LF and traditional MacOS systems (MacOS 9 or older) only use CR. The purpose of ASCII type is to ensure that line endings are properly changed to what is right on the platform. According to the FTP specification, ASCII files are always transferred using a CR+LF pair as line ending.

Compared to ASCII type, binary type is the easier one: the file is just transferred as-is, and no line ending translation is done.

这是从 [2] 中摘抄的一段关于 FTP 用 ASCII TYPE 传输文件的,可以作为参考。

Reference:

[1] SecureCRT rz 上传rar,gif文件不正确及上传大容量文件失败问题解决

[2] Data Type

Search

    Table of Contents