纯文本
cat命令所显示，其內容Royal Dixon所著《动物的人性》的一部份在電腦科學的運算中，纯文本是一個寬鬆的術語，指的是只代表可讀資料的字元，但不代表其圖形表達或其他物件（浮点数、图像等）的数据。它还可能包含了影响文本简单排列的有限数量的“空白”字符，例如空格、换行符或制表符。纯文本有別于格式化文本，格式化文本包含有样式信息；也有別于结构化文本，會識別文件的結構部份，例如段落、小節等；也有別於二进制文件，二進位檔案裡的某些部份必須詮釋為二進位物件（編碼的整數、實數、影像等）。
這個詞有時用得相當寬鬆，意指只包含「可讀」內容的檔案 (或只是某個不包含演講者所不喜歡的內容的檔案)。舉例來說，這可以排除任何字型或排版的指令(例如標記、markdown 、或甚至制表符)；上下引號、不換行空格、軟性連字號、連結線、印刷合字等字元；或其他東西。
原则上，纯文本可以采用任何编码，但有时這個术语被认为暗指ASCII 。随着基于Unicode的编码（例如UTF-8和UTF-16）变得越来越普遍，这种習俗可能会逐漸减少。
純文字有時也僅用於排除「二進制」檔案：檔案中至少有某些部份無法透過字元編碼正確詮釋其效果。例如，某個檔案或字符串是由「hello」(在任何編碼下）這幾個字所組成，緊接著是4個表示二進位整數（不是字元）的位元組，它就是個二進位檔案。將純文字檔案轉換為不同的字元編碼，只要使用正確的字元編碼，並不會改變文字的意義。但是，將二進位檔案轉換為不同的格式可能就會改變非文字資料的詮釋。
纯文本與富文本
[编辑]根据Unicode标准： [1]
- 純文字是一串純粹的字元代碼；因此，純未編碼的文字是一串Unicode字元代碼。
- 相比之下，「样式文本」（也称为「富文本(RTF)」）是包含纯文本以及附加信息（例如语言标识符、字体大小、颜色、超文本链接等）的任何文本表示形式。
- SGML、RTF、HTML、XML和TeX是完全以純文字流表示的富文字的範例，在純文字資料中穿插代表附加資料結構的字元序列。
然而，根據其他定義，包含标记或其他元数据的檔案通常被視為純文字，只要標記也直接是人类可读的形式 (如HTML、XML等)。因此，SGML、RTF、HTML、XML、wiki标记和TeX等表示法，以及幾乎所有程式語言的原始碼檔案，都被視為純文字。特定的檔案內容與檔案本身是否為純文字無關。例如，可縮放向量圖形SVG檔案可以表示繪圖或甚至位图化的圖形，但它仍然是純文字。
使用純文字而不是二進位檔案，可以讓檔案在「窮鄉僻壤」中存活得更好，部份原因是它們基本上很大程度地對於電腦架構的不相容免疫。舉例來說，如果所有資料都編碼為UTF-8文字，所有与字节序有关的問題都可以避免。
用法
[编辑]現在使用純文字的目的主要是為了獨立於需要自己特殊編碼、格式化或檔案格式的程式。純文字檔案可以使用隨處可見的文本编辑器和工具來開啟、讀取和編輯。
命令行界面允許人們以純文字發出命令，並得到回應，回應通常也是純文字。
许多其他计算机程序也能够处理或创建纯文本，例如DOS 、 Windows 、经典Mac OS和Unix及其同类中的无数程序；以及网络浏览器（少数浏览器如Lynx和行模式浏览器仅生成纯文本供显示）和其他电子文本阅读器。
纯文本文件在编程中几乎是一統江湖；包含编程语言指令的源代码文件几乎总是纯文本文件。纯文本也常用于配置文件，在程序启动时读取保存设置的配置文件。
纯文本都用於一些电子邮件。
程式的註解、“.txt檔案”、或TXT记录，通常是仅包含(无格式的)纯文本以供人类阅读。
永久存储知识的最佳格式是纯文本，而不是某种二进制格式。[2]
编码
[编辑]字符编码
[编辑]在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联盟致力於開發單一、統一的字元編碼，以涵蓋所有已知 (或至少所有目前已知) 的語言。經過一些衝突之後[3] ，這些努力得到了統一。 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定义了额外的控制字符，包括双向文本方向覆盖字符（用于明确标记从右到左书写在从左到右书写内，以及反之亦然）和变体选择器，以选择中日韓統一表意文字、表情符号和其他字符的替代形式。
参见
[编辑]参考
[编辑]- ^ The Unicode Standard, version 14.0 (PDF): 18–19.
- ^ Andrew Hunt; David Thomas. 14 "The Power of Plain Text". The Pragmatic Programmer. 1999: 73.
- ^ ISO/Unicode Merger: Ed Hart Memo. www.unicode.org. [2024-10-21].
 |