純文字

在電腦科學的運算中，純文本是一個寬鬆的術語，指的是只代表可讀資料的字元，但不代表其圖形表達或其他物件（浮點數、圖像等）的數據。它還可能包含了影響文本簡單排列的有限數量的「空白」字符，例如空格、換行符或制表符。純文本有別於格式化文本，格式化文本包含有樣式信息；也有別於結構化文本，會識別文件的結構部份，例如段落、小節等；也有別於二進制文件，二進位檔案裡的某些部份必須詮釋為二進位物件（編碼的整數、實數、影像等）。

此文本文件是由xterm視窗中的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定義了額外的控制字符，包括雙向文本方向覆蓋字符（用於明確標記從右到左書寫在從左到右書寫內，以及反之亦然）和變體選擇器，以選擇中日韓統一表意文字、表情符號和其他字符的替代形式。

參見

• 二進制數據
• 二進制文件
• 二進制協議
• 源代碼
• 文本文件
• 基於文本的協議
• 換行和自動換行