Jump to content

Code page 970

From Alfawiki
Adapted from the English Wikipedia article Code page 970, available under CC BY-SA 4.0Updated 9 August 2025
Extended Unix Code (EUC)
Company typeCharacter encoding scheme
IndustryComputing, Information technology
ProductsCharacter encodings for Japanese, Korean, simplified Chinese scripts

Extended Unix Code (EUC) represents a multibyte character encoding scheme mainly utilized for Japanese, Korean, and simplified Chinese scripts.

Typically, EUC encodings employ variable-length schemes where characters from an -compliant set (such as ASCII) are encoded in a single byte, while characters belonging to a 94×94 coded set (for example, ) require two bytes. Instances include EUC-CN (based on GB 2312) and EUC-KR. In the case of EUC-JP, characters can be up to three bytes long, including an initial byte , whereas EUC-TW characters may extend to four bytes.

Although contemporary software predominantly uses UTF-8 for its extensive character repertoire and cross-platform compatibility, EUC continues to be extensively implemented, particularly EUC-KR within South Korea.

Encoding structure

EUC is founded on the standard, which specifies graphical character sets represented by sequences of 94 bytes, either 7-bit (0x21–7E) or 8-bit (0xA1–FE). This framework supports sets containing 94 characters each, allowing up to 943 characters when multiple sets are combined. Subsequent revisions permit inclusion of bytes 0xA0 and 0xFF within sets, enabling 96-character sets. The byte ranges 0x00–1F and 0x80–9F are reserved exclusively for control functions.

As an 8-bit adaptation of , EUC accommodates up to four coded character sets, designated G0 through G3. G0 typically corresponds to an -compliant set such as ASCII, (), or (a component of JIS X 0201), accessed via GL (0x21–7E). When ASCII is employed, EUC functions as an extended ASCII encoding; notably, the byte 0x5C represents a yen sign in EUC-JP and a won sign in EUC-KR.

Other code sets are invoked through GR by setting the most significant bit. To encode characters in EUC, each byte’s most significant bit is set (adding 128 to the original 7-bit value or 160 in kuten notation), thereby differentiating extended code bytes from standard ASCII. Characters from code sets G2 and G3 are preceded by control bytes (0x8E) and (0x8F), respectively. Bytes outside the range of 0xA0–0xFF within these sets are invalid.

While EUC does not employ announcement or designation sequences from , its specification aligns with four particular announcement sequences:

Sequence Hexadecimal Description
ESC SP C 1B 20 43 ISO-8 (8-bit, G0 in GL, G1 in GR)
ESC SP Z 1B 20 5A Accessing G2 via SS2
ESC SP [ 1B 20 5B Accessing G3 via SS3
ESC SP \ 1B 20 5C Single-shift invocation over GR

Fixed-length format

The ISO-2022-based variable-length encoding commonly referred to as the EUC packed format represents the standard EUC encoding method. Internally, data may be transformed into a fixed-length variant known as the EUC complete two-byte format, which encodes:

  • Code set 0 using two bytes within the range 0x21–0x7E (the first byte can be 0x00).
  • Code set 1 with two bytes spanning 0xA0–0xFF (the first byte may be 0x80).
  • Code set 2 as one byte between 0x21–0x7E (or possibly 0x00) followed by one byte in the range of 0xA0–0xFF.
  • Code set 3 consisting of one byte in the range of 0xA0–0xFF (or possibly 0x80) followed by one byte between 0x21–0x7E.

Initial bytes such as 0x00 and 0x80 serve as indicators for single-byte code sets. Additionally, a fixed-length four-byte format exists. These fixed-length formats are generally intended for internal processing rather than external data exchange.

IANA has registered EUC-JP in both formats: the packed variant under "EUC-JP" or "csEUCPkdFmtJapanese" and the fixed-width variant as "csEUCFixWidJapanese". Of these, only the packed format is incorporated into the WHATWG Encoding Standard used for HTML5.

EUC-CN

EUC-CN represents the encoding standard for simplified Chinese characters. In contrast to Japanese encodings such as JIS X 0208 and ISO-2022-JP, EUC-CN is generally not employed in a 7-bit format. However, variants like HZ, which encapsulate text within ASCII delimiters, have been utilized on platforms including USENET.

Standard ASCII characters maintain their original encoding. Characters from the set are encoded using two bytes, each ranging between 0xA1 and 0xFE.

748 code

The "748" code, associated with EUC-CN, was implemented in Beijing Founder Technology’s WITS typesetting system (now superseded by FITS). While it encompasses the full character set of , it does not comply with EUC standards, distinguishing it from genuine EUC encodings. Its structure involves an 8-bit lead byte, and the second byte is identified by its most significant bit, resembling Big5 and other non-ISO 2022 DBCS schemes. The segment outside GB2312 includes traditional Chinese characters, those specific to Hong Kong, and glyphs used for newspaper composition.

IBM code pages 1380, 1381, 1382 and 1383

IBM’s code page 1381 (CCSID 1381) merges single-byte code page 1115 with double-byte code page 1380. It encodes GB 2312 similarly to EUC-CN but extends the range of lead bytes up to 0x8C. Additionally, it incorporates 31 IBM-selected characters (from 0x8CE0 to 0x8CFE) along with 1880 user-defined characters whose lead bytes fall between 0x8D and 0xA0.

Code page 1383 (CCSID 1383) combines single-byte code page 367 with double-byte code page 1382. It adheres to the EUC layout but positions the 31 IBM-selected characters at addresses ranging from 0xFEE0 to 0xFEFE. This page contains only 1360 user-defined characters distributed outside GB 2312 locations. The alternative CCSID 5479 specifies a pure EUC-CN code page that uses CCSID 9574 as its double-byte set, excluding both IBM-selected and user-defined characters.

GBK and GB 18030

GBK extends the base , creating an enhanced version of EUC-CN capable of representing a wider spectrum of CJK characters, including traditional Chinese characters and some used in Japanese, primarily sourced from . It does not qualify as a true EUC encoding because ASCII bytes may appear as trailing bytes, and C1 bytes can function as either lead or trail bytes due to the expanded encoding range.

Various implementations of GBK exist within Windows code page 936 (Microsoft’s simplified Chinese standard) and IBM’s code page 1386.

The Unicode-based standard expands upon GBK by encoding the entirety of Unicode. This variable-length encoding utilizes up to four bytes per character, requiring a significantly larger coding space. As an extension of GBK, it is a superset of EUC-CN but does not conform to strict EUC definitions. Its character repertoire aligns with other Unicode transformation formats such as UTF-8.

Mac OS Chinese Simplified

The classic Mac OS Chinese Simplified encoding (Code page 10008 or x-mac-chinesesimp) diverges from the EUC framework. It assigns specific single-byte values—such as 0x80, 0x81, 0x82, 0xA0, 0xFD, 0xFE, and 0xFF—to characters including ü, special font metrics symbols, non-breaking space, ©, ™, and ellipsis marks. This contrasts with both EUC (where bytes like 0xFD and 0xFE serve as lead bytes) and GBK (where bytes such as 0x81, 0x82, 0xFD, and 0xFE act as lead bytes) in terms of single versus double-byte character definitions.

Its utilization of bytes like 0xA0, 0xFD, 0xFE, and 0xFF corresponds with Apple's variant of Shift_JIS.

Within the double-byte area, it incorporates two extensions to the GB 2312-80 character set found in rows six and eight. These "standard extensions" are not proprietary to Apple: row eight originates from GB 6345.1, both extensions are included in GB/T 12345 (the traditional Chinese adaptation of GB 2312), and both form part of GB 18030, which succeeded GB 2312.

EUC-JP

EUC-JP is a variable-length character encoding that supports three Japanese character set standards: , , and . It is also referred to as Unixized JIS (UJIS) or AT&T JIS. As of 2025, it constitutes 2.3% of Japanese-language websites, ranking as the second most utilized Japanese encoding after UTF-8. IBM labels this encoding as Code page 954, while Microsoft assigns it code pages 51932 and 20932.

This encoding enables the combination of 7-bit ASCII with 8-bit Japanese characters without relying on escape sequences like those used in ISO-2022-JP. Unlike Shift JIS, it prevents ASCII bytes from appearing as trailing bytes.

A related variant, EUC-JISx0213 (also known as EUC-JIS-2004), encodes both and , similarly to its Shift_JIS-based equivalent, Shift_JISx0213.

Though EUC-JP experienced limited use on Japanese personal computers and Macintosh systems—which preferred Shift JIS or its derivatives such as Windows code page 932 and MacJapanese—it gained broad adoption in Unix and Unix-like environments, with the exception of HP-UX. The selection between EUC-JP and Shift_JIS frequently depends on the operating system utilized by the content creator.

Details of character encoding include:

  • C0 control characters, space, and DEL are encoded identically to ASCII.
  • ASCII graphical characters (code set 0) occupy one byte (0x21–0x7E). Most implementations encode standard ASCII, consistent with W3C/WHATWG Encoding specifications applied in HTML5. The byte 0x5C generally corresponds to Unicode U+005C REVERSE SOLIDUS but may render as a Yen symbol in certain Japanese fonts for compatibility reasons.
  • Characters from JIS X 0208 (code set 1) are represented using two bytes (0xA1–0xFE), differing from ISO-2022-JP by having the high bit set. Some versions incorporate vendor-specific extensions. In EUC-JIS-2004, this encodes the first plane of JIS X 0213, which extends JIS X 0208.
  • Half-width katakana from the upper range of JIS X 0201 (code set 2) are encoded with two bytes: an initial byte of 0x8E followed by a byte within 0xA1–0xDF. Certain variants add IBM vendor extensions.
  • Characters from JIS X 0212 (code set 3) use three bytes: starting with 0x8F, followed by two bytes ranging from 0xA1 to 0xFE. Some versions include IBM Shift JIS extensions in rows 83 and 84. In EUC-JIS-2004, this represents the second plane of JIS X 0213 without overlapping with standard JIS X 0212 rows. Implementations such as Python's support both JIS X 0212 and JIS X 0213 plane two within this code set.

Vendor-specific extensions from organizations like the Open Software Foundation, IBM, or NEC are often incorporated directly within code sets rather than employing invalid EUC sequences. Certain proprietary encodings partially align with EUC-JP by encoding JIS X 0208 over GR but do not adhere to the packed EUC format or utilize single shifts; notable exceptions include Super DEC Kanji.

DEC Kanji

Digital Equipment Corporation developed two EUC-JP variants that partially comply with the packed EUC format, closely resembling a full two-byte structure. The "DEC Kanji" encoding largely corresponds to fixed-length (two-byte) EUC; however, code set 0 does not require null-byte padding on the left. Code set 1 uses JIS X 0208; code set 2 (half-width katakana) is omitted; code set 3 encodes two-byte user-defined characters similar to fixed-width formats but without a shift byte. Only the initial 31 rows of code set 3 are designated for user-defined characters; rows from 32 to 94 remain reserved.

The "Super DEC Kanji" variant accepts codes from both "DEC Kanji" and packed-format EUC, encompassing five code sets in total. It permits usage of the entire user-defined code set along with unused rows at the edges of JIS X 0208 and JIS X 0212 for custom characters.

HP-16

Hewlett-Packard introduced "HP-16" as a counterpart to their "HP-15" variant of Shift JIS. This encoding represents characters using EUC-JP byte sequences but excludes single shift codes, thereby omitting code sets 2 and 3. Additionally, HP-16 incorporates three user-defined areas positioned outside the standard packed EUC format:

  • Lead bytes ranging from 0xA1 to 0xC2 with trail bytes between 0x21 and 0x7E
  • Lead bytes from 0xC3 to 0xE3 accompanied by trail bytes from 0x21 to 0x3F
  • Lead bytes spanning 0xC3 to 0xE1 with trail bytes between 0x40 and 0x64

IKIS

The Interactive Kanji Information System (IKIS) encoding, developed by Data General, closely resembles EUC-JP but excludes single shift sequences, thus only utilizing code sets 0 and 1. Half-width katakana characters are placed within row 8 of JIS X 0208, overlapping with box-drawing symbols introduced in 1983. User-defined characters occupy rows 9 through 12 of the same JIS standard.

Adaptations of EUC-JP for EBCDIC

KEIS (Kanji-processing Extended Information System) is an EBCDIC-based encoding employed by Hitachi that supports double-byte characters through shift sequences, making it a stateful encoding scheme. Mode switching between single-byte and double-byte is controlled by specific shift codes. Characters from JIS X 0208 retain the same byte patterns as in EUC-JP, which leads to duplicated encodings for the ideographic space—represented as 0x4040 in the DBCS-Host format and as 0xA1A1 in EUC-JP. Unlike IBM’s DBCS-Host encoding, KEIS extends its lead byte range down to 0x59 and reserves the range 0x81 to 0xA0 for user-defined characters; other areas are allocated for corporate-specific kanji and non-kanji symbols.

JEF (Japanese-processing Extended Feature) is an EBCDIC encoding utilized on Fujitsu FACOM mainframes, differing from FMR—a Shift JIS variant used on Fujitsu personal computers. Similar to KEIS, JEF employs a stateful mechanism toggling between single-byte and double-byte modes via designated shift codes. The byte sequences for JIS X 0208 align with those found in EUC-JP. Its lead byte range extends backward to 0x41, with user-defined characters occupying bytes from 0x80 to 0xA0. Lead bytes from 0x41 through 0x7F correspond to row numbers 101 through 163 in kuten notation (with row 162 unused). Rows numbered 101 to 148 represent extended kanji characters, while rows 149 to 163 cover extended non-kanji symbols.

EUC-KR

EUC-KR is a variable-length character encoding designed for Korean text, combining two coded character sets: KS X 1001 (previously KS C 5601) and either KS X 1003 or ASCII, depending on the specific variant. Established by KS X 1001 (formerly KS C 5861) and standardized under the name EUC-KR in ISO/IEC standards, it encodes KS X 1001 characters using two bytes within the range of 0xA1 to 0xFE, while KS X 1003 or ASCII characters are represented as single bytes between 0x21 and 0x7E.

In South Korea, this encoding is commonly referred to as Wansung (). IBM classifies the double-byte segment as Code page 971, while the variant including ASCII is labeled Code page 970. Microsoft implements these as Code page 20949 ("Korean Wansung") and Code page 51949 ("EUC Korean"), respectively.

By mid-2025, EUC-KR accounts for less than one-twentieth of one percent of global websites but continues to hold a significant share—approximately 4.3%—among South Korean web pages. Despite gradual migration toward UTF-8, especially on Linux and macOS platforms, EUC-KR remains the predominant legacy encoding throughout Korea across macOS, Unix-like systems, and Windows environments.

For new implementations, UTF-8 is favored due to superior cross-platform compatibility and enhanced vendor support.

Unified Hangul Code

A widely recognized extension of EUC-KR is the Unified Hangul Code (or ), which serves as the standard Korean codepage for Microsoft Windows. Microsoft designates this as code page 949, whereas IBM identifies it under code pages 1261 or 1363. It is important to note that IBM’s code page 949 is a separate and unrelated extension of EUC-KR.

The Unified Hangul Code expands upon EUC-KR by incorporating non-EUC byte sequences to represent additional syllable blocks, thereby achieving full coverage of all composed syllables found in Johab and Unicode standards. The W3C/WHATWG Encoding Standard for HTML5 integrates these extensions within its definition of EUC-KR.

Mac OS Korean (HangulTalk)

The Korean encoding used on Mac OS, referred to as Code page 10003 or x-mac-korean, includes EUC-KR as a foundational subset and was implemented in HangulTalk—the Korean localization for classic Mac OS. Created by Elex Computer, Apple’s authorized distributor in South Korea at that time, HangulTalk introduces additional extension characters by utilizing lead bytes ranging from 0xA1 to 0xAD within otherwise unassigned EUC-KR space, alongside non-EUC byte codes outside this range. Some of these are decorative dingbats that remain consistent regardless of font style.

A considerable number of these characters do not have precise Unicode equivalents; Apple’s software handles them through a variety of methods, including mapping to combining character sequences, approximate matches using private-use modifiers, or private-use code points. Furthermore, Apple assigns single-byte codes beyond the standard EUC-KR range for supplementary characters: 0x80 (mandatory space), 0x81 (won sign ₩), 0x82 (en dash), 0x83 (copyright symbol ©), 0x84 (wide underscore), and 0xFF (ellipsis). Although these codes lie outside the typical lead byte ranges for EUC-KR, some coincide with lead bytes used in the Unified Hangul Code.

EUC-KP

Comparable to KS X 1001, North Korea’s KPS 9566 standard is frequently utilized in an EUC-based format often referred to as EUC-KP. Modern iterations extend this EUC encoding with additional characters represented by non-EUC two-byte sequences, following a strategy similar to that of the Unified Hangul Code.

EUC-TH

While certain single-byte encodings such as those from the ISO/IEC 8859 family conform structurally to the EUC scheme, they are seldom classified explicitly as EUC. The designation is employed on Solaris systems to refer specifically to TIS-620 encoding.

EUC-TW

EUC-TW is a variable-length character encoding that supports ASCII alongside up to sixteen planes of , each plane consisting of a 94×94 grid. This encoding caters primarily to traditional Chinese characters used in Taiwan, where variants of Big5 are prevalent despite Big5 only encompassing the first two planes defined by CNS 11643. Meanwhile, the adoption of UTF-8 continues to rise.

Principal characteristics of this encoding include:

  • Standard ASCII and control codes retain their usual representations.
  • ASCII graphical characters (G0) occupy their conventional single-byte ranges (0x21–0x7E).
  • Characters belonging to CNS 11643 plane 1 are encoded as two bytes within the GR range (0xA1–0xFE).
  • Characters from planes one through sixteen employ four-byte sequences:
    • The initial byte is always 0x8E (Single Shift 2).
    • The second byte ranges from 0xA1 to 0xB0, indicating the specific plane number after subtracting 0xA0.
    • The third and fourth bytes fall within the GR range (0xA1–0xFE).

It is noteworthy that CNS 11643 plane 1 appears twice in this scheme—once designated as code set 1 and again within code set 2.

See also

External links

Related profiles

CCode page 971CCode page 954CCode page 952CCode page 955
Retrieved from "https://www.alfawiki.org/index.php?title=Code_page_970&oldid=28712"