纯文本

此文本文件是由xterm视窗中的cat命令所显示，其内容Royal Dixon所着《动物的人性》的一部份
在电脑科学的运算中，纯文本是一个宽松的术语，指的是只代表可读资料的字元，但不代表其图形表达或其他物件（浮点数、图像等）的数据。它还可能包含了影响文本简单排列的有限数量的“空白”字符，例如空格、换行符或制表符。纯文本有别于格式化文本，格式化文本包含有样式信息；也有别于结构化文本，会识别文件的结构部份，例如段落、小节等；也有别于二进制文件，二进位档案里的某些部份必须诠释为二进位物件（编码的整数、实数、影像等）。
这个词有时用得相当宽松，意指只包含「可读」内容的档案 (或只是某个不包含演讲者所不喜欢的内容的档案)。举例来说，这可以排除任何字型或排版的指令(例如标记、markdown 、或甚至制表符)；上下引号、不换行空格、软性连字号、连结线、印刷合字等字元；或其他东西。
原则上，纯文本可以采用任何编码，但有时这个术语被认为暗指ASCII 。随着基于Unicode的编码（例如UTF-8和UTF-16）变得越来越普遍，这种习俗可能会逐渐减少。
纯文字有时也仅用于排除「二进制」档案：档案中至少有某些部份无法透过字元编码正确诠释其效果。例如，某个档案或字符串是由「hello」(在任何编码下）这几个字所组成，紧接着是4个表示二进位整数（不是字元）的位元组，它就是个二进位档案。将纯文字档案转换为不同的字元编码，只要使用正确的字元编码，并不会改变文字的意义。但是，将二进位档案转换为不同的格式可能就会改变非文字资料的诠释。

**纯文本与富文本**
根据Unicode标准： - 纯文字是一串纯粹的字元代码；因此，纯未编码的文字是一串Unicode字元代码。- 相比之下，「样式文本」（也称为「富文本(RTF)」）是包含纯文本以及附加信息（例如语言标识符、字体大小、颜色、超文本链接等）的任何文本表示形式。- SGML、RTF、HTML、XML和TeX是完全以纯文字流表示的富文字的范例，在纯文字资料中穿插代表附加资料结构的字元序列。
然而，根据其他定义，包含标记或其他元数据的档案通常被视为纯文字，只要标记也直接是人类可读的形式 (如HTML、XML等)。因此，SGML、RTF、HTML、XML、wiki标记和TeX等表示法，以及几乎所有程式语言的原始码档案，都被视为纯文字。特定的档案内容与档案本身是否为纯文字无关。例如，可缩放向量图形SVG档案可以表示绘图或甚至位图化的图形，但它仍然是纯文字。
使用纯文字而不是二进位档案，可以让档案在「穷乡僻壤」中存活得更好，部份原因是它们基本上很大程度地对于电脑架构的不相容免疫。举例来说，如果所有资料都编码为UTF-8文字，所有与-{zh-hans:字节序;zh-hant:端序;}-有关的问题都可以避免。

**用法**
现在使用纯文字的目的主要是为了独立于需要自己特殊编码、格式化或档案格式的程式。纯文字档案可以使用随处可见的文本编辑器和工具来开启、读取和编辑。
命令行界面允许人们以纯文字发出命令，并得到回应，回应通常也是纯文字。
许多其他计算机程序也能够处理或创建纯文本，例如DOS 、 Windows 、经典Mac OS和Unix及其同类中的无数程序；以及网络浏览器（少数浏览器如Lynx和行模式浏览器仅生成纯文本供显示）和其他电子文本阅读器。
纯文本文件在编程中几乎是一统江湖；包含编程语言指令的源代码文件几乎总是纯文本文件。纯文本也常用于配置文件，在程序启动时读取保存设置的配置文件。
纯文本都用于一些电子邮件。
程式的注解、“.txt档案”、或TXT记录，通常是仅包含(无格式的)纯文本以供人类阅读。
永久存储知识的最佳格式是纯文本，而不是某种二进制格式。

**编码**

**字符编码**
在1960年代前期之前，电脑主要用于数字运算而非文字，而且记忆体非常昂贵。电脑通常只为每个字元分配6位元，因此只能允许64个字元——为 A-Z、a-z 和 0-9 分配代码只剩下2个代码：远远不够。大多数电脑选择不支援小写字母。因此，早期的文本项目（如罗伯托·布萨的《托马斯提库斯索引》、布朗语料库等）则必须凭借惯例，例如在实际要大写的字母前键入星号。
IBM的Fred Brooks强烈主张采用8位字节，因为有一天人们可能想要处理文本，结果他胜利了。尽管IBM使用了EBCDIC，但从那时起大多数文本都采用ASCII编码，使用0到31之间的值表示（非打印）控制字符，使用32到127之间的值表示字母、数字和标点符号等图形字符。大多数机器是以8位元来存储字符、而不是7位元，会忽略剩余的位元或将其用作检验和。
ASCII 几乎无处不在的特性帮了大忙，但却未能解决国际和语言方面的问题。美元符号 (「$」)在英国并不常用，西班牙文、法文、德文、葡萄牙文、义大利文和许多其他语言所使用的重音字元在 ASCII 中完全无法使用 (更别提希腊文、俄文和大多数东方语言所使用的字元)。许多个人、公司和国家根据需要定义额外的字元──通常是重新指定控制字元，或使用 128 到 255 的范围内的值。使用 128 以上的值会与使用第 8 位元作为校验和相冲突，但校验和的用法逐渐消失。
这些额外的字元在不同的国家有不同的编码方式，使得文字无法在不搞清楚原创者规则的情况下解码。例如，如果浏览器尝试将一个字符集解释为另一个字符集，它可能会显示 ¬A 而不是 `。国际标准化组织(ISO)最终在ISO 8859之下开发了几种代码页，以适应各种语言。其中第一个（ ISO 8859-1 ）也称为“Latin-1”，它涵盖了大多数（并非全部）使用拉丁字符的欧洲语言的需求（没有足够的空间来涵盖所有语言）。然后， ISO 2022提供了在中间文件中不同字符集之间“切换”的约定。许多其他组织在此基础上开发了变体，多年来 Windows 和 Macintosh 电脑使用不相容的变体。
文字编码的情况变得越来越复杂，导致 ISO 和Unicode联盟致力于开发单一、统一的字元编码，以涵盖所有已知 (或至少所有目前已知) 的语言。经过一些冲突之后 ，这些努力得到了统一。 Unicode目前允许1,114,112个编码值，并为几乎所有现代文字书写系统、许多历史文字系统以及许多非语言符号（如印表机标码、数学符号等）分配编码。
不论编码为何，文字都被视为纯文字。为了正确地理解或处理文字，接收者必须知道（或能够弄清楚）使用的是何种编码；但是，他们不需要知道所使用的电脑架构，或任何程式（如有）建立资料时所定义的二进位结构。
明确说明特定纯文字编码的最常见方式也许是MIME 类型。对于电子邮件和HTTP ，默认的 MIME 类型是“ text/plain ”——没有标记的纯文本。电子邮件和 HTTP 中经常使用的另一种 MIME 类型是“ text/html ; charset=UTF-8”——使用带有 HTML 标记的 UTF-8 字符编码表示的纯文本。另一种常见的 MIME 类型是“application/json”——使用带有JSON标记的UTF-8字符编码表示的纯文本。
当接收到的文件没有任何明确的字元编码指示时，有些应用程式会使用字符集检测来尝试猜测所使用的编码。

**控制代码**
ASCII保留了前 32 个代码（十进制数字 0 到 31）用于控制字符，称为“C0 集”：这些代码最初的目的不是为了表示可打印信息，而是用于控制使用 ASCII 的设备（如打印机），或提供有关数据流（如存储在磁带上的数据流）的元数据。它们包括换行符和制表符等常见字符。
在 8 位字符集（例如Latin-1和其他ISO 8859集）中，“上半部分”（128 至 159）的前 32 个字符也是控制码，称为“C1 集”。它们很少被直接使用；当它们出现在表面上是使用 ISO 8859 编码的文档中时，它们的代码位置通常是指在专有系统特定编码中该位置的字符，例如Windows-1252或Mac OS Roman ，这些编码使用这些代码来提供额外的图形字符。
Unicode定义了额外的控制字符，包括双向文本方向覆盖字符（用于明确标记从右到左书写在从左到右书写内，以及反之亦然）和变体选择器，以选择中日韩统一表意文字、表情符号和其他字符的替代形式。

**参见**
 二进制数据- 二进制文件- 二进制协议- 源代码- 文本文件- 基于文本的协议- 换行和自动换行