表情符號複製

表情符號是字元，不是圖片

你從這個頁面複製的是文字。咧嘴笑臉是碼位 U+1F600，和英文字母 A 屬於同一類東西，它在剪貼簿中是以字元而非圖片檔的形式傳遞。

這就是為什麼表情符號到了別的地方外觀會改變。Apple、Google、Microsoft、Samsung 與 Twitter 都為同一個碼位繪製了各自的圖案，而閱讀的裝置會畫出自己字型所提供的版本。字元完全相同，只有圖案不同。這也是為什麼表情符號會跟著周圍文字縮放、可以被搜尋，而且能用在圖片無法使用的檔名或提交訊息中。

這些差異偶爾不只是外觀上的。當某家廠商的詮釋與其他家差距太大時，廠商會重新繪製表情符號；手槍在所有主要平台上都變成水槍，就是最知名的例子。所以某一年送出的字元，在另一年讀到時可能給人不同的印象。

為什麼有些表情符號不見了

Unicode 幾乎每年都會新增表情符號，而裝置只能畫出已安裝字型所認得的那些。比字型更新的表情符號會顯示成「豆腐塊」：一個空的長方形，有時裡面還會顯示碼位的十六進位數字。

為了不讓你複製到看不見的東西，本頁會偵測你的瀏覽器實際能畫出哪些表情符號，並隱藏其他的。這表示網格會因裝置及作業系統最近一次更新的時間而略有不同，也表示你在這裡看得到的，就是你看得到的。但這不保證對方也看得到：對方可能用的是較舊的裝置，非常新的表情符號到了那一端可能會變成方塊。重要的場合，越舊、支援越廣的表情符號越安全。

序列、連接符與膚色

許多表情符號不是一個碼位，而是好幾個。家庭、情侶、職業角色、國旗，都是用看不見的零寬連接符 U+200D 把幾個字元接起來組成的。看得懂這個序列的裝置會畫出一個合併後的圖案；看不懂的則會退而把各個部分並排顯示，這就是為什麼家庭表情符號有時會變成分開的幾個人。

膚色也是同樣的原理。Unicode 定義了五種膚色修飾符，以接在基本表情符號後面的字元形式套用，而且只為部分表情符號定義，大致是手、人物與身體部位這些膚色有意義的類別。這裡的所有表情符號都以預設形式複製，你之後可以用自己的鍵盤或手機表情符號面板加上膚色。

這一切在實務上的結果是：在程式碼中，一個表情符號往往不只一個字元長。長度限制、資料庫欄位與文字截斷邏輯計算的都是組成部分，而不是看到的圖案，所以一個家庭表情符號可能就占用七個以上的字元單位，也可能被簡單的截斷邏輯切成兩半。

表情符號會在哪裡壞掉

最經典的失敗是宣告為 utf8 的 MySQL 欄位，它其實不是 UTF-8，而是無法表示 U+FFFF 以上字元的三位元組子集。插入其中的表情符號會被拒絕，或在第一個表情符號處被默默截斷。解法是 utf8mb4，而且這是結構描述的變更，不是一個設定。

除了儲存之外，表情符號會依碼位順序而非任何有意義的順序排序；除非特別設定，否則全文搜尋通常看不到它們；而且它們可能帶有異體字選擇器，讓兩個看起來完全相同的字串被判定為不同。這些都不是避免使用表情符號的理由，而是在假設某個欄位能處理之前，先放一個進去測試的理由。

一個新的表情符號是怎麼誕生的

表情符號要進入 Unicode，必須通過 Unicode Consortium 主持的正式提案流程。任何人都可以提出，但提案得拿出證據來支持自己的主張：預期的使用頻率、這個概念是否已經被現有字元涵蓋、是不是太過狹隘、是不是只是一時流行，以及它實質上是不是一個商標圖案。大多數提案都因為其中某一項而遭到否決。

通過的字元會在每年一次的版本中發布，接著各家廠商各自設計自己的圖案，再隨作業系統更新推出。這段延遲正是一個新公布的表情符號要等上一年以上才真的能用的原因：碼位已經存在，但多數裝置沒有對應的字形，只會顯示一個佔位的方框。

除了字元本身，Consortium 還會發布 CLDR 資料，也就是每個表情符號的簡稱與搜尋關鍵字，並依各語言環境翻譯。任何能在一種以上語言運作的表情符號搜尋都建立在這份資料上，本頁的搜尋也不例外；同一張圖在不同地區會被不同的詞找到，原因就在這裡。

螢幕閱讀器會念出什麼

表情符號在無障礙樹中有一個名稱，螢幕閱讀器會把它念出來。當表情符號承載意義時這很有用，不承載意義時就只是累贅：一行文字結尾放了五個拉炮，會被念成五段各自獨立的描述；而每個項目都以裝飾性符號開頭的清單，會讓那個符號在每一行重複一次。

真正可行的建議是：把表情符號放在片語結尾而不是中間，這樣即使每一個都被念出來，句子讀起來仍然順暢；不要讓表情符號成為某個控制項的唯一標籤，因為被念出來的名稱未必符合你想表達的意思；也不要把裝飾性的重複帶進內文裡。

名稱與帳號代號中的表情符號是特別麻煩的一種，因為每次這個名稱出現時都會被念一遍。介面如果允許使用者這麼做，就也應該允許設定一個純文字的顯示名稱。

在資料庫裡儲存與搜尋表情符號

最經典的失敗是把 MySQL 欄位宣告成 utf8：它其實是三位元組的子集，無法表示 U+FFFF 以上的任何字元。插入其中的表情符號會被拒絕，或在第一個表情符號的位置被截斷。解法是改用 utf8mb4，這需要修改結構描述，也要一併處理連線的字元集，以及在較舊版本中那個當初逼大家選擇 utf8 的索引長度限制。

下一個意外是搜尋。表情符號依碼位順序排列，這對讀者毫無意義；而全文索引在沒有另行設定時，通常會把它們當成標點符號濾掉。如果要讓使用者能用表情符號搜尋，務實的做法是把 CLDR 名稱和字元一起建立索引。

比較則有自己的陷阱：變體選擇符與零寬度連接符的存在，代表兩個看起來一模一樣的字串，逐位元組比對時卻可能不同。先正規化再比較，或者比較算繪後的結果而不是原始位元組，重複資料的清除才會正常運作。

同一個字元，不同的圖

由於每家廠商各自繪製圖案，表情符號會帶上一種發送者無法控制的語氣。相關研究的結論相當一致：同一個表情符號在不同平台上會被解讀成不同意思，有時情感傾向甚至完全相反——一則出於善意的訊息，就是這樣變成了諷刺。

有些字元的含義隨著廠商互相靠攏而改變。手槍在 2016 到 2018 年間被所有主要平台重畫成水槍；另外有幾個手勢，因為最初的畫法在特定地區被讀成別的意思，後來也重新設計過。

對於任何重要的場合——產品介面、客服訊息、技術文件——實用的原則是：優先使用問世已久、在各平台呈現穩定的表情符號；至少在一台 Apple 裝置和一台 Android 裝置上測試；而且絕不倚賴某個特定圖案去傳達文字本身沒有表達的意思。

程式碼、檔名與識別字中的表情符號

表情符號就是普通字元，所以許多系統會在人們意想不到的地方接受它們：commit 訊息、分支名稱、檔名、JSON 的鍵，在某些程式語言中甚至可以當識別字。至於該不該用在那些地方，是另一個問題。

最常見的是 commit 訊息，這個慣例甚至有自己的名字 gitmoji：用開頭的一個字元來標示這次變更的類別。如果團隊對這套對應關係有共識，它運作得很好；但遇到會解析 commit 訊息的工具就很糟，因為用圖案編碼的類別，比起 fix: 或 feat: 這種前綴要難比對得多。

檔名的風險比看起來大。它們在現代檔案系統上沒問題，卻可能弄壞較舊的建置工具、封存格式，以及任何用字串串接來組出 shell 指令的東西。凡是會跨越系統邊界的檔案，用 ASCII 檔名、把表情符號放進中繼資料而不是名稱裡，才是能一直正常運作的版本。