從一個不起眼的 Bug 開始
最近在做 LINE Bot 設定功能時，收到一個奇怪的使用者回報：
同樣是輸入「設定1_台中_07:30_平日」，系統卻有時候抓不到時間。
仔細一看，問題不在邏輯，而是在 輸入文字的符號 ——原來有些手機鍵盤輸出的「冒號」並不是半形的 :，
而是全形 ：，甚至還有一些更冷門的變體字元。
底線 _ 也有同樣的情況。
我們發現了什麼？
在實際測試中，我遇到了這些奇妙的符號：
符號 Unicode 名稱 最終轉換 ： U+FF1A 全形冒號 Fullwidth Colon : ﹕ U+FE55 Small Colon : ꞉ U+A789 Modifier Letter Colon : ː U+02D0 Modifier Letter Triangular Colon : ∶ U+2236 Ratio : ＿ U+FF3F 全形底線 Fullwidth Low Line _ ﹏ U+FE4F Wavy Low Line _
這些符號看起來幾乎一模一樣，但對程式來說是完全不同的字元。
如果不處理，資料比對就會失敗。
我的解法：normalizeInput()
我寫了一個小工具函式，把常見的變體全部轉成標準半形符號：
function normalizeInput(str) {
if (!str) return "";
return str
// 台 → 臺
.replace(/台/g, "臺")
// 冒號變體
.replace(/[\uFF1A\uFE55\uA789\u02D0\u2236]/g, ":")
// 底線變體
.replace(/[\uFF3F\uFE4F]/g, "_")
// 去除前後空白
.trim();
}
這樣，不管使用者輸入什麼奇怪的冒號或底線，都能正確比對。
實測紀錄
IN : 設定1_台中_07：30_平日
OUT: 設定1_臺中_07:30_平日
IN : 設定1＿臺中＿07﹕30＿平日
OUT: 設定1_臺中_07:30_平日
IN : 設定1꞉臺中_07ː30﹏平日
OUT: 設定1:臺中_07:30_平日
🪄 給非工程師的版本
想像一下，你在餐廳點餐，跟店員說「我要牛肉麵」。
結果店員聽到的卻是「牛☆肉☆麵」，因為你用了奇怪的發音符號。 雖然你看起來講的是同一句話，但對系統（或是店員的收銀機）來說，這已經是不同的字了。
我們這次的問題就是一樣的：
- 你以為打的是
:（半形冒號） - 手機其實輸出的是
：（全形冒號）或其他更罕見的符號
解法就是把這些「長得像」的符號全部換成系統能認得的標準版本，
就像在點餐時，統一用店員熟悉的標準發音。
💬 你有遇過類似的符號坑嗎？
留言跟我分享你踩過的輸入法陷阱， 也許下一篇我們可以一起整理一份「輸入法黑名單」🤭
