ロゴ
ToolkitsLabEfficiency Hub
PR広告を含む

文字コード変換ツールASCIIコード表・JIS区点コード・文字化け診断に対応

UTF-8・Shift_JIS(CP932)・EUC-JP・JIS(ISO-2022-JP)・UTF-16を相互に変換できます。 1文字ごとのUnicode・JISコード・区点コードの一覧表示、0〜127のASCIIコード表、文字化けしたテキストの復元診断にも対応。

入力内容は外部に送信されません。

詳しく
変換テーブルを準備しています…

文字コード変換とは?UTF-8・Shift_JIS・EUC-JP・JISコードの関係と文字化けの仕組み

UTF-8は現在のWebやアプリ開発で標準的に使われる文字コードですが、日本国内では今なおShift_JIS(CP932)やEUC-JPで作られた古いWebシステム、業務システム、CSVファイルなどが数多く現役で稼働しています。異なる文字コード同士でデータをやり取りすると文字化けが発生し、原因の切り分けに時間がかかることがあります。

本ツールは4つのモードを備えた開発者・Web担当者向けの文字コードツールです。①文字コード変換では、UTF-8・Shift_JIS(CP932)・EUC-JP・JIS(ISO-2022-JP)・UTF-16・Windows-1252を相互に変換し、バイト列を16進数・URLエンコード・Base64で入出力できます。

②文字コード表では、入力した文字を1文字ずつ分解しUnicode・UTF-8・UTF-16・Shift_JIS・EUC-JP・JISコード・区点コードを一覧表示。JIS X 0208の範囲内かCP932独自の拡張領域かも判定します。③ASCIIコード表では、0〜127の全コードを10進・16進・8進・2進の対応と制御文字の意味つきで確認できます。

④文字化け診断は、化けたテキストを貼り付けるだけでどの文字コードの組み合わせで誤読されたかを推定し、元のテキストを復元します。すべての処理はブラウザ内のJavaScriptだけで完結し、入力したテキストが外部のサーバーに送信されることはありません。

こんなシーンで便利です

ASCIIコードの対応を確認したい時に

0〜127の10進数・16進数・8進数・2進数の対応と、CR・LF・TAB・ESCといった制御文字の意味を一覧で確認できます。TSV形式でのコピーにも対応しています。

漢字のJISコード・区点コードを調べたい時に

文字を入力すると、Unicode・UTF-8・Shift_JIS・EUC-JPとあわせてJISコードと区点コードを表示。JIS X 0208の第1水準・第2水準かCP932拡張かも判定します。

文字化けしたテキストを復元したい時に

「縺薙s…」「ã“ã‚“…」のような化けた文字列を貼り付けると、誤読パターンを推定して元のテキストの候補を表示します。

レガシーシステムとのデータ連携で文字化けが起きた時に

古い業務システムやCSVファイルがShift_JISやEUC-JPで作られている場合に、実際のバイト列を確認しながら原因を切り分けられます。

①②③などの機種依存文字が正しく扱えるか確認したい時に

丸数字・ローマ数字などがJIS X 0208の範囲内か、CP932独自の拡張領域かを判定し、メール(ISO-2022-JP)で送れるかどうかを事前にチェックできます。

古いURLのクエリ文字列(%XX形式)をデコードして読みたい時に

Shift_JISやEUC-JPでURLエンコードされた古いWebページのクエリ文字列を、実際の日本語テキストに変換して内容を確認できます(「+」は半角スペースとして解釈)。

使い方は簡単 5ステップ

  1. 上部のタブから「文字コード変換」「文字コード表」「ASCIIコード表」「文字化け診断」を選びます。
  2. 変換タブでは、方向(テキスト→バイト列/バイト列→テキスト)と対象の文字コード、バイト列の形式を選びます。
  3. テキストまたはバイト列を入力すると、結果と文字数・バイト数・機種依存文字や変換不可文字の有無が表示されます。
  4. 文字コード表タブに文字を入力すると、1文字ずつUnicode・UTF-8・Shift_JIS・EUC-JP・JISコード・区点コードが並びます。
  5. 文字化け診断タブに化けたテキストを貼り付けると、復元候補が可能性の高い順に表示されます。

※入力・変換処理はすべてブラウザ内で完結し、サーバーへの送信は一切行われません。変換テーブルは初回アクセス時にブラウザ標準のデコーダーから自動構築されます。

ご利用時の注意点

  • 変換の基準:Shift_JISの変換結果は日本語Windowsのコードページ CP932(Windows-31J)の割り当てに基づきます。同じ文字が複数の位置に割り当てられている場合は、Windowsのエンコーダと同じく下位(標準側)のバイト列を採用します。
  • JISコード・区点コード:JIS X 0208で定義されている6,879文字(非漢字524字・第1水準2,965字・第2水準3,390字)にのみ存在します。CP932独自の拡張領域(区13・区89〜92・区115〜120)の文字は「—」と表示します。
  • ISO-2022-JP:エスケープシーケンスで文字集合を切り替える7ビットコードです。JIS X 0208の範囲外の文字(機種依存文字・半角カタカナ)は表現できないため「?」に置き換えます。
  • EUC-JP:半角カタカナは0x8E+1バイトの2バイト、JIS X 0212の補助漢字は0x8F+2バイトの3バイトで表現されます。
  • 変換できない文字:絵文字やサロゲートペアで表される拡張漢字(𠮷など)はShift_JIS・EUC-JPの文字集合に存在しないため変換できません。該当する文字は自動検出して一覧表示します。
  • 文字化け診断:化けた時点で「�」(置換文字)が入っている場合は元のバイト情報が失われているため復元できません。その場合は元のファイルのバイト列から読み直す必要があります。
  • 完全無料・安全:入力したテキストやバイト列が外部に送信されることはない、ブラウザ完結型の設計を採用しています。

主要な文字コードの比較|1文字のバイト数と主な用途

同じ文字でも文字コードによってバイト数が変わります。代表的な文字コードのバイト数と対応範囲の比較です。

文字コード英数字ひらがな・漢字半角カナ絵文字主な用途
UTF-81バイト3バイト3バイト4バイト現在のWeb標準。HTML・JSON・多言語対応システム
Shift_JIS(CP932)1バイト2バイト1バイト非対応日本語Windows環境、レガシーなWebシステム・CSV
EUC-JP1バイト2バイト2バイト(0x8E+1)非対応旧UNIX系サーバー・古い日本語サイト
JIS(ISO-2022-JP)1バイト2バイト+切替3バイト非対応非対応メール本文(RFC準拠)など7ビット伝送
UTF-16(LE/BE)2バイト2バイト2バイト4バイトWindows・Javaの内部表現
ASCII1バイト非対応非対応非対応すべての文字コードの共通基盤(0〜127)
※バイト数は代表的な文字での値です。UTF-8の漢字は一部が4バイト(サロゲートペアで表される拡張漢字)になります。ISO-2022-JPは日本語の区間ごとにエスケープシーケンス(3バイト)が前後に入ります。英数字(0〜127の範囲)はUTF-8・Shift_JIS・EUC-JP・JISのいずれも1バイトで互換です。

ASCIIコード・JISコードの基礎と、文字化けの診断手順

文字コードを扱うときに押さえておきたい基礎知識と、文字化けが起きたときの実務的な対処手順を解説します。

結論:文字化けの正体は「文字コードの解釈違い」。3ステップで切り分ける

文字化けは、データそのものが壊れているのではなく、書き込まれた文字コードと、読み込む側が想定している文字コードが一致していないことで起こります。
切り分けは次の3ステップです。
①化けの形から当たりをつける:「縺薙s」のようにカタカナ混じりの漢字が並ぶならUTF-8をShift_JISで読んだ形、「ã“ã‚“」のようにアクセント付きラテン文字が並ぶならUTF-8をLatin-1で読んだ形です。
②復元できるか試す:本ツールの文字化け診断に貼り付けると、誤読パターンを推定して復元候補を表示します。
③読み込み側の指定を直す:復元できた組み合わせが分かれば、あとは読み込み側のエンコーディング指定を正しい値に変えるだけです。

ASCIIコードとは——0〜127の基本と、各文字コードとの互換性

ASCIIは1文字を7ビット(0〜127)で表す最も基本的な文字コードで、印字可能文字95字(32〜126)と制御文字33字(0〜31・127)で構成されます。
覚えておくと便利な値は、半角スペース=32(0x20)、「0」=48(0x30)、「A」=65(0x41)、「a」=97(0x61)です。大文字と小文字の差はちょうど32(0x20)なので、ビット演算で大小文字を変換できます。
重要なのは、UTF-8・Shift_JIS・EUC-JP・ISO-2022-JPのいずれもこの0〜127の範囲はASCIIと同じ1バイトだという点です。だからこそ英数字だけのテキストは文字コードが違っても化けません。逆にUTF-16はASCII文字も2バイトで表すため、ASCII互換ではありません。

制御文字と改行コード——CR・LF・TABの違い

ASCIIの0〜31には、文字ではなく動作を指示する制御文字が割り当てられています。実務で頻出するのは次の4つです。
・HT(0x09)=水平タブ。TSVの区切りに使われます。
・LF(0x0A)=改行(ラインフィード)。
・CR(0x0D)=復帰(キャリッジリターン)。
・ESC(0x1B)=エスケープ。ISO-2022-JPの文字集合切り替えや、ターミナルの色指定に使われます。
改行コードはOSによって異なり、Windowsは CRLF(0D 0A)、Linux・現在のmacOSは LF(0A)、旧MacOSは CR(0D)でした。CSVやテキストファイルで「行が1行にまとまってしまう」「行末に見えない文字が残る」症状は、この違いが原因です。本ツールの変換タブでバイト列を見れば、0D 0A か 0A かをその場で確認できます。

JISコード・区点コードとは——Shift_JISとの計算上の関係

区点コードは、JIS X 0208の文字を94×94のマス目(区と点)で指定する方式です。たとえば「あ」は4区2点、第1水準漢字の先頭「亜」は16区1点です。
ここから各文字コードのバイト列が機械的に導けます。
・JISコード=区・点にそれぞれ 0x20 を足す(あ → 0x24 0x22 = 2422)
・EUC-JP=区・点にそれぞれ 0xA0 を足す(あ → 0xA4 0xA2)
・Shift_JIS=2区ずつを1バイトにまとめる変換(あ → 0x82 0xA0)
JIS X 0208の区の割り当ては、1〜8区が記号・英数・かな・キリル文字・罫線、16〜47区が第1水準漢字(2,965字)、48〜84区が第2水準漢字(3,390字)で、合計6,879文字です。9〜15区と85〜94区は未定義で、ここがCP932の拡張領域として使われています。

Windowsの文字コードCP932と、機種依存文字が生まれた理由

日本語版Windowsが使ってきた文字コードは、正確にはCP932(Windows-31J)です。これは標準のShift_JIS(JIS X 0208)に、メーカーが独自に文字を追加したものです。
・区13:NEC特殊文字(①②③・ⅠⅡⅢ・㈱・№・℡・㎜など)
・区89〜92:NEC選定IBM拡張文字
・区115〜120:IBM拡張文字
これらが機種依存文字(環境依存文字)と呼ばれるのは、JIS X 0208では未定義のため、他のOSやメールの標準(ISO-2022-JP)では扱えないからです。
さらに厄介なのは、同じ文字がNEC領域とIBM領域の両方に割り当てられている重複文字が約400字ある点です(≒・∵・Ⅰなど)。本ツールはWindowsのエンコーダと同じく下位の割り当てを採用し、「≒」は0x81E0、「Ⅰ」は0x8754として変換します。

EUC-JPとISO-2022-JPの使い分けと特徴

EUC-JPは旧UNIX系サーバーで広く使われた文字コードで、ASCIIは1バイト、JIS X 0208の漢字・かなは2バイト(0xA1〜0xFE)です。半角カタカナは0x8E+1バイト(SS2)、JIS X 0212の補助漢字は0x8F+2バイト(SS3)という特殊な形になります。古いPerl/PHP製サイトやMySQLの旧データベースで今も見かけます。
ISO-2022-JPはメール本文の標準で、7ビットしか使えない経路を通すため、エスケープシーケンスで文字集合を切り替えるという独特の方式を採ります。日本語の開始に ESC $ B(1B 24 42)、ASCIIへの復帰に ESC ( B(1B 28 42)を挿入します。
この方式の制約として、半角カタカナと機種依存文字は送れません。メールで①や㈱が化けるのはこのためです。

HTMLのmeta charsetとHTTPヘッダーの整合性が重要

Webページで文字化けが起きる典型的な原因は、HTMLの<meta charset>タグの指定と、サーバーが返すHTTPヘッダーのContent-Type(charset)が一致していないケースです。
ブラウザはHTTPヘッダーの指定を優先するため、meta charsetだけを修正しても文字化けが解消しないことがあります。両方の設定を必ず揃えて確認しましょう。
加えて、ファイル自体が実際に何でエンコードされているかという3点目の要素もあります。「ファイルの実体」「meta charset」「HTTPヘッダー」の3つを一致させるのが根本的な解決です。

CSVファイルの文字コードトラブルへの対処法

業務システムから出力されるCSVファイルがShift_JIS(CP932)で作られている場合、UTF-8前提のプログラムで読み込むと文字化けが発生します。逆にUTF-8のCSVをExcelでそのまま開くと化けるのも、ExcelがCP932として読もうとするためです。
対処法は2つあります。
①読み込み側の文字コード指定をShift_JISに合わせる(Pythonなら encoding='cp932'、PHPなら mb_convert_encoding を使う)
②事前にファイル自体をUTF-8に変換してから処理する
なおUTF-8にBOM(EF BB BF)を付けるとExcelが自動的にUTF-8として開くため、Excelでの閲覧を前提にするならBOM付きUTF-8が実用的な選択肢です。ただしBOMを想定していないプログラムでは先頭に「」が混入するので、用途に応じて選んでください。

よくある失敗と対策

文字コードの指定を確認せず、思い込みでUTF-8として処理してしまう

現在はUTF-8が標準だからという思い込みだけで、実際にはShift_JISやEUC-JPで作られたファイルやAPIレスポンスをUTF-8として処理してしまい、文字化けの原因調査に時間がかかってしまう失敗です。

💡 対策・解決策を見る▼
文字化けが起きたら、まず化けたテキストを本ツールの文字化け診断に貼り付けて誤読パターンを特定してから対処方法を決めましょう。実際のバイト列を変換タブで確認するのも確実です。

HTMLのmeta charsetだけを修正し、HTTPヘッダーを見落とす

文字化けを直そうとHTMLのmeta charsetタグだけを修正したが、サーバー側のHTTPヘッダーのContent-Typeが異なる文字コードを指定したままになっており、修正が反映されない失敗です。

💡 対策・解決策を見る▼
「ファイルの実体」「meta charset」「HTTPヘッダーのcharset」の3つをすべて同じ文字コードに揃えましょう。ブラウザはHTTPヘッダーを優先するため、サーバー側の設定変更が難しい場合はヘッダー側の指定に合わせます。

機種依存文字を含む文書をメールで送信し、受信側で文字化けする

社内資料やメールに①②③やⅠⅡⅢといった機種依存文字を使ってしまい、異なるメールソフトやOS環境で受信した相手側の画面で文字化けや表示崩れが発生する失敗です。

💡 対策・解決策を見る▼
本ツールの文字コード表タブで、使う文字がJIS X 0208の範囲内かCP932拡張かを確認しましょう。CP932拡張と表示された文字は(1)(2)(3)や(株)のような機種に依存しない表記に置き換えてから送信します。

改行コードの違いを見落とし、行末に見えない文字が残る

Windowsで作られたCSV(CRLF)をLinux上のプログラムでLFだけを区切りとして読み込み、各行の末尾に復帰(0x0D)が残ってしまい、数値の比較や文字列の一致判定が失敗する失敗です。

💡 対策・解決策を見る▼
本ツールの変換タブでバイト列を確認し、行末が「0D 0A」か「0A」かを特定しましょう。読み込み側で改行コードを正規化するか、事前にファイルの改行コードを変換してから処理します。

CSVファイルの文字コードを確認せずにインポートし、文字が化ける

取引先や旧システムから受け取ったCSVファイルの文字コードを確認せずにそのままUTF-8前提のツールに取り込んでしまい、日本語の項目名やデータがすべて文字化けしてしまう失敗です。

💡 対策・解決策を見る▼
インポート前にファイルの一部を本ツールで確認し、Shift_JISとEUC-JPのどちらで解釈すべきかを判断したうえで、取り込み側の文字コード設定を正しく指定してから処理しましょう。

英数字だけで動作確認を済ませ、本番の日本語データで初めて化ける

0〜127のASCII範囲はどの文字コードでも同じバイト表現になるため、英数字だけのテストデータでは文字コードの不一致に気づけず、日本語を含む本番データで初めて文字化けが発覚する失敗です。

💡 対策・解決策を見る▼
動作確認には必ず日本語(ひらがな・漢字)と半角カタカナ、可能なら機種依存文字を含むテストデータを使いましょう。本ツールのサンプルボタンから、各パターンのテキストをすぐに呼び出せます。

よくある質問(FAQ)

Q.ASCIIコード表はどこで確認できますか

Q.

A. 本ツールの「ASCIIコード表」タブに、0〜127のすべてのコードを10進数・16進数・8進数・2進数の対応つきで掲載しています。制御文字(0〜31・127)はNUL・BEL・HT・LF・CR・ESCといった略号と日本語での意味、印字可能文字(32〜126)は実際の文字を表示します。制御文字のみ・印字可能文字のみでの絞り込みや、TSV形式での一括コピーにも対応しています。あわせてShift_JISの半角カタカナ(0xA1〜0xDF)の対応表も確認できます。

Q.JISコードや区点コードも調べられますか

Q.

A. 調べられます。「文字コード表」タブに文字を入力すると、Unicode・UTF-8・UTF-16・Shift_JIS・EUC-JPに加えて、JISコード(ISO-2022-JPで使う2バイトコード)と区点コードを表示します。たとえば「あ」は区4点2・JISコード2422、「亜」は区16点1・JISコード3021です。区点コードに0x20を足したものがJISコード、0xA0を足したものがEUC-JPのバイト列になります。

Q.UTF-8とShift_JISの違いは何ですか

Q.

A. UTF-8は1文字を1〜4バイトの可変長で表現する現在のWeb標準の文字コードで、世界中のほぼすべての文字を扱えます。一方Shift_JIS(実際にはWindows拡張版のCP932であることが多い)は、ASCII文字を1バイト、日本語の漢字やひらがなを2バイト、半角カタカナを1バイトで表現する、かつて日本語Windows環境やレガシーなWebシステムで広く使われてきた文字コードです。両者はバイト表現の仕組みが根本的に異なるため、変換せずに読み込むと文字化けが発生します。

Q.文字化けしたテキストから元の文字を復元できますか

Q.

A. 多くの場合できます。「文字化け診断」タブに化けたテキストを貼り付けると、「UTF-8のデータをShift_JISとして読んだ」「UTF-8のデータをLatin-1として読んだ」など7通りの誤読パターンで一度バイト列に戻し、正しい文字コードで読み直した候補を日本語らしさの高い順に表示します。ただし化けた時点で「&#65533;」(置換文字)が入っている場合は元のバイト情報が失われているため、完全な復元はできません。その場合は元のファイルやレスポンスのバイト列から読み直す必要があります。

Q.どの文字コードに対応していますか

Q.

A. Shift_JIS(CP932)、EUC-JP、JIS(ISO-2022-JP)、UTF-8、UTF-16 LE/BE、Windows-1252(Latin-1)の相互変換に対応しています。バイト列の形式は16進数・URLエンコード(%XX形式)・Base64から選べ、どの組み合わせでも双方向に変換できます。

Q.なぜUTF-8とShift_JISの間で文字化けが起きるのですか

Q.

A. 文字化けは、あるバイト列を「実際にエンコードされた文字コード」とは異なる文字コードとして解釈してしまうことで発生します。たとえばShift_JISでエンコードされたファイルをUTF-8として開いたり、その逆を行ったりすると、本来の文字とは異なる記号や意味不明な文字列として表示されます。HTMLのmeta charset指定やHTTPヘッダーのContent-Type、テキストエディタの保存時の文字コード設定など、複数の箇所で文字コードの認識がずれることが主な原因です。

Q.Windowsの文字コードはShift_JISと同じですか

Q.

A. 厳密には異なります。日本語版WindowsのANSIコードページは「CP932(Windows-31J)」で、これはShift_JISを拡張したものです。標準のShift_JIS(JIS X 0208)に加えて、①②③などのNEC特殊文字(区13)やNEC選定IBM拡張(区89〜92)、IBM拡張(区115〜120)が追加されています。本ツールはこのCP932の割り当てに基づいて変換し、JIS X 0208の範囲外の文字は「CP932拡張」として明示します。

Q.機種依存文字とは何ですか、なぜ注意が必要なのですか

Q.

A. ①②③などの丸数字、ⅠⅡⅢなどのローマ数字、㈱㈲といった略号は「機種依存文字(環境依存文字)」と呼ばれ、Windows拡張のShift_JIS(CP932)では変換できても、標準のJIS X 0208では未定義で他のOS・システムでは正しく扱えないことがある文字です。メールの標準であるISO-2022-JPでは送れないため、受信側で文字化けや表示崩れを起こす可能性があります。本ツールは入力中の機種依存文字を自動検出して警告します。

Q.Shift_JISに変換できない文字にはどのようなものがありますか

Q.

A. 絵文字(😀など)、サロゲートペアで表される拡張漢字(𠮷など)、Shift_JIS制定後に追加された一部の異体字、多くの言語固有の特殊記号などは、Shift_JISの文字集合に含まれていないため変換できません。本ツールではこうした文字を検出すると「?」(0x3F)に置き換えたうえで、変換できなかった文字を一覧表示してお知らせします。

Q.①や≒のように複数の割り当てがある文字はどのバイト列になりますか

Q.

A. CP932には同じ文字が複数の位置に割り当てられている文字が約400字あります(≒・∵・ⅠなどがNEC特殊文字とIBM拡張の両方に存在)。本ツールはWindowsのCP932エンコーダと同じく、より下位(標準側)のバイト列を採用します。たとえば「≒」は0x81E0、「Ⅰ」は0x8754になります。

Q.URLエンコードやBase64形式にも対応していますか

Q.

A. はい。バイト列は16進数表示のほか、レガシーなCGIやクエリ文字列でよく見られる「URLエンコード(%XX形式)」、および「Base64形式」でも出力・入力できます。URLエンコードの入力では、クエリ文字列の慣例に合わせて「+」を半角スペースとして解釈します。

Q.入力したテキストや変換結果は外部に送信されますか

Q.

A. 送信されません。本ツールはエンコード・デコード処理をすべてブラウザ内のJavaScriptだけで完結させる設計です。変換テーブルもブラウザ標準のデコーダーから初回アクセス時にその場で構築するため、サーバーへの通信は一切発生せず、入力内容や変換結果はページを離れると同時に破棄されます。

User Feedback & Request

あなたの声で、
このツールをより鋭く。

「こんな機能が欲しい」「ここを直してほしい」といったご意見や、新しいツールのリクエストを募集しています。エンジニアが直接目を通し、開発の参考にさせていただきます。

フィードバックを送る