Code Table

This is a tabular overview of the similarities and differences of the following text encodings:

• ISO 8859-1 (Latin-1 Western European)
• ISO 8859-2 (Latin-2 Central European)
• ISO 8859-3 (Latin-3 South European)
• ISO 8859-4 (Latin-4 North European)
• ISO 8859-5 (Latin / Cyrillic)
• ISO 8859-6 (Latin / Arabic)
• ISO 8859-7 (Latin / Greek)
• ISO 8859-8 (Latin / Hebrew)
• ISO 8859-9 (Latin-5 Turkish)
• ISO 8859-10 (Latin-6 Nordic)
• ISO 8859-11 (Latin / Thai)
• ISO 8859-13 (Latin-7 Baltic Rim)
• ISO 8859-14 (Latin-8 Celtic)
• ISO 8859-15 (Latin-9)
• ISO 8859-16 (Latin-10 South-Eastern European)
• Windows-1250 (similar to Latin-2, but using 0x80-0x9f for characters and keeping some Latin-1 characters in the 0xa0-0xbf range)
• Windows-1252 (similar to Latin-1, but using 0x80-0x9f for additional characters)
• IBM Code Page 437
• IBM Code Page 850
• Mac OS Roman
• UTF-8

Notes

ISO/IEC 8859 (without hyphen), as defined by ISO/IEC, does not assign control codes to the 0x00-0x1f and 0x7f-0x9f ranges. This is done by its superset ISO-8859 (with hyphen), as defined by IANA, which assigns the C0 and C1 control codes to these code points, as given below.

The "Latin-x" naming of the various ISO-8859 variants is non-continuous. Note the "holes" (8859-5 to 8859-8 and 8859-11 are not "Latin-x").

Standardization of ISO 8859-12 (Devanagari) was officially abandoned in 1997.

IBM CP858 differs from CP850 in only one character: 0xD5 (LATIN SMALL LETTER DOTLESS I), which was replaced with the Euro currency symbol.

Several devices from the IBM codepage era interpret code points 0x01 - 0x1F and 0x7F as graphic characters, but the official encoding tables list the same C0 control codes as given for the Windows and ISO/IEC codepages. The graphic characters are not given here.

Historically, CP1252 was based on an ANSI draft, and calling this encoding "ANSI" is still common in the Microsoft universe despite being a misnomer.

Unicode code points are given as 16bit hexadecimal on this page. This is enough to cover the Basic Multilingual Plane, and by implication, all characters presented here. However, Unicode also specifies several Supplementary Planes (e.g. historic scripts, extended CJK ideographs, emoticons etc.), which are outside the 16bit range. If you need to hold all conceivable Unicode code points, use a 32bit integer.

There are several characters that, from a casual look at their glyphs, seem to be identical, but are not. Special attention is advised at code point 0xd0 (Unicode characters 0x00d0 'Ð' and 0x0110 'Đ'). Other "close" characters are found at 0xd5, 0xd9, 0xe3, 0xf1, 0xf5, 0xfb and 0xf0.

Notation

The top row in each table cell is the character (or the acronym of a control code / special character, see note above).

Bottom row is the Unicode code point as 16-bit hexadecimal (but see note above).

On mouse-over, a tooltip appears with four lines of information:

• HTML encoding of characters (entity where available, Unicode notation for others), long name for control codes;
• Unicode character name;
• UTF-8 encoding (as one or more 8-bit hexadecimal);
• UTF-8 encoding (as one or more 8-bit octal).

The octal encoding is presented for use in C/C++ string literals (\ooo is well-defined, whereas \xhh fails to work as expected if the next character is also a valid hex digit).

Control codes and special characters are given as their two- or three-letter acronym, with a bold-line box around their table cell. (Character 0x20 is the standard space).

A code point not assigned a character in a given encoding is given a black box.

Code points that are assigned a character in the given encoding which differs from ISO-8859-1 are given a grey box. (In case of Windows-1250, grey boxes indicate differences from ISO-8859-2.)

Combining characters are given light grey boxes.

0x00 - 0x7f - the similarities

The first 127 code points are identical for all encodings, including UTF-8 (which was the whole point behind the latter).

0x80 - 0x9f - the twiddly bits

Having a text with codes in this area is a good indication that you are looking at an IBM or Windows encoding, not ISO/IEC (as the C1 control characters are hardly ever used in "normal" text).

0xA0 - 0xFF - The Long March

This is where all encodings have their respective special characters. If you have text with codes from this area (and none in the 0x80 - 0x9f area above), you can only guess as to which encoding you are looking at. Try to find out which characters would make sense in their respective places, and strike off those encodings that would not give meaningful results. (Always keeping in mind that there might be typos in the text and perhaps not all characters do make sense.)

[1]: Apple machines rendered 0xF0 as the Apple logo.

ISO 8859-1 vs. ISO 8859-15 vs. Windows-1252 vs. Unicode

The Latin-1, Latin-9 and Windows-1252 encodings are very difficult to tell apart, especially if the file in question has only a few characters in the "differing" range. Thus a table listing the characters in which Latin-1 and Latin-9 differ, including their encodings in Windows-1252.

Windows Codepages for ISO Encodings

If your environment forces you to state an encoding using codepage numbers, but you want to use ISO/IEC Latin encodings, here is a list of how Windows refers to those standard encodings:

Demonstration of variable length vs. wide encoding

Most people have problems with understanding that UTF-16 is not a "wide" encoding. Just like with UTF-8, a single code point can require more than one code unit (up to four 8-bit code units in UTF-8, up to two 16-bit code units in UTF-16). The only really wide encoding is UTF-32, which takes 32 bits for every code point.

To showcase this, some example characters and their respective encoding. All code units are hexadecimal.

Character	a	ä	Š	€
ISO-8859-15	61	e4	a6	a4	---
UTF-32	00000061	000000e4	00000160	000020ac	0002f929
UTF-16	0061	00e4	0160	20ac	d87e dd29
UTF-8	61	c3 a4	c5 a0	e2 82 ac	f0 af a4 a9

And then you still have to consider that a code point does not necessarily equal a character, and that a given character does not imply a specific code point.

The character Ü, for example, can be encoded as either U+00dc (LATIN CAPITAL LETTER U WITH DIAERESIS), or as the sequence of the two code points U+0055 U+0308 (LATIN CAPITAL LETTER U, COMBINING DIAERESIS).

Hangul 가, for example, can be either the pair U+1100, U+1161 -- or the precomposed U+AC00.

Emojis can combine, forming grapheme clusters.

With UTF-16 and UTF-32, you also have to consider endianess. To enable parsers to determine endianess of a text automatically, a special character is put at the beginning, the Byte Order Mark (BOM, code point U+feff). If no BOM exists, Big Endian should be assumed.

UTF-8 does not have this issue, and a BOM is not required.

Rule of thumb when looking at UTF-8: Any byte value of 0x80 or higher is part of a multi-byte sequence.

Rule of thumb when looking at UTF-16: Any 16-bit value between 0xd800 and 0xdfff is part of a surrogate pair.

Weblinks

• UTF-8 Reference
• Unicode character search
• List of XML and HTML character entity references
• Unicode converter