結論：幅の変換と、使える文字の種類を分ける
6例を変換すると、半角にした後も英数字だけにはならない例が4つありました。全角の「Ａ」は半角の「A」に変わりますが、「－」は「-」へ、「ガ」は「ｶﾞ」へ変わります。空白やカナが消えて英数字になる処理ではありません。
申込フォームで「半角英数字」と書かれているときは、文字の幅に加えて、記号や空白を含めてよいかが別の確認点になります。本稿ではA〜Z、a〜z、0〜9だけを英数字として数えます。各申込先が許す文字・長さの条件を再現した合否判定ではありません。
全角半角変換入力例の幅を変え、残る記号や空白を見比べる登録なしで使えます開く
判定：６例の変換結果と英数字だけの条件
n=6の架空入力を、現行の全角半角変換で「全角→半角・全部」に変換しました。2026年10月1日の計算関数を動かし、空白削除などの追加整形は使っていません。英数字だけかどうかの確認は、変換後の文字を別に調べた本稿の実測です。
| 入力 | 変換後 | A〜Z・a〜z・0〜9だけか | 残った文字 |
|---|---|---|---|
| Ａｂ１２ | Ab12 | はい | 英数字4文字 |
| Ａ－１２ | A-12 | いいえ | ハイフン |
| Ａ １２ | A 12 | いいえ | 半角スペース |
| ガ | ｶﾞ | いいえ | 半角カナと濁点 |
| １２３ | 123 | はい | 数字3文字 |
| 山田 | 山田 | いいえ | 漢字2文字 |
「A-12」と「A 12」は、見た目を細くしても英数字だけにはなりません。ここで示すのは文字種の区別であり、その入力先がハイフンや空白を受け付けるかは別です。住所欄・氏名欄・フリガナ欄の条件を、一つの「半角」という言葉だけで同じものとして扱えません。
一次資料：文字の分類と、画面上の幅は別に定義される
Unicodeの幅の区分は、任意の画面で何ピクセルになるかの保証ではありません。UnicodeのEast Asian Widthには、次の説明があります。
the actual display width of a glyph is given by the font
— Unicode Standard Annex #11「East Asian Width」§4 https://www.unicode.org/reports/tr11/（2026-10-01 到達）
日本語で言えば、実際に描かれる字形の幅はフォントによる、という説明です。本文はさらにレイアウトで調整される場合にも触れています。「全角は必ず半角の2倍に見える」という判定を、任意のフォントへ当てはめる根拠にはなりません。
All of ASCII is an example of East Asian Narrow characters.
— Unicode Standard Annex #11「East Asian Width」§4 ED5 https://www.unicode.org/reports/tr11/（2026-10-01 到達）
ASCIIはこの分類ではNarrowの例です。幅の分類そのものが、フォームで許す文字の一覧になるわけではありません。WHATWGのInfraでは、英数字について次のように定義しています。
An ASCII alphanumeric is an ASCII digit or ASCII alpha .
— WHATWG Infra「Code points」 https://infra.spec.whatwg.org/#ascii-alphanumeric（2026-10-01 到達）
この定義の数字は0〜9、英字はA〜Z・a〜zです。本稿の確認もこの範囲で行い、個別サービスの入力規則とは区別しました。
間違えやすい点：文字数や保存サイズは幅と連動しない
半角カナの「ｶﾞ」は、今回の測り方では2コードポイント・UTF-8で6バイトです。変換前の「ガ」は1コードポイント・3バイトでした。一方で「Ａｂ１２」は4コードポイントのまま、12バイトから4バイトへ減りました。
| 取り違え | 今回の測定から区別できること |
|---|---|
| 半角にすれば全て1バイト | 「ｶﾞ」はUTF-8で6バイト |
| 全角から半角なら文字数も半分 | 「Ａｂ１２」も「Ab12」も4コードポイント |
| 半角変換なら空白が消える | 全角空白1つは半角空白1つへ変わった |
| 漢字も細い形へ変わる | 今回の「山田」はそのまま |
コードポイント数は、見た目の文字のまとまりや入力欄の上限の数え方とは同じとは限りません。6例すべてについて、別のPython処理で出力・コードポイント数・UTF-8バイト数・英数字条件を照合しました。Unicodeの互換正規化による元文字との対応も確認しましたが、変換ツール全体が互換正規化と同じ処理だという検証ではありません。
測っていないこと・ここから先は推論
実在する申込フォームの受理・拒否、スマホのキーボード操作、字体ごとの見た目の幅は測っていません。文字種が条件に合っていても、必須欄・文字数・氏名の表記方法など別の理由でエラーになる可能性は残ります。
今回の6例は全Unicode文字の検証ではありません。異体字、結合文字、絵文字、半角に対応する文字がない記号や、文字数上限の数え方も対象外です。変換によって本人の氏名表記や住所の意味が変わらないかも、この計算だけでは判断できません。
次の１手：入力例の変換前後を比べる
次の1手は、入力例を全角半角変換に入れ、残った文字を見比べることです。幅がそろったかと、英数字以外が残っていないかは別々に見られます。申込先の条件に合うかを自動判定する機能ではありません。