www.fgks.org   »   [go: up one dir, main page]

Jump to content

Character encoding: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
mNo edit summary
Tag: Reverted
mNo edit summary
 
(34 intermediate revisions by 25 users not shown)
Line 3: Line 3:
[[File:Papertape-Wikipedia-example-dark1-2000px.png|thumb|[[Punched tape]] with the word "Wikipedia" encoded in [[ASCII]]. Presence and absence of a hole represents 1 and 0, respectively; for example, "W" is encoded as "1010111".]]
[[File:Papertape-Wikipedia-example-dark1-2000px.png|thumb|[[Punched tape]] with the word "Wikipedia" encoded in [[ASCII]]. Presence and absence of a hole represents 1 and 0, respectively; for example, "W" is encoded as "1010111".]]


'''Character encoding''' is the process of assigning numbers to [[Graphics|graphical]] [[character (computing)|characters]], especially the written characters of [[Language|human languacrosfotge]], allowing them to be [[Data storage|stored]], [[Data communication|transmitted]], and [[Computing|transformed]] using [[Digital electronics|digital]] [[computer]]s.<ref>Definition from [http://techterms.com/definition/characterencoding The Tech Terms Dictionary]</ref> The numerical values that make up a character encoding are known as "[[code point]]s" and collectively comprise a "code space", a "[[code page]]", or a "[[Character Map (Windows)|character map]]".
'''Character encoding''' is the process of assigning numbers to [[Graphics|graphical]] [[character (computing)|characters]], especially the written characters of [[Language|human language]], allowing them to be [[Data storage|stored]], [[Data communication|transmitted]], and [[Computing|transformed]] using [[Digital electronics|digital]] [[computer]]s.<ref>{{cite web|title = Character Encoding Definition|date = September 24, 2010 |url= http://techterms.com/definition/characterencoding |website=The Tech Terms Dictionary}}</ref> The numerical values that make up a character encoding are known as "[[code point]]s" and collectively comprise a "code space", a "[[code page]]", or a "[[Character Map (Windows)|character map]]".


Early character codes associated with the optical or electrical [[Telegraphy|telegraph]] could only represent a subset of the characters used in [[written language]]s, sometimes restricted to [[Letter case|upper case letter]]s, [[Numeral system|numeral]]s and some [[punctuation]] only. The low cost of digital representation of data in modern computer systems allows more elaborate character codes (such as [[Unicode]]) which represent most of the characters used in many written languages. Character encoding using internationally accepted standards permits worldwide interchange of text in electronic form.
Early character codes associated with the optical or electrical [[Telegraphy|telegraph]] could only represent a subset of the characters used in [[written language]]s, sometimes restricted to [[Letter case|upper case letter]]s, [[Numeral system|numeral]]s and some [[punctuation]] only. The low cost of digital representation of data in modern computer systems allows more elaborate character codes (such as [[Unicode]]) which represent most of the characters used in many written languages. Character encoding using internationally accepted standards permits worldwide interchange of text in electronic form.

The [[Popularity of text encodings|most used character encoding]] on the [[World Wide Web|web]] is [[UTF-8]], used in 98.2% of surveyed web sites, as of May 2024.<ref name="W3TechsWebEncoding">{{Cite web |title=Usage Survey of Character Encodings broken down by Ranking |url=https://w3techs.com/technologies/cross/character_encoding/ranking |access-date=2024-04-29 |website=W3Techs |language=en}}</ref> In [[Application software|application programs]] and [[operating system]] tasks, both UTF-8 and [[UTF-16]] are popular options.<ref name=":0">{{Cite web |title=Charset |url=https://developer.android.com/reference/java/nio/charset/Charset |access-date=2021-01-02 |website=Android Developers |language=en |quote=Android note: The Android platform default is always UTF-8.}}</ref><ref name=":1">{{Cite web |last=Galloway |first=Matt |date=9 October 2012 |title=Character encoding for iOS developers. Or UTF-8 what now? |url=https://www.galloway.me.uk/2012/10/character-encoding-for-ios-developers-utf8/ |access-date=2021-01-02 |website=www.galloway.me.uk |language=en |quote=in reality, you usually just assume UTF-8 since that is by far the most common encoding.}}</ref>


== History ==
== History ==
The history of character codes illustrates the evolving need for machine-mediated character-based symbolic information over a distance, using once-novel electrical means. The earliest codes were based upon manual and hand-written encoding and cyphering systems, such as [[Bacon's cipher]], [[Braille]], [[International maritime signal flags]], and the 4-digit encoding of Chinese characters for a [[Chinese telegraph code]] ([[Hans Schjellerup]], 1869). With the adoption of electrical and electro-mechanical techniques these earliest codes were adapted to the new capabilities and limitations of the early machines. The earliest well-known electrically transmitted character code, [[Morse code]], introduced in the 1840s, used a system of four "symbols" (short signal, long signal, short space, long space) to generate codes of variable length. Though some commercial use of Morse code was via machinery, it was often used as a manual code, generated by hand on a [[telegraph key]] and decipherable by ear, and persists in [[amateur radio]] and [[Non-directional beacon|aeronautical]] use. Most codes are of fixed per-character length or variable-length sequences of fixed-length codes (e.g. [[Unicode]]).<ref>{{cite web | url=http://blog.smartbear.com/development/ancient-computer-character-code-tables-and-why-theyre-still-relevant/ | title=Ancient Computer Character Code Tables – and Why They're Still Relevant | publisher=Smartbear | date=17 April 2014 | access-date=29 April 2014 | author=Tom Henderson}}</ref>
The history of character codes illustrates the evolving need for machine-mediated character-based symbolic information over a distance, using once-novel electrical means. The earliest codes were based upon manual and hand-written encoding and cyphering systems, such as [[Bacon's cipher]], [[Braille]], [[international maritime signal flags]], and the 4-digit encoding of Chinese characters for a [[Chinese telegraph code]] ([[Hans Schjellerup]], 1869). With the adoption of electrical and electro-mechanical techniques these earliest codes were adapted to the new capabilities and limitations of the early machines. The earliest well-known electrically transmitted character code, [[Morse code]], introduced in the 1840s, used a system of four "symbols" (short signal, long signal, short space, long space) to generate codes of variable length. Though some commercial use of Morse code was via machinery, it was often used as a manual code, generated by hand on a [[telegraph key]] and decipherable by ear, and persists in [[amateur radio]] and [[Non-directional beacon|aeronautical]] use. Most codes are of fixed per-character length or variable-length sequences of fixed-length codes (e.g. [[Unicode]]).<ref>{{cite web | url=http://blog.smartbear.com/development/ancient-computer-character-code-tables-and-why-theyre-still-relevant/ | title=Ancient Computer Character Code Tables – and Why They're Still Relevant | publisher=Smartbear | date=17 April 2014 | access-date=29 April 2014 | author=Tom Henderson}}</ref>


Common examples of character encoding systems include [[Morse code]], the [[Baudot code]], the American Standard Code for Information Interchange ([[ASCII]]) and [[Unicode]]. [[Unicode]], a well defined and extensible encoding system, has supplanted most earlier character encodings, but the path of code development to the present is fairly well known.
Common examples of character encoding systems include Morse code, the [[Baudot code]], the [[American Standard Code for Information Interchange]] (ASCII) and Unicode. Unicode, a well-defined and extensible encoding system, has supplanted most earlier character encodings, but the path of code development to the present is fairly well known.


The [[Baudot code]], a five-bit encoding, was created by [[Émile Baudot]] in 1870, patented in 1874, modified by Donald Murray in 1901, and standardized by CCITT as International Telegraph Alphabet No. 2 (ITA2) in 1930. The name "baudot" has been erroneously applied to ITA2 and its many variants. ITA2 suffered from many shortcomings and was often "improved" by many equipment manufacturers, sometimes creating compatibility issues. In 1959 the U.S. military defined its [[Fieldata]] code, a six-or seven-bit code, introduced by the U.S. Army Signal Corps. While Fieldata addressed many of the then-modern issues (e.g. letter and digit codes arranged for machine collation), Fieldata fell short of its goals and was short-lived. In 1963 the first ASCII (American Standard Code for Information Interchange) code was released (X3.4-1963) by the ASCII committee (which contained at least one member of the Fieldata committee, W. F. Leubbert) which addressed most of the shortcomings of Fieldata, using a simpler code. Many of the changes were subtle, such as collatable character sets within certain numeric ranges. ASCII63 was a success, widely adopted by industry, and with the follow-up issue of the 1967 ASCII code (which added lower-case letters and fixed some "control code" issues) ASCII67 was adopted fairly widely. ASCII67's American-centric nature was somewhat addressed in the European [[ECMA-6]] standard.<ref>{{cite web | url=https://www.sr-ix.com/Archive/CharCodeHist/index.html | title=An annotated history of some character codes | date=1 March 2010 | access-date=1 November 2018 | author=Tom Jennings}}</ref>
The Baudot code, a five-[[bit]] encoding, was created by [[Émile Baudot]] in 1870, patented in 1874, modified by Donald Murray in 1901, and standardized by CCITT as International Telegraph Alphabet No.&nbsp;2 (ITA2) in 1930. The name ''baudot'' has been erroneously applied to ITA2 and its many variants. ITA2 suffered from many shortcomings and was often improved by many equipment manufacturers, sometimes creating compatibility issues. In 1959 the U.S. military defined its [[Fieldata]] code, a six-or seven-bit code, introduced by the U.S. Army Signal Corps. While Fieldata addressed many of the then-modern issues (e.g. letter and digit codes arranged for machine collation), it fell short of its goals and was short-lived. In 1963 the first ASCII code was released (X3.4-1963) by the ASCII committee (which contained at least one member of the Fieldata committee, W. F. Leubbert), which addressed most of the shortcomings of Fieldata, using a simpler code. Many of the changes were subtle, such as collatable character sets within certain numeric ranges. ASCII63 was a success, widely adopted by industry, and with the follow-up issue of the 1967 ASCII code (which added lower-case letters and fixed some "control code" issues) ASCII67 was adopted fairly widely. ASCII67's American-centric nature was somewhat addressed in the European [[ECMA-6]] standard.<ref>{{cite web | url=https://www.sr-ix.com/Archive/CharCodeHist/index.html | title=An annotated history of some character codes | date=1 March 2010 | access-date=1 November 2018 | author=Tom Jennings}}</ref>


[[File:Blue-punch-card-front-horiz.png|thumb|Hollerith 80-column punch card with EBCDIC character set]]
[[File:Blue-punch-card-front-horiz.png|thumb|Hollerith 80-column punch card with EBCDIC character set]]
[[Herman Hollerith]] invented punch card data encoding in the late 19th century to analyze census data. Initially, each hole position represented a different data element, but later, numeric information was encoded by numbering the lower rows 0 to 9, with a punch in a column representing its row number. Later alphabetic data was encoded by allowing more than one punch per column. Electromechanical [[tabulating machine]]s represented date internally by the timing of pulses relative to the motion of the cards through the machine. When [[IBM]] went to electronic processing, starting with the [[IBM 603]] Electronic Multiplier, it used a variety of binary encoding schemes that were tied to the punch card code.
[[Herman Hollerith]] invented punch card data encoding in the late 19th century to analyze census data. Initially, each hole position represented a different data element, but later, numeric information was encoded by numbering the lower rows 0 to 9, with a punch in a column representing its row number. Later alphabetic data was encoded by allowing more than one punch per column. Electromechanical [[tabulating machine]]s represented date internally by the timing of pulses relative to the motion of the cards through the machine. When [[IBM]] went to electronic processing, starting with the [[IBM 603]] Electronic Multiplier, it used a variety of binary encoding schemes that were tied to the punch card code.


[[IBM]]'s [[Binary-coded decimal#IBM and BCD|Binary Coded Decimal]] ([[BCD (character encoding)|BCD]]) was a six-bit encoding scheme used by IBM as early as 1953 in its [[IBM 702|702]]<ref>{{cite web|url=http://www.bitsavers.org/pdf/ibm/702/22-6173-1_702prelim_Feb56.pdf |archive-url=https://ghostarchive.org/archive/20221009/http://www.bitsavers.org/pdf/ibm/702/22-6173-1_702prelim_Feb56.pdf |archive-date=2022-10-09 |url-status=live|title=IBM Electronic Data-Processing Machines Type 702 Preliminary Manual of Information|date=1954|id=22-6173-1|page=80}}</ref> and [[IBM 704|704]] computers, and in its later [[IBM 700/7000 series|7000 Series]] and [[IBM 1400 series|1400 series]], as well as in associated peripherals. Since the punched card code then in use only allowed digits, upper-case English letters and a few special characters, six bits were sufficient. BCD extended existing simple four-bit numeric encoding to include alphabetic and special characters, mapping it easily to punch-card encoding which was already in widespread use. IBMs codes were used primarily with IBM equipment; other computer vendors of the era had their own character codes, often six-bit, but usually had the ability to read tapes produced on IBM equipment. BCD was the precursor of [[IBM]]'s [[EBCDIC|Extended Binary Coded Decimal Interchange Code]] (usually abbreviated as EBCDIC), an eight-bit encoding scheme developed in 1963 for the [[IBM System/360]] that featured a larger character set, including lower case letters.
IBM used several [[Binary-coded decimal#IBM|Binary Coded Decimal]] ([[BCD (character encoding)|BCD]]) six-bit character encoding schemes, starting as early as 1953 in its [[IBM 702|702]]<ref>{{cite web|url=http://www.bitsavers.org/pdf/ibm/702/22-6173-1_702prelim_Feb56.pdf |archive-url=https://ghostarchive.org/archive/20221009/http://www.bitsavers.org/pdf/ibm/702/22-6173-1_702prelim_Feb56.pdf |archive-date=2022-10-09 |url-status=live|title=IBM Electronic Data-Processing Machines Type 702 Preliminary Manual of Information|date=1954|id=22-6173-1|page=80}}</ref> and [[IBM 704|704]] computers, and in its later [[IBM 700/7000 series|7000 Series]] and [[IBM 1400 series|1400 series]], as well as in associated peripherals. Since the punched card code then in use only allowed digits, upper-case English letters and a few special characters, six bits were sufficient. These BCD encodings extended existing simple four-bit numeric encoding to include alphabetic and special characters, mapping them easily to punch-card encoding which was already in widespread use. IBM's codes were used primarily with IBM equipment; other computer vendors of the era had their own character codes, often six-bit, but usually had the ability to read tapes produced on IBM equipment. These BCD encodings were the precursors of IBM's [[Extended Binary-Coded Decimal Interchange Code]] (usually abbreviated as EBCDIC), an eight-bit encoding scheme developed in 1963 for the [[IBM System/360]] that featured a larger character set, including lower case letters.

The limitations of such sets soon became apparent,{{to whom|date=September 2018}} and a number of ''ad hoc'' methods were developed to extend them. The need to support more [[writing system]]s for different languages, including the [[CJK characters|CJK]] family of [[East Asian scripts]], required support for a far larger number of characters and demanded a systematic approach to character encoding rather than the previous ''ad hoc'' approaches.{{citation needed|date=September 2018}}


In trying to develop universally interchangeable character encodings, researchers in the 1980s faced the dilemma that, on the one hand, it seemed necessary to add more bits to accommodate additional characters, but on the other hand, for the users of the relatively small character set of the Latin alphabet (who still constituted the majority of computer users), those additional bits were a colossal waste of then-scarce and expensive computing resources (as they would always be zeroed out for such users). In 1985, the average personal computer user's [[hard disk drive]] could store only about 10 megabytes, and it cost approximately US$250 on the wholesale market (and much higher if purchased separately at retail),<ref name="Strelho">{{cite news |last1=Strelho |first1=Kevin |title=IBM Drives Hard Disks to New Standards |url=https://books.google.com/books?id=zC4EAAAAMBAJ&pg=PA29 |access-date=November 10, 2020 |work=InfoWorld |publisher=Popular Computing Inc. |date=April 15, 1985 |pages=29–33}}</ref> so it was very important at the time to make every bit count.
In trying to develop universally interchangeable character encodings, researchers in the 1980s faced the dilemma that, on the one hand, it seemed necessary to add more bits to accommodate additional characters, but on the other hand, for the users of the relatively small character set of the Latin alphabet (who still constituted the majority of computer users), those additional bits were a colossal waste of then-scarce and expensive computing resources (as they would always be zeroed out for such users). In 1985, the average personal computer user's [[hard disk drive]] could store only about 10 megabytes, and it cost approximately US$250 on the wholesale market (and much higher if purchased separately at retail),<ref name="Strelho">{{cite news |last1=Strelho |first1=Kevin |title=IBM Drives Hard Disks to New Standards |url=https://books.google.com/books?id=zC4EAAAAMBAJ&pg=PA29 |access-date=November 10, 2020 |work=InfoWorld |publisher=Popular Computing Inc. |date=April 15, 1985 |pages=29–33}}</ref> so it was very important at the time to make every bit count.
Line 26: Line 26:


== Terminology ==
== Terminology ==
Informally, the terms "character encoding", "character map", "character set" and "code page" are often used interchangeably.<ref name="SteeleMSDN">{{cite web|url=https://docs.microsoft.com/en-us/archive/blogs/shawnste/whats-the-difference-between-an-encoding-code-page-character-set-and-unicode|author=Shawn Steele|title=What's the difference between an Encoding, Code Page, Character Set and Unicode?|date=15 March 2005|website=Microsoft Docs}}</ref> Historically, the same standard would specify a repertoire of characters and how they were to be encoded into a stream of code units — usually with a single character per code unit. However, due to the emergence of more sophisticated character encodings, the distinction between these terms has become important.
; Terminology related to character encoding:

[[File:KB Dubeolsik for Old Hangul (NG3).svg|thumb|365x365px]]
* A ''character'' is a minimal unit of text that has semantic value.
* A ''[[Character (computing)|character]]'' is a minimal unit of text that has semantic value.<ref name="SteeleMSDN"/><ref name="Unicode glossary">{{cite web |title=Glossary of Unicode Terms |url=https://unicode.org/glossary/ |publisher=Unicode Consortium}}</ref>
* A ''character set'' is a collection of characters that might be used by multiple languages. ''Example:'' The Latin character set is used by English and most European languages, though the Greek character set is used only by the Greek language.
* A ''character set'' is a collection of elements used to represent text.<ref name="SteeleMSDN"/><ref name="Unicode glossary"/> For example, the [[Latin alphabet]] and [[Greek alphabet]] are both character sets.
* A ''coded character set'' is a character set in which each character corresponds to a unique number.
* {{anchor|CCS}}A ''coded character set'' is a character set mapped to set of unique numbers.<ref name="Unicode glossary"/> For historical reasons, this is also often referred to as a [[code page]].<ref name="SteeleMSDN"/>
* {{anchor|repertoire}}A ''character repertoire'' is the set of characters that can be represented by a particular coded character set.<ref name="Unicode glossary"/><ref name="unicode15">{{cite book |title=The Unicode Standard Version 15.0 – Core Specification |date=September 2022 |publisher=Unicode Consortium |isbn=978-1-936213-32-0 |chapter=Chapter 3: Conformance |url=https://www.unicode.org/versions/Unicode15.0.0/ch03.pdf}}</ref> The repertoire may be closed, meaning that no additions are allowed without creating a new standard (as is the case with ASCII and most of the ISO-8859 series); or it may be open, allowing additions (as is the case with Unicode and to a limited extent [[Windows code page]]s).<ref name="unicode15"/>
* A ''code point'' of a coded character set is any allowed value in the character set or code space.
* A ''code space'' is a range of integers whose values are code points.
* A ''code point'' is a value or position of a character in a coded character set.<ref name="Unicode glossary"/>
* A ''code space'' is the range of numerical values spanned by a coded character set.<ref name="Unicode glossary"/><ref name="utr17"/>
* A ''code unit'' is the "word size" of the character encoding scheme, such as 7-bit, 8-bit, 16-bit. In some schemes, some characters are encoded using multiple code units, resulting in a variable-length encoding. A code unit is referred to as a ''code value'' in some documents.<ref>{{cite web |title=Unicode glossary |url=https://unicode.org/glossary/#code_value |publisher=Unicode consortium}}</ref>
* A ''code unit'' is the minimum bit combination that can represent a character in a character encoding (in [[computer science]] terms, it is the [[Word (computer architecture)|word]] size of the character encoding).<ref name="Unicode glossary"/><ref name="utr17"/> For example, common code units include 7-bit, 8-bit, 16-bit, and 32-bit. In some encodings, some characters are encoded using multiple code units; such an encoding is referred to as a [[variable-width encoding]].

===Code pages===
{{main|Code page}}
"Code page" is a historical name for a coded character set.


Originally, a code page referred to a specific [[page number]] in the IBM standard character set manual, which would define a particular character encoding.<ref name="DEC_VT510">{{cite web |title=VT510 Video Terminal Programmer Information |at=7.1. Character Sets - Overview |publisher=[[Digital Equipment Corporation]] (DEC) |url=http://www.vt100.net/docs/vt510-rm/chapter7.html#S7.1 |access-date=2017-02-15 |quote=In addition to traditional [[Digital Equipment Corporation|DEC]] and [[ISO]] character sets, which conform to the structure and rules of [[ISO 2022]], the [[VT510]] supports a number of IBM PC code pages ([[page number]]s in IBM's standard character set manual) in [[PCTerm]] mode to emulate the [[console terminal]] of industry-standard PCs. |archive-date=2016-01-26 |archive-url=https://web.archive.org/web/20160126192029/http://www.vt100.net/docs/vt510-rm/chapter7.html#S7.1 |url-status=live }}</ref> Other vendors, including [[Microsoft]], [[SAP AG|SAP]], and [[Oracle Corporation]], also published their own sets of code pages; the most well-known code page suites are "[[Windows code page|Windows]]" (based on Windows-1252) and "IBM"/"DOS" (based on [[code page 437]]).
; Character repertoire (the abstract set of characters):


Despite no longer referring to specific page numbers in a standard, many character encodings are still referred to by their code page number; likewise, the term "code page" is often still used to refer to character encodings in general.
The character repertoire is an abstract set of more than one million characters found in a wide variety of scripts including Latin, Cyrillic, Chinese, Korean, Japanese, Hebrew, and Aramaic.


The term "code page" is not used in Unix or Linux, where "charmap" is preferred, usually in the larger context of locales. IBM's Character Data Representation Architecture (CDRA) designates entities with coded character set identifiers ([[CCSID]]s), each of which is variously called a "charset", "character set", "code page", or "CHARMAP".<ref name=utr17/>
Other symbols such as musical notation are also included in the character repertoire. Both the Unicode and [[GB 18030]] standards have a character repertoire. As new characters are added to one standard, the other standard also adds those characters, to maintain parity.


===Code units===
The code unit size is equivalent to the bit measurement for the particular encoding:
The code unit size is equivalent to the bit measurement for the particular encoding:
* A code unit in [[US-ASCII]] consists of 7 bits;
* A code unit in [[ASCII]] consists of 7 bits;
* A code unit in [[UTF-8]], [[EBCDIC]] and GB 18030 consists of 8 bits;
* A code unit in [[UTF-8]], [[EBCDIC]] and [[GB 18030]] consists of 8 bits;
* A code unit in [[UTF-16]] consists of 16 bits;
* A code unit in [[UTF-16]] consists of 16 bits;
* A code unit in [[UTF-32]] consists of 32 bits.
* A code unit in [[UTF-32]] consists of 32 bits.


===Code points===
; Example of a code unit:
A code point is represented by a sequence of code units. The mapping is defined by the encoding. Thus, the number of code units required to represent a code point depends on the encoding:
Consider a [[String (computer science)|string]] of the letters "ab̲c𐐀", that is, a string containing a Unicode combining character ({{unichar|0332}}) as well a supplementary character ({{unichar|10400}}). This string has several representions which are logically equivalent, yet while each is suited to a diverse set of circumstances or range of requirements:
* UTF-8: code points map to a sequence of one, two, three or four code units.
* Four [[Character (computing)|composed characters]]:
* UTF-16: code units are twice as long as 8-bit code units. Therefore, any code point with a scalar value less than U+10000 is encoded with a single code unit. Code points with a value U+10000 or higher require two code units each. These pairs of code units have a unique term in UTF-16: [[UTF-16#Code points from U+010000 to U+10FFFF|"Unicode surrogate pairs".]]
*:{{code|a}}, {{code|b̲}}, {{code|c}}, {{code|𐐀}}
* UTF-32: the 32-bit code unit is large enough that every code point is represented as a single code unit.
* Five [[grapheme]]s:
* GB 18030: multiple code units per code point are common, because of the small code units. Code points are mapped to one, two, or four code units.<ref>{{cite web | url=https://docs.oracle.com/javase/tutorial/i18n/text/terminology.html | title=Terminology (The Java Tutorials) | publisher=Oracle | access-date=25 March 2018 }}</ref>
*:{{code|a}}, {{code|b}}, {{code|_}}, {{code|c}}, {{code|𐐀}}

* Five Unicode [[code point]]s:
===Characters===
*:{{code|U+0061}}, {{code|U+0062}}, {{code|U+0332}}, {{code|U+0063}}, {{code|U+10400}}
{{main|Character (computing)}}
* Five UTF-32 code units (32-bit integer values):
Exactly what constitutes a character varies between character encodings.
*:{{code|0x00000061}}, {{code|0x00000062}}, {{code|0x00000332}}, {{code|0x00000063}}, {{code|0x00010400}}

* Six UTF-16 code units (16-bit integers)
For example, for letters with [[diacritic]]s, there are two distinct approaches that can be taken to encode them: they can be encoded either as a single unified character (known as a precomposed character), or as separate characters that combine into a single [[glyph]]. The former simplifies the text handling system, but the latter allows any letter/diacritic combination to be used in text. [[Typographic ligature|Ligatures]] pose similar problems.
*:{{code|0x0061}}, {{code|0x0062}}, {{code|0x0332}}, {{code|0x0063}}, {{code|0xd801}}, {{code|0xdc00}}

* Nine UTF-8 code units (8-bit values, or [[byte]]s)
Exactly how to handle [[glyph]] variants is a choice that must be made when constructing a particular character encoding. Some writing systems, such as Arabic and Hebrew, need to accommodate things like [[grapheme]]s that are joined in different ways in different contexts, but represent the same semantic character.
*:{{code|0x61}}, {{code|0x62}}, {{code|0xCC}}, {{code|0xB2}}, {{code|0x63}}, {{code|0xf0}}, {{code|0x90}}, {{code|0x90}}, {{code|0x80}}

==Unicode encoding model==
[[Unicode]] and its parallel standard, the ISO/IEC 10646 [[Universal Character Set]], together constitute a unified standard for character encoding. Rather than mapping characters directly to [[byte]]s, Unicode separately defines a coded character set that maps characters to unique natural numbers ([[code point]]s), how those code points are mapped to a series of fixed-size natural numbers (code units), and finally how those units are encoded as a stream of octets (bytes). The purpose of this decomposition is to establish a universal set of characters that can be encoded in a variety of ways. To describe this model precisely, Unicode uses its own set of terminology to describe its process:<ref name="utr17">{{cite web |last1=Whistler |first1=Ken |last2=Freytag |first2=Asmus |title=UTR#17: Unicode Character Encoding Model |url=https://www.unicode.org/reports/tr17/ |publisher=Unicode Consortium |access-date=12 August 2023 |date=2022-11-11}}</ref>

An '''abstract character repertoire''' (ACR) is the full set of abstract characters that a system supports. Unicode has an open repertoire, meaning that new characters will be added to the repertoire over time.

A '''coded character set''' (CCS) is a [[function (mathematics)|function]] that maps characters to ''[[code point]]s'' (each code point represents one character). For example, in a given repertoire, the capital letter "A" in the Latin alphabet might be represented by the code point 65, the character "B" by 66, and so on. Multiple coded character sets may share the same character repertoire; for example [[ISO/IEC 8859-1]] and IBM code pages 037 and [[Code page 500|500]] all cover the same repertoire but map them to different code points.

A '''character encoding form''' (CEF) is the mapping of code points to ''code units'' to facilitate storage in a system that represents numbers as bit sequences of fixed length (i.e. practically any computer system). For example, a system that stores numeric information in 16-bit units can only directly represent code points 0 to 65,535 in each unit, but larger code points (say, 65,536 to 1.4&nbsp;million) could be represented by using multiple 16-bit units. This correspondence is defined by a CEF.

A '''character encoding scheme''' (CES) is the mapping of code units to a sequence of octets to facilitate storage on an octet-based file system or transmission over an octet-based network. Simple character encoding schemes include [[UTF-8]], [[UTF-16BE]], [[UTF-32BE]], [[UTF-16LE]], and [[UTF-32LE]]; compound character encoding schemes, such as [[UTF-16]], [[UTF-32]] and [[ISO/IEC 2022]], switch between several simple schemes by using a [[byte order mark]] or [[escape sequence]]s; compressing schemes try to minimize the number of bytes used per code unit (such as [[Standard Compression Scheme for Unicode|SCSU]] and [[Binary Ordered Compression for Unicode|BOCU]]).

Although [[UTF-32BE]] and [[UTF-32LE]] are simpler CESes, most systems working with Unicode use either [[UTF-8]], which is [[backward compatibility|backward compatible]] with fixed-length ASCII and maps Unicode code points to variable-length sequences of octets, or [[UTF-16BE]],{{cn|date=August 2023}} which is [[backward compatibility|backward compatible]] with fixed-length UCS-2BE and maps Unicode code points to variable-length sequences of 16-bit words. See [[comparison of Unicode encodings]] for a detailed discussion.

Finally, there may be a '''higher-level protocol''' which supplies additional information to select the particular variant of a [[Unicode]] character, particularly where there are regional variants that have been 'unified' in Unicode as the same character. An example is the [[XML]] attribute xml:lang.


The Unicode model uses the term "character map" for other systems which directly assign a sequence of characters to a sequence of bytes, covering all of the CCS, CEF and CES layers.<ref name="utr17" />
Note in particular the last character, which is represented with either one ''1'' 32-bit value, ''2'' 16-bit values. or ''4'' 8-bit values. Although each of those forms uses the same total number of bits (32) to represent the glyph, the actual numeric byte values and their arrangement appear entirely unrelated.


===Unicode code points===
; Code point:
The convention to refer to a character in Unicode is to start with 'U+' followed by the codepoint value in hexadecimal. The range of valid code points for the Unicode standard is U+0000 to U+10FFFF, inclusive, divided in 17 [[Plane (Unicode)|planes]], identified by the numbers 0 to 16. Characters in the range U+0000 to U+FFFF are in plane 0, called the [[Plane (Unicode)#Basic Multilingual Plane|Basic Multilingual Plane]] (BMP). This plane contains most commonly-used characters. Characters in the range U+10000 to U+10FFFF in the other planes are called [[supplementary characters]].
In Unicode, a character can be referred to as 'U+' followed by its codepoint value in hexadecimal. The range of valid code points (the codespace) for the Unicode standard is U+0000 to U+10FFFF, inclusive, divided in 17 [[Plane (Unicode)|planes]], identified by the numbers 0 to 16. Characters in the range U+0000 to U+FFFF are in plane 0, called the [[Plane (Unicode)#Basic Multilingual Plane|Basic Multilingual Plane]] (BMP). This plane contains most commonly-used characters. Characters in the range U+10000 to U+10FFFF in the other planes are called [[supplementary characters]].


The following table shows examples of code point values:
The following table shows examples of code point values:
Line 98: Line 119:
|}
|}


===Example===
A code point is represented by a sequence of code units. The mapping is defined by the encoding. Thus, the number of code units required to represent a code point depends on the encoding:
Consider a [[String (computer science)|string]] of the letters "ab̲c𐐀"—that is, a string containing a Unicode combining character ({{unichar|0332}}) as well a supplementary character ({{unichar|10400}}). This string has several Unicode representations which are logically equivalent, yet while each is suited to a diverse set of circumstances or range of requirements:
* ''UTF-8:'' code points map to a sequence of one, two, three or four code units.
* Four [[Character (computing)|composed characters]]:
* ''UTF-16:'' code units are twice as long as 8-bit code units. Therefore, any code point with a scalar value less than U+10000 is encoded with a single code unit. Code points with a value U+10000 or higher require two code units each. These pairs of code units have a unique term in UTF-16: [[UTF-16#Code points from U+010000 to U+10FFFF|"Unicode surrogate pairs".]]
*:{{code|a}}, {{code|b̲}}, {{code|c}}, {{code|𐐀}}
* ''UTF-32:'' the 32-bit code unit is large enough that every code point is represented as a single code unit.
* Five [[grapheme]]s:
* ''GB 18030:'' multiple code units per code point are common, because of the small code units. Code points are mapped to one, two, or four code units.<ref>{{cite web | url=https://docs.oracle.com/javase/tutorial/i18n/text/terminology.html | title=Terminology (The Java Tutorials) | publisher=Oracle | access-date=25 March 2018 }}</ref>
*:{{code|a}}, {{code|b}}, {{code|_}}, {{code|c}}, {{code|𐐀}}
* Five Unicode [[code point]]s:
*:{{code|U+0061}}, {{code|U+0062}}, {{code|U+0332}}, {{code|U+0063}}, {{code|U+10400}}
* Five UTF-32 code units (32-bit integer values):
*:{{code|0x00000061}}, {{code|0x00000062}}, {{code|0x00000332}}, {{code|0x00000063}}, {{code|0x00010400}}
* Six UTF-16 code units (16-bit integers)
*:{{code|0x0061}}, {{code|0x0062}}, {{code|0x0332}}, {{code|0x0063}}, {{code|0xD801}}, {{code|0xDC00}}
* Nine UTF-8 code units (8-bit values, or [[byte]]s)
*:{{code|0x61}}, {{code|0x62}}, {{code|0xCC}}, {{code|0xB2}}, {{code|0x63}}, {{code|0xF0}}, {{code|0x90}}, {{code|0x90}}, {{code|0x80}}


Note in particular that 𐐀 is represented with either one 32-bit value (UTF-32), two 16-bit values (UTF-16), or four 8-bit values (UTF-8). Although each of those forms uses the same total number of bits (32) to represent the glyph, it is not obvious how the actual numeric byte values are related.
== {{anchor|CCS}}Unicode encoding model ==
[[Unicode]] and its parallel standard, the ISO/IEC 10646 [[Universal Character Set]], together constitute a modern, unified character encoding. Rather than mapping characters directly to octets ([[byte]]s), they separately define what characters are available, corresponding natural numbers ([[code point]]s), how those numbers are encoded as a series of fixed-size natural numbers (code units), and finally how those units are encoded as a stream of octets. The purpose of this decomposition is to establish a universal set of characters that can be encoded in a variety of ways.<ref name=utr17>{{cite web |url=https://www.unicode.org/reports/tr17/ |title=Unicode Technical Report #17: Unicode Character Encoding Model |date=11 November 2008 |access-date=8 August 2009}}</ref> To describe this model correctly requires more precise terms than "character set" and "character encoding." The terms used in the modern model follow:<ref name=utr17/>


== Transcoding ==
{{anchor|repertoire}}A '''character repertoire''' is the full set of abstract characters that a system supports. The repertoire may be closed, i.e. no additions are allowed without creating a new standard (as is the case with ASCII and most of the ISO-8859 series), or it may be open, allowing additions (as is the case with Unicode and to a limited extent the [[Windows code page]]s). The characters in a given repertoire reflect decisions that have been made about how to divide writing systems into basic information units. The basic variants of the [[Latin alphabet|Latin]], [[Greek alphabet|Greek]] and [[Cyrillic]] alphabets can be broken down into letters, digits, punctuation, and a few ''special characters'' such as the space, which can all be arranged in simple linear sequences that are displayed in the same order they are read. But even with these alphabets, [[diacritic]]s pose a complication: they can be regarded either as part of a single character containing a letter and diacritic (known as a precomposed character), or as separate characters. The former allows a far simpler text handling system but the latter allows any letter/diacritic combination to be used in text. [[Typographic ligature|Ligatures]] pose similar problems. Other writing systems, such as Arabic and Hebrew, are represented with more complex character repertoires due to the need to accommodate things like bidirectional text and [[glyph]]s that are joined in different ways for different situations.
As a result of having many character encoding methods in use (and the need for backward compatibility with archived data), many computer programs have been developed to translate data between character encoding schemes, a process known as [[transcoding]]. Some of these are cited below.

A '''coded character set''' (CCS) is a [[function (mathematics)|function]] that maps characters to ''[[code point]]s'' (each code point represents one character). For example, in a given repertoire, the capital letter "A" in the Latin alphabet might be represented by the code point 65, the character "B" to 66, and so on. Multiple coded character sets may share the same repertoire; for example [[ISO/IEC 8859-1]] and IBM code pages 037 and 500 all cover the same repertoire but map them to different code points.

A '''character encoding form''' (CEF) is the mapping of code points to ''code units'' to facilitate storage in a system that represents numbers as bit sequences of fixed length (i.e. practically any computer system). For example, a system that stores numeric information in 16-bit units can only directly represent code points 0 to 65,535 in each unit, but larger code points (say, 65,536 to 1.4&nbsp;million) could be represented by using multiple 16-bit units. This correspondence is defined by a CEF.

Next, a '''character encoding scheme''' (CES) is the mapping of code units to a sequence of octets to facilitate storage on an octet-based file system or transmission over an octet-based network. Simple character encoding schemes include [[UTF-8]], [[UTF-16BE]], [[UTF-32BE]], [[UTF-16LE]] or [[UTF-32LE]]; compound character encoding schemes, such as [[UTF-16]], [[UTF-32]] and [[ISO/IEC 2022]], switch between several simple schemes by using a [[byte order mark]] or [[escape sequence]]s; compressing schemes try to minimize the number of bytes used per code unit (such as [[Standard Compression Scheme for Unicode|SCSU]], [[Binary Ordered Compression for Unicode|BOCU]], and [[Punycode]]).

Although [[UTF-32BE]] is a simpler CES, most systems working with Unicode use either [[UTF-8]], which is [[backward compatibility|backward compatible]] with fixed-length ASCII and maps Unicode code points to variable-length sequences of octets, or [[UTF-16BE]], which is [[backward compatibility|backward compatible]] with fixed-length UCS-2BE and maps Unicode code points to variable-length sequences of 16-bit words. See [[comparison of Unicode encodings]] for a detailed discussion.

Finally, there may be a '''higher-level protocol''' which supplies additional information to select the particular variant of a [[Unicode]] character, particularly where there are regional variants that have been 'unified' in Unicode as the same character. An example is the [[XML]] attribute xml:lang.

The Unicode model uses the term '''character map''' for historical systems which directly assign a sequence of characters to a sequence of bytes, covering all of CCS, CEF and CES layers.<ref name="utr17" />

== Character sets, character maps and code pages ==
Historically, the terms "character encoding", "character map", "character set" and "[[code page]]" were synonymous in [[computer science]], as the same standard would specify a repertoire of characters and how they were to be encoded into a stream of code units – usually with a single character per code unit. But now the terms have related but distinct meanings,<ref name="SteeleMSDN">{{cite web|url=https://docs.microsoft.com/en-us/archive/blogs/shawnste/whats-the-difference-between-an-encoding-code-page-character-set-and-unicode|author=Shawn Steele|title=What's the difference between an Encoding, Code Page, Character Set and Unicode?|date=15 March 2005|website=Microsoft Docs}}</ref> due to efforts by standards bodies to use precise terminology when writing about and unifying many different encoding systems.<ref name=utr17/> Regardless, the terms are still used interchangeably, with ''character set'' being nearly ubiquitous.

A "'''code page'''" usually means a [[byte oriented|byte-oriented]] encoding, but with regard to some suite of encodings (covering different scripts), where many characters share the same [[code point|codes]] in most or all those code pages. Well-known code page suites are "Windows" (based on Windows-1252) and "IBM"/"DOS" (based on [[code page 437]]), see [[Windows code page]] for details. Most, but not all, encodings referred to as code pages are single-byte encodings (but see [[Octet (computing)|octet]] on byte size.)

IBM's Character Data Representation Architecture (CDRA) designates entities with coded character set identifiers ([[CCSID]]s), each of which is variously called a "charset", "character set", "code page", or "CHARMAP".<ref name=utr17/>

The term "code page" does not occur in Unix or Linux where "charmap" is preferred, usually in the larger context of locales.

In contrast to a "[[#CCS|coded character set]]", a "character encoding" is a map from abstract characters to [[code word]]s. A "character set" in [[HTTP]] (and [[MIME]]) parlance is the same as a character encoding (but not the same as CCS).

"[[legacy system|Legacy]] encoding" is a term sometimes used to characterize old character encodings, but with an ambiguity of sense. Most of its use is in the context of [[Unicode|Unicodification]], where it refers to encodings that fail to cover all Unicode code points, or, more generally, using a somewhat different character repertoire: several code points representing one Unicode character,<ref>{{cite web|url=http://www.basistech.co.jp/knowledge-center/database/uc-trillium-2.ppt|title=Processing database information using Unicode, a case study|archive-url=https://web.archive.org/web/20060617193918/http://www.basistech.co.jp/knowledge-center/database/uc-trillium-2.ppt|archive-date=17 June 2006}}</ref> or versa (see e.g. [[code page 437]]). Some sources refer to an encoding as ''legacy'' only because it preceded Unicode.<ref>{{cite web|url=http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter03#79e846db|publisher=[[SIL International]]|title=Character set encoding basics|work=Implementing Writing Systems: An introduction|first=Peter|last=Constable|date=13 June 2001|access-date=19 March 2010|archive-url=https://web.archive.org/web/20130505074221/http://scripts.sil.org/cms/SCRIPTs/page.php?site_id=nrsi&item_id=IWS-Chapter03#79e846db|archive-date=5 May 2013|url-status=dead}}</ref> All Windows code pages are usually referred to as legacy, both because they antedate Unicode and because they are unable to represent all 2<sup>21</sup> possible Unicode code points.

== Character encoding translation ==
As a result of having many character encoding methods in use (and the need for backward compatibility with archived data), many computer programs have been developed to translate data between encoding schemes as a form of data [[transcoding]]. Some of these are cited below.


[[Cross-platform]]:
[[Cross-platform]]:
Line 141: Line 143:
* [[iconv]] – a program and standardized API to convert encodings
* [[iconv]] – a program and standardized API to convert encodings
* [[luit]] – a program that converts encoding of input and output to programs running interactively
* [[luit]] – a program that converts encoding of input and output to programs running interactively
* convert_encoding.py – a Python-based utility to convert text files between arbitrary encodings and line endings<ref>{{GitHub|goerz/convert_encoding.py}}</ref>
* decodeh.py – an algorithm and module to heuristically guess the encoding of a string<ref>{{cite web|url=http://gizmojo.org/code/decodeh/|title=Decodeh – heuristically decode a string or text file|archive-url=https://web.archive.org/web/20080108123255/http://gizmojo.org/code/decodeh/|archive-date=8 January 2008}}</ref>
* [[International Components for Unicode]] – A set of C and Java libraries to perform charset conversion. uconv can be used from ICU4C.
* [[International Components for Unicode]] – A set of C and Java libraries to perform charset conversion. uconv can be used from ICU4C.
* [http://pypi.python.org/pypi/chardet chardet] – This is a translation of the [[Mozilla]] automatic-encoding-detection code into the Python computer language.
* The newer versions of the Unix [[file (command)|file]] command attempt to do a basic detection of character encoding (also available on [[Cygwin]]).
* [http://sourceforge.net/projects/charset charset] – [[C++]] template library with simple interface to convert between C++/user-defined streams. charset defined many character-sets and allows you to use Unicode formats with support of [[endianness]].
[[Unix-like]]:
* cmv – a simple tool for transcoding filenames.<ref>{{cite web|url=http://cmv.fossrec.com|title=CharsetMove – Simple Tool for Transcoding Filenames}}</ref>
* convmv – converts a filename from one encoding to another.<ref>{{cite web|url=http://www.j3e.de/linux/convmv/man/|title=Convmv – converts filenames from one encoding to another}}</ref>
* cstocs – converts file contents from one encoding to another for the Czech and Slovak languages.
* enca – analyzes encodings for given text files.<ref>{{Cite web |url=http://directory.fsf.org/project/enca/ |title=Extremely Naive Charset Analyser |access-date=11 March 2008 |archive-url=https://web.archive.org/web/20101204060724/http://directory.fsf.org/project/enca/ |archive-date=4 December 2010 |url-status=dead }}</ref>
* recode – converts file contents from one encoding to another.<ref>{{GitHub|rrthomas/recode}}</ref>
* utrac – converts file contents from one encoding to another.<ref>{{cite web|url=http://utrac.sourceforge.net/|title=Utrac Homepage}}</ref>


[[Microsoft Windows|Windows]]:
[[Microsoft Windows|Windows]]:
* Encoding.Convert – .NET API<ref>{{cite web|url=https://docs.microsoft.com/en-us/dotnet/api/system.text.encoding.convert?redirectedfrom=MSDN&view=net-6.0#overloads|work=Microsoft .NET Framework Class Library|title=Encoding.Convert Method}}</ref>
* Encoding.Convert – .NET API<ref>{{cite web|url=https://docs.microsoft.com/en-us/dotnet/api/system.text.encoding.convert?redirectedfrom=MSDN&view=net-6.0#overloads|work=Microsoft .NET Framework Class Library|title=Encoding.Convert Method}}</ref>
* MultiByteToWideChar/WideCharToMultiByte – to convert from ANSI to Unicode & Unicode to ANSI<ref>{{cite web|url=https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar|title=MultiByteToWideChar function (stringapiset.h)|website=Microsoft Docs|date=13 October 2021 }}</ref><ref>{{cite web|url=https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte|title=WideCharToMultiByte function (stringapiset.h)|website=Microsoft Docs|date=9 August 2022 }}</ref>
* <ref>{{Cite web |url=https://web.archive.org/web/20220115211927/https://support.microsoft.com/en-us/topic/4fba10d4-12e0-dec0-ee37-9b0365459652 |title=Microsoft Support Article |website=Microsoft Support |access-date=2023-05-02}}</ref>
* enca – analyzes encodings for given text files.<ref>{{Cite web |url=http://www.john.geek.nz/2010/02/enca-binary-compiled-for-32-bit-windows/ |title=Enca binary compiled for 32 bit Windows |access-date=31 March 2011 |archive-url=https://web.archive.org/web/20120315090223/http://www.john.geek.nz/2010/02/enca-binary-compiled-for-32-bit-windows/ |archive-date=15 March 2012 |url-status=dead }}</ref>

== See also ==
* [[Percent-encoding]]
* [[Alt code]]
* [[Character encodings in HTML]]
* [[:Category:Character encoding]] – articles related to character encoding in general
* [[:Category:Character sets]] – articles detailing specific character encodings
* [[Hexadecimal#Representing hexadecimal|Hexadecimal representations]]
* ''[[Mojibake]]'' – character set mismap
* [[Mojikyō]] – a system ("glyph set") that includes over 100,000 Chinese character drawings, modern and ancient, popular and obscure
* [[Presentation layer]]
* [[TRON (encoding)|TRON]], part of the TRON project, is an encoding system that does not use Han Unification; instead, it uses "control codes" to switch between 16-bit "planes" of characters.
* [[Universal Character Set characters]]
* [[Charset sniffing]] – used in some applications when character encoding metadata is not available


=== Common character encodings ===
== Common character encodings ==
{{Main|Popularity of text encodings}}
{{Expand section|Popularity and comparison:
* Statistics on popularity
* Especially, a comparison of the advantages and disadvantages of the few 3-5 most common character encodings (e.g. UTF-8, UTF-16 and UTF-32)|date=June 2024}}
The [[Popularity of text encodings|most used character encoding]] on the [[World Wide Web|web]] is [[UTF-8]], used in 98.2% of surveyed web sites, as of May 2024.<ref name="W3TechsWebEncoding" /> In [[Application software|application programs]] and [[operating system]] tasks, both UTF-8 and [[UTF-16]] are popular options.<ref name=":0" /><ref name=":1" />
{{Div col|colwidth=30em}}
{{Div col|colwidth=30em}}
* [[ISO/IEC 646|ISO 646]]
* [[ISO/IEC 646|ISO 646]]
Line 236: Line 216:
* [[ANSEL]] or [[ISO/IEC 6937]]
* [[ANSEL]] or [[ISO/IEC 6937]]
{{Div col end}}
{{Div col end}}

== See also ==
* [[Percent-encoding]]
* [[Alt code]]
* [[Character encodings in HTML]]
* [[:Category:Character encoding]] – articles related to character encoding in general
* [[:Category:Character sets]] – articles detailing specific character encodings
* [[Hexadecimal#Representing hexadecimal|Hexadecimal representations]]
* ''[[Mojibake]]'' – character set mismap
* [[Mojikyō]] – a system ("glyph set") that includes over 100,000 Chinese character drawings, modern and ancient, popular and obscure
* [[Presentation layer]]
* [[TRON (encoding)|TRON]], part of the TRON project, is an encoding system that does not use Han Unification; instead, it uses "control codes" to switch between 16-bit "planes" of characters.
* [[Universal Character Set characters]]
* [[Charset sniffing]] – used in some applications when character encoding metadata is not available


== References ==
== References ==
Line 241: Line 235:


== Further reading ==
== Further reading ==
* {{cite book |title=Coded Character Sets, History and Development |work=The Systems Programming Series |last=Mackenzie |first=Charles E. |year=1980 |edition=1 |publisher=[[Addison-Wesley Publishing Company, Inc.]] |isbn=978-0-201-14460-4 |lccn=77-90165}}
* {{cite book |url=https://textfiles.meulie.net/bitsaved/Books/Mackenzie_CodedCharSets.pdf |title=Coded Character Sets, History and Development |series=The Systems Programming Series |author-last=Mackenzie |author-first=Charles E. |date=1980 |edition=1 |publisher=[[Addison-Wesley Publishing Company, Inc.]] |isbn=978-0-201-14460-4 |lccn=77-90165 |access-date=2019-08-25 |archive-url=https://web.archive.org/web/20160526172151/https://textfiles.meulie.net/bitsaved/Books/Mackenzie_CodedCharSets.pdf |archive-date=May 26, 2016 |url-status=live |df=mdy-all }}


== External links ==
== External links ==

Latest revision as of 23:28, 21 June 2024

Punched tape with the word "Wikipedia" encoded in ASCII. Presence and absence of a hole represents 1 and 0, respectively; for example, "W" is encoded as "1010111".

Character encoding is the process of assigning numbers to graphical characters, especially the written characters of human language, allowing them to be stored, transmitted, and transformed using digital computers.[1] The numerical values that make up a character encoding are known as "code points" and collectively comprise a "code space", a "code page", or a "character map".

Early character codes associated with the optical or electrical telegraph could only represent a subset of the characters used in written languages, sometimes restricted to upper case letters, numerals and some punctuation only. The low cost of digital representation of data in modern computer systems allows more elaborate character codes (such as Unicode) which represent most of the characters used in many written languages. Character encoding using internationally accepted standards permits worldwide interchange of text in electronic form.

The most used character encoding on the web is UTF-8, used in 98.2% of surveyed web sites, as of May 2024.[2] In application programs and operating system tasks, both UTF-8 and UTF-16 are popular options.[3][4]

History[edit]

The history of character codes illustrates the evolving need for machine-mediated character-based symbolic information over a distance, using once-novel electrical means. The earliest codes were based upon manual and hand-written encoding and cyphering systems, such as Bacon's cipher, Braille, international maritime signal flags, and the 4-digit encoding of Chinese characters for a Chinese telegraph code (Hans Schjellerup, 1869). With the adoption of electrical and electro-mechanical techniques these earliest codes were adapted to the new capabilities and limitations of the early machines. The earliest well-known electrically transmitted character code, Morse code, introduced in the 1840s, used a system of four "symbols" (short signal, long signal, short space, long space) to generate codes of variable length. Though some commercial use of Morse code was via machinery, it was often used as a manual code, generated by hand on a telegraph key and decipherable by ear, and persists in amateur radio and aeronautical use. Most codes are of fixed per-character length or variable-length sequences of fixed-length codes (e.g. Unicode).[5]

Common examples of character encoding systems include Morse code, the Baudot code, the American Standard Code for Information Interchange (ASCII) and Unicode. Unicode, a well-defined and extensible encoding system, has supplanted most earlier character encodings, but the path of code development to the present is fairly well known.

The Baudot code, a five-bit encoding, was created by Émile Baudot in 1870, patented in 1874, modified by Donald Murray in 1901, and standardized by CCITT as International Telegraph Alphabet No. 2 (ITA2) in 1930. The name baudot has been erroneously applied to ITA2 and its many variants. ITA2 suffered from many shortcomings and was often improved by many equipment manufacturers, sometimes creating compatibility issues. In 1959 the U.S. military defined its Fieldata code, a six-or seven-bit code, introduced by the U.S. Army Signal Corps. While Fieldata addressed many of the then-modern issues (e.g. letter and digit codes arranged for machine collation), it fell short of its goals and was short-lived. In 1963 the first ASCII code was released (X3.4-1963) by the ASCII committee (which contained at least one member of the Fieldata committee, W. F. Leubbert), which addressed most of the shortcomings of Fieldata, using a simpler code. Many of the changes were subtle, such as collatable character sets within certain numeric ranges. ASCII63 was a success, widely adopted by industry, and with the follow-up issue of the 1967 ASCII code (which added lower-case letters and fixed some "control code" issues) ASCII67 was adopted fairly widely. ASCII67's American-centric nature was somewhat addressed in the European ECMA-6 standard.[6]

Hollerith 80-column punch card with EBCDIC character set

Herman Hollerith invented punch card data encoding in the late 19th century to analyze census data. Initially, each hole position represented a different data element, but later, numeric information was encoded by numbering the lower rows 0 to 9, with a punch in a column representing its row number. Later alphabetic data was encoded by allowing more than one punch per column. Electromechanical tabulating machines represented date internally by the timing of pulses relative to the motion of the cards through the machine. When IBM went to electronic processing, starting with the IBM 603 Electronic Multiplier, it used a variety of binary encoding schemes that were tied to the punch card code.

IBM used several Binary Coded Decimal (BCD) six-bit character encoding schemes, starting as early as 1953 in its 702[7] and 704 computers, and in its later 7000 Series and 1400 series, as well as in associated peripherals. Since the punched card code then in use only allowed digits, upper-case English letters and a few special characters, six bits were sufficient. These BCD encodings extended existing simple four-bit numeric encoding to include alphabetic and special characters, mapping them easily to punch-card encoding which was already in widespread use. IBM's codes were used primarily with IBM equipment; other computer vendors of the era had their own character codes, often six-bit, but usually had the ability to read tapes produced on IBM equipment. These BCD encodings were the precursors of IBM's Extended Binary-Coded Decimal Interchange Code (usually abbreviated as EBCDIC), an eight-bit encoding scheme developed in 1963 for the IBM System/360 that featured a larger character set, including lower case letters.

In trying to develop universally interchangeable character encodings, researchers in the 1980s faced the dilemma that, on the one hand, it seemed necessary to add more bits to accommodate additional characters, but on the other hand, for the users of the relatively small character set of the Latin alphabet (who still constituted the majority of computer users), those additional bits were a colossal waste of then-scarce and expensive computing resources (as they would always be zeroed out for such users). In 1985, the average personal computer user's hard disk drive could store only about 10 megabytes, and it cost approximately US$250 on the wholesale market (and much higher if purchased separately at retail),[8] so it was very important at the time to make every bit count.

The compromise solution that was eventually found and developed into Unicode[vague] was to break the assumption (dating back to telegraph codes) that each character should always directly correspond to a particular sequence of bits. Instead, characters would first be mapped to a universal intermediate representation in the form of abstract numbers called code points. Code points would then be represented in a variety of ways and with various default numbers of bits per character (code units) depending on context. To encode code points higher than the length of the code unit, such as above 256 for eight-bit units, the solution was to implement variable-length encodings where an escape sequence would signal that subsequent bits should be parsed as a higher code point.

Terminology[edit]

Informally, the terms "character encoding", "character map", "character set" and "code page" are often used interchangeably.[9] Historically, the same standard would specify a repertoire of characters and how they were to be encoded into a stream of code units — usually with a single character per code unit. However, due to the emergence of more sophisticated character encodings, the distinction between these terms has become important.

  • A character is a minimal unit of text that has semantic value.[9][10]
  • A character set is a collection of elements used to represent text.[9][10] For example, the Latin alphabet and Greek alphabet are both character sets.
  • A coded character set is a character set mapped to set of unique numbers.[10] For historical reasons, this is also often referred to as a code page.[9]
  • A character repertoire is the set of characters that can be represented by a particular coded character set.[10][11] The repertoire may be closed, meaning that no additions are allowed without creating a new standard (as is the case with ASCII and most of the ISO-8859 series); or it may be open, allowing additions (as is the case with Unicode and to a limited extent Windows code pages).[11]
  • A code point is a value or position of a character in a coded character set.[10]
  • A code space is the range of numerical values spanned by a coded character set.[10][12]
  • A code unit is the minimum bit combination that can represent a character in a character encoding (in computer science terms, it is the word size of the character encoding).[10][12] For example, common code units include 7-bit, 8-bit, 16-bit, and 32-bit. In some encodings, some characters are encoded using multiple code units; such an encoding is referred to as a variable-width encoding.

Code pages[edit]

"Code page" is a historical name for a coded character set.

Originally, a code page referred to a specific page number in the IBM standard character set manual, which would define a particular character encoding.[13] Other vendors, including Microsoft, SAP, and Oracle Corporation, also published their own sets of code pages; the most well-known code page suites are "Windows" (based on Windows-1252) and "IBM"/"DOS" (based on code page 437).

Despite no longer referring to specific page numbers in a standard, many character encodings are still referred to by their code page number; likewise, the term "code page" is often still used to refer to character encodings in general.

The term "code page" is not used in Unix or Linux, where "charmap" is preferred, usually in the larger context of locales. IBM's Character Data Representation Architecture (CDRA) designates entities with coded character set identifiers (CCSIDs), each of which is variously called a "charset", "character set", "code page", or "CHARMAP".[12]

Code units[edit]

The code unit size is equivalent to the bit measurement for the particular encoding:

  • A code unit in ASCII consists of 7 bits;
  • A code unit in UTF-8, EBCDIC and GB 18030 consists of 8 bits;
  • A code unit in UTF-16 consists of 16 bits;
  • A code unit in UTF-32 consists of 32 bits.

Code points[edit]

A code point is represented by a sequence of code units. The mapping is defined by the encoding. Thus, the number of code units required to represent a code point depends on the encoding:

  • UTF-8: code points map to a sequence of one, two, three or four code units.
  • UTF-16: code units are twice as long as 8-bit code units. Therefore, any code point with a scalar value less than U+10000 is encoded with a single code unit. Code points with a value U+10000 or higher require two code units each. These pairs of code units have a unique term in UTF-16: "Unicode surrogate pairs".
  • UTF-32: the 32-bit code unit is large enough that every code point is represented as a single code unit.
  • GB 18030: multiple code units per code point are common, because of the small code units. Code points are mapped to one, two, or four code units.[14]

Characters[edit]

Exactly what constitutes a character varies between character encodings.

For example, for letters with diacritics, there are two distinct approaches that can be taken to encode them: they can be encoded either as a single unified character (known as a precomposed character), or as separate characters that combine into a single glyph. The former simplifies the text handling system, but the latter allows any letter/diacritic combination to be used in text. Ligatures pose similar problems.

Exactly how to handle glyph variants is a choice that must be made when constructing a particular character encoding. Some writing systems, such as Arabic and Hebrew, need to accommodate things like graphemes that are joined in different ways in different contexts, but represent the same semantic character.

Unicode encoding model[edit]

Unicode and its parallel standard, the ISO/IEC 10646 Universal Character Set, together constitute a unified standard for character encoding. Rather than mapping characters directly to bytes, Unicode separately defines a coded character set that maps characters to unique natural numbers (code points), how those code points are mapped to a series of fixed-size natural numbers (code units), and finally how those units are encoded as a stream of octets (bytes). The purpose of this decomposition is to establish a universal set of characters that can be encoded in a variety of ways. To describe this model precisely, Unicode uses its own set of terminology to describe its process:[12]

An abstract character repertoire (ACR) is the full set of abstract characters that a system supports. Unicode has an open repertoire, meaning that new characters will be added to the repertoire over time.

A coded character set (CCS) is a function that maps characters to code points (each code point represents one character). For example, in a given repertoire, the capital letter "A" in the Latin alphabet might be represented by the code point 65, the character "B" by 66, and so on. Multiple coded character sets may share the same character repertoire; for example ISO/IEC 8859-1 and IBM code pages 037 and 500 all cover the same repertoire but map them to different code points.

A character encoding form (CEF) is the mapping of code points to code units to facilitate storage in a system that represents numbers as bit sequences of fixed length (i.e. practically any computer system). For example, a system that stores numeric information in 16-bit units can only directly represent code points 0 to 65,535 in each unit, but larger code points (say, 65,536 to 1.4 million) could be represented by using multiple 16-bit units. This correspondence is defined by a CEF.

A character encoding scheme (CES) is the mapping of code units to a sequence of octets to facilitate storage on an octet-based file system or transmission over an octet-based network. Simple character encoding schemes include UTF-8, UTF-16BE, UTF-32BE, UTF-16LE, and UTF-32LE; compound character encoding schemes, such as UTF-16, UTF-32 and ISO/IEC 2022, switch between several simple schemes by using a byte order mark or escape sequences; compressing schemes try to minimize the number of bytes used per code unit (such as SCSU and BOCU).

Although UTF-32BE and UTF-32LE are simpler CESes, most systems working with Unicode use either UTF-8, which is backward compatible with fixed-length ASCII and maps Unicode code points to variable-length sequences of octets, or UTF-16BE,[citation needed] which is backward compatible with fixed-length UCS-2BE and maps Unicode code points to variable-length sequences of 16-bit words. See comparison of Unicode encodings for a detailed discussion.

Finally, there may be a higher-level protocol which supplies additional information to select the particular variant of a Unicode character, particularly where there are regional variants that have been 'unified' in Unicode as the same character. An example is the XML attribute xml:lang.

The Unicode model uses the term "character map" for other systems which directly assign a sequence of characters to a sequence of bytes, covering all of the CCS, CEF and CES layers.[12]

Unicode code points[edit]

In Unicode, a character can be referred to as 'U+' followed by its codepoint value in hexadecimal. The range of valid code points (the codespace) for the Unicode standard is U+0000 to U+10FFFF, inclusive, divided in 17 planes, identified by the numbers 0 to 16. Characters in the range U+0000 to U+FFFF are in plane 0, called the Basic Multilingual Plane (BMP). This plane contains most commonly-used characters. Characters in the range U+10000 to U+10FFFF in the other planes are called supplementary characters.

The following table shows examples of code point values:

Character Unicode code point Glyph
Latin A U+0041 Α
Latin sharp S U+00DF ß
Han for East U+6771
Ampersand U+0026 &
Inverted exclamation mark U+00A1 ¡
Section sign U+00A7 §

Example[edit]

Consider a string of the letters "ab̲c𐐀"—that is, a string containing a Unicode combining character (U+0332 ̲ COMBINING LOW LINE) as well a supplementary character (U+10400 𐐀 DESERET CAPITAL LETTER LONG I). This string has several Unicode representations which are logically equivalent, yet while each is suited to a diverse set of circumstances or range of requirements:

  • Four composed characters:
    a, , c, 𐐀
  • Five graphemes:
    a, b, _, c, 𐐀
  • Five Unicode code points:
    U+0061, U+0062, U+0332, U+0063, U+10400
  • Five UTF-32 code units (32-bit integer values):
    0x00000061, 0x00000062, 0x00000332, 0x00000063, 0x00010400
  • Six UTF-16 code units (16-bit integers)
    0x0061, 0x0062, 0x0332, 0x0063, 0xD801, 0xDC00
  • Nine UTF-8 code units (8-bit values, or bytes)
    0x61, 0x62, 0xCC, 0xB2, 0x63, 0xF0, 0x90, 0x90, 0x80

Note in particular that 𐐀 is represented with either one 32-bit value (UTF-32), two 16-bit values (UTF-16), or four 8-bit values (UTF-8). Although each of those forms uses the same total number of bits (32) to represent the glyph, it is not obvious how the actual numeric byte values are related.

Transcoding[edit]

As a result of having many character encoding methods in use (and the need for backward compatibility with archived data), many computer programs have been developed to translate data between character encoding schemes, a process known as transcoding. Some of these are cited below.

Cross-platform:

  • Web browsers – most modern web browsers feature automatic character encoding detection. On Firefox 3, for example, see the View/Character Encoding submenu.
  • iconv – a program and standardized API to convert encodings
  • luit – a program that converts encoding of input and output to programs running interactively
  • International Components for Unicode – A set of C and Java libraries to perform charset conversion. uconv can be used from ICU4C.

Windows:

  • Encoding.Convert – .NET API[15]
  • MultiByteToWideChar/WideCharToMultiByte – to convert from ANSI to Unicode & Unicode to ANSI[16][17]

Common character encodings[edit]

The most used character encoding on the web is UTF-8, used in 98.2% of surveyed web sites, as of May 2024.[2] In application programs and operating system tasks, both UTF-8 and UTF-16 are popular options.[3][4]

See also[edit]

References[edit]

  1. ^ "Character Encoding Definition". The Tech Terms Dictionary. 24 September 2010.
  2. ^ a b "Usage Survey of Character Encodings broken down by Ranking". W3Techs. Retrieved 29 April 2024.
  3. ^ a b "Charset". Android Developers. Retrieved 2 January 2021. Android note: The Android platform default is always UTF-8.
  4. ^ a b Galloway, Matt (9 October 2012). "Character encoding for iOS developers. Or UTF-8 what now?". www.galloway.me.uk. Retrieved 2 January 2021. in reality, you usually just assume UTF-8 since that is by far the most common encoding.
  5. ^ Tom Henderson (17 April 2014). "Ancient Computer Character Code Tables – and Why They're Still Relevant". Smartbear. Retrieved 29 April 2014.
  6. ^ Tom Jennings (1 March 2010). "An annotated history of some character codes". Retrieved 1 November 2018.
  7. ^ "IBM Electronic Data-Processing Machines Type 702 Preliminary Manual of Information" (PDF). 1954. p. 80. 22-6173-1. Archived (PDF) from the original on 9 October 2022.
  8. ^ Strelho, Kevin (15 April 1985). "IBM Drives Hard Disks to New Standards". InfoWorld. Popular Computing Inc. pp. 29–33. Retrieved 10 November 2020.
  9. ^ a b c d Shawn Steele (15 March 2005). "What's the difference between an Encoding, Code Page, Character Set and Unicode?". Microsoft Docs.
  10. ^ a b c d e f g "Glossary of Unicode Terms". Unicode Consortium.
  11. ^ a b "Chapter 3: Conformance". The Unicode Standard Version 15.0 – Core Specification (PDF). Unicode Consortium. September 2022. ISBN 978-1-936213-32-0.
  12. ^ a b c d e Whistler, Ken; Freytag, Asmus (11 November 2022). "UTR#17: Unicode Character Encoding Model". Unicode Consortium. Retrieved 12 August 2023.
  13. ^ "VT510 Video Terminal Programmer Information". Digital Equipment Corporation (DEC). 7.1. Character Sets - Overview. Archived from the original on 26 January 2016. Retrieved 15 February 2017. In addition to traditional DEC and ISO character sets, which conform to the structure and rules of ISO 2022, the VT510 supports a number of IBM PC code pages (page numbers in IBM's standard character set manual) in PCTerm mode to emulate the console terminal of industry-standard PCs.
  14. ^ "Terminology (The Java Tutorials)". Oracle. Retrieved 25 March 2018.
  15. ^ "Encoding.Convert Method". Microsoft .NET Framework Class Library.
  16. ^ "MultiByteToWideChar function (stringapiset.h)". Microsoft Docs. 13 October 2021.
  17. ^ "WideCharToMultiByte function (stringapiset.h)". Microsoft Docs. 9 August 2022.

Further reading[edit]

External links[edit]