Community hub
Recent from talks
Contribute something
Nothing was collected or created yet.
Half-width kana
View on WikipediaHalf-width kana (半角カナ, Hankaku kana) are katakana characters displayed compressed at half their normal width (a 1:2 aspect ratio), instead of the usual square (1:1) aspect ratio. For example, the usual (full-width) form of the katakana ka is カ while the half-width form is ｶ. Additionally, half-width hiragana is included in Unicode, and it is usable on Web or in e-books via CSS's font-feature-settings: "hwid" 1 with Adobe-Japan1-6 based OpenType fonts.[1] Finally, half-width kanji is usable on modern computers, and is used in some receipt printers, electric bulletin board and old computers.[2]
Half-width kana were used in the early days of Japanese computing, to allow Japanese characters to be displayed on the same grid as monospaced fonts of Latin characters. Half-width kanji were not used. Half-width kana characters are not generally used today, but find some use in specific settings, such as cash register displays, on shop receipts, Japanese digital television and DVD subtitles, and mailing address labels. Their usage is sometimes also a stylistic choice, particularly frequent in certain Internet slang.
The term "half-width kana", which strictly refers only to how kana are displayed, not how they are stored – is also used loosely to refer to the A0–DF (hexadecimal) block where katakana are stored in some character encodings, such as JIS X 0201 (1969) – see encodings, below. This is formally incorrect, however – this JIS standard simply specifies that katakana can be stored in these locations, without specifying how they should be displayed; the confusion is because in early computing, the characters stored here were in fact displayed as half-width kana – see confusion, below.
History
[edit]
Half-width kana and 2/3-width kana were used from pre-computer era.[3] In the early computer era, ASCII is defined as a 7-bit character set and has room for 128 characters. However, since this standard was designed for the United States, it does not contain characters and symbols, such as the yen (¥) symbol needed to represent Japanese currency, nor did it include space for characters from other alphabets, such as kana or kanji – thus Japanese characters could not be encoded. Further, Japanese characters, both kana and kanji, are drawn on a square grid, while Latin characters are generally written more narrowly – thus Japanese characters could not be displayed either.
JIS X 0201 was developed in 1969, a time when computers were generally incapable, both by software design and hardware resources, of representing the thousands of Chinese-based kanji characters used in Japanese. As a compromise, this standard encoded katakana (only – not hiragana or kanji) as a small set of characters, assigned in the upper byte value range of 0x80–0xFF. This allowed 8-bit processors to encode and process Japanese text phonetically (as katakana), though without being able to process hiragana or kanji. These katakana characters were in turn displayed as "half-width kana" – a new, unorthodox, narrower form factor to fit the same width as the monospaced Latin alphabets machines were capable of printing and displaying. Encoding-wise, JIS X 0201 is a variant extension of ASCII – it includes additional characters, and does not exactly agree with ASCII on the overlapping part (the Latin character section).
Half-width kana were developed as "... the first Japanese characters encoded on computers because they are used for Japanese telegrams." [1]
The Nationwide Banking Data Communication System (全国銀行データ通信システム), the largest funds transfer system in Japan, was established in 1973. Transaction messages between banks could only use Latin, numbers, and half-width katakana within 20 characters. The system is superseded by ZEDI (The Nationwide Banking Electronic Data Interchange System) in 2018, which can handle hiragana and kanji with variable length characters.[4][5]
To make katakana fit into the narrower cell area allowed, some compromises were made. For example, the diacritical marks dakuten and handakuten are treated as separate characters instead of being part of the preceding character. This compromise led many to consider "half-width kana" visually unattractive, and causes problems for many computer programs today.[citation needed]
Another use of half-width kana is to save space. The Japanese version of Windows 3.1 used both half-width and full-width katakana of MS Gothic in its user interface. The Japanese version of Windows 95 used half-width katakana of MS P Gothic in its user interface. It was replaced by full-width kana of MS UI Gothic, which present on Japanese version of Windows 98 and later, little narrower than MS P Gothic.[6][7]
Encoding
[edit]In the JIS X 0201 specification (1969), katakana are encoded in A0–DF (hexadecimal) block – how they are displayed is not specified, and there is no separate encoding of full-width and half-width kana. In JIS X 0208, katakana, hiragana, and kanji are all encoded (and displayed as full-width characters; there are no half-width characters), though the ordering of the kana is different – see JIS X 0208#Hiragana and katakana.
In Shift JIS, which combines JIS X 0201 and JIS X 0208, these encodings (both of which can encode Latin characters and katakana) are stored separately, with JIS X 0201 all being displayed as half-width (thus the JIS X 0201 katakana are displayed as half-width kana), while JIS X 0208 are all displayed as full-width (thus the JIS X 0208 Latin characters are all displayed as full-width Latin characters). Thus in Shift JIS, Latin characters and katakana have two encodings with two separate display forms, both half-width and full-width.
In Unicode, katakana and hiragana are primarily used as normal, full-width characters (the Katakana and Hiragana blocks are displayed as full-width characters); a separate block, the Halfwidth and Fullwidth Forms block is used to store variant characters, including half-width kana and full-width Latin characters.
Thus, the katakana in JIS X 0201 and the corresponding part of derived encodings (the JIS X 0201 part of Shift JIS) are displayed as half-width, while in Unicode half-width forms are specified separately.
Half-width table
[edit]"J" indicates the first four bits in JIS X 0201 (though see below, these do not necessarily indicate half-width) and in other sets such as Shift JIS, "U" indicates the row in Unicode in the Halfwidth and Fullwidth Forms block.
| J | U | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B | C | D | E | F |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| A | FF6 | ｡ | ｢ | ｣ | ､ | ･ | ｦ | ｧ | ｨ | ｩ | ｪ | ｫ | ｬ | ｭ | ｮ | ｯ | |
| B | FF7 | ｰ | ｱ | ｲ | ｳ | ｴ | ｵ | ｶ | ｷ | ｸ | ｹ | ｺ | ｻ | ｼ | ｽ | ｾ | ｿ |
| C | FF8 | ﾀ | ﾁ | ﾂ | ﾃ | ﾄ | ﾅ | ﾆ | ﾇ | ﾈ | ﾉ | ﾊ | ﾋ | ﾌ | ﾍ | ﾎ | ﾏ |
| D | FF9 | ﾐ | ﾑ | ﾒ | ﾓ | ﾔ | ﾕ | ﾖ | ﾗ | ﾘ | ﾙ | ﾚ | ﾛ | ﾜ | ﾝ | ﾞ | ﾟ |
Please note that the blank first cell represents a non-existent character in JIS, A0; but a fullwidth double parenthesis ｠ in Unicode, U+FF60.
Half-width kana on the Internet
[edit]Since the SMTP and NNTP protocols (used to deliver e-mail and Usenet, respectively) were formerly only able to transmit 7-bit bytes, it was then the convention to use ISO-2022-JP for sending e-mail in Japanese.
Half-width kana is not contained in ISO-2022-JP: it includes the Roman set of JIS X 0201, and all of JIS X 0208, but not the katakana set of JIS X 0201 (which is used for half-width kana in Shift JIS, for instance). Both sets of JIS X 0201 have ISO 2022 codes, but the ISO-2022-JP profile only includes the Roman set: this means that the format for including half-width katakana in ISO-2022-JP is both well-defined and a violation of the ISO-2022-JP format. For this reason, if half-width kana were accidentally included in a message, it could become garbled during transmission (see mojibake). The WHATWG encoding standard used by HTML5 permits decoding, but not encoding, of JIS X 0201 katakana in ISO-2022-JP as an extension to the format, and converts half-width katakana to their JIS X 0208 equivalents upon encoding.[8]
This is no longer such a problem since most e-mail servers today support 8BITMIME extension and hence understand 8-bit characters. Alternatively, an encoding system such as Base64 can be used and specified in the message using MIME.
Web pages
[edit]The problem that exists in e-mail does not exist with Web pages since HTTP accepts 8-bit characters.
However, one problem that does exist is that computer programs have difficulties determining whether to treat a character as Shift JIS, EUC-JP, or UTF-8 – hence character code information should be specified with a HTTP response header or a Meta tag.
Confusion
[edit] |
Strictly speaking, JIS X 0201 encoding as "half-width katakana" is incorrect, as the standard does not define character widths – it defines only the code representation of katakana characters. In the JIS X 0201 standard, katakana characters are printed in normal (full) width, not half-width.
Half-width characters were only used for display during the period when characters were displayed at half-width (and single-byte encodings were used), before full-width character displays (and associated double-byte encodings such as JIS X 0208) became widespread. However, in the Shift JIS standard, which combines the JIS X 0201 standard (whose characters – Latin and katakana – were displayed as half-width) and the JIS X 0208 standard (whose characters – katakana, hiragana, kanji, and Latin – were displayed as full-width), katakana and Latin characters are encoded twice, both in JIS X 0201 and JIS 0208, but displayed as half-width or full-width according to which section they are in (0201 or 0208) – thus the 0201 katakana block can be thought of as corresponding to "half-width kana", and the misunderstanding that the 0201 standard defines "half-width" characters is widespread.
Further, though JIS X 0201 is a single-byte encoding (and displayed at half-width) and JIS X 0208 is a double-byte encoding (and displayed at full-width), there is no connection between number of bytes and width (other than those corresponding in Shift JIS, as above) – for example, Unicode can be encoded with four bytes (UTF-32) to display both full-width and single-width characters.
See also
[edit]
References
[edit]- ^ 改訂新版スタイルシートポケットリファレンス p.107 (in Japanese), Hajime Fujimoto, March 5, 2013, ISBN 978-4774154862
- ^ TSP100futurePRNT (in Japanese), Star Micronics
- ^ 東京築地活版製造所 - 活版見本 p.33 (in Japanese), Sōjūrō Nomura, 1903
- ^ "経理部門の人材不足で悩む会社に朗報、金融EDI「ZEDI」が2018年稼働へ". Nikkei X-TECH. 2017-11-30. Retrieved 2019-05-11.
- ^ "全銀EDIシステム（ZEDI）に対応したサービスの提供について". Mizuho Bank. 2018-12-25. Retrieved 2019-05-11.
- ^ "Windows 98 日本語版β3 ファーストインプレッション 第1回". Impress PC Watch. 1998-03-03. Retrieved 2019-05-11.
- ^ "Windows98のインターフェイス". 1998-06-26. Retrieved 2019-05-11.
- ^ "12.2. ISO-2022-JP". Encoding Standard. WHATWG.
- ^ Lunde, Ken. CJKV Information Processing. O'Reilly, 2nd ed., 2009, p. 224–226 (also 1st ed., 1999. p. 144–145)
Half-width kana
View on GrokipediaOverview
Definition and Characteristics
Half-width kana, known as hankaku kana (半角カナ), consist primarily of compressed katakana characters rendered at half the normal width of full-width forms, resulting in a 1:2 aspect ratio that makes them proportionally taller and narrower, as exemplified by ｶ in contrast to the full-width カ.[1] These forms emerged to support efficient text display in constrained digital and communication systems.[1] The core purpose of half-width kana is to optimize space in monospaced environments, such as early computer terminals and telegraph transmissions, where aligning Japanese text with Latin scripts required narrower glyphs to fit within fixed column widths.[1] This design allowed for single-byte encoding alongside ASCII characters, facilitating early computing applications in Japan without the overhead of multi-byte representations.[4] A key feature of half-width kana is the inclusion of 63 base katakana glyphs within the JIS X 0201 standard's phonetic character set, encompassing voiceless bases, prolonged sounds, iteration marks, and punctuation, but excluding combining voiced sound marks (dakuten or handakuten) or small kana variants as separate modifiers—instead, voiced forms like が are constructed by placing diacritics such as ﾞ adjacent to bases like ｶ.[3] The set also integrates half-width Latin letters, numerals (0-9), and symbols like ｡ and ､ to ensure seamless interoperability with Western typography in 8-bit systems.[4][1] Unlike full-width kana, which maintain a square 1:1 aspect ratio for harmonious integration with kanji in proportional East Asian typesetting, half-width variants prioritize ASCII compatibility and column efficiency, enabling mixed-script documents in legacy monospaced contexts like terminals and printers.[1] This distinction underscores their role as a transitional encoding solution rather than a primary typographic standard.[4]Visual and Typographic Aspects
Half-width kana are katakana characters rendered at half the width of their full-width counterparts, typically occupying a 1:2 aspect ratio rather than the standard 1:1 square proportions used in traditional Japanese typography. This compression results in glyphs that appear narrower and often "squished," with horizontally condensed strokes that sacrifice proportional balance for space efficiency in monospaced grids. For instance, the full-width katakana ア (U+30A2) features evenly distributed strokes filling a square em-width, while its half-width equivalent ｱ (U+FF71) compresses the design into half the horizontal space, leading to a visually denser and less elegant form.[1] Similarly, voiced sounds like ニ (full-width, U+30CB) contrast with ﾆ (half-width, U+FF86), where diacritics may appear as separate combining marks in legacy representations, further altering the glyph's fluidity.[1] Proper rendering of half-width kana requires fonts with dedicated support for these compatibility forms, such as those in the Adobe-Japan1 collection (e.g., versions 1-6), which include compressed glyphs designed for integration with Latin monospaced layouts.[5] In modern fonts like Source Han Mono, half-width katakana are adjusted to intermediate advances (e.g., 667 units in a 1000-unit em) using anisotropic scaling techniques to mitigate distortion while maintaining grid alignment, though they retain their inherently narrow profile.[6] Web and digital rendering often leverages CSS properties likefont-variant-east-asian with values such as proportional-width to toggle between full-width, half-width, or proportional kana variants, provided the font supports the corresponding OpenType features (e.g., 'pwid').
Typographically, half-width kana are considered unsuitable for body text or high-quality print due to their compressed appearance, which disrupts the rhythmic flow and aesthetic harmony of Japanese layouts. They are primarily employed for legacy compatibility in computing interfaces, emphasis in constrained spaces, or when mimicking early digital aesthetics, but contemporary guidelines recommend full-width forms for elegant typesetting.[6]
Historical Development
Adoption in Early Computing
Half-width katakana were first formalized in the Japanese Industrial Standard JIS C 6220-1969, which introduced them to extend the 7-bit ASCII framework into an 8-bit code for basic Japanese text processing on hardware with limited memory and display capabilities. This standard allocated the upper byte range (0xA1 to 0xDF) for 63 half-width katakana characters, allowing them to occupy the same single-byte space as Latin letters and numerals, thus enabling rudimentary digital representation of Japanese phonetic script without requiring additional bytes.[7] The adoption addressed the challenges of early computing environments, where full-width characters would disrupt alignment in fixed-width displays. In the 1970s, half-width katakana played a crucial role in Japanese minicomputers, terminals, and early word processors, such as those developed by Toshiba and other firms, by fitting seamlessly into monospaced grids alongside Latin characters.[8] This compatibility was essential for text-mode interfaces and data entry systems, where hardware constraints like 8-bit processors and low-resolution CRT terminals favored compact encodings to maximize screen real estate and storage efficiency.[7] A notable application was the Nationwide Banking Data Communication System (Zengin System), launched in April 1973, which utilized half-width katakana exclusively for wire transfer data to ensure compatibility with early digital systems and efficient data processing until its replacement by the ZEDI system in 2018.[9][10] A pivotal development occurred with the release of JIS C 6226-1978, later revised as JIS X 0208, which initially focused on full-width characters for kanji and hiragana but incorporated support for half-width katakana via compatibility with JIS X 0201, thereby enabling hybrid text layouts that combined Latin script, half-width katakana, and full-width elements.[7] This dual-width approach expanded input flexibility for evolving systems, allowing users to toggle between compact and proportional representations as needed.[11] The prominence of half-width katakana began to wane in the 1980s with the proliferation of 16- and 32-bit computing platforms, including personal computers like the NEC PC-9800 series, which prioritized full-width characters for improved typographic aesthetics and readability in professional documents.[11] Enhanced hardware capabilities reduced the necessity for space-optimized encodings, shifting industry standards toward comprehensive full-width support in encodings like Shift JIS to better accommodate kanji-heavy text.[7]Encoding and Standards
JIS X 0201 Specification
JIS X 0201, originally published as JIS C 6220 in 1969 and revised in 1976 before being renamed in 1987, with the latest revision in 1997 (JIS X 0201:1997), is an 8-bit character encoding standard developed by the Japanese Industrial Standards Committee to support basic Japanese text processing in computing environments.[7] It combines a 7-bit Roman character set largely compatible with ASCII (with minor modifications such as replacing the backslash with the yen sign) in the lower 128 code points (0x00–0x7F) and a 7-bit Katakana set shifted to the upper 128 code points (0x80–0xFF).[12] The Katakana portion occupies the range 0xA1–0xDF, encompassing 63 characters designed for phonetic representation.[13] The primary purpose of JIS X 0201 was to facilitate compatibility with international 7-bit systems, such as those based on ASCII, by allowing Japanese Katakana to be added via the eighth bit without disrupting existing Latin-based data transmission and processing.[12] Although the standard itself does not explicitly define character widths, the Katakana glyphs became conventionally rendered in half-width form in early computing displays and printers to align visually with full-width Latin characters and optimize space in low-resolution terminals.[14] This approach enabled rudimentary Japanese input and output in resource-constrained settings, such as teletypes and early minicomputers, where full Kanji support was impractical.[7] The Katakana character set in JIS X 0201 consists of 46 unvoiced basic forms (corresponding to the standard Gojūon syllables, including wo and n), 9 small katakana (a, i, u, e, o, ya, yu, yo, and tsu), 6 punctuation and special symbols (including the prolonged sound mark chōonpu), and 2 diacritical marks (dakuten and handakuten) used to form voiced and semi-voiced variants by combining with bases. It excludes hiragana, kanji, and precomposed voiced katakana, focusing solely on Katakana for phonetic transcription. As a single-byte encoding limited to 256 code points, JIS X 0201 inherently excludes Kanji and more complex scripts, making it unsuitable for full Japanese text but ideal for applications requiring simple phonetic notation alongside English.[12] Its design prioritized low-resource environments, such as early data communication networks and office equipment, where multi-byte encodings would have been infeasible due to hardware limitations.[7]Integration in Shift JIS and Unicode
Shift JIS, developed in the 1980s as an extension of the JIS X 0201 standard, incorporated half-width kana by mapping them to the single-byte range 0xA1–0xDF, allowing compatibility with 8-bit environments while reserving double-byte sequences for full-width characters from JIS X 0208.[13] This design enabled efficient handling of mixed text in Japanese computing, particularly supporting the Windows operating system's Japanese localization by providing a compact encoding for legacy half-width katakana alongside kanji and full-width forms.[15] In Unicode, half-width kana were adopted within the Halfwidth and Fullwidth Forms block (U+FF00–U+FFEF), which was introduced in version 1.1 in 1993 to ensure round-trip compatibility with legacy East Asian encodings.[16] The specific range U+FF61–U+FF9F provides a direct transposition of the JIS X 0201 half-width katakana characters, preserving their narrow visual forms for applications requiring exact reproduction of older data.[17] The evolution of Japanese text transport in the 1990s saw ISO-2022-JP, a 7-bit encoding for email and protocols, exclude half-width kana to maintain strict compliance with ISO standards, which necessitated fallback to 8-bit MIME types like Shift JIS for inclusive support.[13] Today, UTF-8 has become the dominant encoding, offering seamless compatibility for half-width kana through Unicode mappings while mitigating issues from earlier variable-width schemes.Character Mapping Table
The character mappings for half-width kana, primarily katakana with associated punctuation and marks, are defined in JIS X 0201 using single-byte codes from 0xA1 to 0xDF, which are directly incorporated as single-byte values in Shift JIS for these characters. These 63 entries correspond to Unicode codepoints in the range U+FF61 to U+FF9F and serve as equivalents to full-width katakana in the Katakana block (U+30A0–U+30FF) and related punctuation. The mappings exclude precomposed voiced (dakuten) and semi-voiced (handakuten) katakana forms, which are instead composed using the base unvoiced characters and the combining marks ﾞ (U+FF9E) and ﾟ (U+FF9F); small tsu (ｯ, U+FF6F) and the choonpu prolonged sound mark (ｰ, U+FF70) are included.[18][17] This table is provided for technical reference; actual glyph rendering depends on the font and context, with half-width forms designed for a 1:2 aspect ratio in monospaced environments but potentially appearing closer to full-width in proportional fonts. For example, the katakana "ka" is encoded as 0xB6 in JIS X 0201 and Shift JIS, U+FF76 in Unicode (glyph: ｶ), with full-width equivalent カ (U+30AB).[17]Punctuation and Special Marks
| JIS X 0201 Hex / Shift JIS Byte | Unicode Codepoint | Half-width Glyph | Full-width Equivalent (Unicode / Glyph) |
|---|---|---|---|
| 0xA1 | U+FF61 | ｡ | U+3002 / 。 |
| 0xA2 | U+FF62 | ｢ | U+300C / 「 |
| 0xA3 | U+FF63 | ｣ | U+300D / 」 |
| 0xA4 | U+FF64 | ､ | U+3001 / 、 |
| 0xA5 | U+FF65 | ･ | U+30FB / ・ |
| 0xA6 | U+FF66 | ｦ | U+30F2 / ヲ |
| 0xB0 | U+FF70 | ｰ | U+30FC / ー |
Small Katakana
| JIS X 0201 Hex / Shift JIS Byte | Unicode Codepoint | Half-width Glyph | Full-width Equivalent (Unicode / Glyph) |
|---|---|---|---|
| 0xA7 | U+FF67 | ｧ | U+30A1 / ァ |
| 0xA8 | U+FF68 | ｨ | U+30A3 / ィ |
| 0xA9 | U+FF69 | ｩ | U+30A5 / ゥ |
| 0xAA | U+FF6A | ｪ | U+30A7 / ェ |
| 0xAB | U+FF6B | ｫ | U+30A9 / ォ |
| 0xAC | U+FF6C | ｬ | U+30E3 / ャ |
| 0xAD | U+FF6D | ｭ | U+30E5 / ュ |
| 0xAE | U+FF6E | ｮ | U+30E7 / ョ |
| 0xAF | U+FF6F | ｯ | U+30C3 / ッ |
Basic Katakana (Unvoiced Bases)
| JIS X 0201 Hex / Shift JIS Byte | Unicode Codepoint | Half-width Glyph | Full-width Equivalent (Unicode / Glyph) |
|---|---|---|---|
| 0xB1 | U+FF71 | ｱ | U+30A2 / ア |
| 0xB2 | U+FF72 | ｲ | U+30A4 / イ |
| 0xB3 | U+FF73 | ｳ | U+30A6 / ウ |
| 0xB4 | U+FF74 | ｴ | U+30A8 / エ |
| 0xB5 | U+FF75 | ｵ | U+30AA / オ |
| 0xB6 | U+FF76 | ｶ | U+30AB / カ |
| 0xB7 | U+FF77 | ｷ | U+30AD / キ |
| 0xB8 | U+FF78 | ｸ | U+30AF / ク |
| 0xB9 | U+FF79 | ｹ | U+30B1 / ケ |
| 0xBA | U+FF7A | ｺ | U+30B3 / コ |
| 0xBB | U+FF7B | ｻ | U+30B5 / サ |
| 0xBC | U+FF7C | ｼ | U+30B7 / シ |
| 0xBD | U+FF7D | ｽ | U+30B9 / ス |
| 0xBE | U+FF7E | ｾ | U+30BB / セ |
| 0xBF | U+FF7F | ｿ | U+30BD / ソ |
| 0xC0 | U+FF80 | ﾀ | U+30BF / タ |
| 0xC1 | U+FF81 | ﾁ | U+30C1 / チ |
| 0xC2 | U+FF82 | ﾂ | U+30C4 / ツ |
| 0xC3 | U+FF83 | ﾃ | U+30C6 / テ |
| 0xC4 | U+FF84 | ﾄ | U+30C8 / ト |
| 0xC5 | U+FF85 | ﾅ | U+30CA / ナ |
| 0xC6 | U+FF86 | ﾆ | U+30CB / ニ |
| 0xC7 | U+FF87 | ﾇ | U+30CC / ヌ |
| 0xC8 | U+FF88 | ﾈ | U+30CD / ネ |
| 0xC9 | U+FF89 | ﾉ | U+30CE / ノ |
| 0xCA | U+FF8A | ﾊ | U+30CF / ハ |
| 0xCB | U+FF8B | ﾋ | U+30D2 / ヒ |
| 0xCC | U+FF8C | ﾌ | U+30D5 / フ |
| 0xCD | U+FF8D | ﾍ | U+30D8 / ヘ |
| 0xCE | U+FF8E | ﾎ | U+30DB / ホ |
| 0xCF | U+FF8F | ﾏ | U+30DE / マ |
| 0xD0 | U+FF90 | ﾐ | U+30DF / ミ |
| 0xD1 | U+FF91 | ﾑ | U+30E0 / ム |
| 0xD2 | U+FF92 | ﾒ | U+30E1 / メ |
| 0xD3 | U+FF93 | ﾓ | U+30E2 / モ |
| 0xD4 | U+FF94 | ﾔ | U+30E4 / ヤ |
| 0xD5 | U+FF95 | ﾕ | U+30E6 / ユ |
| 0xD6 | U+FF96 | ﾖ | U+30E8 / ヨ |
| 0xD7 | U+FF97 | ﾗ | U+30E9 / ラ |
| 0xD8 | U+FF98 | ﾘ | U+30EA / リ |
| 0xD9 | U+FF99 | ﾙ | U+30EB / ル |
| 0xDA | U+FF9A | ﾚ | U+30EC / レ |
| 0xDB | U+FF9B | ﾛ | U+30ED / ロ |
| 0xDC | U+FF9C | ﾜ | U+30EF / ワ |
| 0xDD | U+FF9D | ﾝ | U+30F3 / ン |
Dakuten and Handakuten Marks
| JIS X 0201 Hex / Shift JIS Byte | Unicode Codepoint | Half-width Glyph | Full-width Equivalent (Unicode / Glyph) |
|---|---|---|---|
| 0xDE | U+FF9E | ﾞ | U+3099 / ゙ (combining voiced sound mark) |
| 0xDF | U+FF9F | ﾟ | U+309A / ゜ (combining semi-voiced sound mark) |
Usage Contexts
Legacy Systems and Applications
Half-width kana have played a significant role in legacy hardware and software systems in Japan, where single-byte encodings like Shift JIS were prevalent to accommodate limited memory and display capabilities. These characters enabled efficient text rendering in environments with constrained resources, such as early personal computers, point-of-sale devices, and financial terminals.[1] In retail and service sectors, half-width kana remain functional in cash registers, POS terminals, and ATMs, particularly for generating compact receipts and subtitles. For instance, transaction details on receipts are often printed using half-width katakana to fit within narrow print widths while maintaining readability on thermal paper. This usage stems from the need to save space in fixed-width displays and printers designed for single-byte data. Similarly, ATMs and POS systems utilize half-width forms for menu options and confirmations, ensuring compatibility with older dot-matrix or thermal printers that prioritize efficiency over aesthetic proportions.[1][19] The Japanese banking sector provides a prominent example of half-width kana's persistence in closed financial networks. The nationwide banking data communication system, known as Zenginkei (全銀系), has historically required half-width katakana for account names, transaction messages, and data transmission to maintain interoperability across legacy infrastructure. This standard, implemented since the 1970s, facilitated secure, single-byte exchanges in systems like bankbooks and wire transfer protocols, with half-width forms ensuring uniform data handling without multibyte overhead. Modernizations, such as the implementation of 24-hour 365-day operations in 2018, have occurred, but half-width kana continue in the system and embedded banking devices for backward compatibility.[1][20][21] Other legacy applications, including pre-2000s word processors like Ichitaro, incorporated half-width kana for document composition and formatting in Shift JIS-based environments. These tools allowed users to input and display compressed katakana alongside Roman characters, optimizing storage and screen real estate on early hardware. Early game consoles, such as the Famicom (Japanese NES), also employed half-width-like representations in text rendering, though often through custom tile-based graphics rather than standard encodings.[1] Overall, half-width kana's adoption in these systems reflects a deprecation trend post-2000s, driven by the shift to UTF-8 for broader Unicode support. However, they endure in embedded and offline devices—such as legacy POS hardware and financial terminals—for maintaining compatibility with existing datasets and avoiding costly overhauls.[1][19]Internet and Digital Communication
In early email systems, half-width kana encountered significant incompatibility with the ISO-2022-JP encoding standard defined in RFC 1468, which supports only the Roman character set from JIS X 0201 and excludes the Kana set required for half-width katakana.[22] This limitation meant that half-width kana could not be reliably transmitted without custom escape sequences like ESC ( I, leading to frequent garbling or mojibake in messages during the 1990s, particularly over 7-bit SMTP channels before the 8BITMIME extension in RFC 1426 allowed 8-bit data transport. Systems using 8-bit encodings such as Shift JIS, where half-width katakana occupy single bytes from 0xA1 to 0xDF, often resulted in corrupted display if the recipient expected ISO-2022-JP or lacked 8-bit support.[13] These issues have been largely resolved in modern email through MIME parts encoded in UTF-8, which includes half-width katakana as distinct Unicode characters in the range U+FF61 to U+FF9F, enabling attachments and bodies to handle them without alteration. On the web, half-width kana were accommodated in Japanese pages via 8-bit encodings like Shift JIS and EUC-JP, which integrate the JIS X 0201 Kana set and can be declared using HTTP Content-Type headers specifying charsets such as "Shift_JIS".[13] In UTF-8 environments, half-width katakana render precisely as encoded Unicode points when the charset is correctly specified, though browsers historically defaulted to full-width equivalents in some input methods for typographic harmony. Early 1990s browsers, including NCSA Mosaic and Netscape Navigator, frequently mishandled mixed half-width and full-width content or ambiguous encodings, causing mojibake such as garbled katakana appearing as Latin symbols when Shift JIS was misdetected as ISO-8859-1.[23] HTML5's mandatory tag, recommending UTF-8, now ensures consistent declaration and rendering across browsers, minimizing such errors. Despite technical support, half-width kana appear infrequently in current web content, as full-width forms are favored for aesthetic alignment in Japanese digital typography.Contemporary and Stylistic Uses
Despite the widespread adoption of UTF-8 encoding, which has rendered half-width kana largely obsolete for general text processing since the early 2010s, it persists in niche applications for legacy compatibility and space efficiency.[1] In everyday commercial settings, half-width katakana appears on cash register receipts to conserve printed space on narrow thermal paper.[1] Similarly, it is employed in television and film subtitles, particularly in ticker-style displays or closed captions, to fit more content within limited screen real estate without compromising readability.[1] Embedded systems, such as point-of-sale terminals, continue to output half-width kana in constrained digital interfaces like receipts for backward compatibility with older hardware.[1] In the financial sector, half-width katakana remains standard for account names in Japan's banking systems, including XML payment files, to ensure seamless integration with legacy databases that may misinterpret full-width variants.[24][10] This practice underscores its role in maintaining data integrity during migrations to modern encodings. While some system updates and migrations to support full-width have occurred in the late 2010s and beyond, half-width katakana remains required in core operations like the 全銀システム as of 2025.[25] Stylistically, half-width katakana has found a place in online subcultures as a form of internet slang and coded expression, often to evade content moderation or convey casual, ironic tones. On forums like 2channel (2ch) and in gaming chats, users substitute half-width forms—such as ﾀﾋ for "death" (死)—mixed with numbers and romaji to create in-group dialects or memes, evolving from early net culture into Gen Alpha trends on platforms like TikTok.[26] This usage evokes a retro, low-fi aesthetic reminiscent of early ASCII art, emphasizing brevity in fast-paced digital communication.[26] Emerging applications are minimal, with half-width kana occasionally appearing in mobile apps for compact lists or UI elements where space-saving is prioritized, though no significant revival has occurred as of 2025 due to the dominance of flexible Unicode rendering.[27] Modern fonts and operating systems retain support primarily for data migration and archival purposes, ensuring compatibility without active promotion.[1]Challenges and Misconceptions
Rendering and Compatibility Issues
Half-width kana characters often encounter rendering inconsistencies across different fonts and platforms, particularly in proportional fonts where their intended narrow width may not be preserved. For instance, in web environments using CSS, half-width katakana can render at full width if the font lacks proper support for the East Asian Width property defined by Unicode, leading to visual misalignment in mixed-language text.[28] Encoding mismatches frequently cause mojibake, where half-width kana appear as garbled or unintended characters. This occurs when content encoded in EUC-JP is misinterpreted as Shift JIS, resulting in half-width katakana substituting for full-width forms due to single-byte overlaps in the encodings; conversely, when UTF-8 text is misinterpreted as Shift JIS, it produces sequences like "繧繝" (ungen) from byte misalignment.[23][29] Compatibility challenges persist in older systems predating widespread Unicode adoption, where UTF-8 encoded half-width kana fail to display correctly on pre-Unicode platforms relying on single-byte encodings like JIS X 0201. In legacy environments such as Windows 95-era applications handling mixed Shift JIS and ASCII text, half-width kana often garble into unreadable symbols due to improper byte handling in terminals or file managers.[30][31] Mobile browsers and input methods may automatically normalize half-width kana to full-width equivalents during text processing, exacerbating display uniformity issues in web forms.[32] To mitigate these problems, developers can employ font fallback mechanisms, such as specifying 'monospace' in CSS to enforce consistent widths, or activating OpenType features like "hwid" for half-width rendering in supported fonts. Input method editors (IMEs) provide toggles, such as F8 in Microsoft Japanese IME, to switch between half-width and full-width kana during entry, ensuring accurate input without post-hoc normalization.[28][33]Common Confusions in Standards
A common misconception is that the JIS X 0201 standard mandates the use of half-width forms for its katakana characters. In reality, JIS X 0201 defines the encoding for these characters in a single-byte range but does not specify their display width; the half-width appearance is a convention arising from their use in fixed-pitch, space-constrained environments like early computing systems. Another frequent confusion is the belief that all katakana characters, including additional variants such as small ka (ヵ), have corresponding half-width forms. However, half-width katakana are limited to the 63 characters defined in the JIS X 0201 set, which covers basic forms (with voiced and semi-voiced created via separate marks), basic small kana, and related punctuation but excludes certain extended characters from standards like JIS X 0208.[1][15] These misunderstandings often originate from the structure of Shift JIS encoding, where half-width katakana occupy single-byte slots while full-width forms use double bytes, leading to legacy data errors such as misaligned text or incorrect character interpretation during conversion. This dual-byte assumption has persisted in some tutorials and documentation, which incorrectly treat width as an inherent encoding property rather than a rendering choice.[34] In Unicode, half-width katakana are preserved in the compatibility zone (U+FF61–U+FF9F) for round-trip compatibility with legacy encodings like JIS X 0201, but the standard does not enforce their width; the East Asian Width property merely informs rendering. For new content, Unicode and related guidelines recommend using full-width forms to ensure consistent typography and avoid compatibility issues.[35][36]References
- https://commons.wikimedia.org/wiki/File:Bankbook_description_written_in_half-width_kana.jpg