Jump to content

Code page 971

From Alfawiki
Adapted from the English Wikipedia article Code page 971, available under CC BY-SA 4.0Updated 9 August 2025
Extended Unix Code (EUC)
Company typeCharacter encoding scheme
IndustryComputer software, Information technology
Area served
Mainly Japan, Korea, China
ProductsEUC-CN, EUC-KR, EUC-JP, EUC-TW

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

Typically, EUC encodings are variable-length systems where characters from an compliant set (such as ASCII) are encoded in a single byte, while those from a 94×94 coded set (for instance, ) require two bytes. Examples include EUC-CN (based on GB 2312) and EUC-KR. In contrast, EUC-JP can encode characters using up to three bytes, beginning with an initial , whereas EUC-TW supports sequences as long as four bytes.

Despite modern software favoring UTF-8 for its extensive glyph repertoire and enhanced compatibility, EUC remains prevalent, particularly EUC-KR within South Korea.

Encoding structure

EUC derives from the standard, which specifies graphical character sets composed of sequences containing 94 7-bit bytes (ranging from 0x21 to 0x7E), or with the eighth bit set, from 0xA1 to 0xFE. This framework allows for character sets of 94 members, expanding up to 8836 (94²) or even 830,584 (94³) possible characters. Initially, codes 0x20 and 0x7F were reserved for space and delete functions; however, subsequent standards permitted the inclusion of 0xA0 and 0xFF within character sets under specific conditions. The byte ranges 0x00–1F and 0x80–9F remain designated for control characters.

Unlike the 7-bit profiles such as ISO-2022-JP, EUC operates as an 8-bit variant of . Only compliant character sets are eligible for EUC representation. Up to four coded character sets—designated G0, G1, G2, and G3—are encoded. The G0 set corresponds to an compliant repertoire like ASCII, (), or , mapped over GL (0x21–0x7E). When ASCII is employed, EUC functions as an extended ASCII encoding; notable exceptions include the use of byte 0x5C (backslash) to denote the yen sign in EUC-JP and the won sign in EUC-KR.

Other code sets are invoked through GR (the most significant bit set). Consequently, each EUC byte has its highest bit enabled—effectively adding 128 to each original 7-bit value—to differentiate between standard and extended codes. Characters belonging to G2 and G3 sets are introduced with control prefixes SS2 (0x8E) and SS3 (0x8F), respectively. Bytes outside the range of 0xA0–0xFF within code sets 1 through 3 are considered invalid in EUC.

Although EUC itself does not utilize the announcement and designation sequences defined by , its specification aligns with four such sequences:

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

Fixed-length format

The commonly used ISO-2022-based variable-length method—often referred to as the EUC packed format—is regarded as the standard EUC encoding. Internally, EUC data can be transformed into a fixed-length form known as the EUC complete two-byte format, which encodes character sets as follows:

  • Code set 0 uses two bytes within the range of 0x21–0x7E (the first byte may be 0x00).
  • Code set 1 employs two bytes between 0xA0–0xFF (with a possible first byte of 0x80).
  • Code set 2 consists of one byte in the range of 0x21–0x7E (or possibly 0x00) followed by one byte in the range of 0xA0–0xFF.
  • Code set 3 comprises one byte from the range of 0xA0–0xFF (or possibly 0x80) followed by one byte between 0x21–0x7E.

The initial bytes of 0x00 and 0x80 appear when code sets contain only a single byte. Additionally, a four-byte fixed-length format exists but is seldom used for data interchange; these fixed-length schemes are primarily intended for internal processing purposes.

IANA registers EUC-JP under both formats: the packed version as "EUC-JP" or "csEUCPkdFmtJapanese", and the fixed-width variant as "csEUCFixWidJapanese". However, only the packed format is incorporated into the WHATWG Encoding Standard for HTML5.

EUC-CN

EUC-CN serves as the standard encoding format for simplified Chinese characters. In contrast to Japanese standards like JIS X 0208 and ISO-2022-JP, EUC-CN is seldom implemented in a 7-bit version. Nevertheless, variants such as HZ, which mark Chinese text using ASCII sequences, have occasionally been utilized on platforms like USENET.

Within this encoding, ASCII characters maintain their conventional byte values, while Chinese characters are encoded using two bytes, each ranging from 0xA1 to 0xFE.

748 code

The "748" encoding, associated with EUC-CN, was employed by Beijing Founder Technology’s WITS typesetting system (which has since been superseded by FITS). Although it encompasses all GB2312 characters, it does not adhere strictly to EUC standards. Unlike genuine EUC encodings, it uses an 8-bit lead byte and identifies the second byte by its highest bit, resembling Big5 and other double-byte character sets that do not conform to ISO 2022. Its non-GB2312 segment incorporates traditional characters, those used in Hong Kong, and additional glyphs tailored for newspaper printing.

IBM code pages 1380, 1381, 1382 and 1383

IBM code page 1381 (CCSID 1381) merges the single-byte code page 1115 (CCSID 1115) with the double-byte code page 1380 (CCSID 1380). This combination encodes GB2312 similarly to EUC-CN but extends the lead byte scope up to 0x8C. It introduces 31 IBM-selected characters within the range 0x8CE0–0x8CFE and accommodates 1880 user-defined characters with lead bytes spanning from 0x8D to 0xA0.

Code page 1383 (CCSID 1383) pairs the single-byte code page 367 with double-byte code page 1382 (CCSID 1382), adhering to the EUC structure. It also includes the same set of 31 IBM-selected characters at positions 0xFEE0–0xFEFE but supports only 1360 user-defined characters scattered outside the GB2312 code points. CCSID 5479 represents a pure EUC-CN code page that relies on CCSID 9574 as its double-byte component, excluding both IBM-selected and user-defined characters.

GBK and GB 18030

GBK extends EUC-CN by defining a broader encoding that supports an increased number of CJK characters, such as traditional Chinese characters and certain Japanese symbols from . However, GBK is not a strict EUC code because ASCII bytes may appear as trailing bytes, and C1 control bytes can function as either lead or trailing bytes due to its expanded encoding range.

Variants of GBK are implemented in Windows code page 936, which serves as Microsoft Windows’ simplified Chinese code page, as well as in IBM’s code page 1386.

The Unicode-based encoding extends GBK further to encompass the entire Unicode spectrum. This variable-length format utilizes up to four bytes per character to accommodate its extensive character set. As an extension of GBK, it forms a superset of EUC-CN but does not conform to genuine EUC coding. 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) differs from EUC-CN by assigning particular byte values (0x80, 0x81, 0x82, 0xA0, 0xFD, 0xFE, and 0xFF) to characters including ü, special font metrics symbols, non-breaking space, ©, ™, and ellipsis. This approach contrasts with EUC and GBK in how single-byte and lead bytes are categorized.

Its utilization of bytes such as 0xA0, 0xFD, 0xFE, and 0xFF corresponds with Apple’s variant of Shift_JIS.

Notably, Mac OS Chinese Simplified incorporates two extensions within rows 6 and 8 beyond the fundamental GB 2312-80 set. These "standard extensions" are not proprietary to Apple: row 8 is derived from GB 6345.1, and both extensions are part of GB/T 12345, the traditional Chinese counterpart of GB 2312, as well as included in GB 18030, which succeeded GB 2312.

EUC-JP

EUC-JP, also referred to as Unixized JIS or UJIS, is a variable-length character encoding that encompasses three Japanese character set standards: , , and . It supports text in Japanese, English, and Russian, and is identified by IBM as Code page 954. Microsoft designates this encoding under code pages 51932 and 20932.

As of January 2025, EUC-JP is utilized by under 0.1% of all websites globally but represents 2.3% of Japanese-language sites, ranking it second in popularity for Japanese encodings after UTF-8. In contrast to Shift JIS, EUC-JP prevents ASCII bytes from appearing as trailing bytes and eliminates the need for escape sequences, thereby simplifying the combination of 7-bit ASCII with 8-bit Japanese characters.

A variant known as EUC-JISx0213 or EUC-JIS-2004 extends support to alongside . While EUC-JP found widespread adoption in Unix and Unix-like environments (except HP-UX), it experienced limited usage on Japanese personal computers and Macintosh systems, which predominantly employed Shift JIS or its derivatives (Windows code page 932 and MacJapanese). The preference between EUC-JP and Shift JIS on Japanese websites often reflects the author's choice of operating system.

Encoding specifications include:

  • ASCII characters (code set 0) are represented using standard single-byte codes ranging from 0x21 to 0x7E, with some variants encoding the lower half of . EUC-JP adheres to the W3C/WHATWG Encoding standard, mapping bytes such as 0x5C to Unicode U+005C (backslash), which may render as a Yen symbol in Japanese fonts for compatibility reasons.
  • Characters from JIS X 0208 (code set 1) are encoded as two bytes within the range 0xA1–0xFE; this differs from ISO-2022-JP by having the high bit set. In EUC-JIS-2004, this set encodes the first plane of , which is a superset of JIS X 0208.
  • Half-width kana characters from the upper portion of (code set 2) are encoded using two bytes: an initial byte of 0x8E followed by a byte between 0xA1 and 0xDF. Certain variants incorporate IBM vendor-specific extensions.
  • JIS X 0212 characters (code set 3) utilize a three-byte sequence beginning with 0x8F and followed by two bytes in the range 0xA1–0xFE. Some EUC-JP implementations extend this set with IBM Shift JIS enhancements. In EUC-JIS-2004, this code set encodes the second plane of , avoiding conflicts.

Vendor-specific extensions provided by companies such as IBM, NEC, and the Open Software Foundation are embedded within individual code sets rather than through invalid byte sequences. This approach distinguishes EUC-JP from other EUC variants like EUC-CN or EUC-KR.

Certain vendor encodings maintain partial compatibility with EUC-JP by encoding over GR but diverge from the packed EUC structure by omitting single shifts; notable exceptions include Super DEC Kanji.

DEC Kanji

Digital Equipment Corporation defines two EUC-JP variants that partially comply with the packed format yet resemble fixed two-byte formats. The "DEC Kanji" encoding closely aligns with 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 similarly to fixed-width formats but without employing a shift byte. Only rows 1 through 31 of code set 3 are allocated for user-defined characters, while rows 32 through 94 remain reserved.

The "Super DEC Kanji" variant accepts codes compatible with both "DEC Kanji" and packed-format EUC, encompassing five code sets in total. It permits full usage of the user-defined code set along with unused rows at the ends of JIS X 0208 and JIS X 0212 (rows 85–94 and rows 78–94 respectively) for user-defined characters.

HP-16

Hewlett-Packard's "HP-16" encoding serves as a complement to their "HP-15" version of Shift JIS. HP-16 utilizes byte values derived from EUC-JP but excludes single shift codes, thereby omitting code sets 2 and 3. It introduces three user-defined segments that deviate from the standard packed-format EUC structure:

  • Leading bytes range from 0xA1 to 0xC2, with trailing bytes between 0x21 and 0x7E
  • Leading bytes range from 0xC3 to 0xE3, with trailing bytes between 0x21 and 0x3F
  • Leading bytes range from 0xC3 to 0xE1, with trailing bytes between 0x40 and 0x64

IKIS

The IKIS (Interactive Kanji Information System) encoding developed by Data General resembles EUC-JP but excludes single shift codes, relying solely on code sets 0 and 1. Half-width katakana characters are positioned within row 8 of JIS X 0208, overlapping with box-drawing characters introduced in 1983. Rows numbered 9 through 12 are reserved for user-defined glyphs.

Adaptations of EUC-JP for EBCDIC

KEIS (Kanji-processing Extended Information System), deployed by Hitachi, is an EBCDIC-based stateful encoding that switches between single-byte and double-byte modes via shift sequences. Characters from JIS X 0208 maintain the same byte sequences as in EUC-JP, causing duplicate encodings for the ideographic space character (encoded as 0x4040 following the DBCS-Host scheme and as 0xA1A1 per EUC-JP). Unlike IBM's DBCS-Host encoding, KEIS extends the lead byte range down to 0x59; bytes from 0x81 to 0xA0 are allocated for user-defined characters, while other values are assigned to company-specific kanji and non-kanji symbols.

JEF (Japanese-processing Extended Feature), utilized on Fujitsu FACOM mainframes, contrasts with FMR—a Shift JIS derivative used on Fujitsu personal computers. Similar to KEIS, JEF operates as a stateful system switching between single- and double-byte modes through shift codes. It encodes JIS X 0208 characters identically to EUC-JP. The lead byte range extends back to 0x41; bytes from 0x80 to 0xA0 are reserved for user customization. Bytes in the range 0x41–7F correspond to row numbers 101–163 in kuten notation (with row 162 unused). Rows 101 through 148 represent extended kanji characters, while rows 149 through 163 cover extended non-kanji symbols.

EUC-KR

EUC-KR is a variable-length character encoding designed for Korean scripts, employing two character sets: (formerly KS C 5601) alongside either () or ASCII depending on the implementation. Established by (previously KS C 5861) and formalized as EUC-KR by , it encodes KS X 1001 characters using two bytes (ranging from 0xA1 to 0xFE) and represents KS X 1003 or ASCII characters with a single byte (from 0x21 to 0x7E).

Referred to as Wansung () within South Korea, IBM labels the double-byte segment as Code page 971, while EUC-KR paired with ASCII is identified as Code page 970. Microsoft implements these as Code page 20949 ("Korean Wansung") and Code page 51949 ("EUC Korean").

By mid-2025, EUC-KR is declared by fewer than 0.06% of websites worldwide, though approximately 4.3% of South Korean sites continue its use. Despite this decline and various extensions, EUC-KR remains the predominant legacy encoding in Korea across major operating systems such as macOS, Unix-like platforms, and Windows. Nonetheless, there is a gradual transition toward UTF-8, which is favored for new developments due to its superior cross-platform compatibility and broader vendor adoption.

Unified Hangul Code

An extension of EUC-KR known as the Unified Hangul Code (), serves as the default Korean codepage in Microsoft Windows environments. Microsoft assigns it the identifier code page 949, whereas IBM refers to it as either code page 1261 or 1363. Note that IBM’s code page 949 differs as another form of EUC-KR extension.

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

Mac OS Korean (HangulTalk)

The Mac OS Korean encoding (Code page 10003 or x-mac-korean) was implemented in HangulTalk, which served as the Korean version of the classic Mac OS. This localization was created by Elex Computer, Apple's authorized distributor in South Korea during that period.

HangulTalk incorporates additional extension characters with lead bytes ranging from 0xA1 to 0xAD by utilizing unused segments within the EUC-KR GR plane, along with some codes outside the EUC-KR scope. Among these are stylized dingbats that do not depend on specific fonts. Many of these extension characters lack direct Unicode equivalents; Apple’s software handles this by mapping them to combining sequences, approximate matches with private-use modifiers, or assigning private-use code points.

Furthermore, Apple employs certain single-byte codes beyond the EUC-KR plane to represent extra symbols: 0x80 denotes a mandatory space, 0x81 corresponds to the won sign (₩), 0x82 to the en dash (–), 0x83 to the copyright symbol (©), 0x84 to a wide underscore (＿), and 0xFF to an ellipsis (...). Although these codes fall outside the standard EUC-KR lead byte range, some overlap with lead byte ranges used in Unified Hangul Code.

EUC-KP

The North Korean character set standard KPS 9566, similar to KS X 1001, is generally utilized in its EUC form, often referred to as EUC-KP. Newer versions have expanded the EUC encoding by including characters represented with non-EUC two-byte sequences, analogous to those found in Unified Hangul Code.

EUC-TH

Certain single-byte character sets within the ISO/IEC 8859 family adhere structurally to EUC principles but are seldom identified explicitly as EUC encodings. One exception is found on Solaris, where EUC-TH serves as a designation for TIS-620.

EUC-TW

EUC-TW is a variable-length character encoding format that supports ASCII alongside sixteen planes of , each containing 94×94 characters. Despite its capability, it sees limited use for traditional Chinese characters in Taiwan, where Big5 variants prevail although they cover only the first two CNS 11643 planes. The adoption of UTF-8 is progressively increasing in this region.

  • Standard ASCII and control characters follow the conventional EUC/ISO 2022 encoding scheme.
  • ASCII graphical characters (G0) retain their normal single-byte values (0x21–0x7E).
  • Characters from CNS 11643 plane 1 are encoded as two bytes within GR (0xA1–0xFE).
  • For planes 1 through 16, encoding requires four bytes: beginning with 0x8E (Single Shift 2), followed by a plane indicator byte (ranging from 0xA1 to 0xB0), then two GR bytes (each between 0xA1 and 0xFE).

Notably, CNS 11643’s first plane is encoded twice—once as code set 1 and again within code set 2.

See also

External links

Related profiles

CCode page 954CCode page 970CCode page 952CCode page 955
Retrieved from "https://www.alfawiki.org/index.php?title=Code_page_971&oldid=28710"