In my experience String.fromCharCode(e.keyCode) is unreliable. String.fromCharCode expects unicode charcodes as an argument; e.keyCode returns javascript keycodes. Javascript keycodes and unicode charcodes are not the same thing! In particular, the numberpad keys return a different keycode from the ordinary number keys (since they are different keys) while the same keycode is returned for both upper and lowercase letters (you pressed the same key in both cases), despite them having different charcodes.
For example, the ordinary number key 1 generates an event with keycode 49 while numberpad key 1 (with Numlock on) generates keycode 97. Used with String.fromCharCode we get the following:
String.fromCharCode(49) returns "1"
String.fromCharCode(97) returns "a"
String.fromCharCode expects unicode charcodes, not javascript keycodes. The key a generates an event with a keycode of 65, independentant of the case of the character it would generate (there is also a modifier for if the Shift key is pressed, etc. in the event). The character a has a unicode charcode of 61 while the character A has a charcode of 41 (according to, for example, http://www.utf8-chartable.de/). However, those are hex values, converting to decimal gives us a charcode of 65 for “A” and 97 for “a”.[1] This is consistent with what we get from String.fromCharCode for these values.
My own requirement was limited to processing numbers and ordinary letters (accepting or rejecting depending on the position in the string) and letting control characters (F-keys, Ctrl-something) through. Thus I can check for the control characters, if it’s not a control character I check against a range and only then do I need to get the actual character. Given I’m not worried about case (I change all letters to uppercase anyway) and have already limited the range of keycodes, I only have to worry about the numberpad keys. The following suffices for that:
String.fromCharCode((96 <= key && key <= 105)? key-48 : key)
More generally, a function to reliably return the character from a charcode would be great (maybe as a jQuery plugin), but I don’t have time to write it just now. Sorry.
I’d also mention e.which (if you’re using jQuery) which normalizes e.keyCode and e.charCode, so that you don’t need to worry about what sort of key was pressed. The problem with combining it with String.fromCharCode remains.
[1] I was confused for a while -. all the docs say that String.fromCharCode expects a unicode charcode, while in practice it seemed to work for ASCII charcodes, but that was I think due to the need to convert to decimal from hex, combined with the fact that ASCII charcodes and unicode decimal charcodes overlap for ordinary latin letters.