Unicode в windows utf 16

1. ^ Found under control panel, «Region» entry, «Administrative» tab, «Change system locale» button.

1. ^ ^{a b c} «Use UTF-8 code pages in Windows apps». learn.microsoft.com. Retrieved 2020-06-06. As of Windows version 1903 (May 2019 update), you can use the ActiveCodePage property in the appxmanifest for packaged apps, or the fusion manifest for unpackaged apps, to force a process to use UTF-8 as the process code page. […] CP_ACP equates to CP_UTF8 only if running on Windows version 1903 (May 2019 update) or above and the ActiveCodePage property described above is set to UTF-8. Otherwise, it honors the legacy system code page. We recommend using CP_UTF8 explicitly.
2. ^ ^{a b} «UTF-8 support in the Microsoft Game Development Kit (GDK) — Microsoft Game Development Kit». learn.microsoft.com. 19 August 2022. Retrieved 2023-03-05. By operating in UTF-8, you can ensure maximum compatibility [..] Windows operates natively in UTF-16 (or WCHAR), which requires code page conversions by using MultiByteToWideChar and WideCharToMultiByte. This is a unique burden that Windows places on code that targets multiple platforms. [..] The Microsoft Game Development Kit (GDK) and Windows in general are moving forward to support UTF-8 to remove this unique burden of Windows on code targeting or interchanging with multiple platforms and the web. Also, this results in fewer internationalization issues in apps and games and reduces the test matrix that’s required to get it right.
3. ^ «Unicode in the Windows API». Retrieved 7 May 2018.
4. ^ «Conventions for Function Prototypes (Windows)». MSDN. Retrieved 7 May 2018.
5. ^ «Support for Multibyte Character Sets (MBCSs)». Retrieved 2020-06-15.
6. ^ «Double-byte Character Sets». MSDN. 2018-05-31. Retrieved 2020-06-15. our applications use DBCS Windows code pages with the «A» versions of Windows functions.
7. ^ _strrev, _wcsrev, _mbsrev, _mbsrev_l Microsoft Docs
8. ^ «Differences Between the Windows CE and Windows NT Implementations of TAPI». MSDN. 28 August 2006. Retrieved 7 May 2018. Windows CE is Unicode-based. You might have to recompile source code that was written for a Windows NT-based application.
9. ^ «Code Pages (Windows CE 5.0)». Microsoft Docs. 14 September 2012. Retrieved 7 May 2018.
10. ^ «Code Page Identifiers (Windows)». msdn.microsoft.com. 7 January 2021.
11. ^ «UTF-8 in Windows». Stack Overflow. Retrieved July 1, 2011.
12. ^ «Boost.Nowide». GitHub.
13. ^ «Windows10 Insider Preview Build 17035 Supports UTF-8 as ANSI». Hacker News. Retrieved 7 May 2018.
14. ^ «Windows 10 1903 and later versions finally support UTF-8 with the A forms of the Win32 functions».
15. ^ «Customize the Windows 11 Start menu». docs.microsoft.com. Retrieved 2021-06-29. Make sure your LayoutModification.json uses UTF-8 encoding.
16. ^ «Introducing UTF-8 support for SQL Server». techcommunity.microsoft.com. 2019-07-02. Retrieved 2021-08-24. For example, changing an existing column data type from NCHAR(10) to CHAR(10) using an UTF-8 enabled collation, translates into nearly 50% reduction in storage requirements. [..] In the ASCII range, when doing intensive read/write I/O on UTF-8, we measured an average 35% performance improvement over UTF-16 using clustered tables with a non-clustered index on the string column, and an average 11% performance improvement over UTF-16 using a heap.
17. ^ UTF-8 Everywhere FAQ: How do I write UTF-8 string literal in my C++ code?

History

In the late 1980s, work began on developing a uniform encoding for a «Universal Character Set» (UCS) that would replace earlier language-specific encodings with one coordinated system. The goal was to include all required characters from most of the world’s languages, as well as symbols from technical domains such as science, mathematics, and music. The original idea was to replace the typical 256-character encodings, which required 1 byte per character, with an encoding using 65,536 (2¹⁶) values, which would require 2 bytes (16 bits) per character.

Two groups worked on this in parallel, ISO/IEC JTC 1/SC 2 and the Unicode Consortium, the latter representing mostly manufacturers of computing equipment. The two groups attempted to synchronize their character assignments so that the developing encodings would be mutually compatible. The early 2-byte encoding was originally called «Unicode», but is now called «UCS-2».^[7]

When it became increasingly clear that 2¹⁶ characters would not suffice,^[1]IEEE introduced a larger 31-bit space and an encoding (UCS-4) that would require 4 bytes per character. This was resisted by the Unicode Consortium, both because 4 bytes per character wasted a lot of memory and disk space, and because some manufacturers were already heavily invested in 2-byte-per-character technology. The UTF-16 encoding scheme was developed as a compromise and introduced with version 2.0 of the Unicode standard in July 1996.^[8] It is fully specified in RFC 2781, published in 2000 by the IETF.^[9][10]

In the UTF-16 encoding, code points less than 2¹⁶ are encoded with a single 16-bit code unit equal to the numerical value of the code point, as in the older UCS-2. The newer code points greater than or equal to 2¹⁶ are encoded by a compound value using two 16-bit code units. These two 16-bit code units are chosen from the UTF-16 surrogate range 0xD800–0xDFFF which had not previously been assigned to characters. Values in this range are not used as characters, and UTF-16 provides no legal way to code them as individual code points. A UTF-16 stream, therefore, consists of single 16-bit code points outside the surrogate range for code points in the Basic Multilingual Plane (BMP), and pairs of 16-bit values within the surrogate range for code points above the BMP.

UTF-16 is specified in the latest versions of both the international standard ISO/IEC 10646 and the Unicode Standard. «UCS-2 should now be considered obsolete. It no longer refers to an encoding form in either 10646 or the Unicode Standard.»^[11] There are no plans as of 2021 to extend UTF-16 to support a larger number of code points or the code points replaced by surrogates, as this would violate the Unicode Stability Policy with respect to general category or surrogate code points.^[12] (any scheme that remains a self-synchronizing code would require allocating at least one BMP code point to start a sequence. Changing the purpose of a code point is disallowed).

Description

Each Unicode code point is encoded either as one or two 16-bit code units. How these 16-bit codes are stored as bytes then depends on the ‘endianness’ of the text file or communication protocol.

A «character» may need from as few as two bytes to fourteen^[13] or even more bytes to be recorded. For instance an emoji flag character takes 8 bytes, since it is «constructed from a pair of Unicode scalar values»^[14] (and those vales are outside the BMP and require 4 bytes each).

U+0000 to U+D7FF and U+E000 to U+FFFF

U+D800 to U+DFFF have a special purpose, see below.

Both UTF-16 and UCS-2 encode code points in this range as single 16-bit code units that are numerically equal to the corresponding code points. These code points in the Basic Multilingual Plane (BMP) are the only code points that can be represented in UCS-2.^{[citation needed]} As of Unicode 9.0, some modern non-Latin Asian, Middle-Eastern, and African scripts fall outside this range, as do most emoji characters.

Code points from U+010000 to U+10FFFF

Code points from the other planes (called Supplementary Planes) are encoded as two 16-bit code units called a surrogate pair, by the following scheme:

• 0x10000 is subtracted from the code point (U), leaving a 20-bit number (U’) in the hex number range 0x00000–0xFFFFF. Note for these purposes, U is defined to be no greater than 0x10FFFF.
• The high ten bits (in the range 0x000–0x3FF) are added to 0xD800 to give the first 16-bit code unit or high surrogate (W1), which will be in the range 0xD800–0xDBFF.
• The low ten bits (also in the range 0x000–0x3FF) are added to 0xDC00 to give the second 16-bit code unit or low surrogate (W2), which will be in the range 0xDC00–0xDFFF.

Illustrated visually, the distribution of U’ between W1 and W2 looks like:^[15]

U' = yyyyyyyyyyxxxxxxxxxx  // U - 0x10000
W1 = 110110yyyyyyyyyy      // 0xD800 + yyyyyyyyyy
W2 = 110111xxxxxxxxxx      // 0xDC00 + xxxxxxxxxx

The high surrogate and low surrogate are also known as «leading» and «trailing» surrogates, respectively, analogous to the leading and trailing bytes of UTF-8.^[16]

Since the ranges for the high surrogates (0xD800–0xDBFF), low surrogates (0xDC00–0xDFFF), and valid BMP characters (0x0000–0xD7FF, 0xE000–0xFFFF) are disjoint, it is not possible for a surrogate to match a BMP character, or for two adjacent code units to look like a legal surrogate pair. This simplifies searches a great deal. It also means that UTF-16 is self-synchronizing on 16-bit words: whether a code unit starts a character can be determined without examining earlier code units (i.e. the type of code unit can be determined by the ranges of values in which it falls). UTF-8 shares these advantages, but many earlier multi-byte encoding schemes (such as Shift JIS and other Asian multi-byte encodings) did not allow unambiguous searching and could only be synchronized by re-parsing from the start of the string (UTF-16 is not self-synchronizing if one byte is lost or if traversal starts at a random byte).

Because the most commonly used characters are all in the BMP, handling of surrogate pairs is often not thoroughly tested. This leads to persistent bugs and potential security holes, even in popular and well-reviewed application software (e.g. CVE-2008-2938, CVE-2012-2135).

The Supplementary Planes contain emoji, historic scripts, less used symbols, less used Chinese ideographs, etc. Since the encoding of Supplementary Planes contains 20 significant bits (10 of 16 bits in each of the high and low surrogates), 2²⁰ code points can be encoded, divided into 16 planes of 2¹⁶ code points each. Including the separately-handled Basic Multilingual Plane, there are a total of 17 planes.

U+D800 to U+DFFF

The Unicode standard permanently reserves these code point values for UTF-16 encoding of the high and low surrogates, and they will never be assigned a character, so there should be no reason to encode them. The official Unicode standard says that no UTF forms, including UTF-16, can encode these code points.^{[citation needed]}

However, UCS-2, UTF-8, and UTF-32 can encode these code points in trivial and obvious ways, and a large amount of software does so,^{[citation needed]} even though the standard states that such arrangements should be treated as encoding errors.^{[citation needed]}

It is possible to unambiguously encode an unpaired surrogate (a high surrogate code point not followed by a low one, or a low one not preceded by a high one) in the format of UTF-16 by using a code unit equal to the code point. The result is not valid UTF-16, but the majority of UTF-16 encoder and decoder implementations do this then when translating between encodings.^{[citation needed]} Windows allows unpaired surrogates in filenames and other places,^{[citation needed]} which generally means they have to be supported by software in spite of their exclusion from the Unicode standard.

Examples

To encode U+10437 (𐐷) to UTF-16:

• Subtract 0x10000 from the code point, leaving 0x0437.
• For the high surrogate, shift right by 10 (divide by 0x400), then add 0xD800, resulting in 0x0001 + 0xD800 = 0xD801.
• For the low surrogate, take the low 10 bits (remainder of dividing by 0x400), then add 0xDC00, resulting in 0x0037 + 0xDC00 = 0xDC37.

To decode U+10437 (𐐷) from UTF-16:

• Take the high surrogate (0xD801) and subtract 0xD800, then multiply by 0x400, resulting in 0x0001 × 0x400 = 0x0400.
• Take the low surrogate (0xDC37) and subtract 0xDC00, resulting in 0x37.
• Add these two results together (0x0437), and finally add 0x10000 to get the final decoded UTF-32 code point, 0x10437.

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

Byte-order encoding schemes

UTF-16 and UCS-2 produce a sequence of 16-bit code units. Since most communication and storage protocols are defined for bytes, and each unit thus takes two 8-bit bytes, the order of the bytes may depend on the endianness (byte order) of the computer architecture.

To assist in recognizing the byte order of code units, UTF-16 allows a Byte Order Mark (BOM), a code point with the value U+FEFF, to precede the first actual coded value.^{[nb 1]} (U+FEFF is the invisible zero-width non-breaking space/ZWNBSP character.)^{[nb 2]} If the endian architecture of the decoder matches that of the encoder, the decoder detects the 0xFEFF value, but an opposite-endian decoder interprets the BOM as the non-character value U+FFFE reserved for this purpose. This incorrect result provides a hint to perform byte-swapping for the remaining values.

If the BOM is missing, RFC 2781 recommends^{[nb 3]} that big-endian encoding be assumed. In practice, due to Windows using little-endian order by default, many applications assume little-endian encoding. It is also reliable to detect endianness by looking for null bytes, on the assumption that characters less than U+0100 are very common. If more even bytes (starting at 0) are null, then it is big-endian.

The standard also allows the byte order to be stated explicitly by specifying UTF-16BE or UTF-16LE as the encoding type. When the byte order is specified explicitly this way, a BOM is specifically not supposed to be prepended to the text, and a U+FEFF at the beginning should be handled as a ZWNBSP character. Most applications ignore a BOM in all cases despite this rule.

For Internet protocols, IANA has approved «UTF-16», «UTF-16BE», and «UTF-16LE» as the names for these encodings (the names are case insensitive). The aliases UTF_16 or UTF16 may be meaningful in some programming languages or software applications, but they are not standard names in Internet protocols.

Similar designations, UCS-2BE and UCS-2LE, are used to show versions of UCS-2.

Usage

UTF-16 is used for text in the OS API of all currently supported versions of Microsoft Windows (and including at least all since Windows CE/2000/XP/2003/Vista/7^[17]) including Windows 10. In Windows XP, no code point above U+FFFF is included in any font delivered with Windows for European languages.^[18][19] Older Windows NT systems (prior to Windows 2000) only support UCS-2.^[20] Files and network data tend to be a mix of UTF-16, UTF-8, and legacy byte encodings.

While there’s been some UTF-8 support for even Windows XP,^[21] it was improved (in particular the ability to name a file using UTF-8) in Windows 10 insider build 17035 and the April 2018 update, and as of May 2019 Microsoft recommends software use it instead of UTF-16.^[2]

The IBM i operating system designates CCSID (code page) 13488 for UCS-2 encoding and CCSID 1200 for UTF-16 encoding, though the system treats them both as UTF-16.^[22]

UTF-16 is used by the Qualcomm BREW operating systems; the .NET environments; and the Qt cross-platform graphical widget toolkit.

Symbian OS used in Nokia S60 handsets and Sony Ericsson UIQ handsets uses UCS-2. iPhone handsets use UTF-16 for Short Message Service instead of UCS-2 described in the 3GPP TS 23.038 (GSM) and IS-637 (CDMA) standards.^[23]

The Joliet file system, used in CD-ROM media, encodes file names using UCS-2BE (up to sixty-four Unicode characters per file name).

The Python language environment officially only uses UCS-2 internally since version 2.0, but the UTF-8 decoder to «Unicode» produces correct UTF-16. Since Python 2.2, «wide» builds of Unicode are supported which use UTF-32 instead;^[24] these are primarily used on Linux. Python 3.3 no longer ever uses UTF-16, instead an encoding that gives the most compact representation for the given string is chosen from ASCII/Latin-1, UCS-2, and UTF-32.^[25]

Java originally used UCS-2, and added UTF-16 supplementary character support in J2SE 5.0.

JavaScript may use UCS-2 or UTF-16.^[26] As of ES2015, string methods and regular expression flags have been added to the language that permit handling strings from an encoding-agnostic perspective.

In many languages, quoted strings need a new syntax for quoting non-BMP characters, as the C-style "\uXXXX" syntax explicitly limits itself to 4 hex digits. The following examples illustrate the syntax for the non-BMP character «𝄞» (U+1D11E, MUSICAL SYMBOL G CLEF). The most common (used by C++, C#, D, and several other languages) is to use an upper-case ‘U’ with 8 hex digits such as "\U0001D11E".^[27] In Java 7 regular expressions, ICU, and Perl, the syntax "\x{1D11E}" must be used; similarly, in ECMAScript 2015 (JavaScript), the escape format is "\u{1D11E}". In many other cases (such as Java outside of regular expressions),^[28] the only way to get non-BMP characters is to enter the surrogate halves individually, for example: "\uD834\uDD1E" for U+1D11E.

String implementations based on UTF-16 typically define lengths of the string and allow indexing in terms of these 16-bit code units, not in terms of code points. Neither code points nor code units correspond to anything an end user might recognize as a “character”; the things users identify as characters may in general consist of a base code point and a sequence of combining characters (or might be a sequence of code points of some other kind, for example Hangul conjoining jamos) – Unicode refers to this construct as a grapheme cluster^[29] – and as such, applications dealing with Unicode strings, whatever the encoding, must cope with the fact that this limits their ability to arbitrarily split and combine strings.

UCS-2 is also supported by the PHP language^[30] and MySQL.^[7]

Swift, version 5, Apple’s preferred application language, switched from UTF-16 to UTF-8 as the preferred encoding.^[31]

See also

• Comparison of Unicode encodings
• Plane (Unicode)
• UTF-8
• UTF-32

Notes

References

External links

• A very short algorithm for determining the surrogate pair for any code point
• Unicode Technical Note #12: UTF-16 for Processing
• Unicode FAQ: What is the difference between UCS-2 and UTF-16?
• Unicode Character Name Index
• RFC 2781: UTF-16, an encoding of ISO 10646
• java.lang.String documentation, discussing surrogate handling

<nowiki>//</nowiki> Допустимые значения Code: $0000..$D7FF, $E000..$10FFFF.
Procedure WriteUTF16Char(Code: UInt32)
    If (Code < $10000) Then
        WriteWord(LoWord(Code))
    Else
        Code = Code - $10000
        Var Lo10: Word = LoWord(Code And $3FF)
        Var Hi10: Word = LoWord(Code Shr 10)
        WriteWord($D800 Or Hi10)
        WriteWord($DC00 Or Lo10)
    End If
End Procedure

<nowiki>//</nowiki> В случае успеха возвращаются значения
<nowiki>//</nowiki> в диапазонах $0000..$D7FF и $E000..$10FFFF.
Function ReadUTF16Char: UInt32
    Var Leading:  Word  <nowiki>//</nowiki> Лидирующее (первое) слово.
    Var Trailing: Word  <nowiki>//</nowiki> Последующее (второе) слово.

    Leading = ReadWord();
    If (Leading < $D800) Or (Leading > $DFFF) Then
        Return WordToUInt32(Leading)
    Else If (Leading >= $DC00) Then
        Error("Недопустимая кодовая последовательность.")
    Else
        Var Code: UInt32
        Code = WordToUInt32(Leading And $3FF) Shl 10
        Trailing = ReadWord()
        If ((Trailing < $DC00) Or (Trailing > $DFFF)) Then
            Error("Недопустимая кодовая последовательность.")
        Else
            Code = Code Or WordToUInt32(Trailing And $3FF)
            Return (Code + $10000)
        End If
    End If
End Function

• 437 – IBM PC US, 8-bit SBCS extended ASCII.^[25] Known as OEM-US, the encoding of the primary built-in font of VGA graphics cards.
• 708 – Arabic, extended ISO 8859-6 (ASMO 708)
• 720 – Arabic, retaining box drawing characters in their usual locations
• 737 – «MS-DOS Greek». Retains all box drawing characters. More popular than 869.
• 775 – «MS-DOS Baltic Rim»
• 850 – «MS-DOS Latin 1». Full (re-arranged) repertoire of ISO 8859-1.
• 852 – «MS-DOS Latin 2»
• 855 – «MS-DOS Cyrillic». Mainly used for South Slavic languages. Includes (re-arranged) repertoire of ISO-8859-5. Not to be confused with cp866.
• 857 – «MS-DOS Turkish»
• 858 – Western European with euro sign
• 860 – «MS-DOS Portuguese»
• 861 – «MS-DOS Icelandic»
• 862 – «MS-DOS Hebrew»
• 863 – «MS-DOS French Canada»
• 864 – Arabic
• 865 – «MS-DOS Nordic»
• 866 – «MS-DOS Cyrillic Russian», cp866. Sole purely OEM code page (rather than ANSI or both) included as a legacy encoding in WHATWG Encoding Standard for HTML5.
• 869 – «MS-DOS Greek 2», IBM869. Full (re-arranged) repertoire of ISO 8859-7.
• 874 – Thai, also used as the ANSI code page, extends ISO 8859-11 (and therefore TIS-620) with a few additional characters from Windows-1252. Corresponds to IBM code page 1162 (IBM-874 is similar but has different extensions).

• 37 – IBM EBCDIC US-Canada, 8-bit SBCS^[30]
• 500 – Latin 1
• 870 – IBM870
• 875 – cp875
• 1026 – EBCDIC Turkish
• 1047 – IBM01047 – Latin 1
• 1140 – IBM01141
• 1141 – IBM01141
• 1142 – IBM01142
• 1143 – IBM01143
• 1144 – IBM01144
• 1145 – IBM01145
• 1146 – IBM01146
• 1147 – IBM01147
• 1148 – IBM01148
• 1149 – IBM01149
• 20273 – EBCDIC Germany
• 20277 – EBCDIC Denmark/Norway
• 20278 – EBCDIC Finland/Sweden
• 20280 – EBCDIC Italy
• 20284 – EBCDIC Latin America/Spain
• 20285 – EBCDIC United Kingdom
• 20290 – EBCDIC Japanese
• 20297 – EBCDIC France
• 20420 – EBCDIC Arabic
• 20423 – EBCDIC Greek
• 20424 – x-EBCDIC-KoreanExtended
• 20833 – Korean
• 20838 – EBCDIC Thai
• 20924 – IBM00924 – IBM EBCDIC Latin 1/Open System (1047 + Euro symbol)
• 20871 – EBCDIC Icelandic
• 20880 – EBCDIC Cyrillic
• 20905 – EBCDIC Turkish
• 21025 – EBCDIC Cyrillic
• 21027 – Japanese EBCDIC (incomplete,^[31] deprecated)^[32]

• 1200 – Unicode (BMP of ISO 10646, UTF-16LE). Available only to managed applications.^[32]
• 1201 – Unicode (UTF-16BE). Available only to managed applications.^[32]
• 12000 – UTF-32. Available only to managed applications.^[32]
• 12001 – UTF-32. Big-endian. Available only to managed applications.^[32]
• 65000 – Unicode (UTF-7)
• 65001 – Unicode (UTF-8)

• 10000 – Apple Macintosh Roman
• 10001 – Apple Macintosh Japanese
• 10002 – Apple Macintosh Chinese (traditional) (BIG-5)
• 10003 – Apple Macintosh Korean
• 10004 – Apple Macintosh Arabic
• 10005 – Apple Macintosh Hebrew
• 10006 – Apple Macintosh Greek
• 10007 – Apple Macintosh Cyrillic
• 10008 – Apple Macintosh Chinese (simplified) (GB 2312)
• 10010 – Apple Macintosh Romanian
• 10017 – Apple Macintosh Ukrainian
• 10021 – Apple Macintosh Thai
• 10029 – Apple Macintosh Roman II / Central Europe
• 10079 – Apple Macintosh Icelandic
• 10081 – Apple Macintosh Turkish
• 10082 – Apple Macintosh Croatian

• 28591 – ISO-8859-1 – Latin-1 (IBM equivalent: 819)
• 28592 – ISO-8859-2 – Latin-2
• 28593 – ISO-8859-3 – Latin-3 or South European
• 28594 – ISO-8859-4 – Latin-4 or North European
• 28595 – ISO-8859-5 – Latin/Cyrillic
• 28596 – ISO-8859-6 – Latin/Arabic
• 28597 – ISO-8859-7 – Latin/Greek
• 28598 – ISO-8859-8 – Latin/Hebrew
• 28599 – ISO-8859-9 – Latin-5 or Turkish
• 28600 – ISO-8859-10 – Latin-6
• 28601 – ISO-8859-11 – Latin/Thai
• 28602 – ISO-8859-12 – reserved for Latin/Devanagari but abandoned (not supported)
• 28603 – ISO-8859-13 – Latin-7 or Baltic Rim
• 28604 – ISO-8859-14 – Latin-8 or Celtic
• 28605 – ISO-8859-15 – Latin-9
• 28606 – ISO-8859-16 – Latin-10 or South-Eastern European
• 38596 – ISO-8859-6-I – Latin/Arabic (logical bidirectional order)
• 38598 – ISO-8859-8-I – Latin/Hebrew (logical bidirectional order)

• 20105 – 7-bit IA5 IRV (Western European)^[33][34][35]
• 20106 – 7-bit IA5 German (DIN 66003)^[33][34][36]
• 20107 – 7-bit IA5 Swedish (SEN 850200 C)^[33][34][37]
• 20108 – 7-bit IA5 Norwegian (NS 4551-2)^[33][34][38]
• 20127 – 7-bit US-ASCII^[33][34][39]
• 20261 – T.61 (T.61-8bit)
• 20269 – ISO-6937

1. ^ «Code Pages». 2016-03-07. Archived from the original on 2016-03-07. Retrieved 2021-05-26.
2. ^ ^{a b c} «Glossary of Terms Used on this Site». December 8, 2018. Archived from the original on 2018-12-08. The term «ANSI» as used to signify Windows code pages is a historical reference, but is nowadays a misnomer that continues to persist in the Windows community. The source of this comes from the fact that the Windows code page 1252 was originally based on an ANSI draft—which became International Organization for Standardization (ISO) Standard 8859-1. «ANSI applications» are usually a reference to non-Unicode or code page–based applications.
3. ^ «Character Sets». www.iana.org. Archived from the original on 2021-05-25. Retrieved 2021-05-26.
4. ^ «Extensible Markup Language (XML) 1.1 (Second Edition): Character encodings». W3C. 29 September 2006. Archived from the original on 19 April 2021. Retrieved 5 October 2020.
5. ^ hylom (2017-11-14). «Windows 10のInsider PreviewでシステムロケールをUTF-8にするオプションが追加される» [The option to make UTF-8 the system locale added in Windows 10 Insider Preview]. スラド (in Japanese). Archived from the original on 2018-05-11. Retrieved 2018-05-10.
6. ^ «Character Sets». IANA. Archived from the original on 2016-12-03. Retrieved 2019-04-07.
7. ^ Microsoft. «Windows 1250». Archived from the original on 2014-07-14. Retrieved 2014-07-06.
8. ^ IBM. «SBCS code page information document CPGID 01250». Archived from the original on 2014-07-14. Retrieved 2014-07-06.
9. ^ Microsoft. «Windows 1251». Archived from the original on 2014-07-14. Retrieved 2014-07-06.
10. ^ IBM. «SBCS code page information document CPGID 01251». Archived from the original on 2014-07-14. Retrieved 2014-07-06.
11. ^ Microsoft. «Windows 1252». Archived from the original on 2013-05-04. Retrieved 2014-07-06.
12. ^ IBM. «SBCS code page information document CPGID 01252». Archived from the original on 2014-07-14. Retrieved 2014-07-06.
13. ^ Microsoft. «Windows 1253». Archived from the original on 2014-07-14. Retrieved 2014-07-06.
14. ^ IBM. «SBCS code page information document CPGID 01253». Archived from the original on 2014-07-14. Retrieved 2014-07-06.
15. ^ Microsoft. «Windows 1254». Archived from the original on 2014-07-14. Retrieved 2014-07-06.
16. ^ IBM. «SBCS code page information document CPGID 01254». Archived from the original on 2014-07-14. Retrieved 2014-07-06.
17. ^ Microsoft. «Windows 1255». Archived from the original on 2014-07-14. Retrieved 2014-07-06.
18. ^ IBM. «SBCS code page information document CPGID 01255». Archived from the original on 2014-07-14. Retrieved 2014-07-06.
19. ^ Microsoft. «Windows 1256». Archived from the original on 2014-07-14. Retrieved 2014-07-06.
20. ^ IBM. «SBCS code page information document CPGID 01256». Archived from the original on 2014-07-14. Retrieved 2014-07-06.
21. ^ Microsoft. «Windows 1257». Archived from the original on 2013-03-16. Retrieved 2014-07-06.
22. ^ IBM. «SBCS code page information document CPGID 01257». Archived from the original on 2014-07-14. Retrieved 2014-07-06.
23. ^ Microsoft. «Windows 1258». Archived from the original on 2013-10-25. Retrieved 2014-07-06.
24. ^ IBM. «SBCS code page information document CPGID 01258». Archived from the original on 2014-07-14. Retrieved 2014-07-06.
25. ^ IBM. «SBCS code page information document — CPGID 00437». Archived from the original on 2016-06-09. Retrieved 2014-07-04.
26. ^ «IBM-943 and IBM-932». IBM Knowledge Center. IBM. Archived from the original on 2018-08-18. Retrieved 2020-07-08.
27. ^ «Converter Explorer: ibm-1373_P100-2002». ICU Demonstration. International Components for Unicode. Archived from the original on 2021-05-26. Retrieved 2020-06-27.
28. ^ «Coded character set identifiers – CCSID 5471». IBM Globalization. IBM. Archived from the original on 2014-11-29.
29. ^ Julliard, Alexandre. «dump_krwansung_codepage: build Korean Wansung table from the KSX1001 file». make_unicode: Generate code page .c files from ftp.unicode.org descriptions. Wine Project. Archived from the original on 2021-05-26. Retrieved 2021-03-14.
30. ^ IBM. «SBCS code page information document — CPGID 00037». Archived from the original on 2014-07-14. Retrieved 2014-07-04.
31. ^ Steele, Shawn (2005-09-12). «Code Page 21027 «Extended/Ext Alpha Lowercase»«. MSDN. Archived from the original on 2019-04-06. Retrieved 2019-04-06.
32. ^ ^{a b c d e} «Code Page Identifiers». docs.microsoft.com. Archived from the original on 2019-04-07. Retrieved 2019-04-07.
33. ^ ^{a b c d e} «Code Page Identifiers». Microsoft Developer Network. Microsoft. 2014. Archived from the original on 2016-06-19. Retrieved 2016-06-19.
34. ^ ^{a b c d e} «Web Encodings — Internet Explorer — Encodings». WHATWG Wiki. 2012-10-23. Archived from the original on 2016-06-20. Retrieved 2016-06-20.
35. ^ Foller, Antonin (2014) [2011]. «Western European (IA5) encoding — Windows charsets». WUtils.com — Online web utility and help. Motobit Software. Archived from the original on 2016-06-20. Retrieved 2016-06-20.
36. ^ Foller, Antonin (2014) [2011]. «German (IA5) encoding – Windows charsets». WUtils.com – Online web utility and help. Motobit Software. Archived from the original on 2016-06-20. Retrieved 2016-06-20.
37. ^ Foller, Antonin (2014) [2011]. «Swedish (IA5) encoding — Windows charsets». WUtils.com — Online web utility and help. Motobit Software. Archived from the original on 2016-06-20. Retrieved 2016-06-20.
38. ^ Foller, Antonin (2014) [2011]. «Norwegian (IA5) encoding — Windows charsets». WUtils.com — Online web utility and help. Motobit Software. Archived from the original on 2016-06-20. Retrieved 2016-06-20.
39. ^ Foller, Antonin (2014) [2011]. «US-ASCII encoding — Windows charsets». WUtils.com — Online web utility and help. Motobit Software. Archived from the original on 2016-06-20. Retrieved 2016-06-20.
40. ^ Nechayev, Valentin (2013) [2001]. «Review of 8-bit Cyrillic encodings universe». Archived from the original on 2016-12-05. Retrieved 2016-12-05.