| IBM code page 949 | |
| Alias: |
|
| By: | IBM |
| Extends: | EUC-KR |
| Prev: | Code page 944 |
| Classification: | Extended ISO 646, variable-width encoding, CJK encoding |
| Lang: | Korean |
IBM code page 949 (IBM-949) is a character encoding which has been used by IBM to represent Korean language text on computers. It is a variable-width encoding which represents the characters from the Wansung code defined by the South Korean standard KS X 1001 in a format compatible with EUC-KR, but adds IBM extensions for additional hanja, additional precomposed Hangul syllables, and user-defined characters.
Giving values in hexadecimal, bytes 0x00 through 0x7F are used for single byte KS X 1003 (ISO 646:KR) characters, a similar set to ASCII but with a won sign rather than a backslash. Bytes 0x80 through 0x84 are used for IBM single byte extension characters. Lead bytes 0x8F through 0xA0 are used for IBM double byte extension characters. Lead bytes 0xA1 through 0xFE are used for Wansung code (KS X 1001 characters in EUC-KR form, double byte), but with some unused space opened up for user-defined use.
Although both are sometimes named "cp949", IBM-949 is different from Windows code page 949 (IBM-1363), which is Microsoft's Unified Hangul Code, a different extension of EUC-KR. It should also not be confused with IBM's implementation of plain EUC-KR (IBM-970). Code page 949 in OS/2 is the IBM code page; however, a third-party patch exists to change this.[1]
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 standardised IANA-registered label to identify it. Although UHC is included in the WHATWG Encoding Standard, with labels including "windows-949",[2] IBM-949 is not. IBM-949 therefore is not permitted in HTML5.
Although the meaning of the label "ibm-949" (and conversely "windows-949" and "ms949") is unambiguous where these labels are supported, the interpretation of the encoding labels "949" and "cp949" consequently varies between implementations. For example, International Components for Unicode uses "cp949", "949", "ibm-949" and "x-IBM949" to refer to IBM-949, and additionally the labels "cp949c", "ibm-949c" and "x-IBM949C" to refer to an variant which uses unmodified ASCII mappings for 0x20–7E (resulting in duplicate mappings for the backslash), while (of the labels incorporating the code page number 949) only "ms949" and "windows-949" are assigned to UHC. This is in contrast to Python, which recognises both "cp949" and "949" (in addition to the more explicit "ms949" and "uhc", but not "windows-949") as labels for UHC, and does not include an IBM-949 codec.[3] The code page 949 used by Korean language versions of OS/2 is the IBM code page; to add support for the entire Unicode set of Korean syllables, a third-party patch exists to replace it with the Microsoft code page.[1]
IBM-949 is a variable width encoding defined as the combination of two fixed-width code pages, the single-byte Code page 1088 and the double-byte Code page 951.[4] [5] [6]
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.[7] 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.[7] Some later versions, such as that implemented by International Components for Unicode (ICU), shrink the user-defined region to include these characters as extensions.
| IBM code pages 934 and 944 | |
| Extends: | N-byte Hangul Code |
| Next: | IBM code page 949 |
| Encodes: | Code page 933 |
| Lang: | Korean |
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.[7] 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.[8] [9]
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 [it is] registered") and does not give its chart or mappings from the other code pages,[7] and CCSID 944 is categorised as "coexistence and migration"[9] (contrast "interoperable" for CCSID 949).[4] International Components for Unicode includes Unicode mappings for IBM-949 and IBM-933, but its IBM-944 mapping was removed in 2001.[10]
IBM-949 is designed to support a maximum of 1880 UDC (user-defined characters),[4] including the user-defined rows (lead bytes 0xC9 and 0xFE) 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 0xA1–FE).[7] 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,[11] and is part of a larger corporate private use area scheme which is defined internally by IBM, and uses the range U+F83D–F8FF.[12] [13]
According to the 1992 specification, this entire range is user-defined.[7] 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.
According to the 1992 specification, this entire range is user-defined.[7] 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 뢔 (0x9EFC), 쌰 (0x9FE6), 쎼 (0x9FED), 쓔 (0x9FF3) and 쬬 (0xA0C1), which correspond to the beginnings of the standard Wansung characters 뢨, 썅, 쏀, 쓩, and 쭁 respectively, when partly entered in an input method editor.