半角カナ

ASCII普及前、大型コンピュータ（メインフレーム）で使われていたEBCDICコードでは、各社ごとに8ビットで表現されるカタカナや日本語の句読点コードを定義していたために、各社間の互換性を欠いていた。

ASCIIには、7ビットで表現される128文字分のエリアにしか文字は定義されておらず、そこに制御文字、ラテン文字、数字、約物などが配置されている。ASCIIを元に制定された国際規格ISO 646では10文字が各国特有の文字、記号と交換可能であったが、ラテン文字以外で書かれる言語を符号化するには不足していた。

こうした経緯から、日本では、ラテン文字集合とは別に片仮名と日本語用の句読点などを収録した片仮名文字集合を規定し、7ビット環境または8ビット環境で運用するJIS X 0201が制定された。規格で規定された符号化方式のうち、広く使われたのは0x20–0x7Eにラテン文字集合、0xA1–0xDFに片仮名文字集合を割り当てた8ビット符号化方式である。コンピュータで漢字を扱うことが困難であった創始期は、この片仮名を用いて日本語でメッセージを表示していた。

後にJIS X 0208が規定され、平仮名、片仮名、漢字など様々な文字が扱えるようになった。それまでのJIS X 0201の資産がそのまま使えるように、JIS X 0208をそのまま使うのではなく、JIS X 0201で空いていた領域にJIS X 0208の文字コードを移動 (Shift) して当てはめるShift_JISが開発された。その際、旧来のコンピュータとの互換性などの問題からJIS X 0208で新たに規定された片仮名（全角片仮名）と、従来のJIS X 0201の片仮名（半角片仮名）は別々の文字として扱われるようになった（呼称については後述）。

全角および半角片仮名の区別が生じた当初は半角片仮名は正式な文字ではなく、互換性のために残された規格上の文字に過ぎないと見なされていた。JIS X 0208:1997『附属書 1（規定）シフト符号化表現』では、「参考　JIS X 0201 の片仮名用図形文字集合の割当ては、この規格の将来の改正では削除することを予定する」と記載されていた。符号化方式によっては半角片仮名が文字集合に含まれておらず、例えば当初は電子メールでは使用できないなどの理由もあり、初期の時代のインターネットでは半角片仮名の禁止がマナー化されることがあった。

しかしUnicodeが一般的に使用されるようになると、Unicodeが半角片仮名を正式に文字集合として取り入れたこともあり、半角片仮名を禁止する風潮は薄れていった。JIS X 0213:2000『附属書5（規定）文字の代替名称』では HALFWIDTH KATAKANA が記載されているが、削除予定との記述は取り除かれている。

現代においては片仮名の表示・印刷には全角片仮名の使用が一般的であり、半角片仮名の使用は極めて限定的ではあるが、何らかの理由で半角片仮名が使用されている場面を目にする機会は残っている。

JIS X 0201（もしくはASCII）が使用されていた初期のコンピュータでは描画性能の限界から画面上に表示、または印刷される文字は全て幅が固定のフォントであり、片仮名もラテン文字に合わせて細身の書体で表示されていた。

時代が下ってコンピュータの性能が向上して文字幅が可変長になり、さらにJIS X 0201とJIS X 0208が組み合わせて使われるようになると、JIS X 0208の文字はほぼ正方形で、JIS X 0201の文字は旧来のシステムとの親和性から正方形の半分の幅で表示・印刷されることが一般的になった。そのため、JIS X 0201の文字は「半角文字」、JIS X 0208の文字は「全角文字」、特にJIS X 0201の方の片仮名は「半角カナ」「半角カタカナ」ないしは「半角片仮名」と呼称・表記されるようになった。

もっとも半角・全角は本来字体・フォントの文脈で使われる言葉であり、また一般に文字コードは文字の幅を規定するものではないため、「半角カナ」「半角片仮名」などの呼称は俗称に過ぎなかった（ただし、EUC-JPには文字表示幅の定義が含まれる^[1]。Unicodeにも文字幅に関する規定が存在する。東アジアの文字幅を参照すること）。そのため、正確性に問題があることに意識がある場合は「いわゆる半角カナ」といった言い方をされることが多かった。また、Shift_JISではJIS X 0201の片仮名は1バイト、漢字などは2バイトで表されることから「1バイト (カタ)カナ」と呼ばれることもあったが、文字をあらわすのに必要なバイト数は符号化方式でそれぞれ異なり、JIS X 0201の片仮名を表現するのに、EUC-JPでは2バイト、UTF-16では2バイト、UTF-8では3バイトを要するため、これも必ずしも正しい表現ではなかった。厳密な定義が必要な場合は、その文脈で使われている文字集合によって「JIS X 0201のほうの片仮名」などと呼ぶほかなかった。

しかし、更に時代が下ると結局は慣用的に使用されていた「半角カナ」「半角片仮名 (カタカナ)」などの呼称が定着してしまい、UnicodeやJIS X 0213では「Halfwidth Katakana（半角片仮名）」として表記され、これが今日における正式名称となった。

Unicodeでは通常の片仮名は「Fullwidth Katakana（全角片仮名)」という名称で、「Halfwidth Katakana（半角片仮名）」とは異なる文字として登録されている。なお、同様の経緯を辿ってきた文字集合として「Halfwidth Hangul（半角ハングル）」があり、これらは併せて「Halfwidth and Fullwidth Forms（U+FF00–FFEF）」に入っている。

日本語入力システムにおいては、Microsoft WindowsのMS-IMEおよびmacOSの日本語入力プログラムでは「半角カタカナ」、Google 日本語入力では「半角カナ」の表記が採用されている。

2020年現在でもJIS X 0201しか扱えない機器・端末などでは、日本語を表現する手段として半角カナが使用されている。またソフトウェアやデータの互換性を保つ目的で使用している場合もある。

金融機関は今日もっともJIS X 0201時代の影響が色濃く残る分野の一つである。JIS X 0201時代に構築された各銀行の基幹システムや全国銀行データ通信システムとの互換性の問題から、現在でも口座名義や振込時の依頼人名に使用できる文字は半角の英数字および片仮名に限定されており、一般利用者も預金通帳などでこれらのシステムに起因する片仮名表記を目にする機会が多い。様々な文字が使用可能なWorld Wide Web上ですら、インターネットバンキングでは振込などでの口座名義は片仮名での入力が基本である。もっとも入力インターフェース上では全角片仮名での入力が可能（システムで半角片仮名のデータに変換される）なことが大半ではあるが、一部には直接片仮名半角カナでの入力を求めるシステムも存在する。

パーソナルコンピュータの分野では、特に初期のMicrosoft Windowsにおいて、半角片仮名の幅が狭く表示されるという特徴を利用し、メニュー部など少ない面積でユーザーに情報を与える必要のある場面によく利用されていた。その後、日本語のWindows環境では平仮名・（全角の）片仮名を細身にしたフォント (MS UI Gothicおよび Meiryo UI) が標準で使用されるようになった事や、「固定幅の狭いボタンに文字を詰め込む」という設計思想のアプリが減った事から、現在では半角カナをメニューに用いる必要は無くなっている。

携帯電話の分野では、特にフィーチャーフォンの時代において、画面が小さく表示情報量に制約が大きかったこと、当時一般的であったShift_JISの文字コードでは全角片仮名よりもデータ容量が減少するなどの特徴から、パーソナルコンピュータと同じくメニュー部や、ウェブページ上のテキストなどにおいて積極的に利用された。スマートフォンが普及する頃になると表示情報量の制約は少なくなった上、Shift_JISに代わって一般的となったUTF-8の文字コードではデータ容量が減少するというメリットが存在しないことなどから、Webサイトやメールでの半角片仮名の使用は廃れた。一方でホーム画面などで表示するアプリの名称は文字数制限が厳しいことから、意図しない改行や省略を避けるために2024年現在でも使用が継続されている。

インターネットコミュニティにおいては、全角片仮名との視覚的な差異からアスキーアートを作成するために用いられたり、オンドゥル語などインターネットスラングにおいて通常の片仮名とは異なったニュアンスを伝えるために現在も使用されている。

電子メールを配送するSMTPというプロトコルは7ビットのみを透過し、8ビット目をゼロにする仕様であるため、日本ではJUNET時代に7ビットのみを用いることがルール化された。これは後にRFC 1468として文書化され、ISO-2022-JPという名称になった。

ISO-2022-JPで指示可能な文字集合はASCII、JIS X 0201ラテン文字、JIS X 0208-1978およびJIS X 0208-1983であり、JIS X 0201の片仮名すなわち半角片仮名は含まれていない。一般に「メールでは半角カナは使えない」と言われたのはこのためであり、インターネットで半角片仮名が敬遠される理由の一つにもなった。

ソフトウェアによっては誤ってメッセージ中に半角カナが含まれていた場合に、8ビットコードのまま送信したり、エスケープシーケンスを用いたり、Quoted-printableなどでエンコードし7ビット化して送信するソフトウェアが存在した。後者の場合には、対応したソフト同士であれば問題なく表示が出来るが、違うソフト同士や8ビットで送信された場合は正しく表示されないため、「半角カナを使うと文字化けする」と言われるようになった。ここから、ネット上の文章からの半角カナ撲滅を唱えるような急進的な意見が出現した。また、当初Windowsに付属していたメールソフトが、SI（シフトイン）とSO（シフトアウト）を使用した勝手な符号化方法を使用して、他のメールソフトとの互換性をなくしていたこともその意見を強めさせた。その後、Windowsのメールソフトも、他のメールソフトと同じ符号化方法になったが、「いわゆる半角カナの利用は本来廃止すべきなので、あえて対応しない」という理由により、半角カナを実装していないメールソフトも多かった。

その後、以下の事項などの変化により、Shift_JISをBase64でエンコードすることなどで、半角カナを正当な方法で送受信でき、半角カナの使用により問題が発生することは減っている。

• メールサーバの多くがSMTPを拡張し8ビットコードも扱えるようになったESMTPに対応した
• メッセージ中に文字コードやエンコード方式の情報を明記できるようになった (MIME)
• Unicodeの普及

なお、携帯電話IP接続サービス（iモードなど）の電子メールでは、携帯電話網とインターネットとの接続部分（ゲートウェイ）にて、半角カタカナから全角カタカナへの変換が行われていた。

前述のISO-2022-JPのように半角片仮名が使用できない文字符号化方式が存在する一方で、半角片仮名を規格に含む方式も多数存在し、コンピュータ上での文書保存やWorld Wide Webで利用可能である。

Shift_JISは、JIS X 0201の8ビット符号の未使用領域に漢字などの1バイト目を割り当てたエンコーディングであるので、エスケープシーケンスなどを用いず半角カナや漢字を使用できる。1バイトJIS X 0201との共存を前提としたため、JIS X 0208文字の1バイト目に使用できる領域が限られた結果、2バイト目に7ビットコードを使用せざるを得なくなり、8ビットを利用した符号化にもかかわらず、Shift_JISを理解しない処理系での扱いを難しいものにするという欠点を残した。

日本語EUC (EUC-JP) も8ビット環境を前提とした文字コードだが、JIS X 0208の1文字目にあたるコードは、JIS X 0201を1バイトで表した場合の半角カナ部分に重なるように配置されている。そのため、半角カナに相当する文字を使用する必要がある場合は制御文字SS2（シングルシフト2、0x8E）に続けて使用することになる（このため一見2バイトに見えるが、SS2は文字集合を次の1文字分だけ切り替えるという印のため、片仮名自体はやはり1バイトで符号化される）。この記法によるカナ使用を実装していない処理系も多い。

EUC-JPにおいてJIS X 0208を表すために使用されるコード範囲 (0xA1–0xFE) は、1バイトカナのコード範囲 (0xA1–0xDF) を完全に内包するため、偶数の文字数で書かれたShift_JISの半角カナは、EUC-JP文字列と（頻度やパターンからの推測以外の方法では）区別がつかない。逆に、EUC-JPの半角カナ（1バイト目0x8E、2バイト目0xA1–0xFE）文字列も、Shift_JIS文字列と区別がつかない。これが「半角カナは文字化けする」と言われる理由の1つである。

国際規格の文字符号化方式であるUnicode（UTF-8, UTF-16など）にも半角片仮名は含まれており、Unicodeが一般的となった2020年現在においては世界中で半角片仮名が利用可能となっている。Unicodeによって文字コード間の対応が保証されたことにより、将来のシステムで半角カナが非サポートとなるような事態はまず無くなったと考えてよい^[2]。

緑色で塗りつぶした範囲 (0xA1–0xDF) が半角カナの領域、黄色で塗りつぶした範囲 (0x00–0x7F) は7ビットで表現できる領域、ピンクで塗りつぶした範囲 (0x81–0x9F, 0xE0–0xFC) はShift_JISの1バイト目として使用される領域である。"・「」、。ー"の6記号の半角版も半角カナの領域となっている。(0xA1–0xA5, 0xB0)

• 全角と半角
• JIS X 0201, JIS X 0208, JIS X 0208
• Unicode
• Shift_JIS