Source Code Pro 字體其實並不完美

事情的起因是這樣的，前兩天我在伺服器上看到一個莫名其妙的文件夾 ，所以決定刪了它，於是順手就敲了 。

然而執行結果卻令人意外： 提示目錄並不存在。

刪除包含特殊字元的文件時，需要 參數

顯然這裡顯示出來的 其實並不是 ASCII 中的。之後我又手動的拷貝了 輸出的 ，這一次成功刪除了這個目錄。

為了徹底弄清楚這個字元，我把它拷貝到了 UE，試圖用 16 進位來揭開它的真面目：

可以看到拷貝得到的 UTF-8 (因為終端就是 UTF-8編碼) 編碼為 3 個位元組，而我們習慣上的 只會佔 1 個位元組。查看其 Unicode 碼點為 ：

其實這個字元叫Hyphen (U+2010)，而我們經常使用的減號叫Hyphen-minus (U+002D)。它們都分布在 Unicode 的 BMP 平面上，只是所屬的 block 不同而已。「Hyphen」屬於 General Punctuation Block 而「Hyphen-minus」屬於 Basic Latin Block。實際上人們都只使用繼承自 ASCII 的 Hyphen-minus (U+002D)。

關於兩者的區別就是它們的寬度其實上是不同的，但是這要取決於字體的表現。就拿上面的 Source Code Pro 字體來講，其在終端上的表現就是不盡如人意的。它把「Hyphen」渲染的幾乎和「Hyphen-minus」一樣了，肉眼根本無法分辨出來。而 Courier New 字體就不會這樣：

也許這也是 Courier New 長期稱霸終端的原因之一。

至於系統是怎樣創建 這樣目錄的，這個鍋應該甩給 Typora 了。我們這邊的部署文檔都是使用 markdown 寫的，之後用 Typora 導出 PDF 給運維。問題是老版本的 Typora 會將Hyphen-minus (U+002D)替換為Hyphen (U+2010)。運維部署的時候拷貝了 PDF 中的命令，這樣命令就被成功的 「轉義」 了，於是系統就出現了那些奇怪的目錄。好在目前最新版的 Typora 已經修復了這個問題，建議各位儘早升級。

背景知識

其實上面討論的問題，很類似一種攻擊即：同形異義字攻擊。這種欺騙攻擊就是網址看起來是合法的，但實際上不是，因為其中的一個字元或者多個字元已經被 Unicode 字元代替了。

許多 Unicode 字元，代表的是國際化的域名中的希臘、斯拉夫、亞美尼亞字母，看起來跟拉丁字母一樣，但是計算機卻會把他們處理成完全不一樣的地址。

比如說，斯拉夫字母 「а」（U+0430）和拉丁字母 「a」（U+0061）會被瀏覽器處理成不同的字元，但是在地址欄當中都顯示為 「a」。

去年國內的 @Xudong Zheng 就展示了這種攻擊：Phishing with Unicode Domains，而且最後還得到了 Google 的 2000 美元獎勵。另外，github 上也有個項目 EvilURL，就是專門生成這種 URL 的。

為了防止這種釣魚攻擊，許多瀏覽器使用 「Punycode」 編碼來表示 URL 中的 Unicode 字元。Punycode 是瀏覽器使用的特殊編碼，目的是將 Unicode 字元轉義成字元數目有限的 ASCII 碼字符集（A-Z，0-9），由國際化域名（IDN）系統支持。

比如說，中文域名「短.co」用 Punycode 來表示就是「xn--s7y.co」。此處的 xn 前綴是一個 「ASCII兼容編碼」 前綴，意味著瀏覽器將採用 Punycode 編碼來代表 Unicode 字元。這裡就不再介紹其細枝末節了。

參考文獻

Hyphen

Dash

Plane 「Basic Multilingual Plane」

英文寫作中標點連字號（hyphen）與連接號（dash）的輸入

一種幾乎無法被檢測到的Punycode釣魚攻擊

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！