這是美國國家標準協會（ANSI）所制定的文字編碼方法，一共 128 個字，詳見維基百科。
但 128 個實在沒有全球通用，所以國際標準化組織（ISO）就定義通用字符集 ISO 10646（Universal Character Set，UCS）來統一所有字集，經由統一碼聯盟（主要是一些企業）整理誕生了：
有鑑於 ASCII 一個位元組（1 byte）不夠用，所以 Unicode 就用二個位元組（2 byte）來表示一個字，可達 65536 個字。對應字元的動作是「轉換格式」（Unicode Transformation Format，簡稱為 UTF），而二個位元組 Unicode 實作是：
這是 Unicode 的標準的名稱，在 ISO 的標準叫作 UCS-2 。另外 ISO 也定義了四個位元組，其 Unicode 實作是：
這是 Unicode 的標準的名稱，在 ISO 的標準叫作 UCS-4 。但實際上沒有那麼簡單，在麥金塔和個人電腦上讀取字元順序不同，如「U+4E59」，在個人電腦（像是 Windows）會取「4E59」的「乙」字；但麥金塔會取「594E」的「奎」字。為了區分，前者叫作大端序：
後者叫作小端序：
為了區別二者，編碼時會在文件第一個字加入位元組順序記號（Byte-Order Mark，BOM），第一個字是 U+FFFE 表示小端序；第一個字是 U+FEFF 表示大端序。
但原本 UTF-16 實在太粍空間了，原 ASCII 字集竟然要用二個位元組（2 byte），所以 Unicode 就創造了只用一個位元組（1 byte）存放的方法：
就是把 ASCII 字集第一位元（bit）置「0」以作識別，而其他字就是 UTF-16 字集。 UTF-8 因為編碼過所以不用考慮位元組序（因為很好辨識），但是微軟視窗作業系統的記事本就在所有文字文件檔（.txt）前面加上 0xEFBBBF 這個字來表示這是 UTF-8 ，但在大部份不支援的軟體（尤其是編譯器）會有問題，所以才會有另外一種文字文件產生：
非常之好笑的是命令提示字元是不吃 BOM 的，當它被餵 BOM 時它會認為前面多一個字。
講那麼多是要接接下來的解釋，在前面也看到大部份的字元都要用到 Unicode ，當然在批次檔也有可能會用到，不過很可惜，命令提示字元支援得很差，啟用方法有二種，第一種是：
而第二種方法是：
從 Windows® 10 中命令提示字元己經可以做一些 Unicode 的操作，這是相較之前幾版非常大的改進。連 .cmd 存成 Unicode 也是可以正常支援，這在以往是不行的。讀者可以嘗試對 Unicode 字元顯示，應該不會有什麼問題。但是 Unicode 字元眾多，使用時還是要再三確認執行是否正常，以免日後的批次檔出問題。
命令提示字元對 Unicode 支援進行大幅的改善，謝天謝地，這在之前是連想都不用想。字元編碼的部份也多少會一下，本教學已經整理得很精簡了，以後在使用上也不會有問題。下一章也跟這章性質很接近，會用到但不重要。
下一章：變數變換
- 2012-09-11 初次發佈。
- 2013-07-20 部分字句修改。
- 2017-07-12 更新成 Windows 10 的版本。
沒有留言:
張貼留言
定時會整理。