不知道有多少人跟我一樣是使用「自然輸入法」的呢？我使用該輸入法應該已經有十幾年的時間，至今也是使用自然輸入法 V11 免費版（本來要付費買，但官方限定使用機器數量對我來說是種束縛，所以一直用免費版）。最近幾個月在 Chrome 改版後我遇到一個很奇怪的問題：自然輸入法在記事本與絕大部分的網頁都正常，但一到 X（前推特）或是 Threads 要貼文或回覆的時候，不管自然輸入法怎麼輸入注音，中文字卻沒有出現。但換到其他頁面或 WORD 時又恢復正常，甚至同一個 Chrome 視窗裡的聊天側邊欄也會一起受影響，最奇妙的是微軟注音輸入法一切正常。一開始懷疑是社群網站的輸入框與中文輸入法不相容。不過，這次跟 Codex 一路追到當機紀錄與程式呼叫後，找到的線索居然是：瀏覽器視窗標題太長，觸發自然輸入法讀取標題時的緩衝區錯誤。
後續測試又發現 Telegram 網頁版與 Gmail 側邊 Gemini 的也一樣有自然輸入法中文輸入失常問題（而且臉友反餽確認自然輸入法 V11、V12、V13 也都會遇到同樣的狀況），但不過它們的問題又不相同，這次是網站清理空欄位，干擾輸入法的組字空白。我們針對幾個網站採用不同的相容處理，並做成免費、MIT 授權的開源瀏覽器外掛，讓自然輸入法的使用者可以繼續在 X、Threads、Telegram 與 Gmail 等網站能正常輸入中文。
症狀：為什麼換一個分頁，中文就能打了？
最初遇到的情況，不是所有程式都不能打中文。記事本正常，其他 Chrome 頁面也正常；進入特定 X 貼文，回覆時確認了中文字，欄位卻還是空白。Threads 也曾出現輸入異常。更奇怪的是，失敗不一定只限於 X 的回覆框。同一個 Chrome 視窗裡的聊天側邊欄，也可能突然收不到中文。切到另一個網頁，又能繼續輸入。
這讓問題的範圍不只落在某個 HTML 輸入框，也必須檢查 Windows 輸入法服務與瀏覽器視窗之間發生了什麼。我的需求很單純：保留已經習慣的自然輸入法，在原本的欄位直接打字。不要另外叫出小輸入框，也不要每次先在別的程式打好再貼上。因此，解法必須先弄清楚文字在哪個環節消失。
先監看組字事件，發現網頁根本沒收到完整中文
最怪的是這些網站自然輸入法如果要直接打中文都會異常，但只要先輸入一個任意英數符號後就能解決，但這絕對不是正常的處理方法。後來我叫 Codex 外掛開始監看輸入法的 Key in 狀態，在一次已確認失敗的 X 測試中，頁面確實收到了組字相關事件，但組字資料只有一個空白，後續沒有取得完整中文字。同時，Windows 留下自然輸入法背景程序 GOImeServer11.exe 的當機紀錄，服務之後重新啟動。
這項發現影響了原本的設想：如果外掛只是監聽「組字完成」再把文字貼回去，在這次失敗裡沒有完整文字可拿。問題已經發生在自然輸入法交付文字的過程中，單純做一層轉貼，無法救回沒有交付的內容。
接下來，調查重點轉向自然輸入法本身的當機原因。
十份當機檔，指向同一條讀取視窗標題的路徑
本次針對 V11 收集到的十份本機當機檔，都指向 OVIMGoing.dll 的同一條程式路徑。例外代碼是 0xc0000409，fast-fail 參數為 2，與堆疊安全檢查失敗相符。
這些紀錄並不是看到「不能輸入」就猜測輸入法壞了，而是直接顯示背景程序在何處終止。離線檢查該模組後，找到一個取得前景視窗、接著讀取視窗標題的函式。
真正有問題的地方，是緩衝區容量與傳給 Windows API 的長度單位不一致：
- 目的緩衝區起點到堆疊安全檢查值之間，只有 600 位元組的空間，相當於 300 個 UTF-16 單位。
- 程式呼叫
GetWindowTextW時，卻傳入 600 個字元的長度上限。 - 本次當機檔裡保存的視窗標題長度是 313 個 UTF-16 單位，已超過前述空間。
Windows 的 GetWindowTextW 長度參數以字元數計算，並包含結尾的終止符；它不是「可以寫入多少位元組」。這個單位差異，會讓程式允許寫入比目的空間更長的內容。用一般人比較容易理解的方式說，就是準備了一個只能放約 300 單位文字的空間，卻告訴系統可以寫到 600。短標題時不容易出事，一旦遇到夠長的視窗標題，就可能覆寫到不該碰的堆疊區域，最後被安全檢查終止。
十份當機檔、同一個函式、相同的標題長度，以及緩衝區與 API 參數的差異，形成了強烈指向長標題越界的證據。這是我們依本機資料得出的根因判讀，目前沒有自然輸入法廠商的獨立確認。
X 貼文內容變成標題，為什麼連側邊欄都受影響？
後來測試故障 X 分頁的 document.title 長度實測為 297 個 UTF-16 單位，當機檔保存的 Windows 視窗標題長度則是 313。兩者相差 16，符合 Chrome 在分頁標題後附加瀏覽器名稱的情況。
X 貼文頁面會把貼文文字放入標題，當標題夠長，再加上瀏覽器的視窗後綴，就可能跨過自然輸入法這段程式的安全空間。這也解釋了為什麼有些貼文正常，有些貼文卻打不出中文。
至於同一個視窗的聊天側邊欄為什麼也可能受影響，線索在於輸入法這段程式讀取的是「前景視窗標題」。只要當下 Chrome 視窗的標題符合觸發條件，就算正在輸入的是視窗裡另一個欄位，也可能走到同一條出問題的路徑。這個機制符合觀察到的跨欄位症狀，但仍需更多環境的獨立重現，不能拿它解釋所有中文輸入異常。
解法：縮短長標題，保留原本的輸入操作
找到這條 BUG 觸發路徑後，我們採取的相容處理很直接：在輸入法讀取到過長標題之前，先把指定社群網站的分頁標題縮短。外掛會把超過 180 個 UTF-16 單位的標題截短，保留開頭內容，並預留瀏覽器附加標題的空間。遇到 emoji 時，也會避免在 UTF-16 配對字元中間切開。
X、Threads 的頁面經常在不重新載入的情況下切換內容，因此只改一次標題不夠。外掛會監看後續的標題變化，並在欄位取得焦點、按鍵及開始組字時同步檢查長度。
整個操作仍然是在原本的欄位裡完成：打注音、選字、確認文字，不必叫出其他輸入框，也不需要用剪貼簿轉貼。這個外掛採用 Manifest V3 內容腳本，沒有修改自然輸入法的 DLL，也沒有修補它的二進位檔。
第二個問題：Telegram 把組字空白當成空欄位清掉
解決 X／Threads 問題之後，我突然想起之前跟 OpenClaw、Hermes 等 AI Agent 都是用 Telegram Web 網頁版溝通，當時也出現「一直打注音，欄位沒有反應」的問題。但只要先打英文或數字，後面的中文就正常；清空欄位又可能失敗，在當時沒想到是自然輸入法問題，現在順便一起解決。
這次跟 Codex 監看發現，自然輸入法 V11 開始組字時，會先把一個占位空白交給網頁。Telegram 的輸入事件處理程式判斷內容只有空白，便呼叫 replaceChildren() 清空欄位。占位內容約 6–9 毫秒後被移除，下一個按鍵又重新開始組字，導致流程無法順利接續。
我們不是只靠時間先後推論：針對該欄位的 DOM 呼叫追蹤，確實抓到 Telegram 自己的清空呼叫。Telegram Web K 的公開原始碼也有將只有空白的欄位視為空內容、再清空的處理。這也能解釋「先打英文或數字就正常」：欄位已有非空白內容，就不再走這條空欄位清理路徑。問題不是特定中文字被封鎖，而是第一段組字還沒完成，網站就把它使用的占位內容清掉了。
解法是在實際訊息欄位取得焦點、正在組字、內容僅有空白，且網站要清空所有子節點時，暫時保留占位空白。確認文字、取消組字、離開欄位與一般清空仍可進行；不用自動補英文或數字。套用後，我們用實際 V11 連續確認四次從空白欄位輸入「輸入測試」或「測試輸入」成功。這項保護已加入 v0.2.0，支援 web.telegram.org/k/；Telegram Web A、桌面版及 V12／V13 的這項修正尚未個別驗證。
第三個問題：Gmail Gemini 也是組字干擾
這個 BUG 是臉友提供的，不然我本來沒注意到。在 Gmail 網頁寫信時一般欄位正常，但右側 Gemini 提問欄位卻間歇性無法輸入注音。有時整段沒有反應，有時只漏掉第一個音，例如 ㄕㄨ 的 ㄕ 消失，最後變成「屋」；修正前另一次「輸入測試」只出現「入測試」。切換英文仍能輸入。
事件紀錄確認按鍵抵達欄位，焦點也沒有跑掉，但組字空白約 1–2 毫秒後被移除，下一鍵又重新開始組字。後續追蹤抓到 Gmail／Gemini 的清空程式逐個移除欄位子節點。
這裡有一次重要的試錯：最初的原型嘗試直接阻止 DOM 清空，卻讓網站「只要還有子節點就繼續刪除」的迴圈無法前進，頁面暫時卡住。我們終止執行、撤回這個原型，正式外掛沒有包含這種攔截。
最後採用的方式更窄：當「向 Gemini 提問」欄位收到組字中、內容只有一個占位空白的 input 通知時，暫時不讓網站處理這個通知。原生編輯照常進行，真正的中文字、英文、刪除與其他欄位的事件仍正常傳遞。 這樣不用阻止網站的 DOM 刪除方法，也不會卡住它的清空迴圈。
套用新版原型後，實際 V11 紀錄捕捉到七次中文輸入事件，包含清空後直接輸入完整「輸入測試」、連續中文與換行。我也回報「現在正常」「現在都正常」。目前沒有向 Gemini 送出提問，驗證的是編輯器輸入。
這項初步有效的修正已加入修正外掛的 v0.2.0，但仍保留實驗性標記。目前選擇器只涵蓋繁體中文介面的「向 Gemini 提問」，其他介面語言、V12／V13，以及長時間使用的穩定性仍待驗證。早期也有空白移除後仍成功輸入的例子，因此不能宣稱所有間歇失效的原因都已找齊。
為什麼微軟注音正常，自然輸入法卻失敗？
這看起來奇怪，但同樣打注音，背後的輸入法實作不一定一樣。網頁收到的是輸入法與瀏覽器轉換後的組字事件，不只是鍵盤上的 ㄕ 或 ㄨ；不同輸入法的組字內容、時機與按鍵事件可能有差異。本次已觀察到自然輸入法 V11 使用占位空白，而網站的清理程式會干擾它。微軟注音可能沒有觸發相同的空白流程，或以不同的事件時序維持組字；我們尚未抓取微軟注音的對照紀錄，所以這仍是推論，不能寫成已證實的差異。
至於長標題當機，錯誤位於自然輸入法自己的 DLL，微軟注音沒有走那段程式。不能因為微軟注音正常，就認定網站沒有相容問題，也不能反過來把所有中文輸入異常都歸咎於同一個 BUG。
免費開源外掛下載與安裝
專案已公開在 GitHub，採用 MIT 授權。目前透過 GitHub 下載，並以瀏覽器「載入未封裝項目」方式安裝，尚未上架 Chrome 線上應用程式商店。不過老實說這個問題應該是自然輸入法官方自己要解決，我一開始還以為是 V11 版太舊的問題，不過這情況是在 Chrome 某次改版後發生，猜測是 Chromium 核心更新造成的問題，如果官方看到應該要積極處理才是。
Chrome 安裝步驟（載入方式可參照 Chrome 官方教學）：
- 到下載頁的 Assets 區，取得
natural-ime-v11-title-guard-v0.2.0.zip（或之後的新版），解壓縮到固定資料夾。這裡要下載的是外掛發布包。 - 在 Chrome 網址列開啟
chrome://extensions，打開「開發人員模式」。 - 按「載入未封裝項目」，選擇解壓縮後、裡面有
manifest.json的natural-ime-v11-title-guard資料夾。 - 依 Chrome 顯示的流程確認網站存取權。v0.2.0 除 X／Threads 外，也包含 Telegram Web K 與 Gmail；Gemini 修正目前對應繁體中文介面的「向 Gemini 提問」。
- 先保存現有草稿，再重新載入 X／Threads、Telegram 或 Gmail 分頁，讓外掛開始執行。
- 回到原本不能輸入的欄位，保持欄位空白，直接用自然輸入法打「輸入測試」。確認文字留下後清空，再重複幾次；不必發文或送出訊息。
如果下載的是 GitHub 的原始碼 ZIP，第三步改選其中的 extension 資料夾。Edge 可在 edge://extensions 依相同方式載入；目前公開的實際頁面測試以 Chrome 為主。
已安裝舊版的人，先保存草稿，以新版檔案替換原外掛資料夾中的檔案，在擴充功能頁按這個外掛的重新載入按鈕，依畫面確認新增網站存取權，再重新整理網站。只重新整理網頁，不能把舊版外掛更新成新版。
若 Chrome 顯示找不到資訊清單，請確認選到的資料夾直接包含 manifest.json，不是外面多一層的 ZIP 解壓縮資料夾。要暫時停用修正，可在擴充功能頁關閉外掛，再保存草稿並重新載入網站。
外掛會讀取我輸入的文字嗎？
本外掛已經上 GitHub 開源分享，有需要的可以自己下載使用， X／Threads 腳本只讀寫分頁標題；Telegram 腳本會讀取指定訊息欄位的當前文字，判斷是否只有組字空白；Gmail 腳本會檢查 Gemini 的輸入事件是否為占位空白。這些文字與事件不會被記錄、儲存或傳送。外掛沒有讀取剪貼簿、帳號或 Cookie，也沒有網路請求。Gmail 腳本不查閱郵件內容與一般郵件欄位。Telegram Web K 與 Gmail 的頁面存取範圍，安裝或更新時應確認這些網站權限，擔心的話大家可以把這篇內容交給 AI 自行開發自己的版本。
如果你使用自然輸入法 V11～V13，遇到特定網頁中文失效，可以下載開源外掛，在原本出問題的欄位測試。回報時請附上輸入法與瀏覽器版本、網站與欄位、英文是否正常，以及可重現的操作；後續確認會更新在專案的已知問題與驗證範圍 。
如果遇到類似問題，怎麼一步步排查？
這次經驗中，畫面同樣是「中文沒有出現」，背後卻至少有兩條不同的故障路徑。可以依下面順序縮小範圍，避免只看到症狀就認定是同一個問題：
- 先確認範圍。 在記事本、另一個 Chrome 分頁，以及同頁不同輸入欄位，測試同一段「輸入測試」。記下是所有程式失敗、特定頁面失敗，還是只有 Gemini 這種特定欄位失敗。
- 比較中文與英文。 中文沒有反應時，切換英文測試；再比較「空白欄位直接中文」與「保留一個英文或數字後再中文」。這能幫助辨識是否與空欄位清理有關，但先打英文只是線索，不等於修好。
- 記下清空與重整的影響。 清空後是否復發？重整後是否只是暫時恢復？不要把一次成功當成穩定修正，也要分清楚是自己按刪除，還是網站自動移除組字內容。
- 檢查標題與當機。 有技術經驗的讀者可在開發者工具 Console 查看
document.title.length；一般讀者可先比較首頁、短標題頁與原本失敗的貼文。另在 Windows 的可靠性監視器或事件檢視器找同一時間的輸入法服務當機紀錄。分頁標題不等於完整視窗標題，瀏覽器還會加上後綴，單靠長度不能下結論。 - 追蹤組字到哪裡中斷。 本次進一步監看
compositionstart、compositionupdate、compositionend、beforeinput、input，同時看欄位 DOM。若完整中文根本未交付，與先交付再被移除，處理方向不同。必要時再追蹤網站的清空呼叫來源。 - 用真正的輸入法驗證修正。 在原失敗頁面從空白欄位重複輸入，清空後再試，再測連續中文、英文、換行與正常刪除。自動化直接塞中文字或送出模擬組字，會繞過 Windows 輸入法，不能當成原問題已解決的證據。
回報時附上輸入法與瀏覽器版本、網站和欄位名稱、以上對照結果即可。當機檔、錄影與事件紀錄可能含私人資料，不要直接公開郵件、對話或帳號內容。
