全角文字とは、固定幅フォントにおいて半角文字の 2 倍の表示幅を持つ文字です。日本語のひらがな、カタカナ、漢字、および全角英数字・記号が全角文字に分類されます。この概念は、日本語のコンピュータ処理の黎明期に、1 バイトの ASCII 文字 (半角) と 2 バイトの日本語文字 (全角) を区別するために生まれました。

Unicode では、各文字に East Asian Width というプロパティが定義されています。このプロパティは Fullwidth (F)、Wide (W)、Halfwidth (H)、Narrow (Na)、Ambiguous (A)、Neutral (N) の 6 種類に分類されます。日本語の漢字やひらがなは Wide (W)、ASCII 文字は Narrow (Na) に該当します。Ambiguous (A) に分類される文字 (ギリシャ文字やキリル文字の一部など) は、環境によって全角・半角のどちらで表示されるかが異なるため、レイアウト崩れの原因になることがあります。

文字数カウントにおいて、全角と半角の扱いはプラットフォームによって大きく異なります。X (Twitter) は文字ごとに重みを持たせる方式で、漢字・かな・ハングルなどの CJK 文字は 1 文字が重み 2 として数えられます。上限 280 の枠に対して日本語は実質 140 文字しか入りません。SMS は性質が違い、全角も半角も 1 文字として数えますが、日本語が 1 文字でも混じると伝送のエンコーディングが UCS-2 に切り替わり、1 通の上限そのものが 160 文字から 70 文字へ下がります。Google 広告の見出しは上限 30 文字で、日本語・中国語・韓国語の文字を 1 文字 = 2 文字分として数えるため実質 15 文字です。このように「全角 = 半角 2 文字」という一つの換算式で説明できる仕組みは少なく、正確なカウントには対象プラットフォームのルールを個別に把握する必要があります。

データベース設計では、全角文字のバイト数がエンコーディングによって異なる点に注意が必要です。UTF-8 では全角文字は 3 バイト、UTF-16 では 2 バイトを消費します。ただしこれは基本多言語面に収まる文字の話で、𠮟 のような拡張漢字は UTF-8 で 4 バイト、UTF-16 でもサロゲートペアで 4 バイトを消費します。VARCHAR(255) の列に UTF-8 で全角文字だけを格納すると、バイト数ベースの制限では最大 85 文字しか入りません。一方、文字数ベースの制限 (MySQL の場合) では 255 文字まで格納可能です。この違いを理解していないと、データの切り詰めやエラーの原因になります。

Web フォームの入力バリデーションでは、全角・半角の変換処理が頻繁に必要になります。電話番号や郵便番号の入力で全角数字が使われるケースは多く、JavaScript の String.prototype.normalize('NFKC') を使えば、全角英数字を半角に正規化できます。逆に、カタカナを全角に統一する処理も、住所入力などで求められます。ただし NFKC は全角英数字だけを狙って変換してくれるわけではありません。半角カタカナは全角へ、丸数字の ① は 1 へ、㍿ は「株式会社」へ、全角スペースは半角スペースへと一括で置き換わります。電話番号欄の正規化のつもりで本文全体へ適用すると意図しない書き換えが混ざるため、適用範囲は入力欄単位で絞るのが安全です。

文字数カウントツールを使う際には、全角・半角の区別がカウント結果にどう影響するかを意識することが大切です。「全角 1 文字 = 半角 2 文字」として換算するシステムでは、同じ内容でも全角を多用すると文字数が増えます。文字数制限のある場面では、全角カタカナを半角に変換したり、全角スペースを半角スペースに置き換えたりすることで、制限内に収める工夫が可能です。ただしこれが効くのは表示幅や換算ルールに基づく制限のときだけです。UTF-8 のバイト数で制限される場面では、全角カタカナを半角カタカナにしても 1 文字 3 バイトのままで減りません (全角スペースを半角スペースにする置き換えは 3 バイトから 1 バイトに減ります)。バイト数の制限と表示幅の制限は別物として切り分けて考える必要があります。