文字間的戰(zhàn)斗與其救世主 Unicode
我們都知道如何從鍵盤輸入文字，不是嗎？
那么，請允許我挑戰(zhàn)你在你最愛的文本編輯器中輸入這段文字：
?Ayumi moved to Tokyo in 1993 to pursue her career? said Dmitrii
這段文字難以被輸入因為它包含著：
- 鍵盤上沒有的印刷符號，
- 平假名日文字符，
- 為符合平文式羅馬字標準，日本首都的名字中的兩個字母 “o” 頭頂帶有長音符號，
- 以及最后，用西里爾字母拼寫的名字德米特里。
毫無疑問，想要在早期的電腦中輸入這樣的句子是不可能的。這是因為早期電腦所使用的字符集有限，無法兼容多種書寫系統(tǒng)。而如今類似的限制已不復存在，馬上我們就能在文中看到。
電腦是如何儲存文字的？
計算機將字符作為數(shù)字儲存。它們再通過表格將這些數(shù)字與含有意義的字形一一對應。
在很長一段時間里，計算機將每個字符作為 0 到 255 之間的數(shù)字儲存（這正好是一個字節(jié)的長度）。但這用來代表人類書寫所用到的全部字符是遠遠不夠的。而解決這個問題的訣竅在于，取決于你住在地球上的哪一塊區(qū)域，系統(tǒng)會分別使用不同的對照表。
這里有一張在法國常被廣泛使用的對照表 ??ISO 8859-15??：
The ISO 8859-15 encoding
如果你住在俄羅斯，你的電腦大概會使用 ??KOI8-R??? 或是 ??Windows-1251?? 來進行編碼?，F(xiàn)在讓我們假設我們在使用后者：
The Windows-1251 encoding is a popular choice to store text written using the Cyrillic alphabets
對于 128 之前的數(shù)字，兩張表格是一樣的。這個范圍與 ??US-ASCII?? 相對應，這是不同字符表格之間的最低兼容性。而對于 128 之后的數(shù)字，這兩張表格則完全不同了。
比如，依據(jù) Windows-1251，字符串 “said Дмитрий” 會被儲存為：
按照計算機科學的常規(guī)方法，這十二個數(shù)字可被寫成更加緊湊的十六進制：
如果德米特里發(fā)給我這份文件，我在打開后可能會看到：
這份文件 看起來 被損壞了，實則不然。這些儲存在文件里的數(shù)據(jù)，即數(shù)字，并沒有發(fā)生改變。被顯示出的字符與 另一張表格 中的數(shù)據(jù)相對應，而非文字最初被寫出來時所用的編碼表。
讓我們來舉一個例子，就以字符 “Д” 為例。按照 Windows-1251，“Д” 的數(shù)字編碼為 196（c4）。儲存在文件里的只有數(shù)字 196。而正是這同樣的數(shù)字在 ISO8859-15 中與 “?” 相對應。這就是為什么我的電腦錯誤地認為字形 “?” 就是應該被顯示的字形。
When the same text file is written then read again but using a different encoding
多提一句，你依然可以時不時地看到一些錯誤配置的網(wǎng)站展示，或由 ??用戶郵箱代理??? 發(fā)出的對收件人電腦所使用的字符編碼做出錯誤假設的郵件。這樣的故障有時被稱為亂碼（LCTT 譯注：原文用詞為 ??mojibake??， 源自日語 文字化け）。好在這種情況在今天已經(jīng)越來越少見了。
Example of Mojibake on the website of a French movie distributor. The website name has been changed to preserve the innocent.
Unicode 拯救了世界
我解釋了不同國家間交換文件時會遇到的編碼問題。但事情還能更糟，同一個國家的不同生產(chǎn)商未必會使用相同的編碼。如果你在 80 年代用 Mac 和 PC 互傳過文件你就懂我是什么意思了。
也不知道是不是巧合，??Unicode?? 項目始于 1987 年，主導者來自施樂Xerox和……蘋果Apple
這個項目的目標是定義一套通用字符集來允許同一段文字中 同時 出現(xiàn)人類書寫會用到的任何文字。最初的 Unicode 項目被限制在 65536 個不同字符（每個字符用 16 位表示，即每個字符兩字節(jié)）。這個數(shù)字已被證實是遠遠不夠的。
于是，在 1996 年 Unicode 被擴展以支持高達 100 萬不同的 ??代碼點??code point。粗略來說，一個“代碼點”可被用來識別字符表中的一個條目。Unicode 項目的一個核心工作就是將世界上正在被使用（或曾被使用）的字母、符號、標點符號以及其他文字倉管起來，并給每一項條目分配一個代碼點用以準確分辨對應的字符。
這是一個龐大的項目：為了讓你有個大致了解，發(fā)布于 2017 年的 Unicode 版本 10 定義了超過 136,000 個字符，覆蓋了 139 種現(xiàn)代和歷史上的語言文字。
隨著如此龐大數(shù)量的可能性，一個基本的編碼會需要每個字符 32 位（即 4 字節(jié)）。但對于主要使用 US-ASCII 范圍內字符的文字，每個字符 4 字節(jié)意味著 4 倍多的儲存需求以及 4 倍多的帶寬用以傳輸這些文字。
Encoding text as UTF-32 requires 4 bytes per character
所以除了 ??UTF-32???，Unicode 聯(lián)盟還定義了更加節(jié)約空間的 ??UTF-16??? 和 ??UTF-8?? 編碼，分別使用了 16 位和 8 位。但只有 8 位該如何儲存超過 100,000 個不同的值呢？事實是，你不能。但這其中竅門在于用一個代碼值（UTF-8 中的 8 位以及 UTF-16 中的 16 位）來儲存最常用的一些字符。再用幾個代碼值儲存最不常用的一些字符。所以說 UTF-8 和 UTF-16 是 可變長度 編碼。盡管這樣也有缺陷，但 UTF-8 是空間與時間效率之間一個不錯的折中。更不用提 UTF-8 可以向后兼容大部分 Unicode 之前的 1 字節(jié)編碼，因為 UTF-8 經(jīng)過了特別設計，任何有效的 US-ASCII 文件都是有效的 UTF-8 文件。你也可以說，UTF-8 是 US-ASCII 的超集。而在今天已經(jīng)找不到不用 UTF-8 編碼的理由了。當然除非你書寫主要用的語言需要多字節(jié)編碼，或是你不得不與一些殘留的老舊系統(tǒng)打交道。
在下面兩張圖中，你可以親自比較一下同一字符串的 UTF-16 和 UTF-8 編碼。特別注意 UTF-8 使用了一字節(jié)來儲存拉丁字母表中的字符，但它使用了兩字節(jié)來存儲西里爾字母表中的字符。這是 Windows-1251 西里爾編碼儲存同樣字符所需空間的兩倍。
UTF-16 is a variable length encoding requiring 2 bytes to encode most characters. Some character still requires 4 bytes though (for example
UTF-8 is a variable length encoding requiring 1, 2, 3 or 4 bytes per character
而這些對于打字有什么用呢？
啊……知道一些你的電腦的能力與局限以及其底層機制也不是什么壞事嘛。特別是我們馬上就要說到 Unicode 和十六進制?，F(xiàn)在……讓我們再聊點歷史。真的就一點，我保證……
……就說從 80 年代起，電腦鍵盤曾經(jīng)有過 ??Compose???（有時候也被標為 ??Multi??? 鍵）就在 ??Shift?? 鍵的下邊。當按下這個鍵時，你會進入 “組合Compose” 模式。一旦在這個模式下，你便可以通過輸入助記符來輸入你鍵盤上沒有的字符。比如說，在組合模式下，輸入 RO 便可生成字符 ?（當作是 O 里面有一個 R 就能很容易記?。?/p>
Compose key on lk201 keyboard
現(xiàn)在很難在現(xiàn)代鍵盤上看到 ??Compose??? 鍵了。這大概是因為占據(jù)主導地位的 PC 不再用它了。但是在 Linux 上（可能還有其他系統(tǒng)）你可以模擬 ??Compose?? 鍵。這項設置可以通過 GUI 開啟，在大多數(shù)桌面環(huán)境下調用“鍵盤”控制面板：但具體的步驟取決于你的桌面環(huán)境以及版本。如果你成功啟用了那項設置，不要猶豫，在評論區(qū)分享你在你電腦上所采取的具體步驟。
（LCTT 譯注：如果有讀者想要嘗試，建議將 ??Compose??? 鍵設為大寫鎖定鍵，或是別的不常用的鍵，??Ctrl??? 和 ??Alt??? 會被大部分 GUI 程序優(yōu)先識別為功能鍵。還有一些我自己試驗時遇到過的問題，在開啟 ??Compose?? 鍵前要確認大寫鎖定是關閉的，輸入法要切換成英文，組合模式下輸入大小寫敏感。我試驗的系統(tǒng)是 Ubuntu 22.04 LTS。）
至于我自己嘛，我現(xiàn)在先假設你用的就是默認的 ??Shift+AltGr??? 組合來模擬 ??Compose??? 鍵。（LCTT 校注：??AltGr??? 在歐洲鍵盤上是指右側的 ??Alt??? 鍵，在國際鍵盤上等價于 ??Ctrl+Alt?? 組合鍵。）
那么，作為一個實際例子，嘗試輸入 “LEFT-POINTING DOUBLE ANGLE QUOTATION MARK（左雙角引號）”（LCTT 譯注：Guillemet，是法語和一些歐洲語言中的引號，與中文的書名號不同），你可以輸入 ??Shift+AltGr??? ??<<???（你在敲助記符時不需要一直按著 ??Shift+AltGr??）。如果你成功輸入了這個符號，你自己應該也能猜到要怎么輸入 “RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK（右雙角引號）” 了。
來看看另一個例子，試試 ??Shift+AltGr??? ??---??? 來生成一個 “EM DASH（長破折號）”（LCTT 譯注：中文輸入法的長破折號由兩個 “EM DASH” 組成）。要做到這個，你需要按下主鍵盤上的的 ??連字符減號?? 鍵而非數(shù)字鍵盤上的那個。
值得注意的是 ??Compose?? 鍵在非 GUI 環(huán)境下也能工作。但是取決于你使用的是 X11 控制臺還是只顯示文字的控制臺，它們所支持的組合按鍵順序并不相同。
在控制臺上，你可以通過命令 ??dumpkeys?? 來查看支持的組合按鍵列表（LCTT 譯注：可能需要 root 權限）：
在 GUI 下，組合鍵是在 Gtk/X11 層被實現(xiàn)的。想要知道 Gtk 所支持的助記符，可以查看頁面：??https://help.ubuntu.com/community/GtkComposeTable??
我們可以避免對 Gtk 字符組合的依賴嗎？
或許我是個純粹主義者，但是我為 Gtk 這種對 Compose 鍵進行硬編碼的方式感到悲哀。畢竟，不是所有 GUI 應用都會使用 Gtk 庫。而且我如果想要添加我自己的助記符的話就只能重新編譯 Gtk 了。
幸好在 X11 層也有對字符組合的支持。在以前則是通過令人尊敬的 ??X 輸入法（XIM）??。
這個方法在比起基于 Gtk 的字符組合能夠在更加底層的地方工作，同時具備優(yōu)秀的靈活性并兼容很多 X11 應用。
比如說，假設我只是想要添加 ??-->??? 組合來輸入字符 ??→??? （U+2192，RIGHTWARDS ARROW（朝右箭頭）），我只需要新建 ??~/.XCompose?? 文件并寫入以下代碼：
然后你就可以啟動一個新的 X11 應用，強制函數(shù)庫使用 XIM 作為輸入法，并開始測試：
新的組合排序應該可以在你剛啟動的應用里被輸入了。我鼓勵你通過 ??man 5 compose?? 來進一步學習組合文件格式。
在你的 ??~/.profile?? 中加入以下兩行來將 XIM 設為你所有應用的默認輸入法。這些改動會在下一次你登錄電腦時生效：
這挺酷的，不是嗎？這樣你就可以隨意的加入你想要的組合排序。而且在默認的 XIM 設置中已經(jīng)有幾個有意思的組合了。試一下輸入組合鍵 ??LLAP??。
但我不得不提到兩個缺陷。XIM 已經(jīng)比較老了，而且只適合我們這些不太需要多字節(jié)輸入法的人。其次，當你用 XIM 作為輸入法的時候，你就不能利用 ??Ctrl+Shift+u?? 加上代碼點來輸入 Unicode 字符了。什么？等一下？我還沒聊過那個？讓我們現(xiàn)在來聊一下吧：
如果我需要的字符沒有對應的組合鍵排序該怎么辦？
組合鍵是一個不錯的工具，它可以用來輸入一些鍵盤上沒有的字符。但默認的組合集有限，而切換 XIM 并為一個你一生僅用一次的字符來定義一個新的組合排序十分麻煩。
但這能阻止你在同一段文字里混用日語、拉丁語，還有西里爾字符嗎？顯然不能，這多虧了 Unicode。比如說，名字 “あゆみ” 由三個字母組成：
- ??“HIRAGANA LETTER A（平假名字母 あ）” （U+3042）??
- ??“HIRAGANA LETTER YU（平假名字母 ゆ）” （U+3086）??
- 以及??“HIRAGANA LETTER MI（平假名字母 み）” （U+307F）??
我在上文提及了 Unicode 字符的正式名稱，并遵循了全部用大寫拼寫的規(guī)范。在它們的名字后面，你可以找到它們的 Unicode 代碼點，位于括號之間并寫作 16 位的十六進制數(shù)字。這讓你想到什么了嗎？
不管怎樣，一旦你知道了的一個字符的代碼點，你就可以按照以下組合輸入：
- ?
?Ctrl+Shift+u???，然后是??XXXX??（你想要的字符的十六進制代碼點）然后回車。
作為一種簡寫方式，如果你在輸入代碼點時不松開 ??Ctrl+Shift??，你就不用敲回車。
不幸的是，這項功能的實現(xiàn)是在軟件庫層而非 X11 層，所以對其支持在不同應用間并不統(tǒng)一。以 LibreOffice 為例，你必須使用主鍵盤來輸入代碼點。而在基于 Gtk 的應用則接受來自數(shù)字鍵盤的輸入。
最后，當我和我的 Debian 系統(tǒng)上的控制臺打交道時，我發(fā)現(xiàn)了一個類似的功能，但它需要你按下 ??Alt+XXXXX??? 而 ??XXXXX?? 是你想要的字符的 十進制 的代碼點。我很好奇這究竟是 Debian 獨有的功能，還是因為我使用的語言環(huán)境（Locale） 是 ??en_US.UTF-8??。如果你對此有更多信息，我會很愿意在評論區(qū)讀到它們的！
GUI | 控制臺 | 字符 |
? | ? | あ |
? | ? | ゆ |
? | ? | み |
死鍵
最后值得一提的是，想要不（必須）依賴 Compose 鍵來輸入鍵組合還有一個更簡單的方法。
你的鍵盤上的某些鍵是專門用來創(chuàng)造字符組合的。這些鍵叫做 ??死鍵??Dead Key。這是因為當你按下它們一次，看起來什么都沒有發(fā)生，但它們會悄悄地改變你下一次按鍵所產(chǎn)生的字符。這個行為的靈感來自于機械打字機：在使用機械打字機時，按下一個死鍵會印下一個字符，但不會移動字盤。于是下一次按鍵則會在同一個地方印下另一個字符。視覺效果就是兩次按鍵的組合。
我們在法語里經(jīng)常用到這個。舉例來說，想要輸入字母 ?????? 我必須按下死鍵 ??¨??? 然后再按下 ??e??? 鍵。同樣地，西班牙人的鍵盤上有著死鍵 ??~???。而在北歐語系下的鍵盤布局，你可以找到 ??°?? 鍵。我可以念很久這份清單。
hungary dead keys
顯然，不是所有鍵盤都有所有死鍵。實際上，你的鍵盤上是找不到大部分死鍵的。比如說，我猜在你們當中只有小部分人——如果真的有的話——有死鍵 ??ˉ??? 來輸入 ??Tōkyō?? 所需要的長音符號（“平變音符”）。
對于那些你鍵盤上沒有的死鍵，你需要尋找別的解決方案。好消息是，我們已經(jīng)用過那些技術了。但這一次我們要用它們來模擬死鍵，而非“普通”鍵。
那么，我們的第一個選擇是利用 ??Compose??? ??-??? 來生成長音符號（你鍵盤上有的連字符減號）。按下時屏幕上什么都不會出現(xiàn)，但當你接著按下 ??o??? 鍵你就能看到 ??ō??。
Gtk 在組合模式下可以生成的一系列死鍵都能在 ??這里?? 找到。
另一個解決方法則是利用 Unicode 字符 “COMBINING MACRON（組合長音符號）”（U+0304），然后字母 ??o???。我把細節(jié)都留給你。但如果你好奇的話，你會發(fā)現(xiàn)你打出的結果有著微妙的不同，你并沒有真地打出
“LATIN SMALL LETTER O WITH MACRON（小寫拉丁字母 O
帶長音符號）”。我在上一句話的結尾用了大寫拼寫，這就是一個提示，引導你尋找通過 Unicode 組合字符按更少的鍵輸入 ???ō?? 的方法……現(xiàn)在我將這些留給你的聰明才智去解決了。
輪到你來練習了！
所以，你都學會了嗎？這些在你的電腦上工作嗎？現(xiàn)在輪到你來嘗試了：根據(jù)上面提出的線索，加上一點練習，現(xiàn)在你可以完成文章開頭給出的挑戰(zhàn)了。挑戰(zhàn)一下吧，然后把成果復制到評論區(qū)作為你成功的證明。
贏了也沒有獎勵，或許來自同伴的驚嘆能夠滿足你！
