瀏覽器語言切換 MultiLangSwitcher，讓網站用你選的語言回應

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

「為什麼我把瀏覽器語言切成日文，打開網站還是給我中文？」用過語言切換擴充的人，幾乎都撞過這堵牆。答案一句話講完：網站決定端出什麼語言，看的是三條線，瀏覽器請求裡的 Accept-Language 標頭、你的 IP 位址、你在站上的帳號設定。MultiLangSwitcher 動的只有第一條，而它把改這條線做到點一下就完成：開源、免費、內建 56 個語言選項，還能依網域自動切換。判斷先講，前端開發者與需要反覆驗證網站多語言行為的人，它省下的工夫值得你花四分鐘做原始碼安裝；單純想看外語版網站的人，它對 IP 導向的大站多半無感；至於把它當成反指紋隱私工具的期待，開發者自己在說明文件裡潑了冷水，這點後面會攤開講。

先交代這篇的立足點：我把它的 GitHub 倉庫 clone 下來，讀過 manifest 權限宣告、語言選項清單、網域規則與 AI 整合的原始碼，也翻完中英兩版說明文件與全部 30 個版本的發布紀錄；但我沒有實際裝進瀏覽器跑，所以切換後的實際體感與穩定度，這篇不替它背書，只講原始碼與官方文件撐得住的部分。

Accept-Language：網站聽你報上名的第一句話

瀏覽器發出的每個請求，都會帶一行 Accept-Language 標頭，長得像 zh-TW,zh;q=0.9,en;q=0.8，這是 HTTP 的語言協商機制，瀏覽器替你向網站報告「我偏好的語言是這些，按順序排」。伺服器收到後，決定回你中文頁、英文頁，還是把你導去別的網址。而網站判斷語言的三條線裡，這條是唯一你能直接控制的。

其實不裝任何擴充，瀏覽器設定頁也能改這個標頭，問題在於那是全系統式的變更：介面語言跟著換、偏好語言清單要挖好幾層選單，測完還要記得改回來。需要的是「快切、可逆、不動瀏覽器本體」，這正是這個擴充的存在理由。它的做法是在 Manifest V3 架構下用 declarativeNetRequest 宣告式規則改寫請求標頭，規則交給瀏覽器核心層處理，不需要背景程式攔在每個請求中間監聽，這也是 Manifest V3 時代改請求頭的正規路數。說明文件裡把它跟常見的 User-Agent 切換器並列，兩者確實常搭配使用，一個改身分、一個改語言，湊一套完整的偽裝測試環境。

56 個語言選項，以及它會自己看網域辦事

我逐項數過原始碼裡的語言選項，共 56 個，覆蓋邏輯相當務實：中文三種變體（zh-TW、zh-HK、zh-CN）、英文八種變體（美英澳加愛紐印新加坡）、日韓與東南亞七種、西法德葡的主要變體、俄語與東歐一圈、北歐四語，連土耳其文、阿拉伯文、希伯來文、印地文、波斯文都在清單上，立陶宛、拉脫維亞、愛沙尼亞也沒缺席。操作是彈出視窗下拉選單選語言、按套用，選過的值存在瀏覽器本地儲存，重開瀏覽器仍在。

Pin

比手動切換更有意思的是網域自動模式。原始碼裡有一份網域對應規則表，一百多條靜態映射，邏輯是「這個網域註冊在哪個地區，就套用該地慣用的語言」：com.tw、org.tw、gov.tw、edu.tw 一律送 zh-TW，co.jp 送日文，gov.uk 送英式英文，com.cn 送簡中，其餘類推，沒對應到的網域預設英文。要注意這是「網域地區對語言」的固定規則，它並不會去偵測每個網站本身支援什麼語言，好處是開了自動模式後，逛不同國家的網站不必逐站手切；壞處是規則怎麼定是開發者說了算，覺得對應不合理只能去 debug 頁看規則細節，沒有圖形化介面讓你逐條改。

對台灣使用者還有一個要先想通的細節：預設值是英文而不是你的母語。意思是開啟自動模式後，逛 .com、.net 這類不帶地區尾巴的國際網域，送出去的是英文標頭，逛 .co.jp 才送日文。換句話說，這個模式主張「入境隨俗」，並不打算把所有網站都變成中文。如果你想測的情境是「全部網站都用繁中回應」，那自動模式反而幫倒忙，手動鎖定 zh-TW 再關掉自動切換，才是對的用法。

切完怎麼知道生效了：偵測頁與除錯工具

這個擴充把「驗證」做進本體，是我讀原始碼結構時覺得最值得肯定的部分。內建偵測頁會顯示實際送出的 Accept-Language 標頭、瀏覽器的 navigator.language 與 navigator.languages、Intl 國際化資訊，再加碼列出 WebRTC 本地 IP、Canvas、WebGL、AudioContext 這些指紋欄位，等於切換前後的環境差異一頁看清。

偵測頁刻意把 Accept-Language 與 navigator 兩組值並列顯示，因為它們是不同層的東西，也是評估這類工具時最該分清楚的概念：Accept-Language 是網路層的請求標頭，伺服器看得到；navigator.language 是頁面裡 JavaScript 讀得到的瀏覽器設定，跟著瀏覽器介面語言走。這個擴充用 declarativeNetRequest 改的是前者，我翻遍 manifest 確認它沒有申請任何內容腳本，不注入網頁，所以頁面 JS 讀到的語言環境不會跟著變。實際後果是：靠伺服器端讀標頭做語言導向的網站會反應，靠前端 JavaScript 偵測語言再切換介面的網站則無感。測試時對照偵測頁這兩組值，就能立刻判斷你面對的網站吃哪一套。

除錯頁則更工程師取向：能看每一條生效中的規則細節、對多個端點發測試請求看回傳的標頭、輸入任意完整的自訂 Accept-Language 字串（例如 en-US,en;q=0.9,zh-CN;q=0.8）套用，還有即時日誌與一鍵修復規則衝突。自訂字串這格別小看，帶 q 值權重的多語言標頭正是拿來測 fallback 鏈的：故意送一個網站不支援的第一順位語言，看它會退到清單裡第二順位還是直接給預設語言，這是多語言網站上線前該驗而常常沒驗的行為。改了標頭立刻驗證、壞了有地方查，對測試工作流程的價值，比多塞幾十個語言選項實在。

沒上商店：四步原始碼安裝，和它帶來的摩擦

它在 Chrome Web Store 與 Edge Add-ons 都沒有上架。原因它自己講得很直白，中文版說明文件只給了一句話，開發者沒有註冊 Google 開發者帳號，上架自然無從談起。於是安裝只能走原始碼路線：從 GitHub 下載 Release 壓縮檔解壓（或直接 clone 倉庫）、打開 chrome://extensions/ 或 edge://extensions/、開啟開發人員模式、載入未封裝項目，四步收工。步驟不難，代價要先知道：開發人員模式載入的擴充，Chrome 每次啟動都會跳「停用開發人員模式擴充功能」的提醒，瀏覽器大版本更新後偶爾得手動重新載入，這是所有未上架擴充共同的宿命。附檔形態也隨版本變過：v2.1.0 之前的 Release 還附 crx 檔，之後已停附、只出 zip，而新版 Chrome 本來就不接受商店外的 crx 直接安裝，這條路不用試。介面語言也只有簡體中文跟英文兩種，沒有繁中選項，而且判定邏輯看的是瀏覽器語言開頭：你的瀏覽器是 zh-TW，開頭算 zh，介面就會落在簡體中文，對繁中使用者來說讀起來難免有幾分彆扭。

Pin

下載來源也有講究：請直接從 GitHub Release 頁拿最新壓縮檔，這個專案維持 rolling release，倉庫頁面頂部就掛著最新版連結。第三方網站流傳的瀏覽器擴充安裝檔被二次打包動手腳的案例時有所聞，何況這裡原始碼全程公開，沒有理由繞路。

這種方式裝的擴充不會自動更新，這是原始碼安裝的後續成本。它倒是把這件事的痛感降到最低，彈出視窗內建版本檢查，背後去問 GitHub 的最新 release 資訊，有新版時會顯示版本比較並附上下載連結，原始碼裡看得到這段邏輯。但下載之後的動作仍是手動的：解壓新版的資料夾、回到擴充管理頁按重新載入。把它想成一套「有通知、無自動」的更新流程，心裡就不會落差。

權限要了什麼：讀 manifest 的兩面

安裝任何擴充前看一眼 manifest 是習慣，這份我讀了。它申請的權限是 storage、declarativeNetRequest、declarativeNetRequestFeedback、tabs、contextMenus，網站權限則是 <all_urls>。全站權限看起來嚇人，但改 Accept-Language 這件事本來就必須對所有網站生效才有意義，而宣告式規則只改表頭，不讀頁面內容、不碰回應本體，這與舊式 WebRequest 需要攔截流量的路數不同。內容安全政策是 script-src ‘self’，不載入任何遠端程式碼，這在擴充安全裡是正面訊號。

專案的體質最後交代一下。授權條款 AGPL-3.0，自由軟體，改作商用要注意衍生作品有同樣開源義務；2025 年 5 月發第一版，15 個月內累積 30 個 release，v2.2.0 做過一次完全重構，最新版 v2.2.4 是 2026 年 8 月出的，倉庫 9 月初還有提交紀錄，80 顆星。以個人維護的擴充來說，這個節奏不算懈怠，起碼原始碼攤在陽光下，有疑慮可以自己驗。

三件它做不到、甚至幫倒忙的事

IP 導向的網站，切了也白切。 說明文件自己寫明「不適用於以 IP 位址判斷語言的網站」。串流平台、多數跨國大站的語言決策權在 IP 與帳號設定手上，Accept-Language 只排在後面甚至根本不看。切了標頭沒反應，別急著怪工具，先確認那個站吃不吃這條線，偵測頁看得到標頭已經改了，網站不領情是網站的選擇。

指紋會變得更獨特，離隱形更遠。 中英兩版說明文件都有一段罕見的誠實自白，意思是調整瀏覽器語言設定可以混淆部分偵測，但這會提高你瀏覽器指紋的唯一性。道理不難想：標頭報日文、IP 在台灣、時區在台北，這個組合在人群中反而更罕見。而且別忘了前面講的分層：這個擴充只改網路層的 Accept-Language，頁面裡 JavaScript 讀到的 navigator.language 仍是原值，一個標頭宣稱日文、執行環境宣稱中文的瀏覽器，兩層訊號互相矛盾，這種不一致本身就是指紋偵測方眼裡的高辨識特徵。反指紋的正解是讓自己更像多數人，這工具做的恰恰是往反方向走。想降低辨識度的人，方向錯了。

AI 診斷會把你的環境快照送出門。 偵測頁內建 AI 診斷功能，會把含語言設定、時區與部分指紋欄位的快照，送去你指定的 AI 服務解讀。原始碼裡預建了九家 OpenAI 相容端點：OpenRouter、OpenAI、DeepSeek、Google Gemini、阿里雲、矽基流動、智譜、Moonshot 與 MiniMax，另留一格自訂端點，全都用自己的 API key 啟用。說明文件的提醒寫得很直白，把 AI 診斷視為第三方資料共享，只接你信任的供應商。一個用途是幫你切換語言身分的工具，附帶功能卻會把真實環境快照往外送，要不要用、key 給誰，用之前想清楚。

誰該裝，誰不用麻煩

該裝的輪廓很清楚：你在做多語言網站的前端或測試，需要快速驗證語言協商、導向邏輯與本地化呈現，它附帶的偵測與除錯頁讓這件事不出擴充就能做完，四分鐘的安裝成本攤下來很便宜。想看特定網站外語版的人可以一試，但預期要先校準：先在偵測頁確認標頭已經換了，再觀察目標網站吃不吃這套，沒反應的站就是走 IP 或帳號邏輯，擴充救不了。至於只是想改瀏覽器介面語言的人，Chrome 與 Edge 的設定頁本來就能做，不必裝任何東西；想要反指紋的人，前面講過，這個方向是反的。

第一步建議這樣走：到 GitHub 專案頁抓最新 Release 解壓、照上面四步裝起來、打開它的偵測頁看一眼目前的 Accept-Language，再切一次語言重新整理，對照前後差異，這個工具值不值得留在你的工具列，五分鐘內就會有答案。順帶一提，如果你平常就在乎瀏覽器的乾淨程度，可以看看之前寫過的 Chrome 與 Edge 精簡化指南，擴充裝得少，這類權限問題本來就少一半；累積太多沒在用的擴充時，Chrome 擴充功能清理工具 值得一併看看；需要常駐 Chrome 擴充工作流程的人，也能參考 SmartCopy 這類語言友善的擴充工具怎麼取捨權限。