Как называется международный стандарт кодирования текстовых символов windows unicode

UTF-8 is a variable-length character encoding standard used for electronic communication. Defined by the Unicode Standard, the name is derived from Unicode (or Universal Coded Character Set) Transformation Format – 8-bit.^[1]

UTF-8 is capable of encoding all 1,112,064^[a] valid character code points in Unicode using one to four one-byte (8-bit) code units. Code points with lower numerical values, which tend to occur more frequently, are encoded using fewer bytes. It was designed for backward compatibility with ASCII: the first 128 characters of Unicode, which correspond one-to-one with ASCII, are encoded using a single byte with the same binary value as ASCII, so that valid ASCII text is valid UTF-8-encoded Unicode as well.

UTF-8 was designed as a superior alternative to UTF-1, a proposed variable-length encoding with partial ASCII compatibility which lacked some features including self-synchronization and fully ASCII-compatible handling of characters such as slashes. Ken Thompson and Rob Pike produced the first implementation for the Plan 9 operating system in September 1992.^[2][3] This led to its adoption by X/Open as its specification for FSS-UTF,^[4] which would first be officially presented at USENIX in January 1993^[5] and subsequently adopted by the Internet Engineering Task Force (IETF) in RFC 2277 (BCP 18)^[6] for future internet standards work, replacing Single Byte Character Sets such as Latin-1 in older RFCs.

UTF-8 is the dominant encoding for the World Wide Web (and internet technologies), accounting for 97.8% of all web pages, and up to 100.0% for many languages, as of 2023.^[7] Virtually all countries and languages have 95.0% or more use of UTF-8 encodings on the web.

Naming[edit]

The official Internet Assigned Numbers Authority (IANA) code for the encoding is «UTF-8«.^[8] All letters are upper-case, and the name is hyphenated. This spelling is used in all the Unicode Consortium documents relating to the encoding. However, the name «utf-8» may be used by all standards conforming to the IANA list (which include CSS, HTML, XML, and HTTP headers),^[9] as the declaration is case-insensitive.^[8]

Other variants, such as those that omit the hyphen or replace it with a space, i.e. «utf8» or «UTF 8«, are not accepted as correct by the governing standards.^[10] Despite this, most web browsers can understand them, and so standards intended to describe existing practice (such as HTML5) may effectively require their recognition.^[11]

«UTF-8-BOM» and «UTF-8-NOBOM» are sometimes used for text files which contain or don’t contain a byte order mark (BOM), respectively.^{[citation needed]} In Japan especially, UTF-8 encoding without a BOM is sometimes called «UTF-8N«.^[12][13]

In Windows UTF-8 is codepage 65001^[14] (i.e. CP_UTF8 in source code).

In HP PCL, UTF-8 is called Symbol-ID «18N».^[15]

Encoding[edit]

UTF-8 encodes code points in one to four bytes, depending on the value of the code point. In the following table, the x characters are replaced by the bits of the code point:

The first 128 code points (ASCII) need one byte. The next 1,920 code points need two bytes to encode, which covers the remainder of almost all Latin-script alphabets, and also IPA extensions, Greek, Cyrillic, Coptic, Armenian, Hebrew, Arabic, Syriac, Thaana and N’Ko alphabets, as well as Combining Diacritical Marks. Three bytes are needed for the rest of the Basic Multilingual Plane (BMP), which contains virtually all code points in common use,^[16] including most Chinese, Japanese and Korean characters. Four bytes are needed for code points in the other planes of Unicode, which include less common CJK characters, various historic scripts, mathematical symbols, and emoji (pictographic symbols).

A «character» can take more than 4 bytes because it is made of more than one code point. For instance a national flag character takes 8 bytes since it’s «constructed from a pair of Unicode scalar values» both from outside the BMP.^[17][c]

Examples[edit]

Consider the encoding of the euro sign, €:

1. The Unicode code point for € is U+20AC.
2. As this code point lies between U+0800 and U+FFFF, this will take three bytes to encode.
3. Hexadecimal 20AC is binary 0010 0000 1010 1100. The two leading zeros are added because a three-byte encoding needs exactly sixteen bits from the code point.
4. Because the encoding will be three bytes long, its leading byte starts with three 1s, then a 0 (1110…)
5. The four most significant bits of the code point are stored in the remaining low order four bits of this byte (11100010), leaving 12 bits of the code point yet to be encoded (…0000 1010 1100).
6. All continuation bytes contain exactly six bits from the code point. So the next six bits of the code point are stored in the low order six bits of the next byte, and 10 is stored in the high order two bits to mark it as a continuation byte (so 10000010).
7. Finally the last six bits of the code point are stored in the low order six bits of the final byte, and again 10 is stored in the high order two bits (10101100).

The three bytes 11100010 10000010 10101100 can be more concisely written in hexadecimal, as E2 82 AC.

The following table summarizes this conversion, as well as others with different lengths in UTF-8. The colors indicate how bits from the code point are distributed among the UTF-8 bytes. Additional bits added by the UTF-8 encoding process are shown in black.

Octal[edit]

UTF-8’s use of six bits per byte to represent the actual characters being encoded means that octal notation (which uses 3-bit groups) can aid in the comparison of UTF-8 sequences with one another and in manual conversion.^[18]

With octal notation, the arbitrary octal digits, marked with x, y, z or w in the table, will remain unchanged when converting to or from UTF-8.

Example: Á = U+00C1 = 0301 (in octal) is encoded as 303 201 in UTF-8 (C3 81 in hex).

Example: € = U+20AC = 020254 is encoded as 342 202 254 in UTF-8 (E2 82 AC in hex).

Codepage layout[edit]

The following table summarizes usage of UTF-8 code units (individual bytes or octets) in a code page format. The upper half is for bytes used only in single-byte codes, so it looks like a normal code page; the lower half is for continuation bytes and leading bytes and is explained further in the legend below.

  7-bit (single-byte) code points. They must not be followed by a continuation byte.^[19]

  Continuation bytes.^[20] The tooltip shows in hex the value of the 6 bits they add.^[d]

  Leading bytes for a sequence of multiple bytes, must be followed by exactly N−1 continuation bytes.^[21] The tooltip shows the code point range and the Unicode blocks encoded by sequences starting with this byte.

Overlong encodings[edit]

In principle, it would be possible to inflate the number of bytes in an encoding by padding the code point with leading 0s. To encode the euro sign € from the above example in four bytes instead of three, it could be padded with leading 0s until it was 21 bits long –
000 000010 000010 101100, and encoded as 11110000 10000010 10000010 10101100 (or F0 82 82 AC in hexadecimal). This is called an overlong encoding.

The standard specifies that the correct encoding of a code point uses only the minimum number of bytes required to hold the significant bits of the code point. Longer encodings are called overlong and are not valid UTF-8 representations of the code point. This rule maintains a one-to-one correspondence between code points and their valid encodings, so that there is a unique valid encoding for each code point. This ensures that string comparisons and searches are well-defined.

Invalid sequences and error handling[edit]

Not all sequences of bytes are valid UTF-8. A UTF-8 decoder should be prepared for:

• invalid bytes
• an unexpected continuation byte
• a non-continuation byte before the end of the character
• the string ending before the end of the character (which can happen in simple string truncation)
• an overlong encoding
• a sequence that decodes to an invalid code point

Many of the first UTF-8 decoders would decode these, ignoring incorrect bits and accepting overlong results. Carefully crafted invalid UTF-8 could make them either skip or create ASCII characters such as NUL, slash, or quotes. Invalid UTF-8 has been used to bypass security validations in high-profile products including Microsoft’s IIS web server^[26] and Apache’s Tomcat servlet container.^[27] RFC 3629 states «Implementations of the decoding algorithm MUST protect against decoding invalid sequences.»^[10] The Unicode Standard requires decoders to «…treat any ill-formed code unit sequence as an error condition. This guarantees that it will neither interpret nor emit an ill-formed code unit sequence.»

Since RFC 3629 (November 2003), the high and low surrogate halves used by UTF-16 (U+D800 through U+DFFF) and code points not encodable by UTF-16 (those after U+10FFFF) are not legal Unicode values, and their UTF-8 encoding must be treated as an invalid byte sequence. Not decoding unpaired surrogate halves makes it impossible to store invalid UTF-16 (such as Windows filenames or UTF-16 that has been split between the surrogates) as UTF-8,^[28] while it is possible with WTF-8.

Some implementations of decoders throw exceptions on errors.^[29] This has the disadvantage that it can turn what would otherwise be harmless errors (such as a «no such file» error) into a denial of service. For instance early versions of Python 3.0 would exit immediately if the command line or environment variables contained invalid UTF-8.^[30] An alternative practice is to replace errors with a replacement character. Since Unicode 6^[31] (October 2010), the standard (chapter 3) has recommended a «best practice» where the error ends as soon as a disallowed byte is encountered. In these decoders E1,A0,C0 is two errors (2 bytes in the first one). This means an error is no more than three bytes long and never contains the start of a valid character, and there are 21,952 different possible errors.^[32] The standard also recommends replacing each error with the replacement character «�» (U+FFFD).

Byte order mark[edit]

If the Unicode byte order mark (BOM, U+FEFF) character is at the start of a UTF-8 file, the first three bytes will be 0xEF, 0xBB, 0xBF.

The Unicode Standard neither requires nor recommends the use of the BOM for UTF-8, but warns that it may be encountered at the start of a file trans-coded from another encoding.^[33] While ASCII text encoded using UTF-8 is backward compatible with ASCII, this is not true when Unicode Standard recommendations are ignored and a BOM is added. A BOM can confuse software that isn’t prepared for it but can otherwise accept UTF-8, e.g. programming languages that permit non-ASCII bytes in string literals but not at the start of the file. Nevertheless, there was and still is software that always inserts a BOM when writing UTF-8, and refuses to correctly interpret UTF-8 unless the first character is a BOM (or the file only contains ASCII).^[34]

Adoption[edit]

Many standards only support UTF-8, e.g. open JSON exchange requires it (without a byte order mark (BOM)).^[36] UTF-8 is also the recommendation from the WHATWG for HTML and DOM specifications,^[37] and the Internet Mail Consortium recommends that all e‑mail programs be able to display and create mail using UTF-8.^[38][39] The World Wide Web Consortium recommends UTF-8 as the default encoding in XML and HTML (and not just using UTF-8, also declaring it in metadata), «even when all characters are in the ASCII range … Using non-UTF-8 encodings can have unexpected results».^[40]

Lots of software has the ability to read/write UTF-8, and for some functions (even in some Microsoft products) UTF-8 is the only option. In some cases (e.g. on Windows) it may though require the user to change options from the normal settings, or may require a BOM (byte order mark) as the first character to read the file. Examples of software supporting UTF-8 include Microsoft Word^[41][42][43] and Microsoft Excel (2016 and later).^[44][45] Examples of software supporting UTF-8 include Google Drive and LibreOffice. Most databases support UTF-8 (sometimes the only option as with some file formats), including Microsoft’s since SQL Server 2019, resulting in 35% speed increase, and «nearly 50% reduction in storage requirements.»^[46] Microsoft fully supports and recommends UTF-8 for its products such as Windows and Xbox.

UTF-8 has been the most common encoding for the World Wide Web since 2008.^[47] As of February 2023, UTF-8 accounts for on average 97.8% (previously up to 98.0%) of all web pages (and 985 of the top 1,000 highest ranked web pages).^[7] Although many pages only use ASCII characters to display content, few websites now declare their encoding to only be ASCII instead of UTF-8.^[48] Over a third of the languages tracked have 100% UTF-8 use.

For local text files UTF-8 usage is less prevalent, where a few legacy single-byte (and a few CJK multi-byte) encodings remain in use to some degree. The primary cause for this is a few text editors that refuse to use UTF-8 when processing files, unless the first bytes of the file encode a byte order mark character (BOM). However, as most text editors correctly do not require a BOM, they often do not insert a BOM at the start of files they save, causing compatibility issues with such editors. To support editors that expect a BOM, a BOM must be added manually to the start of the file.^[49] Many other text editors simply assume a UTF-8 encoding for all files due to its nigh-ubiquity.^[50] As of current Windows versions (since Windows 10), Windows Notepad defaults to writing UTF-8 without a BOM (a change since Windows 7), bringing it into line with most other text editors.^[51] With regard to system files, some system files on Windows 11 require UTF-8^[52] with no requirement for a BOM, and almost all files on macOS and Linux are required to be UTF-8 without a BOM.^{[citation needed]} Java 18 defaults to reading and writing files as UTF-8,^[53] and in older versions (e.g. LTS versions) only the NIO API was changed to do so. Many other programming languages default to UTF-8 for I/O, including Ruby 3.0^[54][55] and R 4.2.2.^[56] All currently supported versions of Python support UTF-8 for I/O, even on Windows (where it is opt-in for the open() function^[57]), and plans exist to make UTF-8 I/O the default in Python 3.15 on all platforms.^[58]

Usage of UTF-8 within software is also lower than in other areas as UTF-16 is often used instead. This occurs particularly in Windows, but also in JavaScript, Python^[e], Qt, and many other cross-platform software libraries. Compatibility with the Windows API is the primary reason for this, though the belief that direct indexing of the BMP improves speed was also a factor. More recent software has started to use UTF-8 almost exclusively: The default string primitive in Go,^[60] Julia, Rust, Swift 5,^[61] and PyPy^[62] uses UTF-8; a future version of Python is planned to store strings as UTF-8;^[63] and modern versions of Microsoft Visual Studio use UTF-8 internally^[64] (though still requiring a command-line switch to read or write UTF-8^[65]). UTF-8 is the «only text encoding mandated to be supported by the C++ standard» in C++20.^[66] All currently supported Windows versions support UTF-8 in some way (including Xbox^[67]); partial support has existed since at least Windows XP. As of May 2019, Microsoft has reversed its previous position of only recommending UTF-16; the capability to set UTF-8 as the encoding^[f] for the Windows API was introduced. As of 2020, Microsoft recommends programmers use UTF-8.^[68]

History[edit]

The International Organization for Standardization (ISO) set out to compose a universal multi-byte character set in 1989. The draft ISO 10646 standard contained a non-required annex called UTF-1 that provided a byte stream encoding of its 32-bit code points. This encoding was not satisfactory on performance grounds, among other problems, and the biggest problem was probably that it did not have a clear separation between ASCII and non-ASCII: new UTF-1 tools would be backward compatible with ASCII-encoded text, but UTF-1-encoded text could confuse existing code expecting ASCII (or extended ASCII), because it could contain continuation bytes in the range 0x21–0x7E that meant something else in ASCII, e.g., 0x2F for ‘/’, the Unix path directory separator, and this example is reflected in the name and introductory text of its replacement. The table below was derived from a textual description in the annex.

In July 1992, the X/Open committee XoJIG was looking for a better encoding. Dave Prosser of Unix System Laboratories submitted a proposal for one that had faster implementation characteristics and introduced the improvement that 7-bit ASCII characters would only represent themselves; all multi-byte sequences would include only bytes where the high bit was set. The name File System Safe UCS Transformation Format (FSS-UTF) and most of the text of this proposal were later preserved in the final specification.^{[69][70][71][72]}

FSS-UTF[edit]

In August 1992, this proposal was circulated by an IBM X/Open representative to interested parties. A modification by Ken Thompson of the Plan 9 operating system group at Bell Labs made it self-synchronizing, letting a reader start anywhere and immediately detect character boundaries, at the cost of being somewhat less bit-efficient than the previous proposal. It also abandoned the use of biases and instead added the rule that only the shortest possible encoding is allowed; the additional loss in compactness is relatively insignificant, but readers now have to look out for invalid encodings to avoid reliability and especially security issues. Thompson’s design was outlined on September 2, 1992, on a placemat in a New Jersey diner with Rob Pike. In the following days, Pike and Thompson implemented it and updated Plan 9 to use it throughout, and then communicated their success back to X/Open, which accepted it as the specification for FSS-UTF.^[71]

UTF-8 was first officially presented at the USENIX conference in San Diego, from January 25 to 29, 1993. The Internet Engineering Task Force adopted UTF-8 in its Policy on Character Sets and Languages in RFC 2277 (BCP 18) for future internet standards work, replacing Single Byte Character Sets such as Latin-1 in older RFCs.^[73]

In November 2003, UTF-8 was restricted by RFC 3629 to match the constraints of the UTF-16 character encoding: explicitly prohibiting code points corresponding to the high and low surrogate characters removed more than 3% of the three-byte sequences, and ending at U+10FFFF removed more than 48% of the four-byte sequences and all five- and six-byte sequences.

Standards[edit]

There are several current definitions of UTF-8 in various standards documents:

• RFC 3629 / STD 63 (2003), which establishes UTF-8 as a standard internet protocol element
• RFC 5198 defines UTF-8 NFC for Network Interchange (2008)
• ISO/IEC 10646:2014 §9.1 (2014)^[74]
• The Unicode Standard, Version 14.0.0 (2021)^[75]

They supersede the definitions given in the following obsolete works:

• The Unicode Standard, Version 2.0, Appendix A (1996)
• ISO/IEC 10646-1:1993 Amendment 2 / Annex R (1996)
• RFC 2044 (1996)
• RFC 2279 (1998)
• The Unicode Standard, Version 3.0, §2.3 (2000) plus Corrigendum #1 : UTF-8 Shortest Form (2000)
• Unicode Standard Annex #27: Unicode 3.1 (2001)^[76]
• The Unicode Standard, Version 5.0 (2006)^[77]
• The Unicode Standard, Version 6.0 (2010)^[78]

They are all the same in their general mechanics, with the main differences being on issues such as allowed range of code point values and safe handling of invalid input.

Comparison with other encodings[edit]

Some of the important features of this encoding are as follows:

• Backward compatibility: Backward compatibility with ASCII and the enormous amount of software designed to process ASCII-encoded text was the main driving force behind the design of UTF-8. In UTF-8, single bytes with values in the range of 0 to 127 map directly to Unicode code points in the ASCII range. Single bytes in this range represent characters, as they do in ASCII. Moreover, 7-bit bytes (bytes where the most significant bit is 0) never appear in a multi-byte sequence, and no valid multi-byte sequence decodes to an ASCII code-point. A sequence of 7-bit bytes is both valid ASCII and valid UTF-8, and under either interpretation represents the same sequence of characters. Therefore, the 7-bit bytes in a UTF-8 stream represent all and only the ASCII characters in the stream. Thus, many text processors, parsers, protocols, file formats, text display programs, etc., which use ASCII characters for formatting and control purposes, will continue to work as intended by treating the UTF-8 byte stream as a sequence of single-byte characters, without decoding the multi-byte sequences. ASCII characters on which the processing turns, such as punctuation, whitespace, and control characters will never be encoded as multi-byte sequences. It is therefore safe for such processors to simply ignore or pass-through the multi-byte sequences, without decoding them. For example, ASCII whitespace may be used to tokenize a UTF-8 stream into words; ASCII line-feeds may be used to split a UTF-8 stream into lines; and ASCII NUL characters can be used to split UTF-8-encoded data into null-terminated strings. Similarly, many format strings used by library functions like «printf» will correctly handle UTF-8-encoded input arguments.
• Fallback and auto-detection: Only a small subset of possible byte strings are a valid UTF-8 string: several bytes cannot appear; a byte with the high bit set cannot be alone; and further requirements mean that it is extremely unlikely that a readable text in any extended ASCII is valid UTF-8. Part of the popularity of UTF-8 is due to it providing a form of backward compatibility for these as well. A UTF-8 processor which erroneously receives extended ASCII as input can thus «auto-detect» this with very high reliability. A UTF-8 stream may simply contain errors, resulting in the auto-detection scheme producing false positives; but auto-detection is successful in the vast majority of cases, especially with longer texts, and is widely used. It also works to «fall back» or replace 8-bit bytes using the appropriate code-point for a legacy encoding when errors in the UTF-8 are detected, allowing recovery even if UTF-8 and legacy encoding is concatenated in the same file.
• Prefix code: The first byte indicates the number of bytes in the sequence. Reading from a stream can instantaneously decode each individual fully received sequence, without first having to wait for either the first byte of a next sequence or an end-of-stream indication. The length of multi-byte sequences is easily determined by humans as it is simply the number of high-order 1s in the leading byte. An incorrect character will not be decoded if a stream ends mid-sequence.
• Self-synchronization: The leading bytes and the continuation bytes do not share values (continuation bytes start with the bits 10 while single bytes start with 0 and longer lead bytes start with 11). This means a search will not accidentally find the sequence for one character starting in the middle of another character. It also means the start of a character can be found from a random position by backing up at most 3 bytes to find the leading byte. An incorrect character will not be decoded if a stream starts mid-sequence, and a shorter sequence will never appear inside a longer one.
• Sorting order: The chosen values of the leading bytes means that a list of UTF-8 strings can be sorted in code point order by sorting the corresponding byte sequences.

Single-byte[edit]

• UTF-8 can encode any Unicode character, avoiding the need to figure out and set a «code page» or otherwise indicate what character set is in use, and allowing output in multiple scripts at the same time. For many scripts there have been more than one single-byte encoding in usage, so even knowing the script was insufficient information to display it correctly.
• The bytes 0xFE and 0xFF do not appear, so a valid UTF-8 stream never matches the UTF-16 byte order mark and thus cannot be confused with it. The absence of 0xFF (0377) also eliminates the need to escape this byte in Telnet (and FTP control connection).
• UTF-8 encoded text is larger than specialized single-byte encodings except for plain ASCII characters. In the case of scripts which used 8-bit character sets with non-Latin characters encoded in the upper half (such as most Cyrillic and Greek alphabet code pages), characters in UTF-8 will be double the size. For some scripts, such as Thai and Devanagari (which is used by various South Asian languages), characters will triple in size. There are even examples where a single byte turns into a composite character in Unicode and is thus six times larger in UTF-8. This has caused objections in India and other countries.
• It is possible in UTF-8 (or any other multi-byte encoding) to split or truncate a string in the middle of a character. If the two pieces are not re-appended later before interpretation as characters, this can introduce an invalid sequence at both the end of the previous section and the start of the next, and some decoders will not preserve these bytes and result in data loss. Because UTF-8 is self-synchronizing this will however never introduce a different valid character, and it is also fairly easy to move the truncation point backward to the start of a character.
• If the code points are all the same size, measurements of a fixed number of them is easy. Due to ASCII-era documentation where «character» is used as a synonym for «byte» this is often considered important. However, by measuring string positions using bytes instead of «characters» most algorithms can be easily and efficiently adapted for UTF-8. Searching for a string within a long string can for example be done byte by byte; the self-synchronization property prevents false positives.

Other multi-byte[edit]

• UTF-8 can encode any Unicode character. Files in different scripts can be displayed correctly without having to choose the correct code page or font. For instance, Chinese and Arabic can be written in the same file without specialized markup or manual settings that specify an encoding.
• UTF-8 is self-synchronizing: character boundaries are easily identified by scanning for well-defined bit patterns in either direction. If bytes are lost due to error or corruption, one can always locate the next valid character and resume processing. If there is a need to shorten a string to fit a specified field, the previous valid character can easily be found. Many multi-byte encodings such as Shift JIS are much harder to resynchronize. This also means that byte-oriented string-searching algorithms can be used with UTF-8 (as a character is the same as a «word» made up of that many bytes), optimized versions of byte searches can be much faster due to hardware support and lookup tables that have only 256 entries. Self-synchronization does however require that bits be reserved for these markers in every byte, increasing the size.
• Efficient to encode using simple bitwise operations. UTF-8 does not require slower mathematical operations such as multiplication or division (unlike Shift JIS, GB 2312 and other encodings).
• UTF-8 will take more space than a multi-byte encoding designed for a specific script. East Asian legacy encodings generally used two bytes per character yet take three bytes per character in UTF-8.

UTF-16[edit]

• Byte encodings and UTF-8 are represented by byte arrays in programs, and often nothing needs to be done to a function when converting source code from a byte encoding to UTF-8. UTF-16 is represented by 16-bit word arrays, and converting to UTF-16 while maintaining compatibility with existing ASCII-based programs (such as was done with Windows) requires every API and data structure that takes a string to be duplicated, one version accepting byte strings and another version accepting UTF-16. If backward compatibility is not needed, all string handling still must be modified.
• Text encoded in UTF-8 will be smaller than the same text encoded in UTF-16 if there are more code points below U+0080 than in the range U+0800..U+FFFF. This is true for all modern European languages. It is often true even for languages like Chinese, due to the large number of spaces, newlines, digits, and HTML markup in typical files.
• Most communication (e.g. HTML and IP) and storage (e.g. for Unix) was designed for a stream of bytes. A UTF-16 string must use a pair of bytes for each code unit:
  • The order of those two bytes becomes an issue and must be specified in the UTF-16 protocol, such as with a byte order mark.
  • If an odd number of bytes is missing from UTF-16, the whole rest of the string will be meaningless text. Any bytes missing from UTF-8 will still allow the text to be recovered accurately starting with the next character after the missing bytes.

Derivatives[edit]

The following implementations show slight differences from the UTF-8 specification. They are incompatible with the UTF-8 specification and may be rejected by conforming UTF-8 applications.

CESU-8[edit]

Unicode Technical Report #26^[79] assigns the name CESU-8 to a nonstandard variant of UTF-8, in which Unicode characters in supplementary planes are encoded using six bytes, rather than the four bytes required by UTF-8. CESU-8 encoding treats each half of a four-byte UTF-16 surrogate pair as a two-byte UCS-2 character, yielding two three-byte UTF-8 characters, which together represent the original supplementary character. Unicode characters within the Basic Multilingual Plane appear as they would normally in UTF-8. The Report was written to acknowledge and formalize the existence of data encoded as CESU-8, despite the Unicode Consortium discouraging its use, and notes that a possible intentional reason for CESU-8 encoding is preservation of UTF-16 binary collation.

CESU-8 encoding can result from converting UTF-16 data with supplementary characters to UTF-8, using conversion methods that assume UCS-2 data, meaning they are unaware of four-byte UTF-16 supplementary characters. It is primarily an issue on operating systems which extensively use UTF-16 internally, such as Microsoft Windows.^{[citation needed]}

In Oracle Database, the UTF8 character set uses CESU-8 encoding, and is deprecated. The AL32UTF8 character set uses standards-compliant UTF-8 encoding, and is preferred.^[80][81]

CESU-8 is prohibited for use in HTML5 documents.^[82][83][84]

MySQL utf8mb3[edit]

In MySQL, the utf8mb3 character set is defined to be UTF-8 encoded data with a maximum of three bytes per character, meaning only Unicode characters in the Basic Multilingual Plane (i.e. from UCS-2) are supported. Unicode characters in supplementary planes are explicitly not supported. utf8mb3 is deprecated in favor of the utf8mb4 character set, which uses standards-compliant UTF-8 encoding. utf8 is an alias for utf8mb3, but is intended to become an alias to utf8mb4 in a future release of MySQL.^[85] It is possible, though unsupported, to store CESU-8 encoded data in utf8mb3, by handling UTF-16 data with supplementary characters as though it is UCS-2.

Modified UTF-8[edit]

Modified UTF-8 (MUTF-8) originated in the Java programming language. In Modified UTF-8, the null character (U+0000) uses the two-byte overlong encoding 11000000 10000000 (hexadecimal C0 80), instead of 00000000 (hexadecimal 00).^[86] Modified UTF-8 strings never contain any actual null bytes but can contain all Unicode code points including U+0000,^[87] which allows such strings (with a null byte appended) to be processed by traditional null-terminated string functions. All known Modified UTF-8 implementations also treat the surrogate pairs as in CESU-8.

In normal usage, the language supports standard UTF-8 when reading and writing strings through InputStreamReader and OutputStreamWriter (if it is the platform’s default character set or as requested by the program). However it uses Modified UTF-8 for object serialization^[88] among other applications of DataInput and DataOutput, for the Java Native Interface,^[89] and for embedding constant strings in class files.^[90]

The dex format defined by Dalvik also uses the same modified UTF-8 to represent string values.^[91] Tcl also uses the same modified UTF-8^[92] as Java for internal representation of Unicode data, but uses strict CESU-8 for external data.

WTF-8[edit]

In WTF-8 (Wobbly Transformation Format, 8-bit) unpaired surrogate halves (U+D800 through U+DFFF) are allowed.^[93] This is necessary to store possibly-invalid UTF-16, such as Windows filenames. Many systems that deal with UTF-8 work this way without considering it a different encoding, as it is simpler.^[94]

The term «WTF-8» has also been used humorously to refer to erroneously doubly-encoded UTF-8^[95][96] sometimes with the implication that CP1252 bytes are the only ones encoded.^[97]

PEP 383[edit]

Version 3 of the Python programming language treats each byte of an invalid UTF-8 bytestream as an error (see also changes with new UTF-8 mode in Python 3.7^[98]); this gives 128 different possible errors. Extensions have been created to allow any byte sequence that is assumed to be UTF-8 to be losslessly transformed to UTF-16 or UTF-32, by translating the 128 possible error bytes to reserved code points, and transforming those code points back to error bytes to output UTF-8. The most common approach is to translate the codes to U+DC80…U+DCFF which are low (trailing) surrogate values and thus «invalid» UTF-16, as used by Python’s PEP 383 (or «surrogateescape») approach.^[99] Another encoding called MirBSD OPTU-8/16 converts them to U+EF80…U+EFFF in a Private Use Area.^[100] In either approach, the byte value is encoded in the low eight bits of the output code point.

These encodings are very useful because they avoid the need to deal with «invalid» byte strings until much later, if at all, and allow «text» and «data» byte arrays to be the same object. If a program wants to use UTF-16 internally these are required to preserve and use filenames that can use invalid UTF-8;^[101] as the Windows filesystem API uses UTF-16, the need to support invalid UTF-8 is less there.^[99]

For the encoding to be reversible, the standard UTF-8 encodings of the code points used for erroneous bytes must be considered invalid. This makes the encoding incompatible with WTF-8 or CESU-8 (though only for 128 code points). When re-encoding it is necessary to be careful of sequences of error code points which convert back to valid UTF-8, which may be used by malicious software to get unexpected characters in the output, though this cannot produce ASCII characters so it is considered comparatively safe, since malicious sequences (such as cross-site scripting) usually rely on ASCII characters.^[101]

See also[edit]

• Alt code
• Comparison of email clients § Features
• Comparison of Unicode encodings
  • GB 18030
  • UTF-EBCDIC
• Iconv
• Percent-encoding § Current standard
• Specials (Unicode block)
• Unicode and email
• Unicode and HTML
  • Character encodings in HTML

Notes[edit]

References[edit]

External links[edit]

• Original UTF-8 paper (or pdf) for Plan 9 from Bell Labs
• History of UTF-8 by Rob Pike
• UTF-8 test pages:
  • Andreas Prilop Archived 2017-11-30 at the Wayback Machine
  • Jost Gippert
  • World Wide Web Consortium
• Unix/Linux: UTF-8/Unicode FAQ, Linux Unicode HOWTO, UTF-8 and Gentoo
• Characters, Symbols and the Unicode Miracle on YouTube

UTF-8 is a variable-length character encoding standard used for electronic communication. Defined by the Unicode Standard, the name is derived from Unicode (or Universal Coded Character Set) Transformation Format – 8-bit.^[1]

UTF-8 is capable of encoding all 1,112,064^[a] valid character code points in Unicode using one to four one-byte (8-bit) code units. Code points with lower numerical values, which tend to occur more frequently, are encoded using fewer bytes. It was designed for backward compatibility with ASCII: the first 128 characters of Unicode, which correspond one-to-one with ASCII, are encoded using a single byte with the same binary value as ASCII, so that valid ASCII text is valid UTF-8-encoded Unicode as well.

UTF-8 was designed as a superior alternative to UTF-1, a proposed variable-length encoding with partial ASCII compatibility which lacked some features including self-synchronization and fully ASCII-compatible handling of characters such as slashes. Ken Thompson and Rob Pike produced the first implementation for the Plan 9 operating system in September 1992.^[2][3] This led to its adoption by X/Open as its specification for FSS-UTF,^[4] which would first be officially presented at USENIX in January 1993^[5] and subsequently adopted by the Internet Engineering Task Force (IETF) in RFC 2277 (BCP 18)^[6] for future internet standards work, replacing Single Byte Character Sets such as Latin-1 in older RFCs.

UTF-8 is the dominant encoding for the World Wide Web (and internet technologies), accounting for 97.8% of all web pages, and up to 100.0% for many languages, as of 2023.^[7] Virtually all countries and languages have 95.0% or more use of UTF-8 encodings on the web.

Naming[edit]

The official Internet Assigned Numbers Authority (IANA) code for the encoding is «UTF-8«.^[8] All letters are upper-case, and the name is hyphenated. This spelling is used in all the Unicode Consortium documents relating to the encoding. However, the name «utf-8» may be used by all standards conforming to the IANA list (which include CSS, HTML, XML, and HTTP headers),^[9] as the declaration is case-insensitive.^[8]

Other variants, such as those that omit the hyphen or replace it with a space, i.e. «utf8» or «UTF 8«, are not accepted as correct by the governing standards.^[10] Despite this, most web browsers can understand them, and so standards intended to describe existing practice (such as HTML5) may effectively require their recognition.^[11]

«UTF-8-BOM» and «UTF-8-NOBOM» are sometimes used for text files which contain or don’t contain a byte order mark (BOM), respectively.^{[citation needed]} In Japan especially, UTF-8 encoding without a BOM is sometimes called «UTF-8N«.^[12][13]

In Windows UTF-8 is codepage 65001^[14] (i.e. CP_UTF8 in source code).

In HP PCL, UTF-8 is called Symbol-ID «18N».^[15]

Encoding[edit]

UTF-8 encodes code points in one to four bytes, depending on the value of the code point. In the following table, the x characters are replaced by the bits of the code point:

The first 128 code points (ASCII) need one byte. The next 1,920 code points need two bytes to encode, which covers the remainder of almost all Latin-script alphabets, and also IPA extensions, Greek, Cyrillic, Coptic, Armenian, Hebrew, Arabic, Syriac, Thaana and N’Ko alphabets, as well as Combining Diacritical Marks. Three bytes are needed for the rest of the Basic Multilingual Plane (BMP), which contains virtually all code points in common use,^[16] including most Chinese, Japanese and Korean characters. Four bytes are needed for code points in the other planes of Unicode, which include less common CJK characters, various historic scripts, mathematical symbols, and emoji (pictographic symbols).

A «character» can take more than 4 bytes because it is made of more than one code point. For instance a national flag character takes 8 bytes since it’s «constructed from a pair of Unicode scalar values» both from outside the BMP.^[17][c]

Examples[edit]

Consider the encoding of the euro sign, €:

1. The Unicode code point for € is U+20AC.
2. As this code point lies between U+0800 and U+FFFF, this will take three bytes to encode.
3. Hexadecimal 20AC is binary 0010 0000 1010 1100. The two leading zeros are added because a three-byte encoding needs exactly sixteen bits from the code point.
4. Because the encoding will be three bytes long, its leading byte starts with three 1s, then a 0 (1110…)
5. The four most significant bits of the code point are stored in the remaining low order four bits of this byte (11100010), leaving 12 bits of the code point yet to be encoded (…0000 1010 1100).
6. All continuation bytes contain exactly six bits from the code point. So the next six bits of the code point are stored in the low order six bits of the next byte, and 10 is stored in the high order two bits to mark it as a continuation byte (so 10000010).
7. Finally the last six bits of the code point are stored in the low order six bits of the final byte, and again 10 is stored in the high order two bits (10101100).

The three bytes 11100010 10000010 10101100 can be more concisely written in hexadecimal, as E2 82 AC.

The following table summarizes this conversion, as well as others with different lengths in UTF-8. The colors indicate how bits from the code point are distributed among the UTF-8 bytes. Additional bits added by the UTF-8 encoding process are shown in black.

Octal[edit]

UTF-8’s use of six bits per byte to represent the actual characters being encoded means that octal notation (which uses 3-bit groups) can aid in the comparison of UTF-8 sequences with one another and in manual conversion.^[18]

With octal notation, the arbitrary octal digits, marked with x, y, z or w in the table, will remain unchanged when converting to or from UTF-8.

Example: Á = U+00C1 = 0301 (in octal) is encoded as 303 201 in UTF-8 (C3 81 in hex).

Example: € = U+20AC = 020254 is encoded as 342 202 254 in UTF-8 (E2 82 AC in hex).

Codepage layout[edit]

The following table summarizes usage of UTF-8 code units (individual bytes or octets) in a code page format. The upper half is for bytes used only in single-byte codes, so it looks like a normal code page; the lower half is for continuation bytes and leading bytes and is explained further in the legend below.

  7-bit (single-byte) code points. They must not be followed by a continuation byte.^[19]

  Continuation bytes.^[20] The tooltip shows in hex the value of the 6 bits they add.^[d]

  Leading bytes for a sequence of multiple bytes, must be followed by exactly N−1 continuation bytes.^[21] The tooltip shows the code point range and the Unicode blocks encoded by sequences starting with this byte.

Overlong encodings[edit]

In principle, it would be possible to inflate the number of bytes in an encoding by padding the code point with leading 0s. To encode the euro sign € from the above example in four bytes instead of three, it could be padded with leading 0s until it was 21 bits long –
000 000010 000010 101100, and encoded as 11110000 10000010 10000010 10101100 (or F0 82 82 AC in hexadecimal). This is called an overlong encoding.

The standard specifies that the correct encoding of a code point uses only the minimum number of bytes required to hold the significant bits of the code point. Longer encodings are called overlong and are not valid UTF-8 representations of the code point. This rule maintains a one-to-one correspondence between code points and their valid encodings, so that there is a unique valid encoding for each code point. This ensures that string comparisons and searches are well-defined.

Invalid sequences and error handling[edit]

Not all sequences of bytes are valid UTF-8. A UTF-8 decoder should be prepared for:

• invalid bytes
• an unexpected continuation byte
• a non-continuation byte before the end of the character
• the string ending before the end of the character (which can happen in simple string truncation)
• an overlong encoding
• a sequence that decodes to an invalid code point

Many of the first UTF-8 decoders would decode these, ignoring incorrect bits and accepting overlong results. Carefully crafted invalid UTF-8 could make them either skip or create ASCII characters such as NUL, slash, or quotes. Invalid UTF-8 has been used to bypass security validations in high-profile products including Microsoft’s IIS web server^[26] and Apache’s Tomcat servlet container.^[27] RFC 3629 states «Implementations of the decoding algorithm MUST protect against decoding invalid sequences.»^[10] The Unicode Standard requires decoders to «…treat any ill-formed code unit sequence as an error condition. This guarantees that it will neither interpret nor emit an ill-formed code unit sequence.»

Since RFC 3629 (November 2003), the high and low surrogate halves used by UTF-16 (U+D800 through U+DFFF) and code points not encodable by UTF-16 (those after U+10FFFF) are not legal Unicode values, and their UTF-8 encoding must be treated as an invalid byte sequence. Not decoding unpaired surrogate halves makes it impossible to store invalid UTF-16 (such as Windows filenames or UTF-16 that has been split between the surrogates) as UTF-8,^[28] while it is possible with WTF-8.

Some implementations of decoders throw exceptions on errors.^[29] This has the disadvantage that it can turn what would otherwise be harmless errors (such as a «no such file» error) into a denial of service. For instance early versions of Python 3.0 would exit immediately if the command line or environment variables contained invalid UTF-8.^[30] An alternative practice is to replace errors with a replacement character. Since Unicode 6^[31] (October 2010), the standard (chapter 3) has recommended a «best practice» where the error ends as soon as a disallowed byte is encountered. In these decoders E1,A0,C0 is two errors (2 bytes in the first one). This means an error is no more than three bytes long and never contains the start of a valid character, and there are 21,952 different possible errors.^[32] The standard also recommends replacing each error with the replacement character «�» (U+FFFD).

Byte order mark[edit]

If the Unicode byte order mark (BOM, U+FEFF) character is at the start of a UTF-8 file, the first three bytes will be 0xEF, 0xBB, 0xBF.

The Unicode Standard neither requires nor recommends the use of the BOM for UTF-8, but warns that it may be encountered at the start of a file trans-coded from another encoding.^[33] While ASCII text encoded using UTF-8 is backward compatible with ASCII, this is not true when Unicode Standard recommendations are ignored and a BOM is added. A BOM can confuse software that isn’t prepared for it but can otherwise accept UTF-8, e.g. programming languages that permit non-ASCII bytes in string literals but not at the start of the file. Nevertheless, there was and still is software that always inserts a BOM when writing UTF-8, and refuses to correctly interpret UTF-8 unless the first character is a BOM (or the file only contains ASCII).^[34]

Adoption[edit]

Many standards only support UTF-8, e.g. open JSON exchange requires it (without a byte order mark (BOM)).^[36] UTF-8 is also the recommendation from the WHATWG for HTML and DOM specifications,^[37] and the Internet Mail Consortium recommends that all e‑mail programs be able to display and create mail using UTF-8.^[38][39] The World Wide Web Consortium recommends UTF-8 as the default encoding in XML and HTML (and not just using UTF-8, also declaring it in metadata), «even when all characters are in the ASCII range … Using non-UTF-8 encodings can have unexpected results».^[40]

Lots of software has the ability to read/write UTF-8, and for some functions (even in some Microsoft products) UTF-8 is the only option. In some cases (e.g. on Windows) it may though require the user to change options from the normal settings, or may require a BOM (byte order mark) as the first character to read the file. Examples of software supporting UTF-8 include Microsoft Word^[41][42][43] and Microsoft Excel (2016 and later).^[44][45] Examples of software supporting UTF-8 include Google Drive and LibreOffice. Most databases support UTF-8 (sometimes the only option as with some file formats), including Microsoft’s since SQL Server 2019, resulting in 35% speed increase, and «nearly 50% reduction in storage requirements.»^[46] Microsoft fully supports and recommends UTF-8 for its products such as Windows and Xbox.

UTF-8 has been the most common encoding for the World Wide Web since 2008.^[47] As of February 2023, UTF-8 accounts for on average 97.8% (previously up to 98.0%) of all web pages (and 985 of the top 1,000 highest ranked web pages).^[7] Although many pages only use ASCII characters to display content, few websites now declare their encoding to only be ASCII instead of UTF-8.^[48] Over a third of the languages tracked have 100% UTF-8 use.

For local text files UTF-8 usage is less prevalent, where a few legacy single-byte (and a few CJK multi-byte) encodings remain in use to some degree. The primary cause for this is a few text editors that refuse to use UTF-8 when processing files, unless the first bytes of the file encode a byte order mark character (BOM). However, as most text editors correctly do not require a BOM, they often do not insert a BOM at the start of files they save, causing compatibility issues with such editors. To support editors that expect a BOM, a BOM must be added manually to the start of the file.^[49] Many other text editors simply assume a UTF-8 encoding for all files due to its nigh-ubiquity.^[50] As of current Windows versions (since Windows 10), Windows Notepad defaults to writing UTF-8 without a BOM (a change since Windows 7), bringing it into line with most other text editors.^[51] With regard to system files, some system files on Windows 11 require UTF-8^[52] with no requirement for a BOM, and almost all files on macOS and Linux are required to be UTF-8 without a BOM.^{[citation needed]} Java 18 defaults to reading and writing files as UTF-8,^[53] and in older versions (e.g. LTS versions) only the NIO API was changed to do so. Many other programming languages default to UTF-8 for I/O, including Ruby 3.0^[54][55] and R 4.2.2.^[56] All currently supported versions of Python support UTF-8 for I/O, even on Windows (where it is opt-in for the open() function^[57]), and plans exist to make UTF-8 I/O the default in Python 3.15 on all platforms.^[58]

Usage of UTF-8 within software is also lower than in other areas as UTF-16 is often used instead. This occurs particularly in Windows, but also in JavaScript, Python^[e], Qt, and many other cross-platform software libraries. Compatibility with the Windows API is the primary reason for this, though the belief that direct indexing of the BMP improves speed was also a factor. More recent software has started to use UTF-8 almost exclusively: The default string primitive in Go,^[60] Julia, Rust, Swift 5,^[61] and PyPy^[62] uses UTF-8; a future version of Python is planned to store strings as UTF-8;^[63] and modern versions of Microsoft Visual Studio use UTF-8 internally^[64] (though still requiring a command-line switch to read or write UTF-8^[65]). UTF-8 is the «only text encoding mandated to be supported by the C++ standard» in C++20.^[66] All currently supported Windows versions support UTF-8 in some way (including Xbox^[67]); partial support has existed since at least Windows XP. As of May 2019, Microsoft has reversed its previous position of only recommending UTF-16; the capability to set UTF-8 as the encoding^[f] for the Windows API was introduced. As of 2020, Microsoft recommends programmers use UTF-8.^[68]

History[edit]

The International Organization for Standardization (ISO) set out to compose a universal multi-byte character set in 1989. The draft ISO 10646 standard contained a non-required annex called UTF-1 that provided a byte stream encoding of its 32-bit code points. This encoding was not satisfactory on performance grounds, among other problems, and the biggest problem was probably that it did not have a clear separation between ASCII and non-ASCII: new UTF-1 tools would be backward compatible with ASCII-encoded text, but UTF-1-encoded text could confuse existing code expecting ASCII (or extended ASCII), because it could contain continuation bytes in the range 0x21–0x7E that meant something else in ASCII, e.g., 0x2F for ‘/’, the Unix path directory separator, and this example is reflected in the name and introductory text of its replacement. The table below was derived from a textual description in the annex.

In July 1992, the X/Open committee XoJIG was looking for a better encoding. Dave Prosser of Unix System Laboratories submitted a proposal for one that had faster implementation characteristics and introduced the improvement that 7-bit ASCII characters would only represent themselves; all multi-byte sequences would include only bytes where the high bit was set. The name File System Safe UCS Transformation Format (FSS-UTF) and most of the text of this proposal were later preserved in the final specification.^{[69][70][71][72]}

FSS-UTF[edit]

In August 1992, this proposal was circulated by an IBM X/Open representative to interested parties. A modification by Ken Thompson of the Plan 9 operating system group at Bell Labs made it self-synchronizing, letting a reader start anywhere and immediately detect character boundaries, at the cost of being somewhat less bit-efficient than the previous proposal. It also abandoned the use of biases and instead added the rule that only the shortest possible encoding is allowed; the additional loss in compactness is relatively insignificant, but readers now have to look out for invalid encodings to avoid reliability and especially security issues. Thompson’s design was outlined on September 2, 1992, on a placemat in a New Jersey diner with Rob Pike. In the following days, Pike and Thompson implemented it and updated Plan 9 to use it throughout, and then communicated their success back to X/Open, which accepted it as the specification for FSS-UTF.^[71]

UTF-8 was first officially presented at the USENIX conference in San Diego, from January 25 to 29, 1993. The Internet Engineering Task Force adopted UTF-8 in its Policy on Character Sets and Languages in RFC 2277 (BCP 18) for future internet standards work, replacing Single Byte Character Sets such as Latin-1 in older RFCs.^[73]

In November 2003, UTF-8 was restricted by RFC 3629 to match the constraints of the UTF-16 character encoding: explicitly prohibiting code points corresponding to the high and low surrogate characters removed more than 3% of the three-byte sequences, and ending at U+10FFFF removed more than 48% of the four-byte sequences and all five- and six-byte sequences.

Standards[edit]

There are several current definitions of UTF-8 in various standards documents:

• RFC 3629 / STD 63 (2003), which establishes UTF-8 as a standard internet protocol element
• RFC 5198 defines UTF-8 NFC for Network Interchange (2008)
• ISO/IEC 10646:2014 §9.1 (2014)^[74]
• The Unicode Standard, Version 14.0.0 (2021)^[75]

They supersede the definitions given in the following obsolete works:

• The Unicode Standard, Version 2.0, Appendix A (1996)
• ISO/IEC 10646-1:1993 Amendment 2 / Annex R (1996)
• RFC 2044 (1996)
• RFC 2279 (1998)
• The Unicode Standard, Version 3.0, §2.3 (2000) plus Corrigendum #1 : UTF-8 Shortest Form (2000)
• Unicode Standard Annex #27: Unicode 3.1 (2001)^[76]
• The Unicode Standard, Version 5.0 (2006)^[77]
• The Unicode Standard, Version 6.0 (2010)^[78]

They are all the same in their general mechanics, with the main differences being on issues such as allowed range of code point values and safe handling of invalid input.

Comparison with other encodings[edit]

Some of the important features of this encoding are as follows:

• Backward compatibility: Backward compatibility with ASCII and the enormous amount of software designed to process ASCII-encoded text was the main driving force behind the design of UTF-8. In UTF-8, single bytes with values in the range of 0 to 127 map directly to Unicode code points in the ASCII range. Single bytes in this range represent characters, as they do in ASCII. Moreover, 7-bit bytes (bytes where the most significant bit is 0) never appear in a multi-byte sequence, and no valid multi-byte sequence decodes to an ASCII code-point. A sequence of 7-bit bytes is both valid ASCII and valid UTF-8, and under either interpretation represents the same sequence of characters. Therefore, the 7-bit bytes in a UTF-8 stream represent all and only the ASCII characters in the stream. Thus, many text processors, parsers, protocols, file formats, text display programs, etc., which use ASCII characters for formatting and control purposes, will continue to work as intended by treating the UTF-8 byte stream as a sequence of single-byte characters, without decoding the multi-byte sequences. ASCII characters on which the processing turns, such as punctuation, whitespace, and control characters will never be encoded as multi-byte sequences. It is therefore safe for such processors to simply ignore or pass-through the multi-byte sequences, without decoding them. For example, ASCII whitespace may be used to tokenize a UTF-8 stream into words; ASCII line-feeds may be used to split a UTF-8 stream into lines; and ASCII NUL characters can be used to split UTF-8-encoded data into null-terminated strings. Similarly, many format strings used by library functions like «printf» will correctly handle UTF-8-encoded input arguments.
• Fallback and auto-detection: Only a small subset of possible byte strings are a valid UTF-8 string: several bytes cannot appear; a byte with the high bit set cannot be alone; and further requirements mean that it is extremely unlikely that a readable text in any extended ASCII is valid UTF-8. Part of the popularity of UTF-8 is due to it providing a form of backward compatibility for these as well. A UTF-8 processor which erroneously receives extended ASCII as input can thus «auto-detect» this with very high reliability. A UTF-8 stream may simply contain errors, resulting in the auto-detection scheme producing false positives; but auto-detection is successful in the vast majority of cases, especially with longer texts, and is widely used. It also works to «fall back» or replace 8-bit bytes using the appropriate code-point for a legacy encoding when errors in the UTF-8 are detected, allowing recovery even if UTF-8 and legacy encoding is concatenated in the same file.
• Prefix code: The first byte indicates the number of bytes in the sequence. Reading from a stream can instantaneously decode each individual fully received sequence, without first having to wait for either the first byte of a next sequence or an end-of-stream indication. The length of multi-byte sequences is easily determined by humans as it is simply the number of high-order 1s in the leading byte. An incorrect character will not be decoded if a stream ends mid-sequence.
• Self-synchronization: The leading bytes and the continuation bytes do not share values (continuation bytes start with the bits 10 while single bytes start with 0 and longer lead bytes start with 11). This means a search will not accidentally find the sequence for one character starting in the middle of another character. It also means the start of a character can be found from a random position by backing up at most 3 bytes to find the leading byte. An incorrect character will not be decoded if a stream starts mid-sequence, and a shorter sequence will never appear inside a longer one.
• Sorting order: The chosen values of the leading bytes means that a list of UTF-8 strings can be sorted in code point order by sorting the corresponding byte sequences.

Single-byte[edit]

• UTF-8 can encode any Unicode character, avoiding the need to figure out and set a «code page» or otherwise indicate what character set is in use, and allowing output in multiple scripts at the same time. For many scripts there have been more than one single-byte encoding in usage, so even knowing the script was insufficient information to display it correctly.
• The bytes 0xFE and 0xFF do not appear, so a valid UTF-8 stream never matches the UTF-16 byte order mark and thus cannot be confused with it. The absence of 0xFF (0377) also eliminates the need to escape this byte in Telnet (and FTP control connection).
• UTF-8 encoded text is larger than specialized single-byte encodings except for plain ASCII characters. In the case of scripts which used 8-bit character sets with non-Latin characters encoded in the upper half (such as most Cyrillic and Greek alphabet code pages), characters in UTF-8 will be double the size. For some scripts, such as Thai and Devanagari (which is used by various South Asian languages), characters will triple in size. There are even examples where a single byte turns into a composite character in Unicode and is thus six times larger in UTF-8. This has caused objections in India and other countries.
• It is possible in UTF-8 (or any other multi-byte encoding) to split or truncate a string in the middle of a character. If the two pieces are not re-appended later before interpretation as characters, this can introduce an invalid sequence at both the end of the previous section and the start of the next, and some decoders will not preserve these bytes and result in data loss. Because UTF-8 is self-synchronizing this will however never introduce a different valid character, and it is also fairly easy to move the truncation point backward to the start of a character.
• If the code points are all the same size, measurements of a fixed number of them is easy. Due to ASCII-era documentation where «character» is used as a synonym for «byte» this is often considered important. However, by measuring string positions using bytes instead of «characters» most algorithms can be easily and efficiently adapted for UTF-8. Searching for a string within a long string can for example be done byte by byte; the self-synchronization property prevents false positives.

Other multi-byte[edit]

• UTF-8 can encode any Unicode character. Files in different scripts can be displayed correctly without having to choose the correct code page or font. For instance, Chinese and Arabic can be written in the same file without specialized markup or manual settings that specify an encoding.
• UTF-8 is self-synchronizing: character boundaries are easily identified by scanning for well-defined bit patterns in either direction. If bytes are lost due to error or corruption, one can always locate the next valid character and resume processing. If there is a need to shorten a string to fit a specified field, the previous valid character can easily be found. Many multi-byte encodings such as Shift JIS are much harder to resynchronize. This also means that byte-oriented string-searching algorithms can be used with UTF-8 (as a character is the same as a «word» made up of that many bytes), optimized versions of byte searches can be much faster due to hardware support and lookup tables that have only 256 entries. Self-synchronization does however require that bits be reserved for these markers in every byte, increasing the size.
• Efficient to encode using simple bitwise operations. UTF-8 does not require slower mathematical operations such as multiplication or division (unlike Shift JIS, GB 2312 and other encodings).
• UTF-8 will take more space than a multi-byte encoding designed for a specific script. East Asian legacy encodings generally used two bytes per character yet take three bytes per character in UTF-8.

UTF-16[edit]

• Byte encodings and UTF-8 are represented by byte arrays in programs, and often nothing needs to be done to a function when converting source code from a byte encoding to UTF-8. UTF-16 is represented by 16-bit word arrays, and converting to UTF-16 while maintaining compatibility with existing ASCII-based programs (such as was done with Windows) requires every API and data structure that takes a string to be duplicated, one version accepting byte strings and another version accepting UTF-16. If backward compatibility is not needed, all string handling still must be modified.
• Text encoded in UTF-8 will be smaller than the same text encoded in UTF-16 if there are more code points below U+0080 than in the range U+0800..U+FFFF. This is true for all modern European languages. It is often true even for languages like Chinese, due to the large number of spaces, newlines, digits, and HTML markup in typical files.
• Most communication (e.g. HTML and IP) and storage (e.g. for Unix) was designed for a stream of bytes. A UTF-16 string must use a pair of bytes for each code unit:
  • The order of those two bytes becomes an issue and must be specified in the UTF-16 protocol, such as with a byte order mark.
  • If an odd number of bytes is missing from UTF-16, the whole rest of the string will be meaningless text. Any bytes missing from UTF-8 will still allow the text to be recovered accurately starting with the next character after the missing bytes.

Derivatives[edit]

The following implementations show slight differences from the UTF-8 specification. They are incompatible with the UTF-8 specification and may be rejected by conforming UTF-8 applications.

CESU-8[edit]

Unicode Technical Report #26^[79] assigns the name CESU-8 to a nonstandard variant of UTF-8, in which Unicode characters in supplementary planes are encoded using six bytes, rather than the four bytes required by UTF-8. CESU-8 encoding treats each half of a four-byte UTF-16 surrogate pair as a two-byte UCS-2 character, yielding two three-byte UTF-8 characters, which together represent the original supplementary character. Unicode characters within the Basic Multilingual Plane appear as they would normally in UTF-8. The Report was written to acknowledge and formalize the existence of data encoded as CESU-8, despite the Unicode Consortium discouraging its use, and notes that a possible intentional reason for CESU-8 encoding is preservation of UTF-16 binary collation.

CESU-8 encoding can result from converting UTF-16 data with supplementary characters to UTF-8, using conversion methods that assume UCS-2 data, meaning they are unaware of four-byte UTF-16 supplementary characters. It is primarily an issue on operating systems which extensively use UTF-16 internally, such as Microsoft Windows.^{[citation needed]}

In Oracle Database, the UTF8 character set uses CESU-8 encoding, and is deprecated. The AL32UTF8 character set uses standards-compliant UTF-8 encoding, and is preferred.^[80][81]

CESU-8 is prohibited for use in HTML5 documents.^[82][83][84]

MySQL utf8mb3[edit]

In MySQL, the utf8mb3 character set is defined to be UTF-8 encoded data with a maximum of three bytes per character, meaning only Unicode characters in the Basic Multilingual Plane (i.e. from UCS-2) are supported. Unicode characters in supplementary planes are explicitly not supported. utf8mb3 is deprecated in favor of the utf8mb4 character set, which uses standards-compliant UTF-8 encoding. utf8 is an alias for utf8mb3, but is intended to become an alias to utf8mb4 in a future release of MySQL.^[85] It is possible, though unsupported, to store CESU-8 encoded data in utf8mb3, by handling UTF-16 data with supplementary characters as though it is UCS-2.

Modified UTF-8[edit]

Modified UTF-8 (MUTF-8) originated in the Java programming language. In Modified UTF-8, the null character (U+0000) uses the two-byte overlong encoding 11000000 10000000 (hexadecimal C0 80), instead of 00000000 (hexadecimal 00).^[86] Modified UTF-8 strings never contain any actual null bytes but can contain all Unicode code points including U+0000,^[87] which allows such strings (with a null byte appended) to be processed by traditional null-terminated string functions. All known Modified UTF-8 implementations also treat the surrogate pairs as in CESU-8.

In normal usage, the language supports standard UTF-8 when reading and writing strings through InputStreamReader and OutputStreamWriter (if it is the platform’s default character set or as requested by the program). However it uses Modified UTF-8 for object serialization^[88] among other applications of DataInput and DataOutput, for the Java Native Interface,^[89] and for embedding constant strings in class files.^[90]

The dex format defined by Dalvik also uses the same modified UTF-8 to represent string values.^[91] Tcl also uses the same modified UTF-8^[92] as Java for internal representation of Unicode data, but uses strict CESU-8 for external data.

WTF-8[edit]

In WTF-8 (Wobbly Transformation Format, 8-bit) unpaired surrogate halves (U+D800 through U+DFFF) are allowed.^[93] This is necessary to store possibly-invalid UTF-16, such as Windows filenames. Many systems that deal with UTF-8 work this way without considering it a different encoding, as it is simpler.^[94]

The term «WTF-8» has also been used humorously to refer to erroneously doubly-encoded UTF-8^[95][96] sometimes with the implication that CP1252 bytes are the only ones encoded.^[97]

PEP 383[edit]

Version 3 of the Python programming language treats each byte of an invalid UTF-8 bytestream as an error (see also changes with new UTF-8 mode in Python 3.7^[98]); this gives 128 different possible errors. Extensions have been created to allow any byte sequence that is assumed to be UTF-8 to be losslessly transformed to UTF-16 or UTF-32, by translating the 128 possible error bytes to reserved code points, and transforming those code points back to error bytes to output UTF-8. The most common approach is to translate the codes to U+DC80…U+DCFF which are low (trailing) surrogate values and thus «invalid» UTF-16, as used by Python’s PEP 383 (or «surrogateescape») approach.^[99] Another encoding called MirBSD OPTU-8/16 converts them to U+EF80…U+EFFF in a Private Use Area.^[100] In either approach, the byte value is encoded in the low eight bits of the output code point.

These encodings are very useful because they avoid the need to deal with «invalid» byte strings until much later, if at all, and allow «text» and «data» byte arrays to be the same object. If a program wants to use UTF-16 internally these are required to preserve and use filenames that can use invalid UTF-8;^[101] as the Windows filesystem API uses UTF-16, the need to support invalid UTF-8 is less there.^[99]

For the encoding to be reversible, the standard UTF-8 encodings of the code points used for erroneous bytes must be considered invalid. This makes the encoding incompatible with WTF-8 or CESU-8 (though only for 128 code points). When re-encoding it is necessary to be careful of sequences of error code points which convert back to valid UTF-8, which may be used by malicious software to get unexpected characters in the output, though this cannot produce ASCII characters so it is considered comparatively safe, since malicious sequences (such as cross-site scripting) usually rely on ASCII characters.^[101]

See also[edit]

• Alt code
• Comparison of email clients § Features
• Comparison of Unicode encodings
  • GB 18030
  • UTF-EBCDIC
• Iconv
• Percent-encoding § Current standard
• Specials (Unicode block)
• Unicode and email
• Unicode and HTML
  • Character encodings in HTML

Notes[edit]

References[edit]

External links[edit]

• Original UTF-8 paper (or pdf) for Plan 9 from Bell Labs
• History of UTF-8 by Rob Pike
• UTF-8 test pages:
  • Andreas Prilop Archived 2017-11-30 at the Wayback Machine
  • Jost Gippert
  • World Wide Web Consortium
• Unix/Linux: UTF-8/Unicode FAQ, Linux Unicode HOWTO, UTF-8 and Gentoo
• Characters, Symbols and the Unicode Miracle on YouTube

Главная →
Статьи →
Юникод →
Что такое Юникод?

Что такое Юникод?

Юникод (Unicode), это многоязычный, основанный на ASCII стандарт кодирования символов, а также, связанное с ним, семейство многобайтных кодировок. Если некоторые слова из предыдущего предложения вам не понятны, давайте рассмотрим их подробнее.

Что такое кодировка

Современные компьютеры всё ещё достаточно глупые и, в большинстве своём, не умеют работать ни с чем, кроме чисел.
Мы рассматриваем на своих мониторах фотографии, смотрим фильмы, играем в игры.
Но для компьютеров всё это лишь безликий поток нулей и единичек.
Так же и текст — для компьютера это просто набор байтов.
Буквы и любые другие символы представляются в машинной памяти, как числа.

Поэтому программистам при работе с текстом приходится делать подобные соглашения:
«А давайте каждому символу будет соответствовать один байт.
Причём, если в байте будет число 43, то будем считать, что это цифра ноль.
А если число 66, то пусть это будет заглавная латинская буква B».

Подобный список всех используемых символов и соответствующих им чисел и называется кодировкой.
Вы, скорее всего, уже слышали названия многих кодировок: Windows-1251, KOI-8, ну и, конечно, Unicode.

Крякозябры

Наверное, часто бывала ситуация, когда вы открываете страницу в браузере, а там вместо текста какая-то мешанина из чудных символов.
Или просто сплошные вопросительные знаки.
Или вы пишете любовное письмо своей девушке, а она звонит вам и говорит «что за нечитаемый бред ты мне прислал? Я обиделась».

Это всё из-за того, что в мире наплодилось слишком много разных кодировок.
И текст в одной из них выглядит совершенно не так, как в другой.
Дело в том, что компьютер не знает какую кодировку вы используете для текста.
Для него это просто последовательность каких-то чисел.

Например, ваш текстовый редактор настроен на кодировку Windows-1251.
И вы пишете «Здравствуйте, дорогая Маша!».
Вы нажимаете первую букву и программа думает: «ага, русская заглавная буква Зэ — код 199».
И записывает число 199 в файл.
Маша получает ваше письмо, но в её почтовом клиенте стоит кодировка KOI8-R (потому что Маша любит старый Unix).
А в этой кодировке числу 199 соответствует строчная буква «г».
И Маша читает: «гДПЮБЯРБСИРЕ, ДНПНЦЮЪ лЮЬЮ!».
Маша обиделась!

Чтобы подобного не происходило, нужно каким-то образом указывать кодировку в которой набран текст.
Например, в HTML это делается с помощью тега:

<meta http-equiv="content-type" content="text/html; charset=windows-1251" />

ASCII

В определённый момент времени распространение получила кодировка ASCII (American Standard Code for Information Interchange).
В ней определены 128 символов с кодами от 0 до 127.
Сюда включён латинский алфавит, цифры и основные знаки препинания (

  Основная латиница 0000–007F

), а также .

Практически все современные кодировки, использующиеся на персональных компьютерах являются ASCII-совместимыми.
То есть первые 128 символов у них кодируются одинаково, а различия начинаются с кода 128 и выше.
Вышеупомянутые Windows-1251 и KOI8-r также основаны на ASCII и если бы письмо начиналось бы с «Hello, my dear Maria!», то недопонимания не возникло бы.

Основан на ASCII и Юникод.

Однобайтные кодировки

Одна из причин, по которой появилось такое большое количество кодировок, это то, что вначале каждая компания придумывала свои стандарты, не обращая внимания на другие.
Вторая причина заключается в том, что старые кодировки были однобайтными.
То есть каждому символу в тексте соответствует один байт в памяти компьютера.

Однобайтные кодировки всем хороши: они компактны, с ними легко работать (нужно достать пятый символ — просто берём пятый байт от начала).
Единственная проблема: в них помещается мало символов.
Ровно столько, сколько значений может принимать один байт, то есть обычно, это 256.
Например, в Windows-1251 мы отдали 128 символов под ASCII, добавили 66 букв русского алфавита (строчные и заглавные), несколько знаков препинания и вот у нас уже остаётся не так много свободных позиций.
Даже на псевдографику не хватает.

То есть свести в одну кодировку все возможные символы даже европейских алфавитов достаточно сложно.
А уж для китайцев с их тысячами иероглифов вообще всё тоскливо.
А о всяких смайликах, эмоджи и иконках самолётиков и думать нечего.
Поэтому для кириллицы приходилось изобретать свою кодировку, а для греческого языка другую.

Впрочем, такая ситуация сохранялась достаточно долго.
Потому что проблемы англоязычных пользователей и программистов решила ASCII, а до китайских проблем им не было дела.
С ростом же глобального интернета вдруг оказалось, что в мире говорят не только на английском языке, поэтому с кодировками нужно что-то менять.

Многобайтные кодировки

Самым простым решением было взять два байта вместо одного.
Плюс такого решения: теперь можно в рамках одной кодировки использовать 65 тысяч символов.
Минусы тоже есть:

• Для всех возможных символов, иероглифов и смайликов даже 65 тысяч символов мало.
• Текстовые файлы стали занимать вдвое больше места, даже тексты на английском. Слишком расточительно.
• Кодировки перестали быть ASCII-совместимыми и многие программы не могли с ними работать.

Стандарт Unicode

В конечном итоге всё вылилось в стандарт Юникода, который худо-бедно, но решает практически все стоявшие перед кодировками проблемы.

С одной стороны, Юникод позволяет кодировать практически неограниченное количество символов.
В последнем стандарте определено более 100 000 различных символов всех современных и многих уже мёртвых языков, а также различные иконки и пиктограммы.
С другой стороны, некоторые способы кодирования позволяют Юникоду оставаться ASCII-совместимыми.
Что позволяет работать, как и раньше многим программам, а также американским и другим англоязычным пользователям, многие из которых появления Юникода даже не заметили.
В Юникоде также собраны все символы из всех популярных стандартов кодирования, что позволяет преобразовать в него любой текст из старой кодировки.

Практически все современные программы, работающие с текстом, понимают Юникод.
Более того, обычно они в нём и работают.
Например, даже когда вы открываете сайт в старой доброй Windows-1251, браузер сначала внутри у себя перекодирует все тексты в Юникод, а потом отображает их.
В общем, Юникод, это светлое будущее интернета и всей компьютерной индустрии.

Отличие набора символов от кодировки

Термины «кодировка», «стандарт кодирования», «набор символов» обычно используются, как синонимы, но между ними есть и тонкие различия.
Важно понимать разницу между «стандартом» и, собственно, «кодировкой».
Некий стандарт просто говорит, что буква «A», это число 65, а буква «B» — 66.
Кодировка же отвечает за то, как эти числа представить в памяти компьютера.

В эпоху однобайтных кодировок, это различие было практически неуловимо.
Число 65 — байт со значением 65 или последовательность битов 01000001.
Для многобайтных же уже возникают вопросы: сколько байтов использовать, в каком порядке, фиксированное число байтов или нет?

То есть в стандарте Юникода определено, что кириллической букве «А» соответствует абстрактное число 1040.
Как представить это число в виде последовательности байтов решает уже конкретная кодировка — UTF-8, UTF-16, UTF-32.

То есть текстовый файл не может быть в кодировке «Юникод», а только в конкретной кодировке «UTF-8» или «UTF-16».

Кодировки и шрифты

Юникод, как и любая другая кодировка не описывает того, как следует отрисовывать символы.
Для него число 1040, это «кириллическая заглавная буква А».
А какая она, печатная, прописная, наклонная, жирная или с завитушками, это не его дело.

За изображение символа отвечают шрифты.
Поэтому один и тот же символ в разных шрифтах может выглядеть по разному, а то и вообще отсутствовать.

Подробнее это описано в статье почему у меня не отображаются некоторые символы?

Стандарт кодировки символов

Логотип консорциума Unicode
Псевдоним (а)	Универсальный кодированный набор символов (UCS)
Язык (и)	Международный
Стандарт	Стандарт Unicode
Форматы кодирования	UTF-8, UTF-16, GB18030. Менее распространенный : UTF-32, BOCU, SCSU, UTF-7
Предыдущий	ISO / IEC 8859, другие
v t

Unicode — это стандарт информационных технологий (IT) для согласованного кодирования, представления и обработки текста, выраженного в большинстве мировых систем письма. Стандарт поддерживается Консорциумом Unicode, и по состоянию на март 2020 года существует набор из 143 859 символов с Unicode 13.0 (эти символы состоят из 143 696 графических символов и 163 символов формата), охватывающий 154 современных и исторических скрипта, а также несколько наборов символов и эмодзи. Репертуар символов стандарта Unicode синхронизирован с ISO / IEC 10646, и оба кода идентичны.

Стандарт Unicode состоит из набора кодовых диаграмм для визуальной справки, метода кодирования и набора стандартных кодировок символов , набора справочных файлов данных и ряд связанных элементов, таких как свойства символов, правила для нормализации, декомпозиции, сопоставления, рендеринга и двунаправленного текста порядок отображения (для правильного отображения текст, содержащий как письма с письмом справа налево, например арабский и иврит, так и скрипты с письмом слева направо).

Unicode Успех в унификации наборов символов привел к его широкому распространению и преимущественному использованию при интернационализации и локализации компьютерного программного обеспечения. Стандарт был реализован во многих последних технологиях, включая современные операционные системы, XML, Java (и другие языки программирования ) и .NET Framework.

Unicode может быть реализован с помощью различных кодировок символов. Стандарт Unicode определяет UTF-8, UTF-16 и UTF-32, а также используется несколько других кодировок. Чаще всего используются кодировки UTF-8, UTF-16 и UCS -2 (предшественник UTF-16 без полной поддержки Unicode); GB18030 стандартизирован в Китае и полностью реализует Unicode, но не является официальным стандартом Unicode.

UTF-8, преобладающая кодировка в World Wide Web (используется более чем на 95% веб-сайтов по состоянию на 2020 год и до 100% для некоторых языков), использует одну кодировку байт для первых 128 кодовых точек и до 4 байтов для других символов. Первые 128 кодовых точек Unicode представляют символы ASCII, что означает, что любой текст ASCII также является текстом UTF-8.

UCS-2 использует два байта (16 бит ) для каждого символа, но может кодировать только первые 65 536 кодовых точек, поэтому- называется Basic Multilingual Plane (BMP). С 1112 064 возможными кодовыми точками Unicode, соответствующими символам (см. ниже) на 17 плоскостях, и с более чем 143000 кодовых точек, определенных с версии 13.0, UCS-2 может представлять только менее половины всего закодированного Unicode символы. Таким образом, UCS-2 устарел, хотя все еще широко используется в программном обеспечении. UTF-16 расширяет UCS-2, используя ту же кодировку 16-бит, что и UCS-2 для базовой многоязычной плоскости, и 4-байтовую кодировку для других плоскостей. Пока он не содержит кодовых точек в зарезервированном диапазоне U + D800 – U + DFFF, текст UCS-2 является допустимым текстом UTF-16.

UTF-32 (также называемый UCS-4) использует четыре байта для кодирования любой заданной кодовой точки, но не обязательно любого заданного воспринимаемого пользователем символа (грубо говоря, графема ), поскольку воспринимаемый пользователем символ может быть представлен кластером графемы (последовательностью нескольких кодовых точек). Как и UCS-2, количество байтов на кодовую точку фиксировано, что упрощает индексацию символов; но в отличие от UCS-2, UTF-32 может кодировать все кодовые точки Unicode. Однако, поскольку каждый символ использует четыре байта, UTF-32 занимает значительно больше места, чем другие кодировки, и широко не используется. Примеры UTF-32 также имеют переменную длину (как и все другие кодировки), хотя в другом смысле включают: «Деванагари kshi кодируется 4 кодовыми точками [..] Флаговые смайлики также являются кластерами графем. и состоит из двух символов кодовой точки — например, флаг Японии «и все», объединяющие последовательности символов, являются графемами, но есть и другие последовательности кодовых точек, которые также являются; например, r n является одним. «

Содержание

• 1 Происхождение и развитие
  • 1.1 История
  • 1.2 Консорциум Unicode
  • 1.3 Охваченные сценарии
  • 1.4 Версии
• 2 Архитектура и терминология
  • 2.1 Кодовая точка плоскости и блоки
  • 2.2 Общее свойство категории
  • 2.3 Абстрактные символы
  • 2.4 Сравнение готовых и составных символов
  • 2.5 Лигатуры
  • 2.6 Стандартизированные подмножества
  • 2.7 Отображение и кодирование
• 3 Принятие
  • 3.1 Операционные системы
  • 3.2 Способы ввода
  • 3.3 Электронная почта
  • 3.4 Интернет
  • 3.5 Шрифты
  • 3.6 Новые строки
• 4 Проблемы
  • 4.1 Критика философии и полноты isms
  • 4.2 Сопоставление с устаревшими наборами символов
  • 4.3 Индийские скрипты
  • 4.4 Объединение символов
  • 4.5 Аномалии
• 5 См. также
• 6 Примечания
• 7 Ссылки
• 8 Дополнительная литература
• 9 Внешние ссылки

Происхождение и развитие

Unicode имеет явную цель преодолеть ограничения традиционных кодировок символов, например, определенных в стандарте ISO / IEC 8859, который находят широкое применение в разных странах мира, но остаются в значительной степени несовместимыми друг с другом. Многие традиционные кодировки символов имеют общую проблему в том, что они допускают двуязычную компьютерную обработку (обычно с использованием латинских символов и локальный сценарий), но не многоязычную компьютерную обработку (компьютерная обработка произвольных сценариев, смешанных друг с другом).

Unicode, по сути, кодирует базовые символы — графемы и графемоподобные единицы — а не варианты глифов (визуализации) для таких символов. В случае китайских иероглифов это иногда приводит к разногласиям по поводу отличия основного символа от его вариантов глифов (см. Han unification ).

При обработке текста Unicode обеспечивает уникальную кодовую точку — число, а не глиф — для каждого символа. Другими словами, Unicode представляет символ абстрактным образом и оставляет визуальную визуализацию (размер, форму, шрифт или стиль) другому программному обеспечению, например веб-браузеру или текстовый процессор. Однако эта простая цель усложняется из-за уступок, сделанных разработчиками Unicode в надежде стимулировать более быстрое принятие Unicode.

Первые 256 кодовых точек были сделаны идентичными содержимому ISO / IEC 8859-1, чтобы упростить преобразование существующего западного текста. Многие практически идентичные символы кодировались несколько раз в разных кодовых точках, чтобы сохранить различия, используемые в устаревших кодировках, и, следовательно, обеспечить преобразование из этих кодировок в Unicode (и обратно) без потери какой-либо информации. Например, раздел кодовых точек «полноширинных форм » включает в себя полную копию латинского алфавита, поскольку шрифты китайского, японского и корейского (CJK ) содержат две версии этих букв, «fullwidth» соответствует ширине символов CJK и нормальной ширине. Другие примеры см. В разделе повторяющиеся символы в Unicode.

История

На основе опыта использования стандарта кодов символов Xerox (XCCS) с 1980 года, истоки Unicode датируются 1987 годом., когда Джо Беккер из Xerox с Ли Коллинз и Марк Дэвис из Apple, начали исследовать практические аспекты создание универсального набора символов. При дополнительном вкладе Питера Фенвика и Дэйва Опстада, Джо Беккер опубликовал в августе 1988 г. проект предложения по «международной / многоязычной системе кодирования текстовых символов, предварительно названной Unicode». Он пояснил, что «[t] его название« Unicode »предназначено для обозначения уникальной, унифицированной, универсальной кодировки».

В этом документе под названием Unicode 88 Беккер выделил 16-битный символьная модель:

Unicode предназначен для удовлетворения потребности в работоспособной и надежной мировой кодировке текста. Юникод можно грубо описать как «широкий код ASCII», который был растянут до 16 бит, чтобы охватить символы всех живых языков мира. При правильно спроектированном дизайне для этой цели более чем достаточно 16 бит на символ.

Его первоначальный 16-битный дизайн был основан на предположении, что нужно будет кодировать только те скрипты и символы, которые используются в современном мире:

Unicode отдает более высокий приоритет обеспечению полезности для будущего, чем сохранению прошлых древностей. Unicode нацелен в первую очередь на символы, опубликованные в современном тексте (например, в объединении всех газет и журналов, напечатанных в мире в 1988 году), число которых, несомненно, намного меньше 2 = 16 384. Помимо этих современных символов, все остальные могут быть определены как устаревшие или редкие; это лучшие кандидаты для регистрации для частного использования, чем для чрезмерного заполнения общедоступного списка общих полезных кодов Unicodes.

В начале 1989 года рабочая группа Unicode расширилась и включила Кена Уистлера и Майка Кернагана из Metaphor, Карен Смит-Йошимура и Джоан Алипранд из RLG и Гленна Райт из Sun Microsystems, а в 1990 году к группе присоединились Мишель Суиньяр и Асмус Фрейтаг из Microsoft и Рик Макгоуэн из NeXT. К концу 1990 года большая часть работы по сопоставлению существующих стандартов кодировки символов была завершена, и был готов окончательный проект обзора Unicode.

Консорциум Unicode был учрежден в Калифорнии 3 января 1991 года, а в октябре 1991 года был опубликован первый том стандарта Unicode. Второй том, посвященный идеограммам Хань, был опубликован в июне 1992 года.

В 1996 году в Unicode 2.0 был реализован механизм суррогатных символов, так что Unicode больше не ограничивался 16 битами. Это увеличило кодовое пространство Unicode до более чем миллиона кодовых точек, что позволило кодировать многие исторические сценарии (например, египетские иероглифы ) и тысячи редко используемых или устаревших символов, которые, как предполагалось, не нуждались в кодировании. Среди символов, изначально не предназначенных для Unicode, редко используются кандзи или китайские символы, многие из которых являются частью личных и географических названий, что делает их редко используемыми, но гораздо более важными, чем предполагалось в исходной архитектуре Unicode.

Спецификация Microsoft TrueType версии 1.0 от 1992 года использовала имя Apple Unicode вместо Unicode для идентификатора платформы в таблице имен.

Консорциум Unicode

Консорциум Unicode — это некоммерческая организация, координирующая разработку Unicode. Полноправные члены включают большинство основных производителей компьютерного программного обеспечения и оборудования, которые заинтересованы в стандартах обработки текста, включая Adobe, Apple, Facebook, Google., IBM, Microsoft, Netflix и SAP SE.

За прошедшие годы несколько стран или правительственных агентств были членами Консорциум Unicode. В настоящее время только Министерство по делам религий и пожертвований (Оман) является полноправным членом с правом голоса.

Консорциум ставит амбициозную цель в конечном итоге заменить существующие схемы кодирования символов на Unicode и его стандарт Схемы формата преобразования Unicode (UTF), поскольку многие из существующих схем ограничены по размеру и области применения и несовместимы с многоязычной средой.

Охваченные сценарии

Многие современные приложения могут отображать значительную часть множества сценариев в Unicode, как показано на этом снимке экрана из приложения OpenOffice.org.

Unicode охватывает почти все скрипты (системы письма ), используемые в настоящее время.

Всего 154 скриптов включены в последнюю версию Unicode (охватывающую алфавиты, abugidas и слоговые словари ), хотя все еще есть письменности, которые еще не закодированы, особенно те, которые в основном используются в историческом, литургическом и академическом контексте. Также происходит дальнейшее добавление символов к уже закодированным сценариям, а также символов, в частности для математики и музыки (в виде нот и ритмических символов).

Комитет дорожной карты Unicode (Майкл Эверсон, Рик МакГоуэн, Кен Уистлер, В.С. Умамахесваран) поддерживает список скриптов, которые являются кандидатами или потенциальными кандидатами для кодирования, и их предварительные назначения блоков кода на Дорожная карта Unicode на веб-сайте Консорциума Unicode. Для некоторых скриптов в дорожной карте, таких как чжурчжэнь и киданьский маленький скрипт, были внесены предложения по кодированию, и они проходят процесс утверждения. Для других скриптов, таких как Mayan (кроме чисел) и Rongorongo, предложений еще не было, и они ждут согласия по репертуару персонажей и другим деталям от вовлеченных сообществ пользователей.

Некоторые современные сценарии, которые еще не были включены в Unicode (например, Tengwar ) или которые не могут быть включены в Unicode из-за отсутствия реального использования (например, Klingon ) перечислены в ConScript Unicode Registry вместе с неофициальными, но широко используемыми кодами Private Use Areas.

Существует также Средневековая инициатива по шрифтам Unicode, ориентированная на особые латинские средневековые символы. Часть этих предложений уже включена в Unicode.

Script Encoding Initiative, проект, проводимый Деборой Андерсон из Калифорнийского университета в Беркли, был основан в 2002 году с целью финансирования предложений для сценариев, которые еще не были закодировано в стандарте. В последние годы проект стал основным источником предлагаемых дополнений к стандарту.

Версии

Unicode разработан совместно с Международной организацией по стандартизации и разделяет репертуар символов с ISO / IEC 10646 : универсальный набор символов. Unicode и ISO / IEC 10646 эквивалентны кодировке символов, но стандарт Unicode содержит гораздо больше информации для разработчиков, в которых подробно рассматриваются такие темы, как побитовое кодирование, сопоставление и рендеринг. Стандарт Unicode перечисляет множество свойств символов, включая те, которые необходимы для поддержки двунаправленного текста . В этих двух стандартах используется немного разная терминология.

Консорциум Unicode впервые опубликовал Стандарт Unicode в 1991 году (версия 1.0) и с тех пор регулярно публикует новые версии. Последняя версия стандарта Unicode, версия 13.0, была выпущена в марте 2020 года и доступна в электронном формате на веб-сайте консорциума. Последней версией стандарта, которая была полностью опубликована в виде книги (включая диаграммы кода), была версия 5.0 в 2006 году, но начиная с версии 5.2 (2009) основная спецификация стандарта была опубликована в мягкой обложке для печати по запросу. Полный текст каждой версии стандарта, включая основную спецификацию, стандартные приложения и таблицы кодов, находится в свободном доступе в формате PDF на веб-сайте Unicode.

В апреле 2020 года Unicode объявил, что выпуск предстоящей версии 14.0 был отложен на шесть месяцев с момента его первоначального выпуска в марте 2021 года из-за пандемии COVID-19.

. были опубликованы следующие основные и дополнительные версии стандарта Unicode. Версии обновлений, которые не включают никаких изменений в репертуар символов, обозначены третьим числом (например, «версия 4.0.1») и опущены в таблице ниже.

Архитектура и терминология

Стандарт Unicode определяет кодовое пространство числовых значений в диапазоне от 0 до 10FFFF 16, называемое кодовыми точками и обозначаемое как U + 0000 до U + 10FFFF («U +» плюс значение кодовой точки в шестнадцатеричном формате., с предшествующими ведущими нулями по мере необходимости, чтобы получить как минимум четыре цифры, например, U + 00F7 для знака деления, ÷, по сравнению с U + 13254 для египетского иероглифа обозначение тростникового укрытия или извилистой стены ( )) соответственно. Из этих 2 + 2 определенных кодовых точек кодовые точки от U + D800 до U + DFFF, которые используются для кодирования суррогатных пар в UTF-16, зарезервированы стандартом и не могут использоваться для кодирования допустимых символов, в результате чего в сумме получается 2–2 + 2 = 1,112,064 возможных кодовых точки, соответствующих допустимым символам Unicode. Не все эти кодовые точки обязательно соответствуют видимым символам; несколько, например, присвоены управляющим кодам, таким как возврат каретки.

плоскости и блоки кодовых точек

Кодовое пространство Unicode разделено на семнадцать плоскостей, пронумерованных от 0 до 16:

Все кодовые точки в BMP доступны как единая кодовая единица в кодировке UTF-16 и могут быть закодированы в один, два или три байта в UTF-8. Кодовые точки в плоскостях с 1 по 16 (дополнительные плоскости) доступны как суррогатные пары в UTF-16 и кодируются в четырех байтах в UTF-8.

Внутри каждой плоскости символы распределяются в именованных блоках связанных символов. Хотя блоки имеют произвольный размер, они всегда кратны 16 кодовым точкам и часто кратны 128 кодовым точкам. Символы, необходимые для данного сценария, могут быть распределены по нескольким различным блокам.

Свойство общей категории

Каждая кодовая точка имеет одно свойство Общая категория. Обозначаются основные категории: буква, знак, число, пунктуация, символ, разделитель и прочее. Внутри этих категорий есть подразделения. В большинстве случаев необходимо использовать другие свойства, чтобы в достаточной мере указать характеристики кодовой точки. Возможные общие категории:

Кодовые точки в диапазоне U + D800 – U + DBFF (1024 кодовых точки) известны как высокие- суррогатных кодовых точек и кодовых точек в диапазоне U + DC00 – U + DFFF (1024 кодовых точки) известны как низко-суррогатные кодовые точки. Кодовая точка с высоким суррогатным кодом, за которой следует кодовая точка с низким суррогатом, образуют суррогатную пару в UTF-16 для представления кодовых точек, превышающих U + FFFF. В противном случае эти кодовые точки нельзя использовать (на практике это правило часто игнорируется, особенно когда не используется UTF-16).

Небольшой набор кодовых точек гарантированно никогда не будет использоваться для кодирования символов, хотя приложения могут использовать эти кодовые точки внутри, если захотят. Всего шестьдесят шесть из этих несимволов : U + FDD0 – U + FDEF и любая кодовая точка, заканчивающаяся значением FFFE или FFFF (т. Е. U + FFFE, U + FFFF, U + 1FFFE, U + 1FFFF,… U + 10FFFE, U + 10FFFF). Набор несимволов стабилен, и никакие новые нехарактеры никогда не будут определены. Как и суррогаты, правило, что они не могут быть использованы, часто игнорируется, хотя операция с меткой порядка байтов предполагает, что U + FFFE никогда не будет первой кодовой точкой в ​​тексте.

Исключение суррогатов и несимволов оставляет 1,111 998 кодовых точек, доступных для использования.

Кодовые точки частного использования считаются присвоенными символами, но они не имеют интерпретации, определенной стандартом Unicode, поэтому любой обмен такими символами требует соглашения между отправителем и получателем об их интерпретации. В кодовом пространстве Unicode есть три области частного использования:

• Область частного использования: U + E000 – U + F8FF (6400 символов),
• Дополнительная область частного использования-A: U + F0000 – U + FFFFD (65 534 символа),
• Дополнительная область частного использования-B: U + 100000 – U + 10FFFD (65 534 символа).

Графический ch Символы — это символы, Unicode как имеющие особую семантику, и они либо имеют видимую форму глифа , либо имеют видимое пространство. В Unicode 13.0 имеется 143 696 графических символов.

Формат символов — это символы, которые не имеют видимого внешнего вида, но могут влиять на внешний вид или поведение соседних символов. Например, U + 200C ZERO WIDTH NON-JOINER и U + 200D ZERO WIDTH JOINER могут быть созданы для изменения формы по умолчанию. поведение соседних символов (например, чтобы запретить лигатуры или запросить формирование лигатуры). Unicode 13.0 содержит 163 символа формата.

Шестьдесят пять кодовых точек (U + 0000 — U + 001F и U + 007F — U + 009F) зарезервированы как управляющие коды и соответствуют C0 и C1 коды управления в ISO / IEC 6429. U + 0009 (табуляция), U + 000A (перевод строки) и U + 000D (возврат каретки) широко используются в текстах с кодировкой Unicode. На практике кодовые точки C1 часто неправильно переводятся (mojibake ) как устаревшие символы Windows-1252, используемые в некоторых английских и западноевропейских текстах.

Графические символы, символы формата, символы управляющего кода и символы частного использования известны вместе как назначенные символы. Зарезервированные кодовые точки — это те кодовые точки, которые доступны для использования, но еще не назначены. В Unicode 13.0 зарезервировано 830 606 кодовых точек.

Абстрактные символы

Набор графических символов и символов формата, определенных Unicode, не соответствует непосредственно репертуару абстрактных символов, который может быть представлен в Unicode. Unicode кодирует символы, связывая абстрактный символ с определенной кодовой точкой. Однако не все абстрактные символы кодируются как один символ Unicode, некоторые абстрактные символы могут быть представлены в последовательности Unicode из двух или более символов. Например, латинская строчная буква «i» с ogonek, над точкой и острым ударением, которое требуется в литовском, представленной последовательностью символов + 012F, U + 0307, ​​U + 0301. Unicode поддерживает список последовательностей символов с уникальными именами для абстрактных символов, которые не кодируются напрямую в Unicode.

Все графические символы, символы формата и частного использования имеют уникальное и новое имя, по которому они могут быть идентифицированы. Эта неизменяемость гарантируется, начиная с версии 2.0 Unicode, политикой стабильности имени. В случаях, когда вводится серьезная типографская ошибка, может быть определен формальный псевдоним, и приложениям рекомендуется использовать формальный псевдоним вместо официального имени персонажа. Например, U + A015 ꀕ YI SYLLABLE WU имеет формальный псевдоним YI SYLLABLE ITERATION MARK, а U + FE18 ︘ ФОРМА ПРЕЗЕНТАЦИИ ДЛЯ ВЕРТИКАЛЬНОЙ ПРАВЫЙ БЕЛЫЙ ЛЕНТОКУЛЯРНЫЙ бюстгальC 138>ET (sic ) имеет формальный псевдоним ФОРМА ПРЕДСТАВЛЕНИЯ ДЛЯ ВЕРТИКАЛЬНОЙ ПРАВОЙ БЕЛОЙ ЛЕНТИКУЛЯРНОЙ ЛЮБИМЧИКА CK ET.

Готовые и составные символы

Unicode включает механизм изменения символов, который значительно поддерживает поддерживаемый репертуар глифов. Это касается использования , объединяющего диакритические знаки, которые могут быть добавлены после основного символа. К одному и тому же символу можно одновременно применять несколько комбинированных диакритических знаков. Юникод также содержит составленные версии широко распространенных буквенно-диакритических комбинаций при обычном использовании. Это упрощает преобразование в устаревшие кодировки и обратно и позволяет использовать Unicode в внутреннем текстовом формате без необходимости реализовывать комбинирование символов. Например, он может быть представлен в Юникоде как U + 0065 (СТРОЧНАЯ ЛАТИНСКАЯ БУКВА E), за которым следует U + 0301 (КОМБИНИРОВАНИЕ ОСТРЫХ АКЦЕНТОВ), но он также может быть как построенный составленный символ U + 00E9 (СТРОЧНАЯ ЛАТИНСКАЯ БУКВА E С ОСТРЫМ). Таким образом, во многих случаях есть несколько способов кодирования одного и того же символа. Чтобы справиться с этим, Unicode предоставляет механизм канонической эквивалентности.

. Примером этого является хангыль, корейский алфавит. Unicode предоставляет механизм для составления слогов хангыль с их отдельными подкомпонентами, известный как Hangul Jamo. Тем не менее, он также содержит 11 172 комбинации слогов, состав из наиболее распространенных джамо.

Символы CJK в настоящее время имеют коды только для их первоначальной составленной формы. Тем не менее, большинство этих символов содержат более простые элементы (называемые радикалами ), поэтому в принципе Unicode мог бы разложить, как это было с хангылем. Это значительно увеличило количество требуемых кодовых точек, одновременно позволяя отображать практически все мыслимые некоторые символы (что могло бы устранить проблемы, вызванные объединением Хань ). Похожая идея используется некоторые методы ввода , такими как Cangjie и Wubi. Однако попытки сделать это для кодировки символов натолкнулись на тот факт, что китайские иероглифы не распадаются так просто и регулярно, как хангыль.

Набор лов был предоставлен в Unicode 3.0 (радикалы CJK между U + 2E80 и U + 2EFF, радикалы KangXi в U + 2F00 до U + 2FDF и символы идеографического описания из U От + 2FF0 до U + 2FFB), но стандартный Unicode (глава 12.2 Unicode 5.2) предостерегает от использования последовательностей идеографических описаний в качестве альтернативного представления для ранее закодированных символов:

Этот процесс отличается от формальной кодировки идеограммы. Нет канонического описания незакодированных идеографов; отсутствует семантика описываемых идеографов; для описанных идеографов эквивалентность не определена. Концептуально идеальные описания больше похожи на английскую фразу «an ‘e’ с острым ударением», чем на последовательность символов .

Лигатуры

Многие шрифты, включая арабский и Деванагари, имеют особые орфографические правила, требующие объединения комбинаций букв в специальные лигатурные формы. Правила, управляющие формированием лигатуры, могут быть довольно сложными, требующими специальных технологий формирования шрифтов, таких как ACE (Арабский каллиграфический движок от DecoType в 1980-х годах и использовавшийся для генерации всех арабских примеров в печатных изданиях стандарта Unicode), который стал проверка концепции для OpenType (от Adobe и Microsoft), Graphite (от SIL International ) или AAT (от Apple).

Инструкции также встроены в шрифты, чтобы сообщить операционную систему, как правильно выводить используемые символы. Простое решение для размещения комбинированных знаков или диакри знаков — присвоить знакам нулевую ширину и link сам глиф слева или справа от левого подшипника (в зависимости от направления шрифта, которые предназначены для использования). Знак, обработанный таким образом, будет определять положение любого предшествующего ему символа, но не будет регулировать его положение относительно ширины или высоты базового глифа; это может быть визуально неудобно и может перекрывать некоторые глифы. Настоящее наложение невозможно, но в некоторых случаях можно приблизиться к нему (например, временные верхние гласные и тональные знаки могут быть на разной высоте для начала). Как правило, этот подход эффективен только для моноширинных шрифтов, но может быть как резервный метод рендеринга, когда более сложные методы не работают.

Стандартизированные подмножества

Некоторые подмножества Unicode стандартизированы: Microsoft Windows, начиная с Windows NT 4.0 поддерживает WGL-4 с 656 символами, что считается для поддержки всех современных языков с использованием латинского, греческого или кириллического шрифта. Другие стандартизованные подмножества Unicode включают многоязычные европейские подмножества:

MES-1 (только латинские шрифты, 335 символов), MES-2 (латинские, греческие и кириллические 1062 символа) и MES-3A и MES-3B (два больших подмножества, здесь не показаны). Обратите внимание, что MES-2 включает каждый символ в MES-1 и WGL-4.

Программное обеспечение для визуализации, которое не может должным образом обработать символ Unicode, часто отображает его как открытый прямоугольник или заменяющий символ Unicode «» (U + FFFD,), чтобы указать положение нераспознанного символа. Некоторые системы сделали использование больше информации о таких персонажах. Шрифт Apple Last Resort будет отображать заменяющий глиф, отображающий диапазон Unicode показ символов, а запасной шрифт Unicode SIL International отображит поле, шестнадцатеричное скалярное значение символа.

Отображение и кодирование

Было определено несколько механизмов хранения для кодовых точек в виде последовательности байтов.

Unicode — два метода сопоставления: кодировки формата преобразования Unicode (UTF) и кодировки универсального набора кодированных символов (UCS). Кодирование отображает (возможно, подмножество) диапазон кодовых точек Unicode в пределах значений в некотором диапазоне фиксированного размера, называемые кодовыми единицами. Код карты всех кодировок UTF указывает на уникальную последовательность байтов. Числа в названии кодировок указать количество бит на единицу кода (для кодировок UTF) или количество байтов на единицу кода (для кодировок UCS и UTF-1). UTF-8 и UTF-16 — наиболее часто используемые кодировки. UCS-2 — устаревшее подмножество UTF-16; UCS-4 и UTF-32 функционально эквивалентны.

Кодировки UTF включают:

• UTF-1, устаревший предшественник UTF-8, максимизирует совместимость с ISO 2022, больше не является частью стандарта Unicode
• UTF-7., 7-битная кодировка, иногда используемая в электронной почте, часто устаревшая (не используется устаревшая версия Unicode, а только задокументированная как информационный RFC, то есть не в Интернете Standards Track)
• UTF -8, использует от одного четырех байтов для каждой кодовой точки, максимизирует совместимость с ASCII
• UTF-EBCDIC, аналогичен UTF-8, но разработан для совместимости с EBCDIC (не является частью стандарта Unicode)
• UTF-16, одну или две 16-битных кодовых единиц на каждую кодовую точку, не может кодировать суррогаты
• UTF-32, использует одну 32- битную кодовую единицу на каждую кодовую точку.

UTF-8 использует от одного до четырех байтов кодовую точку и является компактным для латинских скриптов и совместимым с ASCII, обеспечивает стандартное кодирование де-факто для обмена текстом Unicode. Он используется FreeBSD и последними дистрибутивами Linux как прямая замена устаревшим кодировкам в общей обработке текста.

Кодировки UCS-2 и UTF-16 определяют Unicode метку порядка байтов (BOM) для использования в начале текстовых файлов, который может быть определен для определения порядка байтов (или байтовый порядок байтов) обнаружение). Спецификация, кодовая точка U + FEFF важное свойство однозначности при изменении порядка байтов, независимо от используемой кодировки Unicode; U + FFFE (перестановки байтов U + FEFF) не соответствует допустимому символу, а U + FEFF в других местах, кроме начала текста, передает неразрывный пробел нулевой ширины (символ с никакого внешнего вида и никакого эффекта, кроме предотвращения образования лигатур ).

Тот же самый символ, преобразованный в UTF-8, становится последовательностью байтов EF BB BF. Стандарт Unicode позволяет, чтобы спецификация «могла служить подписью для текста в кодировке UTF-8, где набор символов не отмечен». Некоторые устройства программного обеспечения принимают его для других кодировок, включая UTF-8, попытку разработки отличить UTF-8 от локальных 8-битных кодовых страниц . RFC 3629, стандарт UTF-8, запрещает запретить метки порядка байтов в протоколах, использующих UTF-8, но обсуждает случаи, когда это может быть невозможно. Кроме того, предполагается большое ограничение на возможные шаблоны в UTF-8 (например, не может быть никаких одиночных байтов с установленным старшим битом), что предполагает возможность отличить UTF-8 от других кодировок символов, не полагаясь на спецификацию.

В UTF-32 и UCS-4 одна 32-битная кодовая единица используется достаточно прямым представлением кодовой точки любого символа (хотя порядок изменяется на разных платформах, влияет на кодовая единица) проявляется как последовательность байтов). В других кодировках каждая кодовая точка может быть представлена ​​переменным товаром кодовые. UTF-32 широко используется в качестве внутреннего представления текста в программах (отличие от сохраненного или передаваемого текста), поскольку каждая операционная система Unix, которая использует компиляторы gcc для создания программного обеспечения, использует его как стандарт «расширенный символ «кодировка. Некоторые языки программирования, такие как Seed7, используют UTF-32 в качестве внутреннего представления для строк и символов. Последние версии языка программирования Python (начиная с 2.2) также могут быть настроены для использования UTF-32 в качестве представления строк Unicode, эффективно распространяя такую ​​кодировку в высокоуровневом кодированном программном продукте..

Punycode, другая форма кодирования, позволяет кодировать строки Unicode в ограниченный набор символов, поддерживаемый ASCII -системой доменных имен (DNS) на основе ASCII. Кодировка используется как часть IDNA, которая представляет собой систему, позволяющую использовать интернационализированные доменные имена во всех скриптах, поддерживаемых Unicode. Предыдущие и нынешние исторические предложения включают UTF-5 и UTF-6.

GB18030 — еще одна форма кодировки для Unicode, разработанная Администрация по стандартизации Китая. Это официальный набор символов в Китайской Народной Установ (КНР). BOCU-1 и SCSU — это схемы сжатия Unicode. В первоапрельском RFC 2005 г. указаны две пародийные кодировки UTF, UTF-9 и UTF-18.

Adoption

Операционные системы

Unicode стал доминирующей схемой для внутренней обработки и хранения текста. Хотя большая часть текста все еще хранится в устаревших кодировках, Unicode используется почти исключительно для создания новых систем обработки информации. Ранние последователи, как правило, использовали UCS-2 (двухбайтовый предшественник UTF-16 с фиксированной шириной), а позже перешли на UTF-16 (текущий стандарт переменной ширины), так как это был наименее разрушительный способ добавить поддержку символов, отличных от BMP. Самая известная такая система — Windows NT (и ее потомки, Windows 2000, Windows XP, Windows Vista, Windows 7, Windows 8 и Windows 10 ), в котором используется UTF-16 в качестве единственной внутренней кодировки символов. Среды байт-кода Java и .NET, macOS и KDE также используют его для внутреннего представления. Частичная поддержка Unicode может быть установлена ​​в Windows 9x через Microsoft Layer for Unicode.

UTF-8 (первоначально разработанный для Plan 9 ) стал кодировка основного хранилища в большинстве Unix-подобных операционных систем (хотя другие также используются некоторыми библиотеками), потому что это относительно простая замена традиционных расширенных наборов символов ASCII. UTF-8 также является наиболее распространенной кодировкой Unicode, используемой в HTML документах в World Wide Web.

Многоязычные механизмы обработки текста, использующие Unicode, включая Uniscribe и DirectWrite для Microsoft Windows, ATSUI и Core Text для macOS и Pango для GTK + и GNOME рабочий стол.

Методы ввода

Поскольку в раскладках клавиатуры не может быть простых комбинаций клавиш для всех символов, некоторые операционные системы предоставляют альтернативные методы ввода, позволяющие получить доступ ко всему репертуару.

ISO / IEC 14755, который стандартизирует методы ввода символов Unicode из их кодовых точек, определяет несколько методов. Существует метод Basic, в котором за начальной последовательностью следует шестнадцатеричное представление кодовой точки и конечной последовательности. Также указан метод ввода с выбором экрана, когда символы перечислены в таблице на экране, например, в программе сопоставления символов.

Онлайн-инструменты для поиска кодовой точки для известного символа включают Unicode Lookup от Джонатана Хедли и Shapecatcher от Бенджамина Милде. При поиске в Unicode вводится ключ поиска (например, «дроби»), и возвращается список соответствующих символов с их кодовыми точками. В Shapecatcher на основе контекста формы символ рисуется в поле, и возвращается список символов, приближенных к рисунку, с их кодовыми точками.

Электронная почта

MIME определяет два разных механизма для кодирования не-ASCII символов в электронном письме, в зависимости от того, находятся ли символы в заголовках электронной почты (например, «Тема:») или в тексте сообщения; в обоих случаях идентифицируется исходный набор символов, а также кодировка передачи. Для передачи по электронной почте Unicode рекомендуется использовать набор символов UTF-8 и кодировку передачи Base64 или Quoted-printable, в зависимости от того, большая часть сообщения состоит из символов ASCII. Детали двух различных механизмов указаны в стандартах MIME и обычно скрыты от пользователей почтового программного обеспечения.

Внедрение Unicode в электронной почте происходит очень медленно. Некоторый восточноазиатский текст по-прежнему закодирован в таких кодировках, как ISO-2022, а некоторые устройства, такие как мобильные телефоны, по-прежнему не могут правильно обрабатывать данные Unicode. Однако поддержка улучшается. Многие основные поставщики бесплатной почты, такие как Yahoo, Google (Gmail ) и Microsoft (Outlook.com ) поддерживаю это.

Интернет

Все рекомендации W3C использовали Unicode в качестве набора символов документа, начиная с HTML 4.0. Веб-браузеры уже много лет поддерживают Unicode, особенно UTF-8. Раньше возникали проблемы с отображением, в основном из-за проблем, связанных со шрифтом ; например v 6 и более ранние версии Microsoft Internet Explorer не отображали много кодовых точек, если явно не было указано использовать шрифт, который их содержит.

Хотя правила синтаксиса могут влиять на порядок, в котором разрешены символы По-видимому, документы XML (включая XHTML ) по определению содержат символы из большинства кодовых точек Unicode, за исключением:

• большей части элемента управления C0 коды,
• постоянно неназначенные кодовые точки D800 – DFFF,
• FFFE или FFFF.

символы HTML проявляются либо непосредственно как байты в соответствии с кодировкой документа, если кодировка их поддерживает, или пользователи могут записывать их как числовые ссылки на символы на основе кодовой точки Unicode символа. Например, ссылки Δ, , ק, م, ๗, あ, 叶, 葉и 말(или те же числовые значения, выраженные в шестнадцатеричном формате, с префиксом ​​# x) должен отображаться во всех браузерах как Δ,, ק, م, ๗, あ, 叶, 葉 и 말.

При указании URI, например, как URL-адресов в HTTP запросах, символы не-ASCII должны быть закодированы в процентах.

Шрифты

Unicode в принципе не имеет отношения к шрифтам как таковым, рассматривая их как варианты реализации. Любой данный символ может иметь множество аллографов, от более распространенных жирных, курсивных и базовых букв до сложных декоративных стилей. Шрифт является «совместимым с Unicode», если к глифам в шрифте можно получить доступ с помощью кодовых точек, определенных в стандарте Unicode. Стандарт не определяет минимальное количество символов, которое должно быть включено в шрифт; у некоторых шрифтов довольно небольшой репертуар.

Бесплатные и розничные шрифты на основе Unicode широко доступны, поскольку TrueType и OpenType поддерживают Unicode. Эти форматы шрифтов сопоставляют кодовые точки Unicode с глифами, но шрифт TrueType ограничен 65 535 глифами.

На рынке существуют тысячи шрифтов, но менее дюжины шрифтов — иногда называемых «пан-Unicode» шрифтами — пытаются поддерживать большую часть репертуара символов Unicode. Вместо этого шрифты на основе Unicode обычно ориентированы на поддержку только базового ASCII и определенных сценариев или наборов символов или символов. Такой подход оправдан несколькими причинами: приложениям и документам редко требуется отображать символы из более чем одной или двух систем письма; шрифты обычно требуют ресурсов в вычислительной среде; а операционные системы и приложения демонстрируют растущий интеллект в отношении получения информации о глифах из отдельных файлов шрифтов по мере необходимости, т. е. замещения шрифта. Более того, разработка последовательного набора инструкций по рендерингу для десятков тысяч глифов представляет собой монументальную задачу; такое предприятие проходит точку убывающей доходности для большинства шрифтов.

Новые строки

Unicode частично решает проблему новой строки, которая возникает при попытке прочитать текстовый файл на разных платформах. Unicode определяет большое количество символов , которые соответствующие приложения должны распознавать как символы конца строки.

Что касается новой строки, Unicode представил U + 2028 СТРОЧНЫЙ РАЗДЕЛИТЕЛЬ и U + 2029 ПАРАГРАФНЫЙ РАЗДЕЛИТЕЛЬ. Это была попытка предоставить решение Unicode для семантического кодирования абзацев и строк, потенциально заменяющее все различные решения платформы. При этом Unicode действительно позволяет обойти исторические решения, зависящие от платформы. Тем не менее, немногие, если вообще какие-либо решения Unicode приняли эти разделители строк и абзацев Unicode в качестве единственных канонических символов окончания строки. Однако общий подход к решению этой проблемы — нормализация новой строки. Это достигается с помощью текстовой системы Какао в Mac OS X, а также с помощью рекомендаций W3C XML и HTML. В этом подходе каждый возможный символ новой строки внутренне преобразуется в общий символ новой строки (который на самом деле не имеет значения, поскольку это внутренняя операция только для визуализации). Другими словами, текстовая система может правильно обрабатывать символ как новую строку, независимо от фактической кодировки ввода.

Проблемы

Критика философии и полноты

Ханьское объединение (определение форм в восточноазиатских языках, которые можно рассматривать как стилистические вариации тот же исторический характер) стал одним из самых спорных аспектов Unicode, несмотря на присутствие большинства экспертов из всех трех регионов в Ideographic Research Group (IRG), которая консультирует Консорциум и ISO по вопросам дополнений в репертуар и на объединение ханьцев.

Unicode подвергался критике за неспособность отдельно кодировать старые и альтернативные формы кандзи, что, по мнению критиков, усложняет обработку древних японских и необычных японских имен. Часто это связано с тем, что Unicode кодирует символы, а не глифы (визуальные представления основного символа, которые часто меняются от одного языка к другому). Объединение глифов приводит к пониманию того, что объединяются сами языки, а не только базовое представление символов. Было предпринято несколько попыток создать альтернативные кодировки, которые сохраняли стилистические различия между китайскими, японскими и корейскими иероглифами в противовес политике Юникода по унификации ханьцев. Примером одного из них является TRON (хотя он не получил широкого распространения в Японии, есть некоторые пользователи, которым нужно обрабатывать исторический японский текст и отдавать ему предпочтение).

Хотя репертуар из менее чем 21 000 символов хань в самой ранней версии Unicode был в значительной степени ограничен символами, широко используемыми в современном мире, Unicode теперь включает более 92 000 символов хань, и продолжается работа над добавлением еще тысяч исторических и диалектные символы, используемые в Китае, Японии, Корее, Тайване и Вьетнаме.

Современная технология шрифтов предоставляет средства для решения практической проблемы, связанной с необходимостью изобразить унифицированный символ хань в терминах набора альтернативных представлений глифов в форме последовательностей вариантов Unicode. Например, таблицы расширенной типографики OpenType позволяют выбрать одно из ряда альтернативных представлений глифа при выполнении процесса преобразования символа в глиф. В этом случае информация может быть предоставлена ​​в виде обычного текста, чтобы указать, какую альтернативную форму символа выбрать.

Различные символы кириллицы показаны с курсивом и без него

Если разница в соответствующих глифах для двух символов в одном и том же скрипте различается только курсивом, Unicode, как правило, объединил их, как можно видеть в сравнении между русскими (обозначенными как стандартные) и сербскими символами справа, что означает, что различия отображаются с помощью технологии интеллектуальных шрифтов или ручной смены шрифтов.

Преобразование в устаревшие наборы символов

Unicode был разработан для обеспечения последовательного преобразования кодовой точки двустороннего формата в любые существующие кодировки символов и обратно, так что текстовые файлы в более старых наборах символов можно преобразовать в Unicode, а затем вернуться и получить тот же файл без использования контекстно-зависимой интерпретации. Это означает, что несовместимые устаревшие архитектуры, такие как , сочетающие диакритические знаки и предварительно составленные символы, обе существуют в Unicode, что дает более одного метода представления некоторого текста. Это наиболее ярко выражено в трех различных формах кодирования корейского хангыль. Начиная с версии 3.0, любые предварительно составленные символы, которые могут быть представлены последовательностью комбинирования уже существующих символов, больше не могут быть добавлены в стандарт, чтобы сохранить взаимодействие между программным обеспечением, использующим разные версии Unicode.

Injective должны быть обеспечены сопоставления между символами в существующих устаревших наборах символов и символами в Unicode, чтобы облегчить преобразование в Unicode и обеспечить взаимодействие с устаревшим программным обеспечением. Отсутствие согласованности в различных сопоставлениях между более ранними японскими кодировками, такими как Shift-JIS или EUC-JP и Unicode, привело к преобразованию формата туда и обратно несоответствия, особенно отображение символа JIS X 0208 ‘～’ (1-33, WAVE DASH), активно используемого в данных устаревшей базы данных, в U + FF5E ～ ПОЛНОШИРИНЕВАЯ ТИЛЬДА (в Microsoft Windows ) или U + 301C 〜 WAVE DASH (другие поставщики).

Некоторые японские программисты возражали против Unicode, поскольку он требует, чтобы они разделяли использование U + 005C REVERSE SOLIDUS (обратная косая черта) и U + 00A5 ¥ YEN SIGN, который был сопоставлен с 0x5C в JIS X 0201, и с этим использованием существует много устаревшего кода. (Эта кодировка также заменяет тильду ‘~’ 0x7E на макрон ‘¯’, теперь 0xAF.) Разделение этих символов существует в ISO 8859-1, задолго до появления Unicode.

Индийским скриптам

Индийским скриптам, таким как Тамильский и Деванагари, каждому выделяется только 128 кодовых точек, что соответствует ISCII стандарт. Правильная визуализация индийского текста Unicode требует преобразования сохраненных символов логического порядка в визуальный порядок и формирования лигатур (или конъюнктов) из компонентов. Некоторые местные ученые высказывались в пользу присвоения кодовых точек Unicode этим лигатурам, что противоречит практике других систем письма, хотя Unicode содержит некоторые арабские и другие лигатуры только для целей обратной совместимости. Кодирование любых новых лигатур в Unicode не произойдет, отчасти потому, что набор лигатур зависит от шрифта, а Unicode — это кодировка, не зависящая от вариантов шрифта. Такая же проблема возникла для тибетского письма в 2003 году, когда Администрация по стандартизации Китая предложила кодировать 956 предварительно составленных тибетских слогов, но они были отклонены для кодирования соответствующим комитетом ISO (ISO / IEC JTC 1 / SC 2 ).

Поддержка тайского алфавита подверглась критике за упорядочение тайских символов. Гласные เ, แ, โ, ใ, ไ, которые пишутся слева от предшествующего согласного are in visual order instead of phonetic order, unlike the Unicode representations of other Indic scripts. This complication is due to Unicode inheriting the Thai Industrial Standard 620, which worked in the same way, and was the way in wh Их тайский язык всегда был написан на клавиатуре. Эта проблема упорядочивания немного усложняет процесс сопоставления Unicode, требуя поиска в таблице для изменения порядка тайских символов для сопоставления. Даже если бы Unicode принял кодировку в соответствии с порядком произнесения речи, все равно было бы проблематично сопоставить слова в словарном порядке. Например, слово แสดง «выполнять» начинается с группы согласных «สด» (с присущей согласной «ส» гласной), гласной แ — в устном порядке будет стоять после, но в словаре слово сравнивается так, как оно написано, с гласной, следующей за ส.

Объединение символов

Символы с диакритическими знаками обычно могут быть представлены либо как один предварительно составленный символ, либо как разложенная последовательность базовой буквы плюс один или несколько знаков без пробелов. Например, ḗ (предварительно составленный e с макроном и акромом выше) и ḗ (e, за которым следует объединяющий макрон выше и объединяющий акцент выше) должны отображаться одинаково, оба появляются как e с макроном. и с острым ударением, но на практике их внешний вид может варьироваться в зависимости от того, какой механизм визуализации и шрифты используются для отображения символов. Точно так же точки, необходимые в романизации для индийского, часто будут размещены неправильно. Во многих случаях могут использоваться символы Unicode, которые сопоставляются с предварительно составленными глифами., что позволяет избежать проблемы, но там, где заранее составленный символ не был закодирован, проблему часто можно решить, используя специальный шрифт Unicode, например Charis SIL, который использует Graphite, OpenType или AAT для расширенных функций рендеринга.

Аномалии

Стандарт Unicode установил правила, призванные гарантировать стабильность. В зависимости от строгости правила изменение может быть запрещено или разрешено. Например, «имя», данное кодовой точке, не может и не будет изменяться. Но свойство «скрипта» более гибкое по собственным правилам Unicode. В версии 2.0 Unicode изменил многие «имена» кодовой точки по сравнению с версией 1. В тот же момент Unicode заявил, что с этого момента присвоенное имя кодовой точке больше не будет меняться. Это означает, что, когда ошибки публикуются, эти ошибки не могут быть исправлены, даже если они тривиальны (как это произошло в одном случае с написанием BRAKCET вместо BRACKET в имени персонажа). В 2006 году был впервые опубликован список аномалий в именах персонажей, и по состоянию на апрель 2017 года насчитывалось 94 символа с выявленными проблемами, например:

• U + 2118 ℘ SCRIPT CAPITAL P : Это маленькая буква. Заглавная буква: U + 1D4AB 𝒫 МАТЕМАТИЧЕСКИЙ СКРИПТ P
• U + 034F ͏ COMBINING GRAPHEME JOINER : не объединяет графемы.
• U + A015 ꀕ YI SYLLABLE WU : Это не слог Yi, а знак итерации Yi.
• U + FE18 ︘ ФОРМА ПРЕЗЕНТАЦИИ ДЛЯ ВЕРТИКАЛЬНОГО ПРАВОГО БЕЛОГО ЛЕНТИКУЛЯРНОГО ТОРМОЗА: скобка написана неправильно. 967>Орфографические ошибки устраняются с помощью псевдонимов и сокращений Unicode.
  

  См. Также

  • Сравнение кодировок Unicode
  • Культурные, политические и религиозные символы в Unicode
  • Международные компоненты для Unicode (ICU), теперь как ICU- TC как часть Unicode
  • Список двоичных кодов
  • Список символов Unicode
  • Список ссылок на символы XML и HTML
  • Открытый исходный код Гарнитуры Unicode
  • Стандарты, относящиеся к Unicode
  • символы Unicode
  • Универсальный набор кодированных символов
  • Многобайтовый набор символов Lotus (LMBCS), параллельная разработка с аналогичными намерениями

  Примечания

  Ссылки

  Дополнительная литература

  • Яннис Хараламбус; Мартин Дюрст (2019). «Юникод с лингвистической точки зрения». В Хараламбусе, Яннис (ред.). Труды графемики в 21 веке, Брест, 2018. Брест: Издания Fluxus. С. 167–183. ISBN 978-2-9570549-1-6.

  Внешние ссылки

  • Официальный сайт ·Официальный технический сайт
  • Unicode по адресу Curlie
  • Ресурсы Юникода Алана Вуда — содержат списки текстовых процессоров с поддержкой Юникода; шрифты и символы сгруппированы по типу; символы представлены в виде списков, а не сетки.
  • Резервный шрифт Unicode BMP — отображает значение Unicode любого символа в документе, в том числе в области частного использования, а не сам глиф.

Представление символов в электронных
изданиях базируется на таблицах кодов,
в которых каждому из отображаемых на
экране символов соответствует код от
0 до 255. Первые 127 кодовых комбинаций
используются для латинских букв и цифр,
знаков пунктуации и т. д. и, как правило,
строятся по единому принципу.

Стандарт представления символов ASCII —
это 7-битовое описание кода символа.
Поскольку в персональных компьютерах
используются байты, состоящие из 8 бит,
производители компьютеров часто
определяют наборы символов, использующие
256 кодов вместо 128 кодов ASCII. В результате
получается «расширенный набор символов»
(extended character set), который включает в себя
набор символов ASCII и до 128 других символов.

Расширенный набор символов, который
Windows и программы для Windows в большинстве
случаев используют, называется набор
символов ANSI (ANSI character set), фактически он
является международным стандартом ISO.
Кодовая таблица стандарта ANSI представлена
на рис. 3.2.

В нашей стране кодовые комбинации
начиная со 128 используются для кодирования
символов кириллицы, математических
символов и другой информации. Причем
для каждой платформы используется свое
расположение символов в кодовой таблице.
Так, известны кодировки Windows, Mac, DOS-OS/2,
ISO (Dec) и КОИ-8. Поэтому приходится
осуществлять перекодировки символов
кириллицы электронных изданий в
зависимости от используемой платформы.

Стандарт кодировки символов UNICODE.
Стандарт Unicode был предложен некоммерческой
организацией Unicode Consortium, образованной
в 1991 г. Для представления каждого символа
в этом стандарте используются два байта:
один байт для кодирования символа,
другой для кодирования признака. Тем
самым обеспечивается информационная
совместимость данного способа кодирования
со стандартом ASСII.

Двухбайтовое описание кодов символов
позволяет закодировать очень большое
число символов из различных письменностей.
Так, в документах Unicode могут соседствовать
русские, латинские, греческие буквы,
китайские иероглифы и математические
символы.

Кодовое пространство Unicode разделено на
несколько областей. Область с кодами
от 0000 до 007F содержит символы набора
Latin 1 (младшие байты соответствуют
кодировке ISO 8859-1). Далее идут области, в
которых расположены знаки различных
письменностей, а также знаки пунктуации
и технические символы. Часть кодов
зарезервирована для использования в
будущем (29000). 6000 кодовых комбинаций
оставлено программистам.

3.3.2. Формат pdf

Формат PDF (Portable Document Format) — переносимый
формат документов, разработанный
компанией Adobe Systems, используется как
основа для создания электронных изданий
в среде программного пакета Adobe Acrobat.
Формат PDF — это файловый текстовой формат,
предназначенный для представления
публикаций или других документов на
любой аппаратной платформе и в любой
операционной среде. PDF-файл содержит
PDF-публикацию и специальные данные.

PDF-публикация (документ) содержит одну
или более страниц. Каждая страница может
включать любые компоненты электронного
издания: текст, графику и иллюстрации,
анимацию, видео- и аудиоинформацию в
аппаратно-независимом формате, в виде
так называемого страничного описания
(page description). PDF-публикация может также
содержать информацию, обеспечивающую
навигацию в гипертекстовой электронной
публикации.

Характерными особенностями PDF-файла
являются:

PDF-файл может содержать объекты, подобные
гипертекстовым ссылкам, доступные
только при интерактивном просмотре;

для упрощения процесса описания страниц
PDF не использует конструкции программных
языков;

PDF создает определенную структуру файла,
которая позволяет программным приложениям
иметь доступ к любой части документа;

PDF файл содержит информацию о размерах
шрифта и т.п.;

PDF-файл не может быть прямо преобразован
в PostScript-публикацию для печати;

PDF-файл строится на основе либо 7-битового
ASCII-файла, либо на базе бинарного файла.
Если это ASCII-файл, в нем используются
только печатные символы 7-битового
ASCII-кода, пробел, табуляция, возврат
каретки и перевод строки. В случае
бинарного файла могут быть использованы
все символы 8-битового кода. Считается,
что ASCII-код — наиболее удобный для переноса
вид кодировки.

Для уменьшения размера файла PDF использует
различные методы сжатия изображений:

JPEG — для полноцветных иллюстраций и
изображений в градациях серой шкалы;

CCITT — для черно-белых изображений;

LZW — для компрессии и декомпрессии
текстового материала.

Обычный PDF-файл содержит четыре раздела:

заголовок (header);

«тело файла» (body);

таблицу перекрестных ссылок (cross-reference
table);

trailer.

Информатика. 10 класса. Босова Л.Л. Оглавление

§14. Кодирование текстовой информации

Компьютеры третьего поколения «научились» работать с текстовой информацией.

Текстовая информация по своей природе дискретна, т. к. представляется последовательностью отдельных символов.

В памяти компьютера хранятся специальные кодовые таблицы, в которых для каждого символа указан его двоичный код. Все кодовые таблицы, используемые в любых компьютерах и любых операционных системах, подчиняются международным стандартам кодирования символов.

14.1. Кодировка ASCII и её расширения

Основой для компьютерных стандартов кодирования символов послужил код ASCII (American Standard Code for Information Interchange) — американский стандартный код для обмена информацией, разработанный в 1960-х годах в США и применявшийся для любых, в том числе и некомпьютерных, способов передачи информации (телеграф, факсимильная связь и т. д.). Этот код 7-битовый: общее количество символов составляет 2⁷ = 128, из них первые 32 символа — управляющие, а остальные — изображаемые, т. е. имеющие графическое изображение. К изображаемым символам в ASCII относятся буквы латинского алфавита (прописные и строчные), цифры, знаки препинания и арифметических операций, скобки и некоторые специальные символы. Кодировка ASCII приведена в табл. 3.8.

Таблица 3.8

Кодировка ASCII

Хотя для кодирования символов в ASCII достаточно 7 битов, в памяти компьютера под каждый символ отводится ровно 1 байт (8 битов), при этом код символа помещается в младшие биты, а в старший бит заносится 0.

Например, 01000001 — код прописной латинской буквы «А»; с помощью шестнадцатеричных цифр его можно записать как 41.

Стандарт ASCII рассчитан на передачу только английского текста. Со временем возникла необходимость кодирования и неанглийских букв. Во многих странах для этого стали разрабатывать расширения ASCII -кодировки, в которых применялись однобайтовые коды символов. При этом первые 128 символов кодовой таблицы совпадали с кодировкой ASCII, а остальные (со 128-го по 255-й) использовались для кодирования букв национального алфавита, символов национальной валюты и т. п. Из-за несогласованности этих разработок для многих языков было создано несколько вариантов кодовых таблиц (например, для русского языка их было создано около десятка!).

Впоследствии использование кодовых таблиц было несколько упорядочено: каждой кодовой таблице было присвоено особое название и номер. Для русского языка наиболее распространёнными стали однобайтовые кодовые таблицы CP-866, Windows-1251 (табл. 3.9) и КОИ-8 (табл. 3.10). В них первые 128 символов совпадают с ASCII-кодировкой, а русские буквы размещены во второй части таблицы. Обратите внимание на то, что коды русских букв в этих кодировках различны.

Таблица 3.9

Кодировка Windows-1251

Таблица 3.10

Кодировка КОИ-8

Мы выяснили, что при нажатии на алфавитно-цифровую клавишу в компьютер посылается некоторая цепочка нулей и единиц. В текстовых файлах хранятся не изображения символов, а их коды.

При выводе текста на экран монитора или принтера необходимо восстановить изображения всех символов, составляющих данный текст, причём изображения эти могут быть разнообразны и достаточно причудливы. Внешний вид выводимых на экран символов кодируется и хранится в специальных шрифтовых файлах. Современные текстовые процессоры умеют внедрять шрифты в файл. В этом случае файл содержит не только коды символов, но и описание используемых в этом документе шрифтов. Кроме того, файлы, создаваемые с помощью текстовых процессоров, включают в себя и такие данные о форматировании текста, как его размер, начертание, размеры полей, отступов, межстрочных интервалов и другую дополнительную информацию.

14.2. Стандарт Unicode

Ограниченность 8-битной кодировки, не позволяющей одновременно пользоваться несколькими языками, а также трудности, связанные с необходимостью преобразования одной кодировки в другую, привели к разработке нового кода. В 1991 году был разработан новый стандарт кодирования символов, получивший название Unicode (Юникод), позволяющий использовать в текстах любые символы любых языков мира.

Unicode — это «уникальный код для любого символа, независимо от платформы, независимо от программы, независимо от языка» (www.unicode.org).

В Unicode на кодирование символов отводится 31 бит. Первые 128 символов (коды 0-127) совпадают с таблицей ASCII. Далее размещены основные алфавиты современных языков: они полностью умещаются в первой части таблицы, их коды не превосходят 65 536 = 2¹⁶.

Стандарт Unicode описывает алфавиты всех известных, в том числе и «мёртвых», языков. Для языков, имеющих несколько алфавитов или вариантов написания (например, японского и индийского), закодированы все варианты. В кодировку Unicode внесены все математические и иные научные символьные обозначения и даже некоторые придуманные языки (например, язык эльфов из трилогии Дж. Р. Р. Толкина «Властелин колец»).

Всего современная версия Unicode позволяет закодировать более миллиона различных знаков, но реально используется чуть менее 110 000 кодовых позиций.

Для представления символов в памяти компьютера в стандарте Unicode имеется несколько кодировок.

В операционных системах семейства Windows используется кодировка UTF-16. В ней все наиболее важные символы кодируются с помощью 2 байт (16 бит), а редко используемые — с помощью 4 байт.

В операционной системе Linux применяется кодировка UTF-8, в которой символы могут занимать от 1 (символы, входящие в таблицу ASCII) до 4 байт. Если значительную часть текста составляют цифры и латинские буквы, то это позволяет в несколько раз уменьшить размер файла по сравнению с кодировкой UTF-16.

Кодировки Unicode позволяют включать в один документ символы самых разных языков, но их использование ведёт к увеличению размеров текстовых файлов.

14.3. Информационный объём текстового сообщения

Мы уже касались этого вопроса, рассматривая алфавитный подход к измерению информации.

Информационным объёмом текстового сообщения называется количество бит (байт, килобайт, мегабайт и т. д.), необходимых для записи этого сообщения путём заранее оговоренного способа двоичного кодирования.

Оценим в байтах объём текстовой информации в современном словаре иностранных слов из 740 страниц, если на одной странице размещается в среднем 60 строк по 80 символов (включая пробелы).

Будем считать, что при записи используется кодировка «один символ — один байт». Количество символов во всем словаре равно:

80 • 60 • 740 = 3 552 000.

Следовательно, объём равен

3 552 000 байт = 3 468,75 Кбайт ? 3,39 Мбайт.

Если же использовать кодировку UTF-16, то объём этой же текстовой информации в байтах возрастёт в 2 раза и составит 6,78 Мбайт.

САМОЕ ГЛАВНОЕ

Текстовая информация по своей природе дискретна, т. к. представляется последовательностью отдельных символов.

В памяти компьютера хранятся специальные кодовые таблицы, в которых для каждого символа указан его двоичный код. Все кодовые таблицы, используемые в любых компьютерах и любых операционных системах, подчиняются международным стандартам кодирования символов.

Основой для компьютерных стандартов кодирования символов послужил код ASCII, рассчитанный на передачу только английского текста. Расширения ASCII — кодировки, в которых первые 128 символов кодовой таблицы совпадают с кодировкой ASCII, а остальные (со 128-го по 255-й) используются для кодирования букв национального алфавита, символов национальной валюты и т. п.

В 1991 году был разработан новый стандарт кодирования символов, получивший название Unicode (Юникод), позволяющий использовать в текстах любые символы любых языков мира. Кодировки Unicode позволяют включать в один документ символы самых разных языков, но их использование ведёт к увеличению размеров текстовых файлов.

Вопросы и задания

1. Какова основная идея представления текстовой информации в компьютере?

2. Что представляет собой кодировка ASCII? Сколько символов она включает? Какие это символы?

3. Как известно, кодовые таблицы каждому символу алфавита ставят в соответствие его двоичный код. Как, в таком случае, вы можете объяснить вид таблицы 3.8 «Кодировка ASCII»?

4. С помощью таблицы 3.8: 1) декодируйте сообщение 64 65 73 6В 74 6F 70; 2) запишите в двоичном коде сообщение TOWER; 3) декодируйте сообщение 01101100 01100001 01110000 01110100 01101111 01110000

5. Что представляют собой расширения ASCII-кодировки? Назовите основные расширения ASCII-кодировки, содержащие русские буквы.

6. Сравните подходы к расположению русских букв в кодировках Windows-1251 и КОИ-8.

7. Представьте в кодировке Windows-1251 текст «Знание — сила!»:

8. Представьте в кодировке КОИ-8 текст «Дело в шляпе!»: 1) шестнадцатеричным кодом; 2) двоичным кодом; 3) десятичным кодом.

9. Что является содержимым файла, созданного в современном текстовом процессоре?

10. В кодировке Unicode на каждый символ отводится 2 байта. Определите в этой кодировке информационный объём следующей строки: Где родился, там и сгодился.

11. Набранный на компьютере текст содержит 2 страницы. На каждой странице 32 строки, в каждой строке 64 символа. Определите информационный объём текста в кодировке Unicode, в которой каждый символ кодируется 16 битами.

12. Текст на русском языке, первоначально записанный в 8-битовом коде Windows, был перекодирован в 16-битную кодировку Unicode. Известно, что этот текст был распечатан на 128 страницах, каждая из которых содержала 32 строки по 64 символа в каждой строке. Каков информационный объём этого текста?

13. В текстовом процессоре MS Word откройте таблицу символов (вкладка Вставка ? Символ ? Другие символы): В поле Шрифт установите Times New Roman, в поле из — кириллица (дес.). Вводя в поле Код знака десятичные коды символов, декодируйте сообщение

§ 13. Представление чисел в компьютере
§ 14. Кодирование текстовой информации
§ 15. Кодирование графической информации

Перейти к содержанию

Юнико́д^[1] или Унико́д^[2] (англ. Unicode) — стандарт кодирования символов, позволяющий представить знаки практически всех письменных языков.^[3]

Стандарт предложен в 1991 году некоммерческой организацией «Консорциум Юникода» (англ. Unicode Consortium, Unicode Inc.).^[4][5] Применение этого стандарта позволяет закодировать очень большое число символов из разных письменностей: в документах Unicode могут соседствовать китайские иероглифы, математические символы, буквы греческого алфавита, латиницы и кириллицы, при этом становится ненужным переключение кодовых страниц.^[6]

Стандарт состоит из двух основных разделов: универсальный набор символов (англ. UCS, universal character set) и семейство кодировок (англ. UTF, Unicode transformation format). Универсальный набор символов задаёт однозначное соответствие символов кодам — элементам кодового пространства, представляющим неотрицательные целые числа. Семейство кодировок определяет машинное представление последовательности кодов UCS.

Коды в стандарте Юникод разделены на несколько областей. Область с кодами от U+0000 до U+007F содержит символы набора ASCII с соответствующими кодами. Далее расположены области знаков различных письменностей, знаки пунктуации и технические символы. Часть кодов зарезервирована для использования в будущем.^[7] Под символы кириллицы выделены области знаков с кодами от U+0400 до U+052F, от U+2DE0 до U+2DFF, от U+A640 до U+A69F (см. Кириллица в Юникоде).^[8]

Предпосылки создания и развитие Юникода

К концу 1980-х годов стандартом стали 8-битные символы, при этом существовало множество разных 8-битных кодировок, и постоянно появлялись всё новые. Это объяснялось как постоянным расширением круга поддерживаемых языков, так и стремлением создать кодировку, частично совместимую с какой-нибудь другой (характерный пример — появление альтернативной кодировки для русского языка, обусловленное эксплуатацией западных программ, созданных для кодировки CP437). В результате появилось несколько проблем:

1. Проблема «кракозябр» (отображения документов в неправильной кодировке):^[6] её можно было решить либо последовательным внедрением методов указания используемой кодировки, либо внедрением единой для всех кодировки.
2. Проблема ограниченности набора символов:^[6] её можно было решить либо переключением шрифтов внутри документа, либо внедрением «широкой» кодировки. Переключение шрифтов издавна практиковалось в текстовых процессорах, причём часто использовались шрифты с нестандартной кодировкой, т. н. «dingbat fonts» — в итоге при попытке перенести документ в другую систему все нестандартные символы превращались в кракозябры.
3. Проблема преобразования одной кодировки в другую: её можно было решить либо составлением таблиц перекодировки для каждой пары кодировок, либо использованием промежуточного преобразования в третью кодировку, включающую все символы всех кодировок.^[9]
4. Проблема дублирования шрифтов: традиционно для каждой кодировки делался свой шрифт, даже если эти кодировки частично (или полностью) совпадали по набору символов: эту проблему можно было решить, делая «большие» шрифты, из которых потом выбираются нужные для данной кодировки символы — однако это требует создания единого реестра символов, чтобы определять, чему что соответствует.

Было признано необходимым создание единой «широкой» кодировки. Кодировки с переменной длиной символа, широко использующиеся в Восточной Азии, были признаны слишком сложными в использовании, поэтому было решено использовать символы фиксированной ширины. Использование 32-битных символов казалось слишком расточительным, поэтому было решено использовать 16-битные.

Таким образом, первая версия Юникода представляла собой кодировку с фиксированным размером символа в 16 бит, то есть общее число кодов было 2¹⁶ (65 536). Отсюда происходит практика обозначения символов четырьмя шестнадцатеричными цифрами (например, U+04F0). При этом в Юникоде планировалось кодировать не все существующие символы, а только те, которые необходимы в повседневном обиходе. Редко используемые символы должны были размещаться в «области пользовательских символов» (private use area), которая первоначально занимала коды U+D800…U+F8FF. Чтобы использовать Юникод также и в качестве промежуточного звена при преобразовании разных кодировок друг в друга, в него включили все символы, представленные во всех наиболее известных кодировках.

В дальнейшем, однако, было принято решение кодировать все символы и в связи с этим значительно расширить кодовую область. Одновременно с этим, коды символов стали рассматриваться не как 16-битные значения, а как абстрактные числа, которые в компьютере могут представляться множеством разных способов (см. Способы представления).

Поскольку в ряде компьютерных систем (например, Windows NT^[10]) фиксированные 16-битные символы уже использовались в качестве кодировки по умолчанию, было решено все наиболее важные знаки кодировать только в пределах первых 65 536 позиций (так называемая англ. basic multilingual plane, BMP). Остальное пространство используется для «дополнительных символов» (англ. supplementary characters): систем письма вымерших языков или очень редко используемых китайских иероглифов, математических и музыкальных символов.

Для совместимости со старыми 16-битными системами была изобретена система UTF-16, где первые 65 536 позиций, за исключением позиций из интервала U+D800…U+DFFF, отображаются непосредственно как 16-битные числа, а остальные представляются в виде «суррогатных пар» (первый элемент пары из области U+D800…U+DBFF, второй элемент пары из области U+DC00…U+DFFF). Для суррогатных пар была использована часть кодового пространства (2048 позиций), ранее отведённого для «символов для частного использования».

Поскольку в UTF-16 можно отобразить только 2²⁰+2¹⁶−2048 (1 112 064) символов, то это число и было выбрано в качестве окончательной величины кодового пространства Юникода.

Хотя кодовая область Юникода была расширена за пределы 2¹⁶ уже в версии 2.0, первые символы в «верхней» области были размещены только в версии 3.1.

Роль этой кодировки в веб-секторе постоянно растёт, на начало 2010 доля веб-сайтов, использующих Юникод, составила около 50 %.^[11]

Версии Юникода

По мере изменения и пополнения таблицы символов системы Юникода и выхода новых версий этой системы, — а эта работа ведётся постоянно, поскольку изначально система Юникод включала только Plane 0 — двухбайтные коды, — выходят и новые документы ISO. Система Юникод существует в общей сложности в следующих версиях:

• 1.1 (соответствует стандарту ISO/IEC 10646—1:1993), стандарт 1991—1995 годов.
• 2.0, 2.1 (тот же стандарт ISO/IEC 10646—1:1993 плюс дополнения: «Amendments» с 1-го по 7-е и «Technical Corrigenda» 1 и 2), стандарт 1996 года.
• 3.0 (стандарт ISO/IEC 10646—1:2000), стандарт 2000 года.
• 3.1 (стандарты ISO/IEC 10646-1:2000 и ISO/IEC 10646-2:2001), стандарт 2001 года.
• 3.2, стандарт 2002 года.
• 4.0, стандарт 2003.
• 4.01, стандарт 2004.
• 4.1, стандарт 2005.
• 5.0, стандарт 2006.
• 5.1, стандарт 2008.
• 5.2, стандарт 2009.
• 6.0, стандарт 2010.
• 6.1, стандарт 2012.
• 6.2, стандарт 2012.

Кодовое пространство

Хотя формы записи UTF-8 и UTF-32 позволяют кодировать до 2³¹ (2 147 483 648) кодовых позиций, было принято решение использовать лишь 1 112 064 для совместимости с UTF-16. Впрочем, даже и этого более чем достаточно — сегодня (в версии 6.0) используется чуть менее 110 000 кодовых позиций (109 242 графических и 273 прочих символов).

Кодовое пространство разбито на 17 плоскостей по 2¹⁶ (65536) символов. Нулевая плоскость называется базовой, в ней расположены символы наиболее употребительных письменностей. Первая плоскость используется, в основном, для исторических письменностей, вторая — для редко используемых иероглифов ККЯ, третья зарезервирована для архаичных китайских иероглифов^[12]. Плоскости 15 и 16 выделены для частного употребления.^[7]

Для обозначения символов Unicode используется запись вида «U+xxxx» (для кодов 0…FFFF), или «U+xxxxx» (для кодов 10000…FFFFF), или «U+xxxxxx» (для кодов 100000…10FFFF), где xxx — шестнадцатеричные цифры. Например, символ «я» (U+044F) имеет код 044F₁₆ = 1103₁₀.

Система кодирования

Универсальная система кодирования (Юникод) представляет собой набор графических символов и способ их кодирования для компьютерной обработки текстовых данных.

Графические символы — это символы, имеющие видимое изображение. Графическим символам противопоставляются управляющие символы и символы форматирования.

Графические символы включают в себя следующие группы:

• буквы, содержащиеся хотя бы в одном из обслуживаемых алфавитов;
• цифры;
• знаки пунктуации;
• специальные знаки (математические, технические, идеограммы и пр.);
• разделители.

Юникод — это система для линейного представления текста. Символы, имеющие дополнительные над- или подстрочные элементы, могут быть представлены в виде построенной по определённым правилам последовательности кодов (составной вариант, composite character) или в виде единого символа (монолитный вариант, precomposed character).

Модифицирующие символы

Графические символы в Юникоде подразделяются на протяжённые и непротяжённые (бесширинные). Непротяжённые символы при отображении не занимают места в строке. К ним относятся, в частности, знаки ударения и прочие диакритические знаки. Как протяжённые, так и непротяжённые символы имеют собственные коды. Протяжённые символы иначе называются базовыми (англ. base characters), а непротяжённые — модифицирующими (англ. combining characters); причём последние не могут встречаться самостоятельно. Например, символ «á» может быть представлен как последовательность базового символа «a» (U+0061) и модифицирующего символа « ́» (U+0301) или как монолитный символ «á» (U+00C1).

Особый тип модифицирующих символов — селекторы варианта начертания (англ. variation selectors). Они действуют только на те символы, для которых такие варианты определены. В версии 5.0 варианты начертания определены для ряда математических символов, для символов традиционного монгольского алфавита и для символов монгольского квадратного письма.

Формы нормализации

Поскольку одни и те же символы можно представить различными кодами, что иногда затрудняет обработку, существуют процессы нормализации, предназначенные для приведения текста к определённому стандартному виду.

В стандарте Юникода определены 4 формы нормализации текста:

• Форма нормализации D (NFD) — каноническая декомпозиция. В процессе приведения текста в эту форму все составные символы рекурсивно заменяются на несколько составных, в соответствии с таблицами декомпозиции.
• Форма нормализации C (NFC) — каноническая декомпозиция с последующей канонической композицией. Сначала текст приводится к форме D, после чего выполняется каноническая композиция — текст обрабатывается от начала к концу и выполняются следующие правила:
  • Символ S является начальным, если он имеет нулевой класс модификации в базе символов Юникода.
  • В любой последовательности символов, стартующей с начального символа S, символ C блокируется от S, если и только если между S и C есть какой-либо символ B, который или является начальным, или имеет одинаковый или больший класс модификации, чем C. Это правило распространяется только на строки, прошедшие каноническую декомпозицию.
  • Первичным композитом считается символ, у которого есть каноническая декомпозиция в базе символов Юникода (или каноническая декомпозиция для хангыля и он не входит в список исключений).
  • Символ X может быть первично совмещён с символом Y, если и только если существует первичный композит Z, канонически эквивалентный последовательности <X, Y>.
  • Если очередной символ C не блокируется последним встреченным начальным базовым символом L и он может быть успешно первично совмещён с ним, то L заменяется на композит L-C, а C удаляется.
• Форма нормализации KD (NFKD) — совместимая декомпозиция. При приведении в эту форму все составные символы заменяются, используя как канонические карты декомпозиции Юникода, так и совместимые карты декомпозиции, после чего результат ставится в каноническом порядке.
• Форма нормализации KC (NFKC) — совместимая декомпозиция с последующей канонической композицией.

Термины «композиция» и «декомпозиция» понимают под собой соответственно соединение или разложение символов на составные части.

Примеры

Двунаправленное письмо

Стандарт Юникод поддерживает письменности языков как с направлением написания слева направо (англ. left-to-right, LTR), так и с написанием справа налево (англ. right-to-left, RTL) — например, арабское и еврейское письмо. В обоих случаях символы хранятся в «естественном» порядке; их отображение с учётом нужного направления письма обеспечивается приложением.

Кроме того, Юникод поддерживает комбинированные тексты, сочетающие фрагменты с разным направлением письма. Данная возможность называется двунаправленность (англ. bidirectional text, BiDi). Некоторые упрощённые обработчики текста (например, в сотовых телефонах) могут поддерживать Юникод, но не иметь поддержки двунаправленности. Все символы Юникода поделены на несколько категорий: пишущиеся слева направо, пишущиеся справа налево, и пишущиеся в любом направлении. Символы последней категории (в основном это знаки пунктуации) при отображении принимают направление окружающего их текста.

Представленные символы

Юникод включает практически все современные письменности, в том числе:

и другие.

С академическими целями добавлены многие исторические письменности, в том числе: руны, древнегреческая, египетские иероглифы, клинопись, письменность майя, этрусский алфавит.

В Юникоде представлен широкий набор математических и музыкальных символов, а также пиктограмм.

Однако в Юникод принципиально не включаются логотипы компаний и продуктов, хотя они и встречаются в шрифтах (например, логотип Apple в кодировке MacRoman (0xF0) или логотип Windows в шрифте Wingdings (0xFF)). В юникодовских шрифтах логотипы должны размещаться только в области пользовательских символов.

ISO/IEC 10646

Консорциум Юникода работает в тесной связи с рабочей группой ISO/IEC/JTC1/SC2/WG2, которая занимается разработкой международного стандарта 10646 (ISO/IEC 10646). Между стандартом Юникода и ISO/IEC 10646 установлена синхронизация, хотя каждый стандарт использует свою терминологию и систему документации.

Сотрудничество Консорциума Юникода с Международной организацией по стандартизации (англ. International Organization for Standardization, ISO) началось в 1991 году. В 1993 году ISO выпустила стандарт DIS 10646.1. Для синхронизации с ним Консорциум утвердил стандарт Юникода версии 1.1, в который были внесены дополнительные символы из DIS 10646.1. В результате значения закодированных символов в Unicode 1.1 и DIS 10646.1 полностью совпали.

В дальнейшем сотрудничество двух организаций продолжилось. В 2000 году стандарт Unicode 3.0 был синхронизирован с ISO/IEC 10646-1:2000. Предстоящая третья версия ISO/IEC 10646 будет синхронизирована с Unicode 4.0. Возможно, эти спецификации даже будут опубликованы как единый стандарт.

Аналогично форматам UTF-16 и UTF-32 в стандарте Юникода, стандарт ISO/IEC 10646 также имеет две основные формы кодирования символов: UCS-2 (2 байта на символ, аналогично UTF-16) и UCS-4 (4 байта на символ, аналогично UTF-32). UCS значит универсальный многооктетный (многобайтовый) кодированный набор символов (англ. universal multiple-octet coded character set). UCS-2 можно считать подмножеством UTF-16 (UTF-16 без суррогатных пар), а UCS-4 является синонимом для UTF-32.

Способы представления

Юникод имеет несколько форм представления (англ. Unicode transformation format, UTF): UTF-8, UTF-16 (UTF-16BE, UTF-16LE) и UTF-32 (UTF-32BE, UTF-32LE). Была разработана также форма представления UTF-7 для передачи по семибитным каналам, но из-за несовместимости с ASCII она не получила распространения и не включена в стандарт. 1 апреля 2005 года были предложены две шуточные формы представления: UTF-9 и UTF-18 (RFC 4042).

В Microsoft Windows NT и основанных на ней системах Windows 2000 и Windows XP в основном используется форма UTF-16LE. В UNIX-подобных операционных системах GNU/Linux, BSD и Mac OS X принята форма UTF-8 для файлов и UTF-32 или UTF-8 для обработки символов в оперативной памяти.

Punycode — другая форма кодирования последовательностей Unicode-символов в так называемые ACE-последовательности, которые состоят только из алфавитно-цифровых символов, как это разрешено в доменных именах.

UTF-8

Основная статья: UTF-8

UTF-8 — представление Юникода, обеспечивающее наилучшую совместимость со старыми системами, использовавшими 8-битные символы. Текст, состоящий только из символов с номером меньше 128, при записи в UTF-8 превращается в обычный текст ASCII. И наоборот, в тексте UTF-8 любой байт со значением меньше 128 изображает символ ASCII с тем же кодом. Остальные символы Юникода изображаются последовательностями длиной от 2 до 6 байт (на деле, только до 4 байт, поскольку в Юникоде нет символов с кодом больше 10FFFF, и вводить их в будущем не планируется), в которых первый байт всегда имеет вид 11xxxxxx, а остальные — 10xxxxxx.

Формат UTF-8 был изобретён 2 сентября 1992 года Кеном Томпсоном и Робом Пайком и реализован в Plan 9^[13]. Сейчас стандарт UTF-8 официально закреплён в документах RFC 3629 и ISO/IEC 10646 Annex D.

Символы UTF-8 получаются из Unicode следующим образом:

Unicode UTF-8:
0x00000000 — 0x0000007F: 0xxxxxxx
0x00000080 — 0x000007FF: 110xxxxx 10xxxxxx
0x00000800 — 0x0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx
0x00010000 — 0x001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

Теоретически возможны, но не включены в стандарт также:

0x00200000 — 0x03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
0x04000000 — 0x7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

Несмотря на то, что UTF-8 позволяет указать один и тот же символ несколькими способами, только наиболее короткий из них правильный. Остальные формы должны отвергаться по соображениям безопасности.

Порядок байтов

В потоке данных UTF-16 старший байт может записываться либо перед младшим (англ. UTF-16 big-endian), либо после младшего (англ. UTF-16 little-endian). Аналогично существует два варианта четырёхбайтной кодировки — UTF-32BE и UTF-32LE.

Для определения формата представления Юникода в начало текстового файла записывается сигнатура — символ U+FEFF (неразрывный пробел с нулевой шириной), также именуемый меткой порядка байтов (англ. byte order mark, BOM). Это позволяет различать UTF-16LE и UTF-16BE, поскольку символа U+FFFE не существует. Также этот способ иногда применяется для обозначения формата UTF-8, хотя к этому формату и неприменимо понятие порядка байтов. Файлы, следующие этому соглашению, начинаются с таких последовательностей байтов:

UTF-8 

EF BB BF

UTF-16BE 

FE FF

UTF-16LE 

FF FE

UTF-32BE 

00 00 FE FF

UTF-32LE 

FF FE 00 00

К сожалению, этот способ не позволяет надёжно различать UTF-16LE и UTF-32LE, поскольку символ U+0000 допускается Юникодом (хотя реальные тексты редко начинаются с него).

Файлы в кодировках UTF-16 и UTF-32, не содержащие BOM, должны иметь порядок байтов big-endian (unicode.org).

Юникод и традиционные кодировки

Внедрение Юникода привело к изменению подхода к традиционным 8-битным кодировкам. Если раньше кодировка задавалась шрифтом, то теперь она задаётся таблицей соответствия между данной кодировкой и Юникодом. Фактически 8-битные кодировки превратились в форму представления некоторого подмножества Юникода. Это намного упростило создание программ, которые должны работать с множеством разных кодировок: теперь, чтобы добавить поддержку ещё одной кодировки, надо всего лишь добавить ещё одну таблицу перекодировки в Юникод.

Кроме того, многие форматы данных позволяют вставлять любые символы Юникода, даже если документ записан в старой 8-битной кодировке. Например, в HTML можно использовать коды с амперсандом.

Реализации

Большинство современных операционных систем в той или иной степени обеспечивают поддержку Юникода.

В операционных системах семейства Windows NT для внутреннего представления имён файлов и других системных строк используется двухбайтовая кодировка UTF-16LE. Системные вызовы, принимающие строковые параметры, существуют в однобайтном и двухбайтном вариантах. Подробнее см. в статье Юникод в операционных системах Microsoft.

UNIX-подобные операционные системы, в том числе GNU/Linux, BSD, Mac OS X, используют для представления Юникода кодировку UTF-8. Большинство программ могут работать с UTF-8 как с традиционными однобайтными кодировками, не обращая внимания на то, что символ представляется как несколько последовательных байт. Для работы с отдельными символами строки обычно перекодируются в UCS-4, так что каждому символу соответствует машинное слово.

Одной из первых успешных коммерческих реализаций Юникода стала среда программирования Java. В ней принципиально отказались от 8-битного представления символов в пользу 16-битного. Сейчас большинство языков программирования поддерживают строки Юникода, хотя их представление может различаться в зависимости от реализации.

Методы ввода

Поскольку ни одна раскладка клавиатуры не может позволить вводить все символы Юникода одновременно, от операционных систем и прикладных программ требуется поддержка альтернативных методов ввода произвольных символов Юникода.

Microsoft Windows

Начиная с Windows 2000, служебная программа «Таблица символов» (charmap.exe) показывает все символы в ОС и позволяет копировать их в буфер обмена. Похожая таблица есть, например, в Microsoft Word.

Иногда можно набрать шестнадцатеричный код, нажать Alt+X, и код будет заменён на соответствующий символ, например, в WordPad, Microsoft Word. В редакторах Alt+X выполняет и обратное преобразование.

Во многих программах MS Windows, чтобы получить символ Unicode, нужно при нажатой клавише Alt набрать десятичное значение кода символа на цифровой клавиатуре. Например, полезными при наборе кириллических текстов будут комбинации Alt+0171 («) и Alt+0187 (»). Интересны также комбинации Alt+0133 (…) и Alt+0151 (—).

Macintosh

В Mac OS 8.5 и более поздних версиях поддерживается метод ввода, называемый «Unicode Hex Input». При зажатой клавише Option требуется набрать четырёхзначный шестнадцатеричный код требуемого символа. Этот метод позволяет вводить символы с кодами, большими U+FFFF, используя пары суррогатов; такие пары операционной системой будут автоматически заменены на одиночные символы. Этот метод ввода перед использованием нужно активизировать в соответствующем разделе системных настроек и затем выбрать как текущий метод ввода в меню клавиатуры.

Начиная с Mac OS X 10.2, существует также приложение «Character Palette», позволяющее выбирать символы из таблицы, в которой можно выделять символы определённого блока или символы, поддерживаемые конкретным шрифтом.

GNU/Linux

В GNOME также есть утилита «Таблица символов», позволяющая отображать символы определённого блока или системы письма и предоставляющая возможность поиска по названию или описанию символа. Когда код нужного символа известен, его можно ввести в соответствии со стандартом ISO 14755: при зажатых клавишах Ctrl и Shift ввести шестнадцатеричный код (начиная с некоторой версии GTK+ ввод кода нужно предварить нажатием клавиши «U»). Вводимый шестнадцатеричный код может иметь до 32 бит в длину, позволяя вводить любые символы Юникода без использования суррогатных пар.

Все приложения X Window, включая GNOME и KDE, поддерживают ввод при помощи клавиши Compose. Для клавиатур, на которых нет отдельной клавиши Compose, для этой цели можно назначить любую клавишу — например, Caps Lock.

Консоль GNU/Linux также допускает ввод символа Юникода по его коду — для этого десятичный код символа нужно ввести цифрами расширенного блока клавиатуры при зажатой клавише Alt. Можно вводить символы и по их шестнадцатеричному коду: для этого нужно зажать клавишу AltGr, и для ввода цифр A—F использовать клавиши расширенного блока клавиатуры от NumLock до Enter (по часовой стрелке). Поддерживается также и ввод в соответствии с ISO 14755. Для того чтобы перечисленные способы могли работать, нужно включить в консоли режим Юникода вызовом unicode_start(1) и выбрать подходящий шрифт вызовом setfont(8).

Mozilla Firefox для Linux поддерживает ввод символов по ISO 14755.

Проблемы Юникода

В Юникоде английское «a» и польское «a» — один и тот же символ. Точно так же одним символом (но отличающимся от «a» латинского) считаются русское «а» и сербское «а». Такой принцип кодирования не универсален; по-видимому, решения «на все случаи жизни» вообще не может существовать.

• Тексты на китайском, корейском и японском языке имеют традиционное написание сверху вниз, начиная с правого верхнего угла. Переключение горизонтального и вертикального написания для этих языков не предусмотрено в Юникоде — это должно осуществляться средствами языков разметки или внутренними механизмами текстовых процессоров.
• Юникод предусматривает возможность разных начертаний одного и того же символа в зависимости от языка. Так, китайские иероглифы могут иметь разные начертания в китайском, японском (кандзи) и корейском (ханча), но при этом в Юникоде обозначаться одним и тем же символом (так называемая CJK-унификация), хотя упрощённые и полные иероглифы всё же имеют разные коды. Часто возникают накладки, когда, например, японский текст выглядит «по-китайски». Аналогично, русский и сербский языки используют разное начертание курсивных букв п и т (в сербском они выглядят как и и ш, см. сербский курсив). Поэтому нужно следить, чтобы текст всегда был правильно помечен как относящийся к тому или другому языку.
• Перевод из строчных букв в заглавные тоже зависит от языка. Например: в турецком существуют буквы İi и Iı — таким образом, турецкие правила изменения регистра конфликтуют с английскими, которые предписывают «i» переводить в «I». Подобные проблемы есть и в других языках — например, в канадском диалекте французского языка регистр переводится немного не так, как во Франции.^[14]
• Даже с арабскими цифрами есть определённые типографские тонкости: цифры бывают «прописными» и «строчными», пропорциональными и моноширинными^[15] — для Юникода разницы между ними нет. Подобные нюансы остаются за программным обеспечением.

Некоторые недостатки связаны не с самим Юникодом, а с возможностями обработчиков текста.

• Файлы неанглийского текста в Юникоде всегда занимают больше места, так как один символ кодируется не одним байтом, как в различных национальных кодировках, а последовательностью байтов (исключение составляет UTF-8 для языков, алфавит которых укладывается в ASCII, а также наличие в тексте символов двух и более языков, алфавит которых не укладывается в ASCII^[16]). Файл шрифта, необходимый для отображения всех символов таблицы Юникод, занимает сравнительно много места в памяти и требует бо́льших вычислительных ресурсов, чем шрифт только одного национального языка пользователя^[17]. С увеличением мощности компьютерных систем и удешевлением памяти и дискового пространства эта проблема становится всё менее существенной; тем не менее, она остаётся и в ближайшем будущем останется актуальной для портативных устройств, например, для мобильного телефона^[18].
• Хотя поддержка Юникода реализована в наиболее распространённых операционных системах, до сих пор не всё прикладное программное обеспечение поддерживает корректную работу с ним. В частности, не всегда обрабатываются метки порядка байтов (BOM) и плохо поддерживаются диакритические символы. Проблема является временной и есть следствие сравнительной новизны стандартов Юникода (в сравнении с однобайтовыми национальными кодировками).
• Производительность всех программ обработки строк (в том числе и сортировок в БД) снижается при использовании Юникода вместо однобайтовых кодировок.
• Философия UNIX (перенаправление ввода-вывода из одной программы в другую) неявно подразумевает, что минимальная единица ввода-вывода — байт — совпадает с одним символом текста. Поэтому UNIX-подобные ОС перешли на Unicode (UTF-8) относительно поздно.

Первоначальная версия Юникода предполагала наличие большого количества готовых символов, в последующем было отдано предпочтение сочетанию букв с диакритическими модифицирующими знаками (англ. combining diacritics). Например, русские буквы Ё (U+0401) и Й (U+0419) существуют в виде монолитных символов, хотя могут быть представлены и набором базового символа с последующим диакритическим знаком, то есть в составной форме (англ. decomposed): Е+  ̈ (U+0415 U+0308), И+  ̆ (U+0418 U+0306). В то же время множество символов из языков с алфавитами на основе кириллицы не имеют монолитных форм.

Наконец, некоторые редкие системы письма всё ещё не представлены должным образом в Юникоде. Изображение «длинных» надстрочных символов, простирающихся над несколькими буквами, как, например, в церковнославянском языке, пока не реализовано.

«Юникод» или «Уникод»?

«Unicode» — одновременно и имя собственное (или часть имени, например, Unicode Consortium), и имя нарицательное, происходящее из английского языка.

На первый взгляд предпочтительнее использовать написание «Уникод». В русском языке уже есть морфемы «уни-» (слова с латинским элементом «uni-» традиционно переводились и писались через «уни-»: универсальный, униполярный, унификация, униформа) и «код». Напротив, торговые марки, заимствованные из английского языка, обычно передаются посредством практической транскрипции, в которой деэтимологизированное сочетание букв «uni-» записывается в виде «юни-» («Юнилевер», «Юникс» и т. п.), то есть точно так же, как в случае с побуквенными сокращениями, вроде UNICEF «United Nations International Children’s Emergency Fund» — ЮНИСЕФ.

Написание «Юникод» уже твёрдо вошло в русскоязычные тексты. Согласно «Яндексу», частота использования этого слова примерно в 11 раз превышает «Уникод»^[19]. В Википедии используется более распространённый вариант.

На сайте Консорциума есть специальная страница, где рассматриваются проблемы передачи слова «Unicode» в различных языках и системах письма. Для русской кириллицы указан вариант «Юникод»^[1].

Формы, принятые иностранными организациями для русской передачи слова «Unicode», являются рекомендательными.

См. также

• Символы, представленные в Юникоде
• ASCII
• ISO 8859-1
• UTF-8
• Кириллица в Юникоде
• Дроби в Юникоде
• XeTeX
• Шрифты, поддерживающие юникод
• Свободные универсальные шрифты
• Windows Glyph List 4
• Широкий символ

• Проект:Внесение символов алфавитов народов России в Юникод

Примечания

Ссылки

• Официальный сайт Консорциума Юникода  (англ.)
• Unicode в каталоге ссылок Open Directory Project (dmoz).  (англ.)
• Что такое Unicode?  (рус.)
• Последняя версия [1] стандарта Юникод  (англ.)
• Таблица символов Юникода с названиями и описаниями  (рус.)  (англ.)
• Связь Юникода и ISO/IEC 10646 (файл PDF)  (англ.)
• FAQ по UTF-8 и Unicode  (англ.)
• Кириллица в Юникоде: [2], [3], [4], [5] (файлы PDF)  (англ.)
• DecodeUnicode — Unicode WIKI (50 000 изображений символов)  (англ.)
• Включение поддержки дополнительных символов Юникода в Windows  (англ.)
• Поиск по символам Юникода  (англ.)

Стандарты ISO
Перечни:  Перечень стандартов ИСО • Перечень романизаций ISO • Перечень стандартов IEC Категории:  Категория:Стандарты ISO • Категория:Протоколы OSI
1 по 9999	1 • 2 • 3 • 4 • 5 • 6 • 7 • 9 • 16 • 31 (-0, -1, -2, -3, -4, -5, -6, -7, -8, -9, -10, -11, -12, -13) • 128 • 216 • 217 • 226 • 228 • 233 • 259 • 269 • 296 • 302 • 306 • 428 • 639 (-1, -2, -3, -5, -6) • 646 • 690 • 732 • 764 • 843 • 898 • 1000 • 1004 • 1007 • 1073-1 • 1413 • 1538 • 1745 • 2014 • 2015 • 2022 • 2108 • 2145 • 2146 • 2281 • 2709 • 2711 • 2788 • 3029 • 3103 • 3166 (-1, -2, -3) • 3297 • 3307 • 3602 • 3864 • 3901 • 3977 • 4031 • 4157 • 4217 • 5218 • 5775 • 5776 • 5964 • 6166 • 6344 • 6346 • 6425 • 6429 • 6438 • 6523 • 6709 • 7001 • 7002 • 7098 • 7185 • 7388 • 7498 • 7736 • 7810 • 7811 • 7812 • 7813 • 7816 • 8000 • 8217 • 8571 • 8583 • 8601 • 8632 • 8652 • 8691 • 8807 • 8820-5 • 8859 (-1, -2, -3, -4, -5, -6, -7, -8, -9, -10, -11, -12, -13, -14, -15, -16) • 8879 • 9000 • 9075 • 9126 • 9241 • 9362 • 9407 • 9506 • 9529 • 9564 • 9594 • 9660 • 9897 • 9945 • 9984 • 9985 • 9995
10000 по 19999	10006 • 10118-3 • 10160 • 10161 • 10165 • 10179 • 10206 • 10303 • 10303-11 • 10303-21 • 10303-22 • 10303-238 • 10303-28 • 10383 • 10487 • 10585 • 10589 • 10646 • 10664 • 10746 • 10861 • 10957 • 10962 • 10967 • 11073 • 11170 • 11179 • 11404 • 11544 • 11783 • 11784 • 11785 • 11801 • 11898 • 11940 • 11941 • 11941 (TR) • 11992 • 12006 • 12164 • 12182:1998 • 12207:1995 • 12207:2008 • 12234-2 • 13211 (-1, -2) • 13216 • 13250 • 13399 • 13406-2 • 13407 • 13450 • 13485 • 13490 • 13567 • 13568 • 13584 • 13616 • 14000 • 14031 • 14396 • 14443 • 14496-10 • 14496-14 • 14644 (-1, -2, -3, -4, -5, -6, -7, -8, -9) • 14649 • 14651 • 14698 • 14698-2 • 14750 • 14882 • 14971 • 15022 • 15189 • 15288 • 15291 • 15292 • 15408 • 15444 • 15445 • 15438 • 15504 • 15511 • 15686 • 15693 • 15706 • 15706-2 • 15707 • 15897 • 15919 • 15924 • 15926 • 15926 WIP • 15930 • 16023 • 16262 • 16750 • 17024 • 17025 • 17369 • 17799 • 18000 • 18004 • 18014 • 18245 • 18629 • 18916 • 19005 • 19011 • 19092-1 • 19092-2 • 19114 • 19115 • 19439 • 19501:2005 • 19752 • 19757 • 19770 • 19775-1 • 19794-5
20000+	20000 • 20022 • 21000 • 21047 • 21827:2002 • 22000 • 23008-2 • 23270 • 23360 • 24613 • 24707 • 25178 • 26000 • 26300 • 26324 • 27000 series • 27000 • 27001 • 27002 • 27003 • 27004 • 27005 • 27006 • 27007 • 27729 • 27799 • 29199-2 • 29500 • 31000 • 32000 • 38500 • 42010 • 50001 • 80000
См. также: Все статьи, начинающиеся с «ISO»