一开始我想实时监控<input type="text">的变化(例如，当用户按下一个键时)。onChange事件不起作用，因为只有当用户按下Enter或从输入元素中移除焦点时才会触发它。然后我在StackOverflow上看到了这个问题。我尝试了这个答案中的代码，但问题是我不想收到不代表可打印字符的按键通知，所以我不得不以这种方式修改它，使其验证事件中是否有可打印字符:
...
textInputElement.onKeyDown.listen((KeyboardEvent ev) {
if (new String.fromCharCode(ev.keyCode).length > 0) {
callAFunction();
}
});
...
(+ onKeyUp事件相同的变化)
当我在Dartium中进行测试时，我看到通过聚焦输入元素然后按任何键，ev.keyCode = ev.which = 229和ev.charCode = 0触发keydown事件。在此事件之后，另一个keydown事件被触发，使用按下的键的正确ev.keyCode = ev.which和ev.charCode = 0。我不明白这个229键是从哪里来的，但我看到它是一个可打印的字符，å。我搜索了一下互联网，我发现其他人也有这个问题，有时他们使用其他编程语言和技术。一个相关的链接是这样的，选择的修复是在这个非常小的提交中-他们选择忽略所有具有keyCode = 229的事件，并解释说，最近版本的Chrome/Chromium/WebKit开始在每个标准键盘事件之前发送这些keydown事件，并且它们的含义是用户按下了某个按钮。但是输入法仍然在处理或者输入法编辑器正在处理键输入。
我的问题是，如果new String.fromCharCode(229)返回可打印字符"å"，是否可以忽略keydown事件与keyCode = 229 ?我考虑了一种可能的情况:有一个真正的密钥，它产生相同的密钥代码和相应的字符。
简短的回答是否定的。可以忽略keyCode = 229的keydown事件，但前提是它们紧跟在按键事件之后。
如果你按住某些键，一些浏览器发送一个重复的keydown事件，keyCode值为229，而另一些浏览器再次发送原始keydown keyCode。有些浏览器发送0作为与按键事件相关联的keyCode，并将字符代码放在charCode属性中。
在所有情况下，从我的测试中可以看出，事件的顺序总是可以预测的:
keydown (event.keyCode = key-keyCode ex: 65 = "A")
keypress (event.keyCode = 0 | character-keyCode ex: 97 = "a") - conflated model
event.charCode = character-keyCode - split model
keydown (event.keyCode = 229 | key-keyCode ex: 229 | 65) - may be repeated
keyup (event.keyCode = key-keyCode ex: 65)
字母
EVENT keyCode
keydown 219 ("[" key position)
keypress 229 (å)
keydown 229 (repeatedly, indicating that the Input Monitor is busy)
keyup 219
注意初始keydown keyCode是219，而不是229。
要在初始keydown事件上生成229 keyCode，您可以按任何"死键"。例如，在Mac上的瑞典语键盘上，紧靠BACKSPACE键左边的键是´(重音)，用于déjà-vu这样的单词。当您按死键时，字符出现在输入字段中，但插入点不移动。当您随后键入一个可以与之组合的字符时，浏览器可能会将初始的死键字符替换为具有自己的Unicode值的复合字符(´+ e =
以下是您将在Safari 6.1.5中看到的事件，当用户在瑞典键盘上按下并释放'后跟着e时:
EVENT keyCode
keydown 229 (dead key)
keyup 187 (acute accent)
keydown 229 (second key is being treated)
keyup 69 ("E")
请注意，根本没有发送任何按键事件，因为没有"
换句话说，您可以忽略在按键事件之后带有229 keyCode 的任何按键事件，但是如果忽略所有229 keyCode，您可能会阻止用户添加各种变音符字符。
有关keyCode 229的更多信息，请访问w3.org网站:键事件的keyCode属性