Unicode 與 UTF-8 的關係

我記得小時候常常下載一個東西安裝精靈就出現亂碼。現在就比較少見了。現在比較常從 Google Drive 下載 csv 的時候會出現亂碼，網路上也有許多解決方案。我最近閱讀一篇有趣的文章在講這個編碼東西，順手做些筆記。

Unicode

由於電腦底層就只認識數字而已，Unicode 是一種把文字對應到數字的規格。舉例來講，可以把大寫字母的 A 對應到 16 進位表示的 0x0041 ，或是 10 進位的 65 。本質上決定了哪個字元要對應到哪個數字。目前已經規定了從 0 到 0x1FFFFF 。目前最長的字元，一個字元要用 3 bytes 表示。

UTF-8

決定數字之後，接下來決定要如何放進記憶體。有些方式可以省空間，有點像是資料壓縮。

如果是用原始的 UTF-32 ，每個字元會佔用到 4 bytes ，這樣雖然簡單但比較沒有效率。所以我們有的 UTF-16 以及 UTF-8 。目前 UTF-8 風靡全球，有些時候可高效率的減少使用的空間。而且對於英文字母，在 UTF-8 跟 ASCII 的表示法是一樣的。

不過這樣也帶來了一些缺點，比如說算字數，或是要跳到第幾個字的時候，會比較難以計算時機的降落地點。

�

Unicode \uFFFD 用來表示解析失敗的字元。所以我們以後看到此符號的時候不用太過害怕，他只是表示你可能用錯了編碼來解析目前的 bytes 。

Unicode 奇怪之處

有個東西叫做 extended grapheme clusters (grapheme)，是一個字元的最小單位，理論上字數應該要用這個來算。但可惜的是，目前大部分的語言，字數會用 code points 來算，所以通常對於單一 emoji 的的長度會顯示為多個。