Terminology and encoding labelling
Both IBM-949 and Unified Hangul Code (Windows-949) are known as "code page 949" (or "cp949") although they share only the EUC-KR subset in common. Neither has a standardisedHistory
A version of Code page 951 (a DBCS-PC, i.e. double-byte non- EUC non- EBCDIC, code), the double-byte component for IBM-949, is defined in the September 1992 revision of IBM Corporate Specification C-H 3-3220-125, along with Code page 834 (a DBCS-Host, i.e. double-byte EBCDIC, code), which is the double byte component of Code page 933. This version of Code page 949/951 considered the entire lead byte range 0x8F–A0 to be a user-defined region, and included only standard Wansung assignments and user-defined areas, thus not including some characters which Code page 933/834 included. Some later versions, such as that implemented by International Components for Unicode (ICU), shrink the user-defined region to include these characters as extensions. The earlier October 1989 revision of C-H 3-3220-125 had instead defined Code page 926 as its DBCS-PC code, which encoded the same characters as IBM-834 in a layout differing from both IBM-951 and IBM-834, which had a different lead byte range and was not an EUC-KR extension. IBM-926 was combined with Code page 891 or Code page 1040 (respectively 8-bit N-byte Hangul Code and an extension thereof; compare how Shift JIS extends 8-bit JIS X 0201) to form IBM-934 or IBM-944 respectively. Code page 944/926 are now deprecated in favour of IBM-949. The 1992 revision designates code page 926 as "restricted" ("limited to the particular environment for which t isregistered") and does not give its chart or mappings from the other code pages, and CCSID 944 is categorised as "coexistence and migration" (contrast "interoperable" for CCSID 949). International Components for Unicode includes Unicode mappings for IBM-949 and IBM-933, but its IBM-944 mapping was removed in 2001.Single byte codes
Double byte codes
Lead bytes 0x8F–99, 0xC9, 0xFE (user defined ranges)
IBM-949 is designed to support a maximum of 1880 UDC (user-defined characters), including ranges within unused rows of the Wansung plane, and ranges outside the Wansung plane. In this version, the lead bytes 0x8F–A0 contain a maximum of 1692 UDC, and lead bytes 0xC9 and 0xFE contain a maximum of 94 each (i.e. with trail bytes 0xA0–FE). However, when the extensions to support the entire double-byte repertoire of IBM-933 are implemented, they use lead bytes 0x9A–A0, resulting in a smaller maximum number of characters left for user definition. When mapped to Unicode, 0xC9A1–C9FE (between the syllable and hanja ranges) are mapped to the Unicode Private Use Area code points U+E000–E05D, while 0xFEA1–FEFE (between the end of the hanja range and the end of the plane) are mapped to U+E05E–E0BB. Outside the Wansung plane, 0x8FA0–9AA5 (where the second byte is in the range 0xA1–FE) are mapped to the Private Use Area code points U+E0BC–E4CA. The last of these ranges cuts into the start of the 0x9A row (shown below). Collectively these private use ranges cover the code points U+E000..E4CA, allowing 1227 UDC to be mapped from IBM-949 to Unicode. The separate private use area range U+F843..F86E is used by IBM to map some characters within the extended hanja range. This follows early recommendations from the Unicode Consortium that corporate characters be allocated from U+F8FF downward and user-defined characters be allocated from U+E000 upward, and is part of a larger corporate private use area scheme which is defined internally by IBM, and uses the range U+F83D..F8FF. (Included with )Lead bytes 0x9A–9D (extended symbols and hanja)
According to the 1992 specification, this entire range is user-defined. As implemented in the codec contributed to ICU by IBM, however, 0x9AA1 through 0x9AA5 are the end of the user-defined range. The remainder of this range includes some non-Hangul characters included in Code page 933 but not in Wansung code. 0x9AA6 through 0x9AAB contain miscellaneous technical or mathematical symbols. The remainder contains hanja additional to those included in KS X 1001, although some are mapped by IBM to the Private Use Area. } , , , , , , , , , , - , , , , , , , , , , , , , , , , , , - , , , , , , , , , , , , , , , , , , - , , , , , , , , , , , , , , , , , , - , , , , , , , , , , , , , , , , , , - , , , , , , , , , , , , , , , , ,Lead bytes 0x9E–A0 (extended hanja and syllables)
According to the 1992 specification, this entire range is user-defined. As implemented in the codec contributed to ICU by IBM, 0x9EA1 through 0x9EAC contain the remainder of the extended hanja. The rest of the range contains a few additional Hangul syllables which are not available in pre-composed form in pure EUC-KR. Unlike Unified Hangul Code, this is insufficient to support all non-partial Johab syllables absent in Wansung code. Significant amongst these are 뢔 (rwae, 0x9EFC), 쌰 (ssya, 0x9FE6), 쎼 (ssye, 0x9FED), 쓔 (ssyu, 0x9FF3) and 쬬 (jjyo, 0xA0C1), which correspond to the beginnings of the standard Wansung characters 뢨, 썅, 쏀, 쓩, and 쭁 respectively, when partly entered in an input method editor.Lead bytes 0xA1–C8, 0xCA–FD (standard Wansung)
See also
* LMBCS-17 * Code page 951 * Windows-949Footnotes
References
{{character encoding 949 Encodings of Asian languages