Misplaced Pages

#66933

66-562: The Unicode Consortium has warned implementers that the latest version of this Chinese standard, GB 18030-2022 , introduces what they describe as "disruptive changes" from the previous version GB 18030-2005 "involving 33 different characters and 55 code positions". GB 18030-2022 was enforced from 1 August 2023. It has been implemented in ICU 73.2; and in Java 21, and backported to older Java 8, 11, 17 (LTS releases) and 20.0.2. In addition to

132-759: A Unicode Private Use Area code point (U+E000–F8FF) in GBK 1.0 and that have later been encoded in Unicode. This is specified in Appendix E of GB 18030. There are 24 characters in GB ;18030-2005 that are still mapped to Unicode PUA. In the GB 18030-2022 update, the requirements for characters to be mapped to PUA has been lifted completely and all characters should be mapped to their standard Unicode codepoints. Of these, 18 mappings were updated by position-swapping similar to what happened between GBK and GB 18030. The remaining six kept

198-411: 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

264-545: A further amendment are to be made to GB 18030-2022 available for public consultation. The current draft updates up to Unicode 15.1 on Ideographic Description Characters , CJK Unified Ideographs URO, Extension A, B, C, G, H and I. Originally, in late 2022, it would have placed 897 new sinographic characters in Plane 10 ( hexadecimal : 0A), a yet-untitled astral Unicode plane , for citizen real-name certification in China, but eventually

330-500: A hint to perform byte-swapping for the remaining values. If the BOM is missing, RFC 2781 recommends that big-endian (BE) encoding be assumed. In practice, due to Windows using little-endian (LE) 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

396-459: 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

462-560: A mix of UTF-16, UTF-8, and legacy byte encodings. While there's been some UTF-8 support for even Windows XP, it was improved (in particular the ability to name a file using UTF-8) in Windows 10 insider build 17035 and the May 2019 update. As of May 2019, Microsoft recommends software use UTF-8 , on Windows and Xbox , instead of other 8-bit encodings. It is unclear if they are recommending usage of UTF-8 over UTF-16, though they do state "UTF-16 [..]

528-475: A range of values for the second byte of 0x30–0x39 (the ASCII codes for decimal digits). The first byte has the range 0x81 to 0xFE, as before. This means that a string-search routine that is safe for GBK should also be reasonably safe for GB18030 (in much the same way that a basic byte-oriented search routine is reasonably safe for EUC ). This gives a total of 1,587,600 (126×10×126×10) possible 4 byte sequences, which

594-674: A universal character encoding scheme called Unicode was initiated in 1987 by Joe Becker , Lee Collins , and Mark Davis . The Unicode Consortium was incorporated in California on January 3, 1991, with the stated aim to develop, extend, and promote the use of the Unicode Standard . Mark Davis was the president of the Unicode Consortium from when the Consortium was incorporated in 1991 until 2023, when he changed roles to CTO. Our goal

660-616: Is "constructed from a pair of Unicode scalar values" (and those values are outside the BMP and require 4 bytes each). UTF-16 in no way assists in "counting characters" or in "measuring the width of a string". UTF-16 is often claimed to be more space-efficient than UTF-8 for East Asian languages, since it uses two bytes for characters that take 3 bytes in UTF-8. Since real text contains many spaces, numbers, punctuation, markup (for e.g. web pages), and control characters, which take only one byte in UTF-8, this

726-491: Is a 501(c)(3) non-profit organization incorporated and based in Mountain View , California , U.S. Its primary purpose is to maintain and publish the Unicode Standard which was developed with the intention of replacing existing character encoding schemes that are limited in size and scope, and are incompatible with multilingual environments. The consortium describes its overall purpose as: ...enabl[ing] people around

SECTION 10

#1732887184067

792-500: Is a character encoding method capable of encoding all 1,112,064 valid code points of Unicode. The encoding is variable-length as code points are encoded with one or two 16-bit code units . UTF-16 arose from an earlier obsolete fixed-width 16-bit encoding now known as UCS-2 (for 2-byte Universal Character Set), once it became clear that more than 2 (65,536) code points were needed, including most emoji and important CJK characters such as for personal and place names. UTF-16

858-718: Is a unique burden that Windows places on code that targets multiple platforms." 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. 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

924-475: Is basically an extension based on GBK with additional characters in CJK Unified Ideographs Extension A. The second version designated GB 18030-2005 Information Technology—Chinese coded character set has the same mandatory subset as GB 18030-2000 of 1-, 2- and 4-byte encodings. This version also includes the full CJK Unified Ideographs Extension B in the 4-byte encoding section which

990-484: 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

1056-521: Is easily sufficient to cover Unicode 's 1,112,064 (17×65536 − 2048 surrogates) assigned, reserved, and noncharacter code points. Unfortunately, to further complicate matters there are no simple rules to translate between a 4 byte sequence and its corresponding code point . Instead, codes are allocated sequentially (with the first byte containing the most significant part and the last the least significant part) only to Unicode code points that are not mapped in any other manner. For example: An offset table

1122-690: Is encoded either as one or two 16-bit code units . Code points less than 2 ("in the BMP") are encoded with a single 16-bit code unit equal to the numerical value of the code point, as in the older UCS-2. Code points greater than or equal to 2 ("above the BMP") are encoded 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 codes outside

1188-552: Is only true for artificially constructed dense blocks of text. A more serious claim can be made for Devanagari and Bengali , which use multi-letter words and all the letters take 3 bytes in UTF-8 and only 2 in UTF-16. In addition the Chinese Unicode encoding standard GB 18030 always produces files the same size or smaller than UTF-16 for all languages, not just for Chinese (it does this by sacrificing self-synchronization). UTF-16

1254-408: Is outside the BMP as a suggestion support requirement. However, as the inclusion of CJK Unified Ideographs Extension B in a 4-byte region is required to be maintained during information processing, software can no longer get away with treating characters as 16-bit fixed width entities ( UCS-2 ). Therefore, they must either process the data as a variable-width format (as with UTF-8 or UTF-16 ), which

1320-410: Is rarely tested), has led to many bugs in software, including in Windows itself, the solution is usually adopting UTF-8 , as most software has done including (partially) Windows itself and Java and JavaScript. 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

1386-415: Is still used. JavaScript may use UCS-2 or UTF-16. As of ES2015, string methods and regular expression flags have been added to the language that permit handling strings from an encoding-agnostic perspective. UEFI uses UTF-16 to encode strings by default. Swift , Apple's preferred application language, used UTF-16 to store strings until version 5 which switched to UTF-8. Quite a few languages make

SECTION 20

#1732887184067

1452-486: Is the most common choice, or move to a larger fixed-width format (i.e. UTF-32 ). Microsoft made the change from UCS-2 to UTF-16 with Windows 2000. This version matches with Unicode 3.1, and also provided support for Hangul ( Korean ), Mongolian (including Manchu , Clear script , Sibe hergen , Galik ), Tai Nuea , Tibetan , Uyghur / Kazakh / Kyrgyz and Yi . The third and latest version, GB 18030-2022 Information Technology—Chinese coded character set , mandates

1518-430: Is to make sure that all of the text on computers for every language in the world is represented but we get a lot more attention for emojis than for the fact that you can type Chinese on your phone and have it work with another phone. The Unicode Consortium cooperates with many standards development organizations , including ISO/IEC JTC 1/SC 2 and W3C . While Unicode is often considered equivalent to ISO/IEC 10646 , and

1584-518: Is used by systems such as the Microsoft Windows API , the Java programming language and JavaScript /ECMAScript. It is also sometimes used for plain text and word-processing data files on Microsoft Windows. It is used by more modern implementations of SMS . UTF-16 is the only encoding (still) allowed on the web that is incompatible with 8-bit ASCII . However it has never gained popularity on

1650-473: 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 ) including Windows 10 . In Windows XP, no code point above U+FFFF is included in any font delivered with Windows for European languages. Older Windows NT systems (prior to Windows 2000) only support UCS-2 . Files and network data tend to be

1716-642: Is used in the WHATWG and W3C version of GB 18030 to efficiently translate code points. ICU and glibc use similar range definitions to avoid wasting space on large sequential blocks. GB   18030 has been supported on Windows since the release of Windows 95 , as code page 54936. Windows 2000 and XP offer a GB18030 Support Package. The open source PostgreSQL database supports GB18030 through its full support for UTF-8, i.e. by converting it to and from UTF-8. Similarly Microsoft SQL Server supports GB18030 by conversion to and from UTF-16. More specifically, supporting

1782-453: The 3GPP TS 23.038 ( GSM ) and IS-637 ( CDMA ) standards. The Joliet file system , used in CD-ROM media, encodes file names using UCS-2BE (up to sixty-four Unicode characters per file name). Python version 2.0 officially only used UCS-2 internally, but the UTF-8 decoder to "Unicode" produced correct UTF-16. There was also the ability to compile Python so that it used UTF-32 internally, this

1848-460: The BMP . These parts are fully mandatory in GB 18030-2000. Most major computer companies had already standardized on some version of Unicode as the primary format for use in their binary formats and OS calls. However, they mostly had only supported code points in the BMP originally defined in Unicode 1.0, which supported only 65,536 codepoints and was often encoded in 16 bits as UCS-2 . This standard

1914-656: The Bangladesh Computer Council , Emojipedia , Facebook , Google , IBM , Microsoft , the Omani Ministry of Endowments and Religious Affairs , Monotype Imaging , Netflix , Salesforce , SAP SE , Tamil Virtual Academy , and the University of California, Berkeley . Technical decisions relating to the Unicode Standard are made by the Unicode Technical Committee (UTC). The project to develop

1980-409: 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". When it became increasingly clear that 2 characters would not suffice, IEEE introduced

2046-401: 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

GB 18030 - Misplaced Pages Continue

2112-752: The repertoire (reduced to 622 characters after expert review) was fast-tracked into Unicode 15.1 in September 2023, as the CJK Unified Ideographs Extension I block. Following this, the amendment draft was modified to use the Extension I code points. GB 18030 defines a one (ASCII), two (extended GBK), or four-byte (UTF) encoding. The two-byte codes are defined in a lookup table, while the four-byte codes are defined sequentially (hence algorithmically) to fill otherwise unencoded parts in UCS . GB 18030 inherits

2178-555: The GB18030 encoding on Windows means that Code Page 54936 is supported by MultiByteToWideChar and WideCharToMultiByte . Due to the backward compatibility of the mapping, many files in GB18030 can be actually opened successfully as the legacy Code Page 936, that is GBK, even if the Code Page 54936 is not supported. However, that is only true if the file in question contains only GBK characters. Loading will fail or cause corrupted result if

2244-634: The UTC releases a public statement on each proposal it considered. Due to the volume of proposals, various subcommittees, such as the Script Ad Hoc Group and Emoji Subcommittee, exist to submit recommendations to the full UTC en banc . The UTC is under no obligation to heed these recommendations, although in practice it usually does. The Unicode Consortium maintains a History of Unicode Release and Publication Dates . Publications include: UCS-2 UTF-16 ( 16-bit Unicode Transformation Format)

2310-551: The Unicode Consortium or not. The UTC holds its meetings behind closed doors. As of July 2020, the UTC rules on both emoji and script proposals at the same meeting. Due to the COVID-19 pandemic's effect on travel , the meetings, which used to be hosted on by various companies for free, were in 2020 held online via Zoom , although the discussions remain confidential. The UTC prefers to work by consensus , but on particularly contentious issues, votes may be necessary. After it meets,

2376-637: The Unicode standard in July 1996. It is fully specified in RFC 2781, published in 2000 by the IETF . 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." UTF-16 will never be extended to support a larger number of code points or to support

2442-414: The appearance of CJK Unified Ideographs Extension B. Some characters used by ethnic minorities in China , such as Mongolian characters and Tibetan characters ( GB 16959 -1997 and GB/T 20542 -2006), have been added as well, which accounts for the renaming of the standard. Compared with its ancestors, GB 18030's mapping to Unicode has been modified for the 81 characters that were provisionally assigned

2508-422: The bad aspects of GBK , most notably needing special code to safely find ASCII characters in a GB18030 sequence. The one- and two-byte code points are essentially GBK with the euro sign, PUA mappings for unassigned/user-defined points, and vertical punctuations. The four byte scheme can be thought of as consisting of two units, each of two bytes. Each unit has a similar format to a GBK two byte character but with

2574-537: The basic set", was published on March 17, 2000. The encoding scheme stays the same in the new version, and the only difference in GB-to-Unicode mapping is that GB 18030-2000 mapped the character A8 BC (ḿ) to a private use code point U+E7C7, and character 81 35 F4 37 (without specifying any glyph) to U+1E3F (ḿ), whereas GB 18030-2005 swaps these two mapping assignments. More code points are now associated with characters due to update of Unicode , especially

2640-479: 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. (U+FEFF is the invisible zero-width non-breaking space /ZWNBSP character). 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 noncharacter value U+FFFE reserved for this purpose. This incorrect result provides

2706-512: The character sets are essentially identical, the Unicode standard imposes additional restrictions on implementations that ISO/IEC 10646 does not. Apart from The Unicode Standard (TUS) and its annexes (UAX), the Unicode Consortium also maintains the CLDR , collaborated with the IETF on IDNA , and publishes related standards (UTS), reports (UTR), and utilities. The group selects the emoji icons used by

GB 18030 - Misplaced Pages Continue

2772-486: The characters in Unicode 2.1 plus new characters found in the Unicode CJK Unified Ideographs Extension A block although, despite its name, it does not contain glyphs for all characters encoded by GB 18030, as all (about a million) Unicode code points up to U+10FFFF can be encoded as GB 18030. GB 18030 compliance certification only requires correct handling and recognition of glyphs in

2838-426: The code point are distributed among the UTF-16 bytes. Additional bits added by the UTF-16 encoding process are shown in black. 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

2904-465: The code points that were replaced by surrogates, as this would violate the Unicode Stability Policy with respect to general category or surrogate code points. (Any scheme that remains a self-synchronizing code would require allocating at least one Basic Multilingual Plane (BMP) code point to start a sequence. Changing the purpose of a code point is disallowed.) Each Unicode code point

2970-447: The encoding is a full UTF). The standard is known to support English/ASCII and the "following non-Chinese scripts are recognized by GB 18030-2022: Arabic, Tibetan, Mongolian, Tai Le, New Tai Lue, Tai Tham, Yi, Lisu, Hangul (Korean), and Miao." The GB18030 Support Package for Windows contains SimSun18030.ttc, a TrueType font collection file which combines two Chinese fonts, SimSun-18030 and NSimSun-18030. The SimSun 18030 font includes all

3036-681: The encoding method, this standard contains requirements about which additional scripts and languages should be represented, and to whom this standard is applicable. This standard however does not define the official character forms for the Chinese characters; this is standardised in List of Commonly Used Standard Chinese Characters . The GB18030 character set is formally called "Chinese National Standard GB 18030-2005: Information Technology—Chinese coded character set". GB abbreviates Guójiā Biāozhǔn (国家标准), which means national standard in Chinese. The standard

3102-548: The encoding part of the string object, and thus store and support a large set of encodings including UTF-16. Most consider UTF-16 and UCS-2 to be different encodings. Examples are the PHP language and MySQL . A method to determine what encoding a system is using internally is to ask for the "length" of string containing a single non-BMP character. If the length is 2 then UTF-16 is being used. 4 indicates UTF-8. 3 or 6 may indicate CESU-8 . 1 may indicate UTF-32, but more likely indicates

3168-658: The file contains characters that do not exist in GBK (see § Technical details for examples). GNU glibc 's gconv, the character codec library used on most Linux distributions, supports GB 18030-2000 since 2.2, and GB 18030-2005 since 2.14; glibc notably includes non-PUA mappings for GB 18030-2005 in order to achieve round-trip conversion. GNU libiconv , an alternative iconv implementation frequently used on non-glibc UNIX-like environments like Cygwin , supports GB 18030 since version 1.4. As of 2022, "supporting non-Chinese scripts continues to be optional" (presumably for display/font support only; and in China, since

3234-467: The mandatory (two-byte, and CJK Ext. A) Chinese part. Nevertheless, the requirement of PUA characters in the standard have hampered this implementation. Microsoft YaHei and DengXian provided by Microsoft are updated in 2023 to match GB 18030-2022 implementation level 2, and SimSun is updated to match implementation level 3. Source Han Sans (and its counterpart Noto Sans CJK) are already compliant with GB 18030-2022 implementation level 2 when

3300-485: 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 . A "character" may use any number of Unicode code points. For instance an emoji flag character takes 8 bytes, since it

3366-402: The other planes are encoded as two 16-bit code units called a surrogate pair . The first code unit is a high surrogate and the second is a low surrogate (These are also known as "leading" and "trailing" surrogates, respectively, analogous to the leading and trailing bytes of UTF-8. ): Illustrated visually, the distribution of U' between W1 and W2 looks like: Since the ranges for

SECTION 50

#1732887184067

3432-559: The public a standard character encoding that provides for an allocation for more than a million characters. Unicode's success at unifying character sets has led to its widespread adoption in the internationalization and localization of software . The standard has been implemented in many technologies, including XML , the Java programming language , Swift , and modern operating systems . Members are usually but not limited to computer software and hardware companies with an interest in text-processing standards, including Adobe , Apple ,

3498-433: The requirement of "all products using this standard should implements Implementation Level 1" that includes 66 new BMP characters in the 4-byte encoding region that were added between Unicode 3.1 and Unicode 11.0. Implementation Level 2 requires the support of List of Commonly Used Standard Chinese Characters , and Implementation Level 3 requires all other specified regions in the standard. From late 2022 to 2023, drafts of

3564-629: The standard states that such arrangements should be treated as encoding errors. 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 when translating between encodings. To encode U+10437 (𐐷) to UTF-16: To decode U+10437 (𐐷) from UTF-16: The following table summarizes this conversion, as well as others. The colors indicate how bits from

3630-822: The standard update for GB 18030 is announced as of November 2022. Source Han Serif (and its counterpart Noto Serif CJK) however is not compliant at the time, and an update is provided to ensure the font is compliant to implementation level 2. Similarly Microsoft YaHei and PingFang (Apple) require a small number of URO additions that are associated with implementation level 1 in order to become compliant with GB 18030-2022 implementation level 2. Other CJK font families like HAN NOM and Hanazono Mincho provide wider coverage for Unicode CJK Extension blocks than SimSun-18030 or even SimSun (Founder Extended), but they don't support all code points defined in GB 18030. Unicode Consortium The Unicode Consortium (legally Unicode, Inc. )

3696-478: 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 official Unicode standard says that no UTF forms, including UTF-16, can encode

3762-428: The suggestion support part of CJK Unified Ideographs Extension B in GB 18030-2005, along with updates up to Unicode 11.0 including Kangxi Radicals and CJK Unified Ideographs URO , Extension C, D, E and F. Additional languages are also recognized by GB 18030-2022 such as part of Arabic , Tai Le , New Tai Lue , Tai Tham , Lisu , and Miao . GB 18030-2022 also introduces three implementation levels, with

3828-446: The surrogate code points. Since these will never be assigned a character, there should be no reason to encode them. However, Windows allows unpaired surrogates in filenames and other places, which generally means they have to be supported by software in spite of their exclusion from the Unicode standard. 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, even though

3894-671: The surrogate range, and pairs of 16-bit values that are within the surrogate range. 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. 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

3960-546: The two-byte PUA mappings, so that a change to the 4-byte sequence is needed to follow the non-PUA preference. The first version of GB 18030, designated GB 18030-2000 Information Technology—Chinese coded character set for information interchange — Extension for the basic set , consists of 1-byte and 2-byte encodings, together with 4-byte encoding for CJK Unified Ideographs Extension A matching those in Unicode 3.0. The corresponding Unicode code points of this subset, including provisional private assignments, lie entirely in

4026-462: The web, where it is declared by under 0.003% of public web pages. UTF-8 , by comparison, accounts for over 98% of all web pages. The Web Hypertext Application Technology Working Group (WHATWG) considers UTF-8 "the mandatory encoding for all [text]" and that for security reasons browser applications should not use UTF-16. The variable length character of UTF-16, combined with the fact that most characters are not variable length (so variable length

SECTION 60

#1732887184067

4092-499: The world to use computers in any language, by providing freely-available specifications and data to form the foundation for software internationalization in all major operating systems, search engines, applications, and the World Wide Web. An essential part of this purpose is to standardize, maintain, educate and engage academic and scientific communities, and the general public about, make publicly available, promote, and disseminate to

4158-556: The world's smartphones, based on submissions from individuals and organizations who present their case with evidence for why each one is needed. The Unicode Technical Committee (UTC) meets quarterly to decide whether new characters will be encoded. A quorum of half of the Consortium's full members is required. As of May 2024, there are nine full members: Adobe , Airbnb , Apple , Google , Meta , Microsoft , Netflix , Salesforce and Translated. The UTC accepts documents from any organization or individual, whether they are members of

4224-534: Was published by the China Standard Press, Beijing, 8 November 2005. Only a portion of the standard is mandatory. Since 1 May 2006, support for the mandatory subset is officially required for all software products sold in the PRC. An older version of the standard, known as "Chinese National Standard GB 18030-2000: Information Technology—Chinese ideograms coded character set for information interchange—Extension for

4290-532: Was sometimes done on Unix. Python 3.3 switched internal storage to use one of ISO-8859-1 , UCS-2, or UTF-32 depending on the largest code point in the string. Python 3.12 drops some functionality (for CPython extensions) to make it easier to migrate to UTF-8 for all strings. Java originally used UCS-2, and added UTF-16 supplementary character support in J2SE 5.0 . Recently they have encouraged dumping support for any 8-bit encoding other than UTF-8 but internally UTF-16

4356-426: 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

#66933