Alt code

On IBM compatible personal computers, characters available in the currently active codepage, but not associated with direct key combinations in the currently active keyboard layout can be entered using the Alt Numpad input method to enter an Alt code: pressing and holding the Alt key while typing the corresponding character code with the keyboard's numeric keypad. Similar or extended forms of this feature are also available in many operating systems, including DOS and Microsoft Windows.

Often this is the best or only method many computer users know for entering non-ASCII characters. Many Wikipedia articles on various characters will include how to type that character using Alt codes for codepage 437.

History and description
Originally on IBM PCs, the user could hold down the Alt key and type a decimal number on the keypad. The system BIOS would place the corresponding code into the keyboard buffer so that, for software using the BIOS for character input, it would look (almost) as if the code would have been entered by a direct key combination in the default US keyboard layout. Applications reading that code from the keyboard buffer (through the BIOS) would behave according to what action they associate with that code. Some would interpret the code as a command, but often it would be interpreted as a code to be placed on the screen at the location of the cursor, thus displaying the corresponding 8-bit character from the current codepage. Without other software loaded, this is the so called hardware codepage, which is codepage 437 for original IBM PCs and most other computer systems using English. Some Eastern European, Arabic and Asian computers use other hardware codepages, however.

When an operating system like DOS was used, it became possible to load drivers (typically named ) to change the keyboard layout and override the hardware codepage with a varity of other codepages and even switch between them at runtime with commands like   or. While most English systems still used codepage 437 under DOS, another very common choice in locales using variants of the Latin alphabet was codepage 850, which provided more Latin character variants than codepage 437. There were, however, many more codepages; for a more complete list, see codepage. The default codepage under DOS is called OEM codepage by Microsoft. The DOS keyboard driver basically resembled the same Alt Numpad input method of the underlying BIOS driver, sometimes slightly modified or extended in its behaviour in order to cope with locale-specific peculiarities of the chosen keyboard layout. In either case, the resulting characters were those associated with the currently active 8-bit codepage of the console.

These numbers became so well known and memorized by computer users that Microsoft was forced to preserve them even though it used a new and different set of codepages for Windows. Codepage 1252, the English default Windows codepage, or similar international codepages of the new set were called ANSI codepages by Microsoft. Holding Alt and typing three digits (first one non-zero) would attempt to translate the code from the 8-bit OEM codepage (for example, codepage 850) to the matching glyph in the 8-bit Windows codepage. A leading zero (0) and then a number would produce the character from the ANSI codepage instead. In a DOS box, the traditional Alt Numpad input method (typically without leading zero) was still available and resulted in whatever (OEM) codepage the corresponding console was assigned to.

For instance, the combination Alt+42 (or under Windows Alt+042 in both cases) yields "*" (codepoint 42 is invariant in most codepages). Typing Alt+161 for codepoint 161 would result in "í" (Latin letter i with acute accent) with an OEM codepage setting of e.g. 437 or 850, but may show other characters in other codepages. On a Windows system using codepage 1252 as ANSI codepage, Alt+0161 yields the character "¡" (inverted exclamation) which is at 161 in ANSI codepage 1252.

When Windows later transitioned to Unicode, the 0-leading codes had become so well known as well that a third method needed to be invented to produce Unicode codepoints. Although codepage 1252 is quite close to the start of Unicode and it would seem logical to just allow larger numbers to be typed, other international sets did not match. In addition, some users were accustomed to the composition exiting after the third digit without releasing Alt, and numbers larger than 255 being translated modulus 256. To enable the third method, a user must set or create the registry key  with type REG_SZ to value 1 and reboot (logging out and logging back in is sufficient). Once the registry key is set, the following method can be used to enter Unicode codepoints: For example, Alt++11b will produce "ě" (e with caron).
 * Keep the key pressed. Press the  key on the numeric keypad.
 * With the key still pressed, type the hexadecimal number using the numeric keypad for digits - and the normal keys for -.

The transition to Unicode actually made the older legacy Alt codes (the ones with no leading zero) more reliable, as all the glyphs in the legacy codepages have matching glyphs in Unicode, so they all work.

Problems
If Num Lock is disabled, attempting an Alt code may cause unexpected results in some applications. For example, +4 can be taken as +←, causing a web browser to go back one page.

Many laptops do not have a separate numeric keypad; however, the Fn key can be used to turn certain keys into a numeric keypad. There usually is a key called Num lock to "shift" certain keys to act as if they were the numeric keypad keys. For example, on keyboards where there is no dedicated num-pad (mostly found on small-medium laptops and netbooks), the following scheme is very common:

Linux
The Alt key method does not work on Linux systems. There are two alternative methods for direct input of Unicode characters in Linux:
 * Hold and type  followed by the four hex digits. Then release Ctrl + Shift.
 * Enter, then type the four hex digits, and press.

In OpenOffice.org and Inkscape, for example, only the second method works.

GTK
GTK-based applications sport a similar input method:


 * Press and type the two hex digits. Then release  again.

Opera
In the Opera, Unicode characters can be entered by typing the four hex-digits and then press Ctrl.

K3PLUS / FreeKEYB
The alternative DOS keyboard and console drivers K3PLUS and FreeKEYB offered a number of extensions to the Alt Numpad input method compared to the default behaviour of the standard keyboard driver KEYB. For example, codepoints could be entered in various numeral systems:


 * Decimal system: followed by one to three decimal digits (-)
 * Hex system: followed by one or two hex digits (-, -)
 * Octal system: followed by one to three octal digits (-)
 * Binary system: followed by one to eight binary digits (-)

As with a standard keyboard driver, in decimal input mode the first digit had to be entered through the Numpad in order to avoid conflicts with standard key definitions for the layer. However, once in Alt input mode, these keyboard drivers accepted key presses for digits 0-9 also from the numeric row, and the key could be released again. Leading zeros were accepted as well. Pressing instead of releasing the  key would output the character without leaving the Alt input method, so that characters could be repeated. was used to emulate keyboard scancodes rather than only compose characters. In addition to this, integer calculations and combinational logic evaluation could be carried out in a small resident RPN-like calculator embedded into the Alt Numpad input method. This included a base converter into other numeral systems by pressing, , , or before releasing the  key. Pressing would output the current value as text. Numbers could be stored in a set of internal memories for later use. If invoked, another feature of these keyboard drivers, a freely moveable second cursor called CopyCursor, could be used to take the character under the CopyCursor as input into the Alt Numpad input method, so that characters on the screen could be converted back into an expression of its codepoint, stuffed into the keyboard buffer and read by applications like editors. Since these functions were an integral part of the keyboard driver, they were fully transparent to running software and therefore worked with virtually any DOS programs when using these drivers. Examples:

+ or + would both produce the character "*", + would produce the string "2Ah", whereas + would result in the string "42d" to be spooled into the keyboard buffer instead.