コンテンツにスキップ

半角カナ

出典: フリー百科事典『ウィキペディア(Wikipedia)』

これはこのページの過去の版です。ケイ20003 (会話 | 投稿記録) による 2011年9月14日 (水) 11:01個人設定で未設定ならUTC)時点の版であり、現在の版とは大きく異なる場合があります。

半角カナ(はんかくカナ)とは、JIS X 0208など片仮名を含む他の文字集合と同時に運用される場合におけるJIS X 0201片仮名文字集合の通称である。漢字を含む文字集合で定義された片仮名に対して、半分の文字幅で表示されることが一般的であったためこのように呼ばれる。JIS X 0201で規定される8ビット符号化およびShift_JISにおいて0xA1-0xDFの範囲の1バイト文字がこれにあたる。また、Shift_JISEUC-JPなどの符号化方式やUnicodeでも互換性の目的でこの文字集合をもっている。

これらの文字は過去との互換性の維持のために用意されており、新規の文書等では使うべきでないとされている[1]

歴史

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が開発され、使用されるようになった。

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

いずれにしても、コンピュータによる漢字処理が一般化するのは1980年代中頃からで、それまでは8ビットのカタカナを用いてメッセージの表示やデータベースが構築されていた。かつてのダイレクトメールのコンピュータによる宛名印字がすべてカタカナであったのは、このためである。

呼称の是非

JIS X 0201(もしくはASCII)とJIS X 0208を組み合わせて使う場合、JIS X 0208側の文字はほぼ正方形で、JIS X 0201の文字はJIS X 0208の文字の半分の幅・同じ高さで表示・印刷されることが一般的であった。そのため、JIS X 0201の文字は「半角文字」、JIS X 0208の文字は「全角文字」、特にJIS X 0201の方の片仮名は「半角カナ」、「半角カタカナ」と呼ばれるようになった。しかしそもそも半角・全角は字体・フォントの文脈で使われる言葉であり、また一般に文字コードは文字の幅を規定するものではないため、この表現は間違いである。ただし、EUC-JPには文字表示幅の定義が含まれる[2]。またUnicodeにも文字幅に関する規定が存在する。東アジアの文字幅を参照すること。

Shift_JISではJIS X 0201の片仮名は1バイト、漢字などは2バイトで表されることから「1バイトカナ」と呼ばれることもある。しかし文字をあらわすのに必要なバイト数は符号化方式でそれぞれ異なる。実際、「半角カナ」相当の文字を表現するのに、EUC-JPでは2バイト、UTF-16では2バイト、UTF-8では3バイトを要する。

このように正しい名称を与えることが難しいため、結局慣用的な「半角カナ」という呼称が用いられることが多いが、正確性に問題があることに意識がある場合は「いわゆる半角カナ」といった言い方をされることもある。「半角カナ」にこだわらず厳密な定義が必要な場合は、その文脈で使われている文字集合によって「JIS X 0201のほうの片仮名」や「Unicodeの半角・全角形の片仮名」と呼ばれる。

符号化方式による半角カナの扱い

ISO-2022-JP

ISO-2022-JP電子メール等で使われる符号化方式であり、エスケープシーケンスによって7ビットの領域に文字集合を指示して運用する。指示可能な文字集合はASCIIJIS X 0201ラテン文字、JIS X 0208-1978およびJIS X 0208-1983であり、JIS X 0201片仮名は含まれていない。一般に「メールでは半角カナは使えない」といわれるのはこの事による。

Shift_JIS

Shift_JISは、JIS X 0201の8ビット符号の未使用領域に漢字などの1バイト目を割り当てたエンコーディングであるので、エスケープシーケンスなどを用いず半角カナや漢字を使用できる。MS-DOSが全盛であった頃は、全角文字を使用できない環境との互換性の問題や、データ量や画面表示幅の節約などの面から、2バイト日本語に半角カナが併用されることが頻繁であった。

1バイトJIS X 0201との共存を前提としたため、JIS X 0208文字の1バイト目に使用できる領域が限られた結果、2バイト目に7ビットコードを使用せざるを得なくなり、8ビットを利用した符号化にも関わらず、Shift_JISを理解しない処理系での扱いを難しいものにしてしまった。

EUC-JP

日本語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

過去、すでに多くのShift_JIS等の文書で半角カナが使用されており、それらの文書のコード変換において情報が欠損しないようにするために(いわゆるround-trip conversionの保証)、Unicodeには通常の片仮名とは別に半角カナに相当する互換用文字が定義されている。具体的にはHalfwidth and Fullwidth Formsという分類の中にHalfwidth Katakana variantsとして含まれている。あくまで過去の文章との互換のためであり、半角カナがお墨付きを得たと見るのは誤りである。とはいえ、将来のシステムで半角カナが非サポートとなるような事態はまず無くなったと考えてよい。

インターネットにおける半角カナ

電子メール

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

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

その後、

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

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

なお、携帯電話iモードなど)の電子メールでは、携帯電話網とインターネットとの接続部分(ゲートウェイ)にて、半角カタカナ→全角カタカナの変換が行われている。

World Wide Web

転送プロトコルであるHTTPにはSMTPのように8ビットコードを扱えないという問題は存在しない。文書を記述するHTMLについては、Shift_JISやEUC-JP、Unicodeなど半角カナを扱える文字コードであれば、そのまま半角カナを使用できる。

インターネットバンキングでは全国銀行データ通信システム互換性上、振込などでの口座名義に半角カナを直接入力する場合がある。全角入力した文字を半角カナのデータに変換する事で意図しない文字数の変化を避ける信頼性確保のためでもある。

電子掲示板に半角カナを書き込んでも、ほとんどの場合、文字化けしない。ただし、半角カナを使用した場合、前述したようにShift_JISとEUC-JPを区別することが難しいため、ブラウザCGIなどで文字コードの自動認識に失敗する事が多いという問題がある。また、半角カナを表示不能な端末もある。

文字コードの自動認識は完全たり得ない為、HTTPレスポンスヘッダやMETA要素で文字コード情報のオプションパラメータを指定する場合もある。また、HTMLのフォームでは、漢字を含むあらかじめ決められた文字列をhiddenフィールドなどを経由しクライアントから送信させるなど、自動認識に依存せずに送信コードを判別する手法も用いられている。このような確実な対応があれば、文字コード誤認の問題は発生しない。

半角カナが使用されるケース

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

なお、全角カナとの視覚的差異があることや、文字コード(8ビット)によって、全角カナ(16ビット)の約半分のバイト数しか要さないことなどの特徴から、携帯電話向けのサービスでは現在でも積極的に使用されている。

前者の特徴は、等幅フォントを使用してテキストのみで表形式を表示する場合などで、上下位置などを合わせる目的として多く使用される。また、ニュアンスの微妙な違いを伝えたり、アスキーアートを作成するために用いられることも多い(ただし、発信者と受信者のフォントセットが異なる場合、これはうまくいかないことがある)。

後者の特徴は、例えばデータベースなどで使用可能なバイト数に制限がある場合や、1バイトの文字しか使用できないシステムで使用されている。また、文字(パケット)通信に課金がなされるような場合(特に携帯電話などのパケット通信)に有利になるため、使用されることもある。

一般的なフォントでは幅が狭く表示されることから、Microsoft Windowsではメニュー部などで少ない面積でユーザーに情報を与える必要のある場面によく利用されていた。その後、ひらがな・(全角の)カタカナが細い造型のフォント (MS UI Gothic) を用意することによって、脱半角カナを図った。現在、新規のアプリケーションで半角カナをメニューに用いる例は無くなったとみてよい。ただ、一般的なデスクトップコンピュータシステムと異なり、表示情報量に制約の大きい携帯電話などの画面を前提としたシステムでは、半角カナによるシステムが現在も開発されている。日本経済新聞のウェブページ(NIKKEI NET、日経ネット。無償で速報記事等を公開しているページ)では2010年3月現在、見出し一覧に半角カタカナと全角カタカナを併用(混在)している。このほか、近畿日本鉄道のサイト([1][2])でもしばしば半角カタカナが使用されている。

半角カナ一覧

上位4ビット
0 1 2 3 4 5 6 7 8 9 A B C D E F


4


0
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F ソ

緑色で塗りつぶした範囲 (0xA1-0xDF) が半角カナの領域、黄色で塗りつぶした範囲は7ビットで表現できる領域、ピンクで塗りつぶした範囲はShift_JISの1バイト目として使用される領域である。

関連項目

脚注

  1. ^ JIS X 0208:1997 附属書 1(規定)シフト符号化表現
  2. ^ 日本語 EUC の定義と解説, Revision 1.7, UI-OSF-USLP 共同技術資料(1991年12月10日).