純文字
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].
 |