ASCII table — decimal, hex, octal and binary

The structure of the table

ASCII is a 7-bit code with 128 positions, standardised in 1963 and essentially unchanged since. It divides cleanly into four blocks of 32, and the boundaries were chosen so that common operations became single bit flips.

• 0–31 plus 127 — control characters. Not printable; they instruct a device.
• 32–63 — space, punctuation and the digits.
• 64–95 — @, the uppercase letters, and five brackets.
• 96–126 — backtick, the lowercase letters, and the braces.

Two consequences of that layout are still used constantly. Uppercase and lowercase differ by exactly one bit (0x20), so case conversion is c ^ 32. And a digit’s numeric value is its code minus 48, which is why c - '0' parses a digit in C.

Control characters that still matter

Dec	Name	Escape	Still used for
0	NUL	\0	Terminating C strings; a null byte in input is a classic injection vector
7	BEL	\a	The terminal beep, and the terminator of some OSC escape sequences
8	BS	\b	Backspace
9	HT	\t	Tab — the delimiter in TSV, and in Makefiles
10	LF	\n	Newline on Unix and in every internet protocol
12	FF	\f	Page break in printed output and some source files
13	CR	\r	Paired with LF as CRLF on Windows and in HTTP headers
27	ESC	\e	Starts every ANSI terminal colour and cursor sequence
4	EOT	—	What Ctrl+D sends: end of input
3	ETX	—	What Ctrl+C sends: interrupt

The Ctrl-key mapping is not a coincidence: holding Ctrl clears the top two bits, so Ctrl+A is 1, Ctrl+C is 3 and Ctrl+[ is 27, which is why Escape and Ctrl+[ are the same keystroke in vim.

CR, LF and the line-ending problem

Unix and macOS end a line with LF alone. Windows uses CRLF, inherited from teletypes where the carriage physically returned and then the paper advanced. HTTP headers, SMTP and most internet protocols specify CRLF.

The symptoms are recognisable: a stray ^M at the end of every line in a diff, a shell script failing with “bad interpreter” because the shebang line ends in CR, and a comparison that fails between two apparently identical strings. Configure git’s core.autocrlf or add a .gitattributes and the problem stops recurring.

Above 127: where mojibake comes from

ASCII stops at 127. Everything above is a different standard, and the two that matter disagree in exactly the range people paste from.

ISO-8859-1 (Latin-1) leaves 128–159 as a second block of unused control codes. Windows-1252 fills that block with typographic characters: curly quotes, the em dash, the ellipsis, the euro sign. When a document containing those is declared as Latin-1 or UTF-8 and decoded as the other, you get the familiar corruption — a curly quote becoming “, an em dash becoming —. The 128–159 rows in the table above are marked so the source of that is visible.

ASCII and UTF-8

UTF-8 was designed so every ASCII byte encodes itself: any file containing only characters 0–127 is simultaneously valid ASCII and valid UTF-8. Characters above 127 use two to four bytes, each with the high bit set, so an ASCII parser reading UTF-8 never mistakes a continuation byte for a delimiter. That backwards compatibility is the single reason UTF-8 displaced every competing encoding.

Converting in code

JavaScript:  "A".charCodeAt(0)      // 65
             String.fromCharCode(65)  // "A"
             "🎉".codePointAt(0)      // 127881 — use this above U+FFFF
Python:      ord("A")   chr(65)
Go:          rune('A')  string(rune(65))
Shell:       printf '%d' "'A"   printf '\x41'

In JavaScript, prefer codePointAt and fromCodePoint over the charCode pair: the older functions work on UTF-16 code units, so they return half of a surrogate pair for emoji and other characters above U+FFFF.