什么是文件/组/记录/单元分隔符控制字符及其用法?

Eon*_*nil 33 unicode history text control-characters

Unicode从ASCII定义了几个控制字符.http://www.unicode.org/charts/PDF/U0000.pdf

我看到很多控制字符被广泛使用,但我真的看不到"信息分隔符"的使用位置.(U + 001C〜U + 001F)

他们是什么?他们的历史是什么?他们在哪里使用?

Jon*_*röm 44

Lammert Bies解释了他们的用法和背后的历史.

28 - FS - 文件分隔符文件分隔符FS是一个有趣的控制代码,因为它让我们深入了解计算机技术在六十年代的组织方式.我们现在习惯于随机访问媒体,如RAM和磁盘,但是当定义ASCII标准时,大多数数据都是串行的.我不仅谈论串行通信,还谈论打孔卡,纸带和磁带等串行存储.在这种情况下,使用单个控制代码来发信号通知两个文件的分离显然是有效的.为此目的定义了FS.

29 - GS - 组分隔符数据存储是某些控制代码进入ASCII定义的主要原因之一.数据库大多数时候都是使用包含记录的表进行设置.一个表中的所有记录具有相同的类型,但不同表的记录可以不同.组分隔符GS被定义为分离串行数据存储系统中的表.请注意,那时没有使用单词表,ASCII人称之为组.

30 - RS - 记录分隔符在组(或表)中,记录用RS或记录分隔符分隔.

31 - US - 单位分隔符要存储在数据库中的最小数据项在ASCII定义中称为单位.我们现在称他们为田地.单元分隔符在串行数据存储环境中分隔这些字段.大多数当前的数据库实现要求大多数类型的字段具有固定长度.记录中有足够的空间来存储每个字段的最大可能成员,即使在大多数情况下不需要这样做.在许多情况下,这会花费大量空间.美国控制代码允许所有字段具有可变长度.如果数据存储空间有限 - 如同六十年代 - 这是保护宝贵空间的好方法.另一方面,串行存储远远低于现代表驱动RAM和磁盘实现的效率.我可以'

单位分隔符可以提供与CSV文件中的逗号或制表符分隔文件中的选项卡基本相同的目的.

  • 得知 CSV 和 TSV 文件格式是基于缺乏 ASCII 知识,这有点令人沮丧。 (13认同)
  • 回复:_“所有控制代码都被认为是不可打印的”_ - 它们的 ASCII 形式是不可打印的。但是,正如我今天发现的,Unicode_也_具有代表这些控制代码的可打印字符:␜ ␝ ␞ ␟ (7认同)
  • CSV 使用逗号,但这是一个可打印字符。所有控制代码都被认为是不可打印的,因此是二进制数据 - 即使大部分是人类可读的。所以有一点小小的差别。 (3认同)

Juk*_*ela 7

你的意思是这些天大多数人通常都不习惯吗?控制字符主要与设备控制功能有关,但其中一些可能已用作文本文件中的分隔符.有关快速参考,请查看我的C0控件表.

信息分隔符已经用于以简单的方式对数据进行分组,但是现在,二进制格式或XML格式用于数据组织.仍有好奇心,比如在Microsoft Word中内部使用U + 001E和U + 001F来实现程序自己的"不间断连字符"和"可选连字符"的概念(与类似用途的Unicode字符相反).这主要说明程序可以以奇怪的方式使用控制字符.如果字符包含在发送到其他程序的文本中,则会出现问题.


scr*_*uss 5

They\'re deliberately ambiguous in function. From the standard reference for character coding development (Mackenzie, Charles E. Coded-Character Sets: History and Development. Addison-Wesley Longman Publishing Co., Inc., 1980.), chapter 26 section 1, page 460:

\n
\n

Four additional general-purpose characters, the so-called information separators, were designed into the [ASCII] 7-Bit Code and into EBCDIC. File Separator, Group Separator, Record Separator, and Unit Separator were defined broadly to be used to separate blocks of information. But how they were to be used to separate blocks, what philosophy of file and record structuring was to be used, was intentionally not specified. Such detailed specification would be left to the particular data processing application in which the separators would be used. Initially, a hierarchial [sic] philosophy of structuring information blocks was defined. A \xe2\x80\x9cfile\xe2\x80\x9d was larger than, and would enclose, \xe2\x80\x9cgroups.\xe2\x80\x9d A \xe2\x80\x9cgroup\xe2\x80\x9d was larger than, and would enclose, \xe2\x80\x9crecords.\xe2\x80\x9d And a \xe2\x80\x9crecord\xe2\x80\x9d was larger than, and would enclose, \xe2\x80\x9cunits.\xe2\x80\x9d Eventually, the standards committees made this hierarchial [sic] specification optional; that is, the separators need not be used hierarchially [sic], buf if they were, then the hierarchy would be as described above. The standards committees realized that, as with the Device Controls, the unspecificity of the information separators could lead to difficulty of information interchange, but such difficulties could be worked out in the rare instances when they arose.

\n
\n

One example of a standard that uses this outline hierarchy is a now-superseded version of the ANSI/NIST-ITL Standard for interchange of forensic biometric images. The ITL \xe2\x80\x9cTraditional Encoding\xe2\x80\x9d used the ASCII separators as follows:

\n
\n

\xe2\x90\x9c 文件分隔符 \xe2\x80\x93 分隔逻辑记录。

\n
\n
\n

\xe2\x90\x9d 组分隔符 \xe2\x80\x93 分隔字段。

\n
\n
\n

\xe2\x90\x9e 记录分隔符 \xe2\x80\x93 分隔重复的子字段。

\n
\n
\n

\xe2\x90\x9f 单位分隔符 \xe2\x80\x93 分隔信息项。

\n
\n

这种用法可能看起来与分隔符的指定用途相矛盾,但了解字符代码的预期层次结构会使 ITL 标准中的选择更加合适。

\n

使用 ASCII 分隔符控制代码的数据格式的当前示例是 JavaScript 对象表示法 (JSON) 文本序列格式(RFC 7464,媒体类型application/json-seq),它在每个记录之前放置 ASCII 记录分隔符 (0x1E) 字符。

\n