ISO/IEC 646 encoding family

ISO/IEC 646 Invariant. Redlooped squares (⌘) denote national code points. Other red characters are changed in noteworthy minor modifications.
Standard	ISO/IEC 646,ITU T.50
Classification	7-bitBasic Latin encoding
Preceded by	US-ASCII
Succeeded by	ISO/IEC 8859,ISO/IEC 10646
Other related encoding(s)	DEC NRCS,World System Teletext Adaptations to other alphabets: ELOT 927,Symbol,KOI-7,SRPSCII and MAKSCII,ASMO 449,SI 960
v t e

ISO/IEC 646 is a set ofISO/IEC standards, described asInformation technology — ISO 7-bit coded character set for information interchange, and developed in cooperation withASCII at least since 1964.^[1][2] Since its first edition in 1967^[3] it has specified a 7-bit character code from which several national standards are derived.

ISO/IEC 646 was also ratified byECMA asECMA-6. The first version of ECMA-6 had been published in 1965,^[4] based on work the ECMA's Technical Committee TC1 had carried out since December 1960.^[4]

Characters in the ISO/IEC 646 Basic Character Set areinvariant characters.^[5] Since that portion of ISO/IEC 646, that is theinvariant character set shared by all countries, specified only those letters used in theISO basic Latin alphabet, countries using additional letters needed to create national variants of ISO/IEC 646 to be able to use their native scripts. Since transmission and storage of 8-bit codes was not standard at the time, the national characters had to be made to fit within the constraints of 7 bits, meaning that some characters that appear inASCII do not appear in other national variants of ISO/IEC 646.

ISO/IEC 646 and its predecessorASCII (ASA X3.4) largely endorsed existing practice regarding character encodings in thetelecommunications industry.

As ASCII did not provide a number of characters needed for languages other than English, a number of national variants were made that substituted some less-used characters with needed ones. Due to the incompatibility of the various national variants, an International Reference Version (IRV) of ISO/IEC 646 was introduced, in an attempt to at least restrict the replaced set to the same characters in all variants. The original version (ISO 646 IRV) differed fromASCII only in that code point 0x24, ASCII'sdollar sign ($) was replaced by theinternational currency symbol (¤). The final 1991 version of the code ISO/IEC 646:1991 is also known asITU T.50, International Reference Alphabet or IRA, formerlyInternational Alphabet No. 5 (IA5). This standard allows users to exercise the 12 variable characters (i.e., two alternative graphic characters and 10 national defined characters). Among these exercises, ISO 646:1991 IRV (International Reference Version) is explicitly defined and identical toASCII.^[6]

TheISO/IEC 8859 series of standards governing 8-bit character encodings supersede the ISO/IEC 646 international standard and its national variants, by providing 96 additional characters with the additional bit and thus avoiding any substitution of ASCII codes. TheISO/IEC 10646 standard, directly related toUnicode, supersedes all of the ISO646 and ISO/IEC 8859 sets with one unified set of character encodings using a larger 21-bit value.

A legacy of ISO/IEC 646 is visible on Windows, where in many East Asian locales thebackslash character used infilenames is rendered as¥ or other characters such as₩. Despite the fact that a different code for ¥ was available even on the original IBM PC'scode page 437, and a separate double-byte code for ¥ is available inShift JIS (although this often usesalternative mapping), so much text was created with the backslash code used for ¥ (due to Shift_JIS being officially based on ISO 646:JP, although Microsoft maps it as ASCII) that even modern Windows fonts have found it necessary to render the code that way. A similar situation exists with ₩ andEUC-KR. Another legacy is the existence oftrigraphs in theC programming language.

• ECMA-6 (1965-04-30), first edition (withdrawn)^[4]
• ISO/R646-1967 (withdrawn),^[3] or ECMA-6 (1967-06), second edition (withdrawn)^[3][4]
• ECMA-6 (1970-07), third edition (withdrawn)^[4][7]
• ISO 646:1972 (withdrawn), or ECMA-6 (1973-08), fourth edition (withdrawn)^[4][7]
• ISO 646:1983 (withdrawn),^[8] or ECMA-6 (1984-12, 1985-03), fifth edition (withdrawn)^[4]
• ITU-T Recommendation T.50 IA5 (1988-11-25) (withdrawn),^[9][10] or ISO/IEC 646:1991 (in force),^[11][12] or ECMA-6 (1991-12, 1997-08), sixth edition (in force)^[11]
• ITU-T Recommendation T.50 IRA (1992-09-18) (in force)^[9][13]

The following table shows the ISO/IEC 646 Invariant character set. Each character is shown with itsUnicode equivalent. National code points are gray with the ASCII character that is replaced. Yellow indicates a character that, in some regions, could be combined with a previous character as adiacritic using thebackspace character, which may affectglyph choice.

In addition to the invariant set restrictions, 0x23 is restricted to be either# or£ and 0x24 is restricted to be either$ or¤ in ECMA-6:1991, equivalent to ISO/IEC 646:1991.^[11] However, these restrictions are not followed by all national variants.^[14][15]

Some national variants of ISO/IEC 646 are as follows:

Some national character sets also exist which are based on ISO/IEC 646 but do not strictly follow its invariant set (see also§ Derivatives for other alphabets):

All the variants listed above are solely graphical character sets, and are to be used with aC0 control character set such as listed in the following table:

The following table lists supplementary graphical character sets defined by the same standard as specific ISO/IEC 646 variants. These would be selected by using a mechanism such asshift out or the NATS super shift (single shift),^[51] or by setting the eighth bit in environments where one was available:

The specifics of the changes for some of these variants are given in the following table. Character assignments unchanged across all listed variants (i.e. which remain the same as ASCII) are not shown.

For ease of comparison, variants detailed include national variants of ISO/IEC 646, DEC's closely relatedNational Replacement Character Set (NRCS) series used onVT200 terminals, the related EuropeanWorld System Teletext encoding series defined inETS 300 706, and a few other closely related encodings based on ISO/IEC 646. Individual code charts are linked from the second column. The cells with non-white background emphasize the differences fromUS-ASCII (also theBasic Latin subset of ISO/IEC 10646 and Unicode).

Several characters could be used ascombining characters, when preceded or followed with abackspaceC0 control. This is attested in the code charts for IRV, GB, FR1, CA, and CA2, which note that"',^ would behave as thediaeresis,acute accent,cedilla, andcircumflex (rather thanquotation marks, acomma, and anupward arrowhead) when preceded or followed by a backspace. The current PL standard explicitly directs the use of the backspace and apostrophe to form Polish letters with an acute accent. The tilde character (~) was similarlyintroduced as a diacritic (˜). This encoding method originated in the typewriter/teletype era when use of backspace would overstamp a glyph, and may be considereddeprecated.

Later, when wider character sets gained more acceptance,ISO/IEC 8859, vendor-specific character sets and eventuallyUnicode became the preferred methods of coding most of these variants.

TheNational Replacement Character Set (NRCS) is a family of 7-bit encodings introduced in 1983 byDEC with theVT200 series of computer terminals. It is closely related to ISO/IEC 646, being based on a similar invariant subset of ASCII, differing in retaining$ as invariant but not_ (although most NRCS variants retain the_, and hence comply with the ISO/IEC 646 invariant set). Most NRCS variants are closely related to corresponding national ISO/IEC 646 variants where they exist, with the exception of theDutch variant.

TheEuropean telecommunications standard ETS 300 706, "Enhanced Teletext specification", defines Latin, Greek, Cyrillic, Arabic, and Hebrew code sets with several national variants for both Latin and Cyrillic.^[66] Like NRCS and ISO/IEC 646, within the Latin variants, the family of encodings known as theG0 set are based on a similar invariant subset of ASCII, but do not retain either$ nor_ as invariant. Unlike NRCS, variants often differ considerably from corresponding national ISO/IEC 646 variants.

HP hascode page 1054, which adds the medium shade (▒, U+2592) at 0x7F.^[94]Code page 1052 replaces a few ASCII characters from code page 1054.^[95]

Some 7-bit character sets for non-Latin alphabets are derived from the ISO/IEC 646 standard: these do not themselves constitute ISO/IEC 646 due to not following its invariant code points (often replacing the letters of at least one case), due to supporting differing alphabets which the set of national code points provide insufficient encoding space for. Examples include:

• 7-bit Turkmen (ISO-IR-230).^[96]
• 7-bit Greek.
  • InELOT 927 (ISO-IR-088),^[48] theGreek alphabet is mapped in alphabetical order (except for the final-sigma) to positions 0x61–0x71 and 0x73–0x79, on top of the Latin lowercase letters.
  • ISO-IR-018^[97] maps the Greek alphabet over both letter cases using a different scheme (not in alphabetical order, but trying where possible to match Greek letters over Roman letters which correspond in some sense), and ISO-IR-019^[98] maps the Greek uppercase alphabet over the Latin lowercase letters using the same scheme as ISO-IR-018.
  • The lower half of theSymbol font character encoding^[99] uses its own scheme for mapping Greek letters of both cases over the ASCII Roman letters, also trying to map Greek letters over Roman letters which correspond in some sense, but making different decisions in this regard (see chart below). It also replaces invariant code points 0x22 and 0x27 and five national code points with mathematical symbols. Although not intended for use in typesetting Greek prose, it is sometimes used for that purpose.
  • ISO-IR-027^[49] (detailed in the chart above rather than below) includes the Latin alphabet unchanged, but adds some Greek capital letters which cannot be represented with Latin-scripthomoglyphs; while it is explicitly based on ISO/IEC 646, some of these are mapped to code points which are invariant in ISO/IEC 646 (0x21, 0x3A, and 0x3F), and it is therefore not a true ISO/IEC 646 variant.
  • TheWorld System Teletext encoding for Greek uses yet another scheme of mapping Greek letters in alphabetical order over the ASCII letters of both cases, notably including several letters with diacritics.^[100]
• 7-bit Cyrillic
  • KOI-7 or Short KOI, used forRussian. The Cyrillic characters are mapped to positions 0x60–0x7E, on top of the Latin lowercase letters, matching homologous letters where possible (where в is mapped to w, not v). Superseded by theKOI-8 variants.
  • SRPSCII and MAKSCII, Cyrillic variants of YUSCII (the Latin variant is YU/ISO-IR-141 in the chart above), used forSerbian andMacedonian respectively. Largely homologous to the Latin variant of YUSCII (following Serbiandigraphiarules), except forЉ (lj),Њ (nj),Џ (dž), andѕ (dz), which correspond to digraphs inLatin-script orthography, and are mapped over letters which are not used in Serbian or Macedonian (q, w, x, y).
  • The G0 sets for theWorld System Teletext encodings for Russian/Bulgarian^[101] and Ukrainian^[102] use G0 sets similar to KOI-7 with some modifications. The corresponding G0 set for Serbian Cyrillic^[a][103] uses a scheme based on the Teletext encoding for Latin-scriptSerbo-Croatian andSlovene, as opposed to the significantly different YUSCII.
• 7-bit Hebrew,SI 960. TheHebrew alphabet is mapped to positions 0x60–0x7A, on top of the lowercase Latin letters (and grave accent for aleph). 7-bit Hebrew was always stored in visual order. This mapping with the high bit set, i.e. with the Hebrew letters in 0xE0–0xFA, isISO/IEC 8859-8. The World System Teletext encoding for Hebrew uses the same letter mappings, but uses BS_Viewdata as its base encoding (whereas SI 960 uses US-ASCII) and includes ashekel sign at 0x7B.
• 7-bit Arabic,ASMO 449 (ISO-IR-089).^[104] TheArabic alphabet is mapped to positions 0x41–0x5A and 0x60–0x6A, on top of both uppercase and lowercase Latin letters.

A comparison of some of these encodings is below. Only one case is shown, except in instances where the cases are mapped to different letters. In such instances, the mapping with the smallest code is shown first. Possible transcriptions are given for some letters; where this is omitted, the letter can be considered to correspond to the Roman one which it is mapped over.

• ISO/IEC 2022Information technology: Character code structure and extension techniques
• ISO/IEC 6937 (ANSI)
• ISO/IEC JTC 1/SC 2

• Fischer, Eric, ed. (1975) [1972].Source documents on the history of character codes, 1972–1975 (Compilation). Archived from the original on 2020-06-07. Retrieved2020-06-07{{cite book}}: CS1 maint: bot: original URL status unknown (link) (79 pages) including:Bemer, Robert William (1972). "a view of the history of the ISO character set".Honeywell Computer Journal.6 (4). Phoenix, Arizona, USA: Honeywell Information Systems:274–286,287–291. (13+5 pages) and many other documents and correspondence.

• ISO/IEC 646:1991 Information technology — ISO 7-bit coded character set for information interchange
• Zeichensatz nach ISO 646 (ASCII) (in German)
• History atGNU Aspell website
• ISO646 Character Tables Character Tables by Koichi Yasuoka (安岡孝) (seeDomestic ISO646 Character Tables andQuasi-ISO646 Character Tables)
• Turkish TextDeasciifier a tool (based on statistical pentagram analysis of the Turkish language) which reverts an ASCII'fied Turkish text by determining the appropriate (but ambiguous) diacritics normally needed in Turkish but missing in the US-ASCII set.

• Character sets
• Ecma standards
• ISO/IEC standards

• CS1 maint: numeric names: authors list
• CS1 maint: multiple names: authors list
• Articles with short description
• Short description matches Wikidata
• Use dmy dates from June 2019
• CS1 maint: bot: original URL status unknown