Skip to main content

3.1 数据表示和存储 (Data Representation and Storage)

数据从发送主机的存储设备传输到接收主机的存储设备。通常需要对数据执行某些转换, 因为两个系统中的数据存储表示不同。例如, NVT-ASCII在不同系统中具有不同的数据存储表示。DEC TOPS-20通常将NVT-ASCII存储为五个7位ASCII字符, 在36位字中左对齐。IBM主机将NVT-ASCII存储为8位EBCDIC代码。Multics将NVT-ASCII存储为36位字中的四个9位字符。在不同系统之间传输文本时, 期望将字符转换为标准NVT-ASCII表示。发送和接收站点必须在标准表示和其内部表示之间执行必要的转换。

在具有不同字长的主机系统之间传输二进制数据 (非字符代码) 时会出现不同的表示问题。发送方应如何发送数据以及接收方应如何存储数据并不总是清楚的。例如, 当从32位字长系统向36位字长系统传输32位字节时, 出于效率和实用性的原因, 可能需要将32位字节在后一系统的36位字中右对齐存储。无论如何, 用户应该可以选择指定数据表示和转换功能。应该注意的是, FTP为数据类型表示提供了非常有限的能力。超出此有限能力的所需转换应由用户直接执行。

3.1.1 数据类型 (DATA TYPES)​

FTP中的数据表示由用户指定表示类型来处理。此类型可以隐式 (如在ASCII或EBCDIC中) 或显式 (如在本地字节中) 定义用于解释的字节大小, 称为"逻辑字节大小 (Logical Byte Size)"。请注意, 这与通过数据连接传输使用的字节大小 (称为"传输字节大小 (Transfer Byte Size)") 无关, 两者不应混淆。例如, NVT-ASCII的逻辑字节大小为8位。如果类型是Local byte, 则TYPE命令具有指定逻辑字节大小的强制性第二参数。传输字节大小始终为8位。

3.1.1.1 ASCII类型 (ASCII TYPE)​

这是默认类型, 必须被所有FTP实现接受。它主要用于文本文件的传输, 除非两个主机都认为EBCDIC类型更方便。

发送方将数据从内部字符表示转换为标准8位NVT-ASCII表示 (参见Telnet规范)。接收方将数据从标准形式转换为其自己的内部形式。

根据NVT标准, 必要时应使用<CRLF>序列表示文本行的结束。(请参阅数据表示和存储部分末尾关于文件结构的讨论。)

使用标准NVT-ASCII表示意味着数据必须解释为8位字节。

下面讨论ASCII和EBCDIC类型的格式参数。

3.1.1.2 EBCDIC类型 (EBCDIC TYPE)​

此类型用于在内部字符表示使用EBCDIC的主机之间进行高效传输。

对于传输, 数据表示为8位EBCDIC字符。字符代码是EBCDIC和ASCII类型功能规范之间的唯一区别。

行尾 (End-of-Line) (与记录结束相对--请参阅结构的讨论) 在EBCDIC类型中可能很少用于表示结构, 但在必要时应使用<NL>字符。

3.1.1.3 图像类型 (IMAGE TYPE)​

数据作为连续位发送, 为传输将其打包到8位传输字节中。接收站点必须将数据存储为连续位。存储系统的结构可能需要将文件 (或对于记录结构文件, 每个记录) 填充到某个方便的边界 (字节、字或块)。此填充 (必须全为零) 只能出现在文件末尾 (或每个记录的末尾), 并且必须有一种方法来识别填充位, 以便在检索文件时可以将其剥离。填充转换应广为公布, 以使用户能够在存储站点处理文件。

图像类型用于文件的高效存储和检索以及二进制数据的传输。建议所有FTP实现都接受此类型。

3.1.1.4 本地类型 (LOCAL TYPE)​

数据以由强制性第二参数Byte size指定的大小的逻辑字节传输。Byte size的值必须是十进制整数; 没有默认值。逻辑字节大小不一定与传输字节大小相同。如果字节大小存在差异, 则逻辑字节应连续打包, 忽略传输字节边界, 并在末尾进行任何必要的填充。

当数据到达接收主机时, 它将以依赖于逻辑字节大小和特定主机的方式进行转换。此转换必须是可逆的 (即, 如果使用相同的参数, 可以检索相同的文件), 并且应由FTP实现者广为公布。

例如, 向具有32位字的主机发送36位浮点数的用户可以将该数据作为逻辑字节大小为36的Local byte发送。然后期望接收主机存储逻辑字节, 以便可以轻松操作它们; 在此示例中, 将36位逻辑字节放入64位双字应该足够。

在另一个示例中, 一对具有36位字大小的主机可以通过使用TYPE L 36以字为单位将数据发送给彼此。数据将在8位传输字节中发送, 打包使得9个传输字节承载两个主机字。

3.1.1.5 格式控制 (FORMAT CONTROL)​

ASCII和EBCDIC类型还采用第二个 (可选) 参数; 这是为了指示与文件关联的垂直格式控制的种类 (如果有)。FTP中定义了以下数据表示类型:

字符文件可以传输到主机用于三个目的之一: 打印、存储和稍后检索, 或处理。如果发送文件进行打印, 接收主机必须知道如何表示垂直格式控制。在第二种情况下, 必须能够在主机上存储文件, 然后以完全相同的形式稍后检索它。最后, 应该可以将文件从一个主机移动到另一个主机, 并在第二个主机上处理文件而不会有不必要的麻烦。单一的ASCII或EBCDIC格式不能满足所有这些条件。因此, 这些类型具有指定以下三种格式之一的第二参数:

3.1.1.5.1 非打印 (NON PRINT)​

如果省略第二个 (格式) 参数, 这是要使用的默认格式。所有FTP实现都必须接受非打印格式。

文件不需要包含垂直格式信息。如果将其传递给打印机进程, 则此进程可以假定间距和边距的标准值。

通常, 此格式将用于用于处理或仅存储的文件。

3.1.1.5.2 TELNET格式控制 (TELNET FORMAT CONTROLS)​

文件包含ASCII/EBCDIC垂直格式控制 (即<CR>, <LF>, <NL>, <VT>, <FF>), 打印机进程将适当解释。<CRLF>, 正好按此顺序, 也表示行尾。

3.1.1.5.3 回车控制 (ASA) (CARRIAGE CONTROL (ASA))​

文件包含ASA (FORTRAN) 垂直格式控制字符。(参见RFC 740附录C; 以及Communications of the ACM, Vol. 7, No. 10, p. 606, October 1964。) 在根据ASA标准格式化的行或记录中, 第一个字符不被打印。相反, 应使用它来确定在打印记录的其余部分之前应发生的纸张的垂直移动。

ASA标准指定了以下控制字符:

字符垂直间距
空格 (blank)向上移动纸张一行
0向上移动纸张两行
1将纸张移至下一页顶部
+无移动, 即叠印

显然, 必须有某种方法让打印机进程区分结构实体的结束。如果文件具有记录结构 (见下文), 这不是问题; 记录将在传输和存储期间明确标记。如果文件没有记录结构, 则<CRLF>行尾序列用于分隔打印行, 但这些格式效果符会被ASA控制覆盖。

3.1.2 数据结构 (DATA STRUCTURES)​

除了不同的表示类型外, FTP还允许指定文件的结构。FTP中定义了三种文件结构:

  • file-structure (文件结构) - 没有内部结构, 文件被视为连续的数据字节序列
  • record-structure (记录结构) - 文件由顺序记录组成
  • page-structure (页结构) - 文件由独立的索引页组成

如果未使用STRUcture命令, 则文件结构是要假定的默认值, 但所有FTP实现都必须接受"文本"文件 (即具有TYPE ASCII或EBCDIC的文件) 的文件和记录结构。文件的结构将影响文件的传输模式 (参见传输模式部分) 以及文件的解释和存储。

文件的"自然"结构将取决于哪个主机存储文件。源代码文件通常在IBM主机上以固定长度记录存储, 但在DEC TOPS-20上作为字符流存储, 例如通过<CRLF>划分为行。如果在这样不同的站点之间传输文件有用, 则必须有某种方法让一个站点识别另一个站点对文件的假设。

由于某些站点自然是面向文件的, 而另一些站点自然是面向记录的, 如果将具有一种结构的文件发送到面向另一种结构的主机, 可能会出现问题。如果将具有记录结构的文本文件发送到面向文件的主机, 则该主机应根据记录结构对文件应用内部转换。显然, 此转换应该是有用的, 但它也必须是可逆的, 以便可以使用记录结构检索相同的文件。

在将具有文件结构的文件发送到面向记录的主机的情况下, 存在主机应使用什么标准将文件划分为可以在本地处理的记录的问题。如果需要此划分, FTP实现应使用行尾序列, ASCII文本文件使用<CRLF>, EBCDIC文本文件使用<NL>作为分隔符。如果FTP实现采用此技术, 则必须准备在使用文件结构检索文件时反转转换。

3.1.2.1 文件结构 (FILE STRUCTURE)​

如果未使用STRUcture命令, 则文件结构是要假定的默认值。

在文件结构中, 没有内部结构, 文件被视为连续的数据字节序列。

3.1.2.2 记录结构 (RECORD STRUCTURE)​

所有FTP实现都必须接受"文本"文件 (即具有TYPE ASCII或EBCDIC的文件) 的记录结构。

在记录结构中, 文件由顺序记录组成。

3.1.2.3 页结构 (PAGE STRUCTURE)​

为了传输不连续的文件, FTP定义了页结构。此类文件有时被称为"随机访问文件 (Random Access Files)" 甚至"空洞文件 (Holey Files)"。在这些文件中, 有时有与整个文件关联的其他信息 (例如, 文件描述符), 或与文件的一部分关联的其他信息 (例如, 页访问控制), 或两者都有。在FTP中, 文件的部分称为页。

为了提供各种页大小和相关信息, 每个页都带有页头发送。页头具有以下定义的字段:

Header Length (头长度)
页头中的逻辑字节数, 包括此字节。最小头长度为4。

Page Index (页索引)
此文件部分的逻辑页号。这不是此页的传输序列号, 而是用于标识文件此页的索引。

Data Length (数据长度)
页数据中的逻辑字节数。最小数据长度为0。

Page Type (页类型)
这是什么类型的页。定义了以下页类型:

  • 0 = Last Page (最后一页)
    用于指示分页结构传输的结束。头长度必须为4, 数据长度必须为0。

  • 1 = Simple Page (简单页)
    这是没有页级关联控制信息的简单分页文件的正常类型。头长度必须为4。

  • 2 = Descriptor Page (描述符页)
    此类型用于传输整个文件的描述性信息。

  • 3 = Access Controlled Page (访问控制页)
    此类型包括具有页级访问控制信息的分页文件的附加头字段。头长度必须为5。

Optional Fields (可选字段)
可以使用进一步的头字段来提供每页控制信息, 例如, 每页访问控制。

所有字段的长度为一个逻辑字节。逻辑字节大小由TYPE命令指定。有关页结构的更多详细信息和特定情况, 请参见附录I。

关于参数的注意事项: 如果检索的版本与原始传输的版本相同, 则必须使用相同的参数存储和检索文件。相反, 如果用于存储和检索文件的参数相同, FTP实现必须返回与原始文件相同的文件。

Last updated on