Tftp协议实现以及netascii和octect的区别
我正在构建一个应用程序，它是实现 tftp 协议的服务器。我很难理解 tftp 中 ASCII 格式和二进制格式（netascii 和 octect）之间的区别，以及我应该如何按照协议规定以不同方式读取文件。
我知道 ASCII 字符可以用单个字节表示。所以我不明白以ascii模式（每个字符1个字节）和二进制模式（1个原始字节）读取有什么区别。
我可以使用标志 ios::binary 读取二进制模式的文件（tftp 中的八位字节），而没有它的 ascii（tftp 中的 netascii），但我真的不明白以这两种方式读取文件有什么区别（我总是提出一个字节数组）。
如果有人可以帮助我理解，我将非常感激
tftp 协议规范： http:// /www.rfc-editor.org/rfc/rfc1350.txt
我不明白的部分是这个：
目前支持三种传输模式：netascii（这是 ascii 定义于“美国信息交换标准代码”
[1] 进行“Telnet 协议
”中指定的修改 规范”[3]。）请注意，它是 8 位 ASCII。术语
本文档中将使用“netascii”来表示这个
特定版本的 ascii。）；八位字节（这取代了“二进制”模式 本文档的先前版本。）原始 8 位字节；邮件，
netascii 字符发送给用户而不是文件。 （邮件
模式已过时，不应实现或使用。）其他
模式可以由成对的合作主机来定义。
I'm building an application that is a server that implements the tftp protocol. I'm having hard times in understand what's the difference between ASCII format and binary format (netascii and octect) in tftp, and how should I read files differently as the protocol states.
I know that an ASCII char can be rapresented with a single byte. So I don't understand what's the difference between reading in ascii mode (1 byte each character) and binary mode (1 raw byte).
I can read the file with flag ios::binary for binary mode (octet in tftp) and without it for ascii (netascii in tftp), but I really don't understand what's the difference in reading files in these two ways (I always come up with an array of bytes).
If someone can help me understand, I'll really appreciate it
The tftp protocol specification: http://www.rfc-editor.org/rfc/rfc1350.txt
The part that I don't understand is this one:
Three modes of transfer are currently supported: netascii (This is
ascii as defined in "USA Standard Code for Information Interchange"
[1] with the modifications specified in "Telnet Protocol
Specification" [3].) Note that it is 8 bit ascii. The term
"netascii" will be used throughout this document to mean this
particular version of ascii.); octet (This replaces the "binary" mode
of previous versions of this document.) raw 8 bit bytes; mail,
netascii characters sent to a user rather than a file. (The mail
mode is obsolete and should not be implemented or used.) Additional
modes can be defined by pairs of cooperating hosts.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
RFC-1350/TFTP 中有两段文字可以帮助阐明 netascii 的用途：
“Telnet 协议规范”是 RFC-764，它描述了解释用于“网络虚拟终端”的各种 ASCII 代码。因此，netascii 将遵循这些解释（其中包括行必须以 CR/LF 序列终止）。
和：
因此，例如，使用 EBCDIC 作为本机编码的主机可能会将 netascii 转换为该编码，但会保留“八位字节”数据。
如果您在使用 LF 作为行结尾的 Unix（或其他）系统上实现 TFTP 服务器，则需要为 netascii 传输添加 CR（以及将文件中的实际 CR 字符转换为 CR/NUL）序列。
There are two passages which can help clarify what the purpose of netascii is in RFC-1350/TFTP:
The "Telnet Protocol Specification" is RFC-764, and it describes the interpretation of various ASCII codes for use on the "Network Virtual Terminal". So, netascii would follow those interpretations (which include that lines must be terminated with a CR/LF sequence).
and:
So a host that used EBCDIC as it's native encoding, for example, might be expected to translate netascii to that encoding, but would leave "octet" data alone.
If you're implementing the TFTP server on a Unix (or other) system that uses LF for line endings, you'd be expected to add the CR for netascii transfers (as well as convert actual CR characters in the file to CR/NUL sequences.