In this article I’ll fill you in on exactly what every working programmer should know. All that stuff about "plain text = ascii = characters are 8 bits" it’s hopelessly wrong.

Some people are under the misconception that Unicode is simply a 16-bit code where each character takes 16 bits and therefore there are 65,536 possible characters.
This is not, actually, correct. It is the single most common myth about Unicode, so if you thought that, don’t feel bad.

Until now, we’ve assumed that a letter maps to some bits which you can store on disk or in memory:
A -> 0100 0001 // 65 (hex:41)

Every platonic letter in every alphabet is assigned a magic number by the Unicode consortium which is written like this: U+0639.  This magic number is called a code point.
The U+ means "Unicode" and the numbers are hexadecimal. U+0639 is the Arabic letter Ain. The English letter A would be U+0041.
You can find them all using the charmap utility on Windows 2000/XP or visiting the Unicode web site. // http://www.unicode.org/

# РАЗНИЦА МЕЖДУ high-endian & low-endian в том, КАК читать слово "Hello"
// так:
00 48 00 65 00 6C 00 6C 00 6F   // high
// или так:
48 00 65 00 6C 00 6C 00 6F 00   // low
// разные CPU имеют разную скорость обработки
в начало каждой Unicode-строки кладутся 2 байта (Unicode Byte Order Mark): FE+FF (hiend) или FF+FE (loend) // http://www.unicode.org/faq/utf_bom.html
if you are swapping your high and low bytes it will look like a FF+FE and the person reading your string will know that they have to swap every other byte.
(НЕТ, не каждой! Not every Unicode string in the wild has a byte order mark at the beginning).
// в utf-8 НЕТ этих индейцев: There are no byte-order/endianness issues, since UTF-8 data is a byte stream.

Using UCS-2 (or UCS-4) under Unix would lead to very severe problems. Strings with these encodings can contain as parts of many wide characters bytes like "\0" or "/" which have a special
meaning in filenames and other C library function params. In addition, the majority of UNIX tools expects ASCII files and cannot read 16-bit words as characters without major modifications.
For these reasons, UCS-2 is not a suitable external encoding of Unicode in filenames, text files, environment variables, etc.

The UTF-8 encoding defined in ISO 10646-1:2000 Annex D and also described in RFC 3629 as well as section 3.9 of the Unicode 4.0 standard does not have these problems.
It is clearly the way to go for using Unicode under Unix-style operating systems.

// UTF-8 has the following properties:
1. UCS characters U+0000 to U+007F (ASCII) are encoded simply as bytes 0x00 to 0x7F (ASCII compatibility).
    This means that files and strings which contain only 7-bit ASCII characters have the same encoding under both ASCII and UTF-8.
2. All UCS characters >U+007F are encoded as a sequence of several bytes, each of which has the most significant bit set.
    Therefore, no ASCII byte (0x00-0x7F) can appear as part of any other character.
3. The first byte of a multibyte sequence that represents a non-ASCII character is always in the range 0xC0 to 0xFD and it indicates how many bytes follow for this character.
    All further bytes in a multibyte sequence are in the range 0x80 to 0xBF. This allows easy resynchronization and makes the encoding stateless and robust against missing bytes.
4. All possible 2^31 UCS codes can be encoded.
5. UTF-8 encoded characters may theoretically be up to six bytes long, however 16-bit BMP characters are only up to three bytes long.
6. The sorting order of Bigendian UCS-4 byte strings is preserved.
7. The bytes 0xFE and 0xFF are never used in the UTF-8 encoding (little/big Endian).

// Examples: The Unicode character U+00A9 = 1010 1001 (copyright sign) is encoded in UTF-8 as
    11000010 10101001 = 0xC2 0xA9
// and character U+2260 = 0010 0010 0110 0000 (not equal to) is encoded as:
    11100010 10001001 10100000 = 0xE2 0x89 0xA0

The official name and spelling of this encoding is UTF-8, where UTF stands for UCS Transformation Format.
Please do not write UTF-8 in any documentation text in other ways (such as utf8 or UTF_8), unless of course you refer to a variable name and not the encoding itself.

An important note for developers of UTF-8 decoding routines: For security reasons, a UTF-8 decoder must not accept UTF-8 sequences that are longer than necessary to encode a character.
For example, the character U+000A (line feed) must be accepted from a UTF-8 stream only in the form 0x0A, but not in any of the following five possible overlong forms:
  0xC0 0x8A
  0xE0 0x80 0x8A
  0xF0 0x80 0x80 0x8A
  0xF8 0x80 0x80 0x80 0x8A
  0xFC 0x80 0x80 0x80 0x80 0x8A


wchar_t следует избегать практически во всех случаях (кроме тех, когда происходит взаимодействие с Windows API).