全角半角変換
全角・半角の文字を一括で相互変換します。全角英数字・記号・カタカナを半角に、または半角を全角に変換できます。ひらがな・漢字は変換されません。テキストを貼り付けてボタンを押すだけで完了します。
0文字
0文字
使い方
変換モード(「全角 → 半角」または「半角 → 全角」)を選び、テキストを入力欄に貼り付けてから「変換する」ボタンを押してください。変換結果が出力欄に表示されたら、「コピー」ボタンでクリップボードに取り込めます。
変換対象は英数字・記号・カタカナです。「全角 → 半角」モードでは全角英数字(A〜Z、a〜z、0〜9)・全角記号(!〜~)・全角カタカナ(ア〜ン)を半角に変換します。全角スペースも半角スペースに変換します。「半角 → 全角」モードでは半角の英数字・記号・カタカナをすべて全角に変換します。ひらがな(あ〜ん)と漢字はどちらのモードでも変換されず、そのまま保持されます。
変換が役立つ場面の例:データベースや帳票に入力する際のフォーマット統一(英数字を半角に揃える)、SNSや印刷物で文字の幅を統一したいとき(英字を全角に揃える)、プログラムのログや設定ファイルから半角英数字のみ使いたいとき、などです。
変換の仕組み
全角英数字・記号はUnicodeの「Halfwidth and Fullwidth Forms」ブロック(U+FF01〜U+FF5E)に格納されています。この範囲の文字は、対応する半角ASCII文字(U+0021〜U+007E)とコードポイントの差が0xFEE0(65,248)で一定です。そのため「全角→半角」変換はコードポイントから0xFEE0を引き、「半角→全角」変換は0xFEE0を足すだけで正確に変換できます。全角スペース(U+3000)は半角スペース(U+0020)と別規格なので個別に処理しています。
全角カタカナ(U+30A1〜U+30F6)と半角カタカナ(U+FF65〜U+FF9F)は上記の算術的な関係がなく、静的なマッピングテーブルを使って変換しています。半角→全角方向で難しいのが濁音・半濁音の処理です。半角カタカナでは「ガ」を「カ(U+FF76)」+「゙(U+FF9E)」の2文字で表しますが、全角では「ガ(U+30AC)」という1つのコードポイントで表します。半角→全角変換では文字を1文字ずつ読み進めながら「次の文字が濁点・半濁点かどうか」を先読みし、2文字を1文字に合成します。逆に全角→半角変換ではガ1文字をガ2文字に展開します。この「文字数の増減」が発生する点が、単純な文字コード変換と異なります。
【独自観点A:全角・半角の歴史的背景】「全角」「半角」という概念は1970年代末〜80年代の日本語端末に由来します。当時の端末は1行80文字(カラム)という制限があり、漢字のような幅の広い文字は2カラム分(全角)、ASCIIの英数字は1カラム分(半角)を占めると定められました。これが「全角=漢字の幅」「半角=英数字の幅」という慣例の起源です。規格面では、1969年に制定されたJIS X 0201が半角カタカナを明示的に規定しました。これは日本語端末でカタカナを1カラムに収める実用的な要求に応えるもので、英字(A〜Z)と同じ桁幅でカタカナを扱えるようにした当時の工夫です。その後1978年制定のJIS X 0208では全角の漢字・全角カタカナ・全角ひらがなが体系的に規定され、今日の全角文字セットの基盤が整いました。Unicodeが1991年に公開されたとき、これらの過去資産との互換性を維持するために「Halfwidth and Fullwidth Forms」ブロック(U+FF00〜U+FFEF)が設けられました。このブロックはあくまでレガシー互換目的の領域であり、Unicode本来の設計では「同じ文字に2つのコードポイントが存在する」のは異例です。新規テキストの作成では本来このブロックを意識する必要はありませんが、既存の業務システムや日本語処理の現場では表記統一の需要が今も根強く残っています。
【独自観点B:濁点・半濁点の2文字問題と実害】半角カタカナの濁音・半濁音が「2文字」になる仕様は、見た目上は問題なく見えても、実際のシステム処理でさまざまな実害を生じさせます。代表的な3つの場面を挙げます。まず文字数制限の問題です。フォームに maxlength=20 が設定されている場合、「パスワード」(全角5文字)を半角カタカナで入力すると「パスワード」=7文字になります。逆に半角→全角変換では文字数が減りますが、想定外のmaxlength超過が起きることもあります。次にJavaScriptの split() 問題です。`'ガ'.split('')` は `['カ', '゙']` という2要素配列を返し、文字数カウントが全角換算の倍になります。スプレッド構文(`[...'ガ']`)でも同様に2要素です。最後に検索ヒット漏れです。データベースに半角カタカナで格納されたレコードを全角カタカナで検索するとヒットしません。LIKE検索や全文検索インデックスは文字コードを直接比較するため、正規化(COLLATE設定やアプリ側での変換)が必要です。本ツールで全角に統一してから文字数カウントツール(/ja/text/character-counter/)と組み合わせると、正確な文字数を確認できます。
よくある質問
- 全角と半角、どちらで統一すべきですか?
- 用途によって異なります。プログラムのソースコード・URLパラメータ・CSVファイルなどのデータ処理には半角英数字が標準で、全角が混入するとバグや文字化けの原因になります。一方、書籍や雑誌の組版・看板・SNSの装飾的な投稿では全角で統一するとレイアウトが揃います。業務システムへの入力規則や印刷物のデザイン仕様に従って選ぶのが基本です。
- ひらがなは変換されないのはなぜですか?
- ひらがなには「全角版」と「半角版」が存在しないためです。半角カタカナ(アイウ)はJIS X 0201で規定された文字セットに含まれ、Unicodeでも半角・全角の両方に対応するコードポイントが割り当てられています。一方、ひらがなはJIS X 0208(後にUnicodeに統合)で全角のみとして規定されており、対応する半角の文字が存在しません。そのため変換の対象外となっています。
- 半角カタカナは使わない方がいいですか?
- 現代のWebや一般的なアプリケーションではUTF-8が標準のため、半角カタカナ自体は技術的に問題ありません。しかし半角カタカナを意識的に扱っていない古いシステムやShift_JIS前提のデータベースでは文字化けが起きる場合があります。また全角・半角が混在すると全文検索でヒット漏れが起きることがあります(例:「ラーメン」と「ラーメン」は別文字列として扱われる場合がある)。業務データや大量テキストを扱う場合は、このツールで全角に統一しておくと安全です。
- 全角スペースと半角スペースはコードにどんな影響がありますか?
- プログラムのソースコードや設定ファイルに全角スペース(U+3000)が混入すると、パーサーがスペースと認識せずに構文エラーが発生します。PythonやYAMLなどインデントに意味がある言語では特に起きやすいミスで、エラーメッセージが分かりにくいため原因を特定しにくいことがあります。コピー元のドキュメントやWebページに全角スペースが含まれていることが多いため、コードに貼り付ける前にこのツールで半角に変換しておくと安心です。HTMLでは見た目の違いはほぼありませんが、JavaScriptの文字列処理(trim()やsplit())では全角スペースを空白として扱わない場合があります。