半角文字とは、固定幅フォントにおいて全角文字の半分の表示幅を持つ文字の総称です。ASCII の英数字 (A-Z, a-z, 0-9) や記号類、そして半角カタカナが半角文字に分類されます。「半角」「全角」という概念は、日本のコンピュータ文化に深く根ざした用語であり、英語圏では halfwidth / fullwidth という表現で Unicode 仕様にも取り入れられています。

半角・全角の区別が生まれた背景には、1970 年代から 1980 年代にかけての日本語コンピュータの発展があります。当時の固定幅フォントでは、英数字を 1 バイト (8x16 ドット)、漢字やひらがなを 2 バイト (16x16 ドット) で表示していました。この表示幅の比率が「半角」「全角」の語源です。現在のプロポーショナルフォントでは実際の表示幅は文字ごとに異なりますが、概念としての半角・全角は入力規則やデータ処理の場面で依然として重要な役割を果たしています。

日本語の入力フォームでは「半角英数字で入力してください」という指示が頻繁に見られます。電話番号、郵便番号、メールアドレス、クレジットカード番号などは半角での入力が求められるのが一般的です。全角で入力するとバリデーションエラーになるフォームも多く、ユーザビリティの観点からは自動変換機能の実装が推奨されます。

エンコーディングの観点では、UTF-8 において半角英数字は 1 バイト、全角文字は 3 バイトを消費します。一方、半角カタカナ (Unicode の「Halfwidth and Fullwidth Forms」ブロック U+FF00〜U+FFEF のうち、半角カタカナに割り当てられた U+FF65〜U+FF9F) は見た目こそ半角ですが UTF-8 では 3 バイトを占めるため、バイト数の節約にはなりません。Shift_JIS では半角カタカナが 1 バイトだったため、レガシーシステムとの互換性を考慮する場面では注意が必要です。

プログラミングにおいて、全角と半角の混在はバグの温床になります。全角スペース (U+3000) がインデントに紛れ込んでコンパイルエラーを引き起こしたり、全角数字「１２３」を数値として処理できなかったりする問題は実務で頻繁に発生します。JavaScript では String.prototype.normalize() や正規表現を使って全角英数字を半角に変換する処理がよく実装されます。ただし半角カタカナを含む文字列を normalize('NFKC') にかけるときは、濁点・半濁点の扱いに癖があります。「ｶﾞ」は合成済みの「ガ」1 文字にまとまりますが、合成形が存在しない「ｱﾞ」は「ア」と結合用濁点の 2 コードポイントとして残ります。正規化してから数えると文字数が想定とずれる場合があるということです。

よくある誤解として、「半角文字は常に全角文字の半分のバイト数」という認識があります。これは Shift_JIS 時代には概ね正しかったものの、UTF-8 では半角カタカナも全角ひらがなも同じ 3 バイトです。また、Unicode の East Asian Width プロパティでは、文字を Fullwidth、Halfwidth、Wide、Narrow、Ambiguous、Neutral の 6 種類に分類しており、単純な半角・全角の二分法では捉えきれない複雑さがあります。

文字数カウントの観点では、半角・全角の区別はカウント方法に直接影響します。X (Twitter) は文字ごとに重みを割り当てる方式で、ASCII の英数字や記号は重み 1、漢字・かななどの CJK 文字は重み 2 として数えられます。上限は重み換算で 280 なので、日本語だけで書くと実質 140 文字が上限になります。ここで注意したいのは、重み 1 が適用される範囲がコードポイントの若い側 (おおむね U+10FF まで) に限られていることです。半角カタカナは U+FF65 以降に置かれているため、見た目が半角でも重み 2 として数えられます。「半角に置き換えれば枠の消費が半分になる」という発想は X では通用しません。SMS では半角英数字のみなら 160 文字、全角文字を含むと 70 文字が上限です。このように、サービスごとに半角・全角の扱いが異なるため、正確な文字数カウントには文字種の判定が欠かせません。