JavaScript 按鍵代碼查詢工具是一項在本機、瀏覽器端運作的替代方案，可取代靜態的按鍵代碼參考表。它會在一個刻意取得焦點的擷取區域中捕捉單一 KeyboardEvent，並顯示現代的 key 與 code 欄位、位置、輔助鍵、重複狀態、組合狀態，以及舊式的 keyCode，而無須將按鍵動作或文字傳送至伺服器。靜態的按鍵代碼列表描述的是瀏覽器在 2000 年代初期於 Windows 上的舊行為，但無法回答真實應用程式真正會問的問題：按下的是哪個實體按鍵、目前鍵盤配置產生了什麼字元、按下的是左側或右側的 Alt，以及這個事件是否是按住按鍵時自動觸發的重複事件。一個本機擷取的替代方案能在執行你程式碼的同一個瀏覽器內回答這些問題，因此診斷結果反映的是真實輸入，而不是一張背下來的對應表。本文將說明開發者為何會尋找替代方案、基於擷取的工具實際解決了什麼問題、檢查按鍵的確切步驟，以及當你同時看到 key、code 與 keyCode 時該如何選擇。
為何靜態參考表對真實應用不再管用
查詢按鍵代碼的傳統方式是一張人手整理的 HTML 表格，以十進位數字對應按鍵名稱。這類表格在網頁應用程式剛萌芽時還算有用，但無法抵擋現代輸入的三項現實：鍵盤配置、輔助鍵組合，以及同一邏輯按鍵擁有多個實體位置。參考表可以列出 50 是 US QWERTY 鍵盤上數字 2 的 keyCode，卻無法告訴你使用者按下的究竟是數字列的 2、數字鍵盤的 2，或在 Dvorak 配置上同一個實體按鍵會產生不同字元的字母列位置。它也無法顯示擷取到的 Alt 是左側還是右側變體、keydown 是否是按住按鍵時觸發的重複事件，或是輸入法編輯器目前是否正在組字。
當你建立一個以字元 @ 為核心的快捷鍵時，舊式做法會去抓一個固定的整數，而現代做法則會讀取 event.key。當你建立一個依賴 W、A、S、D 鍵的移動處理器時，你需要從 event.code 取得與配置無關的識別碼。參考表因為只回答一個數字，把這兩種情況混為一談，讓你得自行猜測該整數代表的是意義、位置，還是瀏覽器的特殊怪癖。一個能讀取你剛剛觸發之實際 KeyboardEvent 的擷取工具，則能把這些答案乾淨俐落地分開，這也正是為何在真實專案中，搜尋 JavaScript 按鍵代碼查詢工具替代方案的行為會一再出現。
開發者會尋找替代方案，也因為部分熱門工具會上傳按鍵動作、為硬體加上指紋、記錄完整歷史，或在頁面上以明碼保存使用者輸入的秘密。一個值得信賴的替代方案則專注於一次一個事件、記憶體中僅保留最新一個事件，並明確勸阻使用者在診斷期間輸入密碼或復原碼。這些限制屬於一個重視隱私工具的合約的一部分，而非行銷話術，且會反映在頁面的建構方式上。
本機擷取替代方案實際解決了什麼
基於擷取的工具會在你於其受限焦點區域內按下按鍵的那一刻，精準觀察一次 keydown，接著將該事件對應到 W3C UI Events 規格所定義、也是當今每個現代瀏覽器都會呈現的標準化欄位。它並非要你背誦十進位與名稱的配對，而是直接顯示瀏覽器對你所關心按鍵實際回報的內容，包含各國字母、數字鍵盤的數字、功能鍵、導覽鍵以及輔助鍵組合。由於擷取動作是在你的瀏覽器內於執行階段發生，因此這些數值反映的是你真實的配置、真實的平台，以及真實的 IME 狀態，而非憑空猜測的近似值。
JavaScript 按鍵代碼查詢工具正是圍繞著這個單一事件模型所建構。它不會安裝全域監聽器、不儲存歷史記錄、不識別鍵盤型號、不對硬體建立指紋，也不會上傳事件資料。擷取區域保持鍵盤可存取：絕不取消 Tab 鍵，因此使用者可以將焦點移開，而不會被卡住。其他按鍵的預設動作，僅在擷取目標取得焦點期間被取消，因此在你檢查按鍵時，空白鍵與方向鍵不會捲動頁面。
這個單一事件、本機儲存的模型之所以對診斷至關重要，是因為大多數程式碼路徑在正常使用期間會產生各式各樣的事件。一個全域監聽的工具會看到每個焦點元素上的每一次按鍵，包括在無關輸入欄位中輸入的文字。透過將擷取限制在一個焦點區域內，並在下一次按下時替換擷取到的事件，這個工具既能讓頁面保持乾淨，又能精確回答你所提出的問題。
逐步檢查 KeyboardEvent
使用基於擷取的替代方案，是一個四步驟的工作流程，可融入任何除錯工作階段：
- 點擊或以 Tab 切換至 JavaScript 按鍵代碼查詢工具頁面頂部帶有邊框的擷取區域，讓該區域取得焦點並準備好觀察一次 keydown。
- 按下你想檢查的按鍵或組合——可以是單一字母、帶 Shift 的數字、功能鍵、數字鍵盤的按鍵，或輔助鍵加字母的組合，例如 Control+S 或 Shift+Digit2。
- 依序讀取顯示的欄位：key 代表套用目前配置與輔助鍵狀態後所產生的意義；code 代表實體按鍵位置；location 用來區分標準、左、右及數字鍵盤變體；輔助鍵清單用來確認事件發生當時按住了哪些鍵；repeat 用來檢查瀏覽器是否正在發出按住按鍵的重複事件；isComposing 則用來查看 IME 或死鍵組合是否仍在作用中。
- 僅在需要用於錯誤回報或本機測試固定資料時，才將顯示的記錄以格式化 JSON 形式複製下來，接著確認你正在除錯的 JavaScript 快捷鍵或輸入處理器，在你功能所支援的真實目標瀏覽器、配置與作業系統上，都能產生預期的數值。
舉個具體例子，想像你正在除錯一位 US QWERTY 使用者同時按下 Shift 與數字列 2 的情況。按照上述四個步驟操作後，擷取區域會回報 key 為 "@"、code 為 "Digit2"、location 為 0（標準），且 shiftKey 為 true。比較一下在沒有 Shift 情況下按住同一個實體按鍵：key 會變成 "2"，而 code 仍然是 "Digit2"。key 欄位會變動，是因為它遵循配置與輔助鍵；code 欄位不會變動，則是因為它遵循實體位置。靜態參考表永遠無法同時顯示這兩者，這正是一個能感知配置的替代方案值得加入書籤的原因。
key、code 與 keyCode：選擇正確的欄位
key 與 code 之間的區別，正是開發者搜尋替代方案的最常見原因。較舊的程式碼片段使用數值型 keyCode 來偵測字母，這會在不同瀏覽器間產生不一致的結果，並完全忽略配置。一個現代的擷取工具會同時將兩個欄位顯示在畫面上，讓你能挑選符合用途的那一個。下表比較此工具所呈現的三個欄位，所使用的數值直接來自標準本身，以及當今瀏覽器填入這些欄位的方式。
| 欄位 | 回答什麼問題 | 跨配置是否穩定？ | 跨輔助鍵狀態是否穩定？ | 建議用途 |
|---|---|---|---|---|
| key | 套用配置與輔助鍵後所產生的意義 | 否——Dvorak 配置可能會使其改變 | 否——Shift 會把 "2" 變成 "@" | 應遵循字元或具名動作的快捷鍵，例如 Ctrl+S 的儲存 |
| code | 鍵盤上的實體按鍵位置 | 實際上跨主要配置為是 | 依定義為是 | 物理位置很重要的情況，例如 WASD 移動、數字鍵盤運算，或左與右 Shift 的區分 |
| keyCode | 舊式的數值識別碼 | 否 | 否 | 僅用於相容性診斷；新程式碼不應以此進行分支判斷（依據 MDN KeyboardEvent 文件） |
對於輔助鍵，key 經常回傳具名動作——「Shift」、「Control」、「Alt」、「Meta」、「Enter」——而 code 則能區分「ShiftLeft」與「ShiftRight」。location 欄位以數值標籤重複同樣的區分，這在遊戲、無障礙控制或輸入診斷必須對左與右變體分別處理時尤為重要。W3C UI Events 規格將 key 與 code 視為獨立且互補的識別碼；同一個事件會同時提供兩者，而你依據所要回答的問題選擇讀取哪一個。
安全地讀取 JSON 診斷輸出
當你檢查完一個按鍵，便可將記錄以格式化 JSON 形式複製，用於錯誤回報或測試固定資料。這個 JSON 區塊是一份診斷資料，並非指令。請用對待任何其他擷取承載的方式處理它：讀取它、決定你的程式碼應依賴哪個欄位，然後在功能所支援的真實瀏覽器、配置、作業系統與輔助科技上驗證該決定。完整記錄包含 key、code、location、altKey、ctrlKey、shiftKey 與 metaKey 等輔助鍵旗標、repeat 旗標、isComposing 旗標，以及已棄用的 keyCode 數值。
其中有兩個旗標值得特別注意。當瀏覽器在使用者按住按鍵時發出重複的 keydown 事件，repeat 會變成 true；快捷鍵處理器通常需要忽略重複事件，使單次長時間按住不會重複觸發同一動作。當 IME 或死鍵序列正在產出文字時，isComposing 會變成 true；同一事件也可能透過組字產出文字，因此快捷鍵處理器一般應如 MDN KeyboardEvent 文件所建議，等到組字結束後再動作。這兩個旗標都會出現在擷取輸出中，便於你對照真實裝置進行確認。
在建構自動化測試時，這份 JSON 也能作為起點，但請記住合成的 KeyboardEvent 固定資料並非受信任的使用者輸入，未必能重現原生平台的行為。一套健全的測試組合，應包含在功能承諾支援的配置上、以真實裝置執行的測試，而非僅仰賴測試執行器中產生的合成事件。把這份 JSON 想成是，在你偏好的環境中對單一標準化事件的紀錄文件，之後再以實體鍵盤的執行結果加以驗證。
Limits of In-Browser Capture
Even with a clean local alternative, several real-world limits deserve to be named. Browser-reserved shortcuts such as Ctrl+T or Ctrl+W, operating-system shortcuts such as Alt+Tab or Ctrl+Alt+Delete, accessibility technology, password managers, remote desktops, and input methods can all intercept events before any page receives them. Mobile virtual keyboards may expose fewer code values because no physical key position exists. None of these limits are unique to the JavaScript Key Code Finder; they apply to every browser-side diagnostic, which is why the final compatibility check must run on the real target devices.
A few practical rules follow. Do not infer ASCII, Unicode, or a typed character from the deprecated keyCode; a value of zero does not necessarily mean that no key exists, and printable-key behavior has differed across browsers and layouts. Avoid typing passwords, recovery codes, or other secrets even though the captured record stays local, because a keyboard diagnostic never needs confidential content. Provide an alternate clickable control for essential shortcuts, document layout-specific conflicts, and never make a single physical keyboard layout the only way to complete a critical action.
A capture-based alternative earns its place by exposing key and code side by side, holding only one event at a time, running entirely inside the browser, and refusing to obscure that legacy fields like keyCode carry no modern guarantee. Static tables and global listeners each fail at least one of those requirements, which is the gap a focused capture tool is built to close. Treat the diagnostic as a fast answer to a layout-aware question, then confirm it on the real device before shipping the feature.
Related reading: Nano ID Generator Alternative: A Browser-Based Option.