Email 收信人，抱怨信件出現亂碼嗎？
程式在讀寫檔案時，為何會不時需要 encode 或 decode？
Unicode, UTF-8, UTF-16 又有什麼差別？
本篇筆記，針對不論 前端(Front-end)、後端(Back-end) 或 DevOps 的工程師，都需要了解的「字元編碼」章節，在 104 職場導師的導讀後，整理而成。
字元編碼 (Character Encoding)
首先，電腦上所有的資訊由 0 與 1 組成，要表示一台主機在網際網路上的位置，可以用四個位元組的 IP 位址 (IPv4) 來定位。那要在螢幕上顯示一個特定字元，我們會需要多長的位元組呢？因為國際間對此還沒有共識，所以採取不同的規則，在螢幕上，就會顯示出不同的符號。所謂的亂碼，時常就是大眾所看見用錯規則而顯示的符號 。
根據《約耳談軟體》的編碼章節 (英文原文/中文譯文)，我們可以感受到約耳字裡行間的幽默，和字元編碼的重要性。由於資訊科學由使用英語的國家發展而來，剛開始只要涵蓋 英文大小寫字母和標點符號，就足以使用，所以早期的電腦多採用 ASCII 編碼方式，以七個位元來表示的一個字元。
多國語系與萬國碼的出現
接著，開始有來自世界各地的人想要使用自己的語言，來傳遞資訊，因此打算把每個字元的空間增為兩倍，由兩個位元組來表示一個字元。第一個位元組仍沿襲 ASCII 的規則，後面根據各個語言的需求，自行制定規則。
常常聽到的 萬國碼(Unicode) 解決了所有問題嗎？
Unicode 其實只是一個業界標準，記載著所有國際上目前已知的字元，它認為應該有個編碼方式，可以支援這些所有字元。實現這樣的理想有很多種辦法，像上一段落所說的，為每個字元制定更大的儲存空間，也可算是一種。如此一來，只要增加字元長度到所有文字符號都涵蓋 (目前全球約七千種語言)，多國語系的問題似乎就能解決？
掌聲歡迎最新加入 Unicode 的字元 U+32FF「㋿」
事情才沒那麼簡單呢！想像一下，家中書架原本可以塞十本書，只因為每張紙的厚度增為兩倍，整個架上能裝的知識量，被硬生生地被裁半，變成只能放五本書。雖然書架可以支援更多種語言，但對於只看英文書的人，就會覺得是非常浪費空間的做法。所以這並沒有成為國際通用規範，英語系的國家仍然想要維持使用 ASCII。
而且，兩個位元組夠長嗎？光是中文字與英文字的搭配，就快要佔滿兩個位元組的使用 (Big-5 編碼)，如果要同時支援阿拉伯文字、俄羅斯字母、日文韓文等語言，需要三個位元組？還是更多呢？同樣地，只會用到一兩種語言的國家，對於這種浪費空間的做法嗤之以鼻。
彈性的字元儲存空間
聰明的程式設計師因此設計出彈性的字元儲存空間，只要用些許位元前綴來表示接下來的字元共有多長。像是 0 開頭的就代表，後面不用擴充，只要考量最小單位就行；如果是 10 開頭的就代表，後面有一個接續； 110 開頭代表後面有兩個接續。
常聽到的 UTF-8 的編碼方式，最小單位是一個位元組，因為完全相容於 ASCII，是目前編碼主流。而 UTF-16 最小單位是兩個位元組，有些非英語為主的國家，可能因為使用的字元都分佈在較晚加入 Unicode 的範圍，採用 UTF-16 會比 UTF-8 更有效率。
指定編碼方式
現在我們知道有不同的編碼方式可以選擇，選擇的編碼可以寫在 HTML 網頁之中，只要在 <head>後頭寫入 <meta charset="UTF-8"/> 來指定編碼。那電子郵件要怎麼設定呢？現今各家圖形化介面有不同方式，要查說明中心的文件才能確定，但底層都同樣是在 email 的 header 加入 Content-type: text/html; charset=utf-8;。
如果讀者很好奇，想知道沒有設定編碼方式的狀況下，瀏覽器會怎麼判斷網頁的編碼方式，可以延伸閱讀這篇：What Every Programmer Absolutely, Positively Needs To Know About Encodings And Character Sets To Work With Text。
