有人还在使用或熟悉 rz 和 sz 命令吗？

Question 1

rz 和 sz 内部如何工作？

他们基本上只是使用终端连接来相互通信，并使用特定的协议通过该连接发送文件。这涉及一些同步（因为sz程序不只是在启动时转储数据）、元数据处理（例如文件名）以及错误检测和必要时重新发送。此外，他们似乎做了一些终端设置，可能是为了防止任何可能的控制字符以干扰传输的方式被解释。

不过，我不知道该协议的实际细节，但其中有一些链接维基百科上的 ZMODEM 页面如果你有兴趣的话。

也许他们所做的一些事情并不是真正需要通过 SSH 连接进行的。例如，对于 TCP/IP 和以太网，较低级别上有错误检测代码，TCP 处理重新发送，并且 SSH 级别上的任何经过身份验证的加密套件至少应该检测传输错误（因为它们会显示为就像恶意修改的数据包一样））。

您可以通过 SSH 连接发送文件

cat somefile.txt | ssh me@somewhere 'cat > somefile.txt'

这只是通过 SSH 连接转储数据，这工作得很好，因为 SSH 是 8 位干净的，并且当这样使用时，它不会在远程端设置终端，因此终端控制不是问题。

当然，如果需要在中间跳转主机上手动运行SSH客户端，比如

myworkstation$ ssh me@jumphost
jumphost$ ssh me@destination

那么设置管道就有点困难了，你必须做类似的事情

myworkstation$ cat somefile.txt | ssh me@jumphost 'ssh me@destination "cat > somefile.txt"'

我不确定该嵌套命令行是否适用于 SSH。因此，从这个意义上说，如果两端都可以使用 ZMODEM，那么它似乎是一个有点可用的替代方案，因为它至少可以在终端会话中使用。

话又说回来，SSH 具有ProxyCommand简化使用跳转主机的功能，并且可能使使用 justscp或更容易sftp。参见例如https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_Jump_Hosts

rz和sz可靠吗？还有人用那个吗？有更好的解决方案满足我的需求吗？

当我使用这样旧的、不受欢迎的东西时，我感到非常害怕。我不知道哪里会出问题。我总是在上传或下载文件后执行 sha256sum，这让我发疯。

好吧，它们已经使用了很长时间，而且文件（大部分）仍然只是每字节 8 位的数据转储，所以没有理由它们基本上仍然可以工作。虽然它们有点过时，但这本身并没有错。当然，性能是另一个问题，如果您发现错误，您可能需要准备好很难找到活跃的维护者来修复它。

尽管通常不需要，但如果您重视数据并想确定的话，我不确定手动验证数据传输是否是一件坏事。如果您通过 HTTP 传输某些内容，您仍然可以获得剪切传输，例如两者，wget http://...并且curl -o http://...如果它们被中断，似乎很乐意留下部分文件......（这同样适用于cat | ssh cat我上面介绍的内容，请注意。）

至于什么最适合您的需要，您必须自己决定。

Answer

rz 和 sz 内部如何工作？

他们基本上只是使用终端连接来相互通信，并使用特定的协议通过该连接发送文件。这涉及一些同步（因为sz程序不只是在启动时转储数据）、元数据处理（例如文件名）以及错误检测和必要时重新发送。此外，他们似乎做了一些终端设置，可能是为了防止任何可能的控制字符以干扰传输的方式被解释。

不过，我不知道该协议的实际细节，但其中有一些链接维基百科上的 ZMODEM 页面如果你有兴趣的话。

也许他们所做的一些事情并不是真正需要通过 SSH 连接进行的。例如，对于 TCP/IP 和以太网，较低级别上有错误检测代码，TCP 处理重新发送，并且 SSH 级别上的任何经过身份验证的加密套件至少应该检测传输错误（因为它们会显示为就像恶意修改的数据包一样））。

您可以通过 SSH 连接发送文件

cat somefile.txt | ssh me@somewhere 'cat > somefile.txt'

这只是通过 SSH 连接转储数据，这工作得很好，因为 SSH 是 8 位干净的，并且当这样使用时，它不会在远程端设置终端，因此终端控制不是问题。

当然，如果需要在中间跳转主机上手动运行SSH客户端，比如

myworkstation$ ssh me@jumphost
jumphost$ ssh me@destination

那么设置管道就有点困难了，你必须做类似的事情

myworkstation$ cat somefile.txt | ssh me@jumphost 'ssh me@destination "cat > somefile.txt"'

我不确定该嵌套命令行是否适用于 SSH。因此，从这个意义上说，如果两端都可以使用 ZMODEM，那么它似乎是一个有点可用的替代方案，因为它至少可以在终端会话中使用。

话又说回来，SSH 具有ProxyCommand简化使用跳转主机的功能，并且可能使使用 justscp或更容易sftp。参见例如https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_Jump_Hosts

rz和sz可靠吗？还有人用那个吗？有更好的解决方案满足我的需求吗？

当我使用这样旧的、不受欢迎的东西时，我感到非常害怕。我不知道哪里会出问题。我总是在上传或下载文件后执行 sha256sum，这让我发疯。

好吧，它们已经使用了很长时间，而且文件（大部分）仍然只是每字节 8 位的数据转储，所以没有理由它们基本上仍然可以工作。虽然它们有点过时，但这本身并没有错。当然，性能是另一个问题，如果您发现错误，您可能需要准备好很难找到活跃的维护者来修复它。

尽管通常不需要，但如果您重视数据并想确定的话，我不确定手动验证数据传输是否是一件坏事。如果您通过 HTTP 传输某些内容，您仍然可以获得剪切传输，例如两者，wget http://...并且curl -o http://...如果它们被中断，似乎很乐意留下部分文件......（这同样适用于cat | ssh cat我上面介绍的内容，请注意。）

至于什么最适合您的需要，您必须自己决定。

Question 2

首先，让我们确认我们使用的词upload和download方式是相同的。

在调制解调器连接上，“上传”意味着“从本地系统向远程系统发送文件”，“下载”意味着“让远程系统向我发送文件”。我真的不知道“上”和“下”从何而来 - 也许来自系统的层次结构，其中单个小型PC（甚至终端）是最低层，而大型中央计算机被认为是“更高层” 。

Xshell 有自己内置的 ZMODEM 协议实现 - 它实际上并不在本地使用sz和rz命令。

Xshell 中的“上传命令”选项

“上传命令”选项确定哪个命令是由Xshell发送到远程系统如果你只是使用Xshell的“使用ZMODEM发送文件”功能，而远程云服务器端没有做任何准备。所以当Xshell发送时，云服务器必须接收，因此上传命令为rz。

为此，与云服务器的 Xshell 会话必须处于命令提示符状态，准备好接收命令。否则（例如，如果您top在会话中运行并尝试使用 ZMODEM 发送文件），它只会使显示乱码top并挂起大约一分钟左右，然后告诉您远程端无法开始接收。

您也可以在云服务器的命令提示符下键入rz，告诉云服务器准备将文件接收到您当前cd所在的目录中。如果这样做，rz将输出其特殊字符串，该字符串可以被Xshell识别，并且然后 Xshell 将自动弹出“发送文件”对话框，并在您告诉它要发送哪个文件后开始传输。（ZMODEM 协议的设计是这样的：如果发送方发送“上传命令”字符串，而接收方 ZMODEM 已准备好接收，则不需要的命令将自动被忽略。）

如果您想以其他方式传输文件，例如，如果您config-backup.zip想访问本地计算机的云服务器，则只需键入sz config-backup.zip与云服务器的 SSH 会话即可。云服务器将启动sz（Send Zmodem）命令，该命令将输出另一个特殊字符串。在这种情况下，Xshell 可能会立即开始接收文件，并且要么将其保存到配置的下载目录，要么在下载文件后（甚至仍在下载时）询问您文件应放置在本地系统上的哪个位置。

至少在我的 Debian 10 系统上，的手册页rz还涵盖了rx和rb命令，并且的手册页sz还涵盖了sx和sb。--ascii每个手册页中对转换的指定有所不同：

在rz手册页上，该选项的描述--ascii是：

 -a, --ascii
         Convert  files to Unix conventions by stripping carriage returns
         and all characters beginning with the first Control Z (CP/M  end
         of file).

在sz 手册页上，描述是：

  -a, --ascii
         Convert NL characters in the transmitted file to CR/LF.  This is
         done by the sender for XMODEM and YMODEM, by  the  receiver  for
         ZMODEM.

因此，当您将文件从云服务器传输给自己时，Xshell 负责实际转换。

当我在一家仍然拥有一些 OpenVMS 服务器的公司工作时，OpenVMS 服务器管理员表示，他更喜欢尽可能将任何文件格式转换作为单独的、明确的步骤进行。他的理由是（解释为）“这是我可以确定某些东西是否已被转换以及转换是如何完成的唯一方法。”在处理了 PC8 中的行结尾和斯堪的纳维亚字符、各种旧的 7 位国家字符编码、ISO-8859-1、ISO-8859-15 和最后的 UTF-8 以及这些之间的转换之后，我倾向于同意他的观点。

此外，每当检查字符转换结果时，我都学会了对任何可疑的转换结果进行十六进制转储，并根据适当的编码表检查字符。当涉及到行结尾时，您还可以使用cat -A使额外\r的可见，file或者描述使用的行结尾类型而不是尝试展示他们。有时转换并不会完全按照您期望的方式应用；有时，云服务器的文本编辑器、TTY 驱动程序或您的终端可能会“有帮助地”应用另一层转换，从而改变您要检查的内容，并让您得出错误的结论。

Answer