按键键值查询

功能

• 按下任意键，同时显示 key、code、keyCode、which 与 ASCII 码
• 逐项标明每个字段跟着什么走 —— 字符、物理位置、还是老代码的遗留值
• 可打印字符给出十进制与十六进制的 ASCII 码（`A` 是 65 / 0x41）
• 属性键给出 ASCII 控制码（回车 13 是 CR、Delete 127 是 DEL），这正是「keyCode 与 ASCII 对不上」的来源
• 同时按住的修饰键组合会列出来（Ctrl + Shift）
• 长按产生的重复事件会标出来 —— 判断「按住不放」时要用到
• 输入法组字中会明确提示（这时 `key` 是 `Process`，不是工具坏了）
• 100 多个键位的速查表，按名字、code、keyCode 或 ASCII 码都能搜
• 左右 Shift / Ctrl / Alt 各自成条 —— 只有 `code` 分得清左右，keyCode 一律相同
• 0–127 的 ASCII 码表，控制字符给缩写与说明，而不是 33 个空白格子
• 带 Ctrl / Alt / Cmd 的组合键不被拦截，浏览器自己的快捷键照常可用

使用方法

1. 点一下页面顶部的检测框，然后按键盘上任意一个键
2. 结果区立刻列出这个键的 key、code、keyCode、ASCII 码与修饰键状态
3. 想看别的键就接着按 —— 不需要点任何按钮
4. 在下方速查表里按键名或键值搜索，或者直接翻 0–127 的 ASCII 码表

常见问题

keyCode 都已经废弃了，为什么还要查它？

因为废弃的是规范，不是它出现在代码里的事实。已有的项目、老版本的库、以及大量还在跑的示例代码里都是 `event.keyCode`，读它们时必须知道那个数字是什么意思；反过来写新代码时，也需要一个对照来确认「这个键在新写法里该用 `key` 还是 `code`」。所以这里把它和另外两个并列给出，并标明它已废弃 —— 而不是藏起来。

为什么 Delete 的 keyCode 是 46，ASCII 码却是 127？

这两个数字回答的是不同的问题。`keyCode` 说的是「按了哪个键」，Delete 键在小键盘上的位置编号是 46；ASCII 说的是「产生了哪个字符」，而 Delete 在 ASCII 表里是 127（DEL）。回车键同理：`keyCode` 13 恰好等于它的 ASCII 控制码 13（CR），纯属历史巧合 —— 因为这个键从终端时代起就直接产生那个字节。工具里把这两栏分开显示，就是为了让这件事看得见。

写代码时该用 key 还是 code？

看你要的是字符还是位置。快捷键（如 Ctrl+S）用 `code`：它对应物理位置，不会因为用户切到俄语或法语键盘就失灵；而「用户打出了什么字符」用 `key`：输入判断、快捷键提示、游戏操作都属于这一类。历史经验是：用 `keyCode` 写快捷键，在非美式键盘上会出错，这正是它被废弃的主要原因。

中文输入法打字时为什么显示 Process？

因为那时按键还没有变成字符。输入法正在组字（本工具会同时标出「输入法组字中」），此时浏览器上报的 `key` 就是 `Process`，`keyCode` 是 229。这不是故障，而是一个真实的信号：要判断用户真的输入了什么，得等 `compositionend` 之后再读，只看 `keydown` 会把一段中文读成一串 `Process`。

为什么按 Ctrl+W 没有被这个页面拦住？

故意的。这个页面只在焦点位于检测框内、且没有按修饰键时拦截少量按键的默认行为 —— 具体是空格与方向键（否则页面会被滚走）以及 `/`（Firefox 的快速查找）。带 Ctrl / Alt / Cmd 的组合一律放行：那些是浏览器与操作系统的地盘，连 Ctrl+W（关标签页）、F5（刷新）、F12（开发者工具）都拦掉的话，用户只会以为自己的浏览器坏了。