Jump to content

Code page 954

From Alfawiki
Adapted from the English Wikipedia article Code page 954, available under CC BY-SA 4.0Updated 9 August 2025
Extended Unix Code (EUC)
Company typeCharacter encoding standard
IndustryComputing / Information technology
Area served
Japanese, Korean, and simplified Chinese text encoding
ProductsEUC-CN, EUC-KR, EUC-JP, EUC-TW

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

Typically, EUC encodings are variable-length systems where characters from a compliant set such as ASCII occupy one byte, while those from a 94×94 coded set (for example, ) require two bytes. Notable instances include EUC-CN (GB 2312) and EUC-KR. In the case of EUC-JP, characters may extend up to three bytes, beginning with an initial , whereas EUC-TW supports character lengths of up to four bytes.

Despite the growing preference for UTF-8 due to its extensive glyph coverage and cross-platform compatibility, EUC remains in prevalent use, particularly EUC-KR within South Korea.

Encoding structure

The foundation of EUC lies in the standard, which specifies graphical character sets encoded as sequences of 94 7-bit bytes (ranging from 0x21 to 0x7E) or 8-bit bytes (0xA1 to 0xFE). This framework permits character sets comprising 94 characters, or combinations reaching up to 8836 (94²) or even 830,584 (94³) unique symbols. Initially, bytes 0x20 and 0x7F were reserved for space and , while 0xA0 and 0xFF remained unused; subsequent revisions allowed these values in specific sets, enabling 96-character collections. Control codes occupy the byte ranges 0x00–1F and 0x80–9F.

EUC profiles function as 8-bit adaptations of , differing from the 7-bit profiles like ISO-2022-JP. Only character sets compliant with can be represented in EUC form. The encoding supports up to four coded character sets designated G0 through G3. G0 typically corresponds to a compliant set such as ASCII, (), or (the lower half of ), accessed via GL (0x21–0x7E). When ASCII is employed, EUC behaves similarly to an extended ASCII scheme; for instance, in EUC-JP, the byte 0x5C frequently denotes a yen sign, whereas in EUC-KR it represents a won sign.

Other code sets are invoked through GR by setting the most significant bit. Each byte forming an EUC character has its most significant bit set (adding either 128 to each original 7-bit byte or adding 160 to each kuten code), facilitating clear differentiation between ISO 646 and extended codes. Characters from G2 and G3 are introduced with control prefixes (0x8E) and (0x8F), respectively. Any byte outside the range 0xA0–0xFF within code sets one through three is considered invalid.

While EUC itself does not employ announcement or designation sequences from , its definition aligns with these four 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 Access to G2 via SS2
ESC SP [ 1B 20 5B Access to G3 via SS3
ESC SP \ 1B 20 5C Single-shift invocation over GR

Fixed-length format

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

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

Bytes such as 0x00 and 0x80 serve as indicators for single-byte code sets. Additionally, a fixed-length four-byte format exists but is mainly utilized for internal processing rather than data exchange.

For EUC-JP, both formats are registered with IANA: the packed variant under "EUC-JP" or "csEUCPkdFmtJapanese" and the fixed-width version as "csEUCFixWidJapanese". Only the packed format is recognized within the WHATWG Encoding Standard for HTML5.

EUC-CN

EUC-CN represents the standardized encoded format for the simplified Chinese character set. Unlike Japanese encodings such as JIS X 0208 and ISO-2022-JP, it is rarely employed as a 7-bit ISO 2022 code variant. However, derivatives like HZ, which encapsulate GB 2312 text within ASCII delimiters, have occasionally seen use on USENET.

Within this encoding, ASCII characters remain encoded in a single byte. Characters from the set are encoded using two bytes, both falling within the 0xA1–0xFE range.

748 code

The "748" code, associated with EUC-CN, was utilized by Beijing Founder Technology's WITS typesetting system (now superseded by FITS). Although it encompasses the entire character set, it does not conform to –standards and thus cannot be classified as a true EUC encoding. It employs an 8-bit lead byte and differentiates second bytes based on their highest bit, resembling Big5 and other non–ISO 2022 compliant DBCS formats. Its non-GB2312 segment incorporates traditional Chinese and Hong Kong characters along with glyphs tailored for newspaper typesetting.

IBM code pages 1380, 1381, 1382 and 1383

IBM code page 1381 (CCSID 1381) merges single-byte code page 1115 (CCSID 1115) with double-byte code page 1380 (CCSID 1380), encoding GB 2312 similarly to EUC-CN but extending the lead byte range up to 0x8C. It introduces 31 IBM-selected characters in the range 0x8CE0–0x8CFE and supports an additional 1880 user-defined characters with lead bytes spanning from 0x8D to 0xA0.

Code page 1383 (CCSID 1383) combines single-byte code page 367 alongside double-byte code page 1382 (CCSID 1382), adhering to the EUC structure. This code page includes the same 31 IBM-selected characters at positions 0xFEE0–0xFEFE and integrates 1360 user-defined characters scattered outside of GB 2312 locations. CCSID 5479 corresponds to the pure EUC-CN code page, utilizing CCSID 9574 as its double-byte component (derived from CPGID 1382) but excluding IBM-specific and user-defined additions.

GBK and GB 18030

GBK serves as an extension of , offering an enhanced EUC-CN variant that supports a wider array of CJK characters, including traditional Chinese characters and certain ones used in Japanese, primarily sourced from . It does not qualify as a genuine EUC code because ASCII bytes can appear as trailing bytes, and C1 bytes may function as either lead or trail bytes due to its expanded encoding capacity.

Variations of GBK are implemented by Microsoft Windows' code page 936 for simplified Chinese and IBM's code page 1386.

The Unicode-based standard extends GBK further to encompass the entire Unicode spectrum through a variable-length encoding system that can use up to four bytes per character. While it is a superset of EUC-CN, it is not a true EUC encoding; GB 18030's character repertoire aligns with other Unicode transformation formats like UTF-8.

Mac OS Chinese Simplified (x-mac-chinesesimp)

The classic Mac OS simplified Chinese script (Code page 10008 or x-mac-chinesesimp) departs from standard EUC-CN conventions. It assigns specific byte values—such as 0x80, 0x81, 0x82, 0xA0, 0xFD, 0xFE, and 0xFF—to characters including ü, special font metrics, non-breaking space, ©, ™, and ellipsis. This behavior contrasts with EUC and GBK in how it defines single-byte versus lead byte roles.

Its usage of bytes like 0xA0, 0xFD, 0xFE, and 0xFF corresponds with Apple's Shift_JIS adaptation for MacJapanese.

Notably, its double-byte segment contains two extensions to GB 2312-80 located in rows six and eight—these standard extensions derive from GB 6345.1 and are incorporated into GB/T 12345 (the traditional Chinese variant) as well as GB 18030, thereby ensuring interoperability with broader Chinese character collections.

EUC-JP

EUC-JP is a variable-length character encoding that represents three Japanese character set standards: , , and . It is also referred to as Unixized JIS (UJIS) or AT&T JIS. As of 2025, it ranks as the second most widely used encoding for Japanese websites, accounting for 2.3% of Japanese-language pages, though it remains less prevalent than UTF-8. IBM designates it as Code page 954, while Microsoft uses code pages 51932 and 20932 for this encoding.

This encoding allows for the smooth combination of 7-bit ASCII with 8-bit Japanese characters without needing escape sequences, which are required in ISO-2022-JP. Unlike Shift JIS, EUC-JP avoids the issue of ASCII bytes being mistaken as trailing bytes.

A related variant, EUC-JISx0213 or EUC-JIS-2004, supports encoding of and , paralleling the Shift_JIS-based version known as Shift_JISx0213.

EUC-JP found considerable adoption within Unix and Unix-like environments (excluding HP-UX), but it never became the dominant encoding on Japanese PC or Macintosh systems, where Shift JIS variants remained more common. The choice of encoding on Japanese websites often corresponds to the platform preferences of their creators.

Encoding specifics:

  • ASCII characters (code set 0) are represented by single-byte values ranging from 0x21 to 0x7E, consistent with W3C/WHATWG guidelines; byte 0x5C typically corresponds to Unicode U+005C REVERSE SOLIDUS but may appear as a Yen symbol in Japanese fonts.
  • Characters from (code set 1) are encoded using two bytes within the range 0xA1–0xFE; in EUC-JIS-2004, this includes the first plane of , which extends JIS X 0208.
  • Half-width kana from the upper portion of (code set 2) utilize two bytes: a lead byte of 0x8E followed by a byte between 0xA1 and 0xDF; certain variants incorporate IBM-specific extensions.
  • Characters from (code set 3) employ three bytes: an initial byte of 0x8F followed by two bytes in the range 0xA1–0xFE. Some versions of EUC-JP add IBM Shift JIS extension characters here. In EUC-JIS-2004, this set encodes the second plane of without conflicts.

Vendor-specific extensions developed by companies such as IBM, NEC, and the Open Software Foundation are embedded within these code sets rather than employing invalid sequences. This contrasts with approaches used in EUC-CN and EUC-KR. Certain vendor encodings align partially with EUC-JP but are not fully compatible due to differences in single-shift handling, except for Super DEC Kanji.

DEC Kanji

Digital Equipment Corporation specifies two EUC-JP variants that partially adhere to the EUC packed format but resemble a full two-byte fixed-length encoding. The "DEC Kanji" format largely follows fixed-length (two-byte) EUC conventions; however, code set 0 does not require null-byte padding on the left. It uses JIS X 0208 for code set 1 and excludes half-width katakana in code set 2. Code set 3 encodes user-defined two-byte characters without a shift byte, relying solely on setting the first high bit. In standard "DEC Kanji," only rows 1 through 31 of code set 3 are allocated for user-defined characters; rows 32 through 94 remain unused.

The "Super DEC Kanji" variant supports codes from both "DEC Kanji" and packed-format EUC, encompassing five code sets in total. It permits use of the entire user-defined code set as well as unused rows at the edges of JIS X 0208 and JIS X 0212 (specifically rows 85–94 and 78–94 respectively) for custom characters.

HP-16

Hewlett-Packard developed the "HP-16" encoding as a counterpart to their "HP-15," which is a variant of Shift JIS. The HP-16 format encodes characters using EUC-JP byte sequences but excludes single shift codes, thereby omitting code sets 2 and 3. It introduces three user-defined segments that diverge from the conventional packed EUC structure:

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

IKIS

The Interactive Kanji Information System (IKIS), created by Data General, is an encoding similar to EUC-JP but without employing single shift codes, thus utilizing only code sets 0 and 1. Half-width katakana characters are placed in row 8 of JIS X 0208, overlapping with box-drawing symbols introduced in 1983. Rows 9 through 12 are reserved for user-defined characters.

Adaptations of EUC-JP for EBCDIC

KEIS (Kanji-processing Extended Information System), an EBCDIC-based encoding designed by Hitachi, relies on shift sequences to toggle between single-byte and double-byte modes, making it a stateful system. Specifically, one sequence switches to single-byte mode, while another activates double-byte mode. Characters from JIS X 0208 use the same byte patterns as EUC-JP, resulting in duplicate representations for the ideographic space (0x4040 in DBCS-Host and 0xA1A1 in EUC-JP). Unlike IBM’s older DBCS-Host encoding, KEIS expands the lead byte range backward to include 0x59; bytes between 0x81 and 0xA0 are allocated for user-defined characters, with other ranges assigned to corporate-specific kanji and non-kanji symbols.

JEF (Japanese-processing Extended Feature), an EBCDIC encoding employed on Fujitsu FACOM mainframes, differs from FMR—a Shift JIS variant used on Fujitsu PCs. Like KEIS, JEF operates as a stateful encoding that switches modes via designated shift sequences: one for single-byte and another for double-byte mode. It uses JIS X 0208 codes identical to those in EUC-JP. The lead byte range extends backward to 0x41; bytes from 0x80 to 0xA0 are reserved for user-defined characters. Lead bytes between 0x41 and 0x7F correspond to kuten row numbers from 101 to 163, excluding row 162. Rows numbered from 101 to 148 contain extended kanji characters, while rows from 149 to 163 include extended non-kanji symbols.

EUC-KR

EUC-KR is a variable-length character encoding system designed for Korean text, utilizing two character sets: KS X 1001 (previously KS C 5601) and either KS X 1003 or ASCII depending on the variant. It is defined by KS X 1001 (formerly KS C 5861) and standardized under the name EUC-KR by ISO/IEC. This encoding represents KS X 1001 characters using two bytes within the range of 0xA1–0xFE, while KS X 1003 or ASCII characters are encoded with a single byte between 0x21 and 0x7E.

Referred to as Wansung () in South Korea, IBM identifies the double-byte segment as Code page 971 and the variant incorporating ASCII as Code page 970. Implementations include IBM’s Code page 20949 ("Korean Wansung") and Microsoft’s Code page 51949 ("EUC Korean").

As of the year 2025, EUC-KR accounts for under 0.06% of worldwide web content but remains utilized by approximately 4.3% of websites based in South Korea. Despite this usage, UTF-8 is increasingly favored for new projects due to its superior cross-platform compatibility. Although its prevalence is declining gradually in favor of UTF-8, EUC-KR remains the dominant legacy encoding across major operating systems in Korea such as macOS, Unix-like systems, and Windows.

Unified Hangul Code

An extension commonly applied to EUC-KR is known as the Unified Hangul Code (), which serves as the default Korean code page on Microsoft Windows platforms. Microsoft assigns this extension code page number 949, while IBM refers to it as either code page 1261 or code page 1363; notably, IBM’s code page labeled as 949 corresponds to a different EUC-KR extension.

The Unified Hangul Code enhances EUC-KR by incorporating non-EUC codes that enable additional syllable blocks, thereby achieving full coverage of composed syllables found in Johab and Unicode standards. This extension is integrated within the W3C/WHATWG Encoding Standard for HTML5 under its definition of EUC-KR.

Mac OS Korean (HangulTalk)

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

HangulTalk incorporates additional extension characters using lead bytes ranging from 0xA1 to 0xAD within the unused GR plane space of EUC-KR, as well as non-EUC codes outside this range. Some of these are font-independent decorative dingbats. Many of these characters do not have direct Unicode equivalents; Apple’s software translates them into combining sequences, approximate private-use mappings with modifiers, or assigns private-use characters.

Furthermore, Apple uses several single-byte codes beyond the EUC-KR plane for supplementary characters: 0x80 represents a required space, 0x81 the ₩ won symbol, 0x82 an en dash, 0x83 the © copyright mark, 0x84 a wide underscore, and 0xFF an ellipsis. Although these single-byte values lie outside the standard EUC-KR lead byte range, some fall within the lead byte range defined by Unified Hangul Code.

EUC-KP

The North Korean standard KPS 9566, similar to KS X 1001, is frequently employed in an EUC format commonly referred to as EUC-KP. Recent versions have expanded the EUC encoding by including characters represented with non-EUC two-byte codes, paralleling the approach taken by Unified Hangul Code.

EUC-TH

Certain single-byte encodings like those from the ISO/IEC 8859 family technically conform to the EUC framework but are seldom identified as EUC encodings. However, Solaris uses this designation for TIS-620.

EUC-TW

EUC-TW is a variable-length character encoding that supports ASCII plus sixteen planes of (each plane containing 94×94 code points). It is infrequently used for traditional Chinese in Taiwan, where Big5 variants predominate despite only covering the initial two CNS 11643 planes. UTF-8 is progressively becoming the preferred encoding.

  • Control and ASCII characters are encoded identically to ASCII.
  • ASCII graphical characters (G0 set) use single-byte codes between 0x21 and 0x7E.
  • Characters from CNS 11643 plane 1 are encoded as two bytes in the GR area (0xA1–0xFE).
  • Characters from planes 1 through 16 are encoded using four bytes: starting with 0x8E (Single Shift 2), followed by a plane identifier byte (ranging from 0xA1 to 0xB0), then two bytes in the GR range (0xA1–0xFE).

Plane 1 of CNS 11643 is encoded both as code set 1 and also forms part of code set 2.

See also

External links

Related profiles

CCode page 971CCode page 970CCode page 952CCode page 955
Retrieved from "https://www.alfawiki.org/index.php?title=Code_page_954&oldid=28711"