At least under unix (I wont even try to assume win32's behaviour), all keyboard control keys, such as cursor arrows, function keys, home/insert/del and friends, follow the escape code immediately with a '[' when dumped into the keyboard input buffer. So it would be reasonably safe to have your code immediately assume that escape was pressed by itself if the following character was NOT '['. The key sequence 'ESC','[' is highly unlikely to be used for anything other than the function/control keys.

So, if the escape character WAS followed by '[', you can immediately jump to a keyboard control key parser, which 'listens' for a variable length sequence depending on the characters that follow.
On a linux console, F1 through F5 are represented by '\e[[A' through '\e[[E'. F6 through F12 return '\e[[17~' through '\e[[24~', cursor keys return '\e[A' through '\e[D', and the INS/DEL/PG/etc matrix returns '\e[1~' through '\e[6~', respectively. So there are some easy-to-recognize patterns to look for.

As someone else might have stated, the character sequences you get when someone hits a function or cursor control key are completely dependent on the OS that the keyboard is attached to. Luckily, most OSs adhere to the lowest common denominator of vt100 and/or ansi terminal emulation when passing data to the running program.

The "raw" data coming from the keyboard are called scancodes, and they're usually exactly one byte in length, and have more correlation to the position of the key on the keyboard membrane matrix than what's on the keycap. Luckily, that's pretty standardized as well, but you wouldn't need to worry about the scancodes at all in your case.