開発者向け

文字コード判定・変換ツール

最大256KBのファイルや16進ダンプからUTF-8・Shift_JIS・EUC-JP・ISO-2022-JP・UTF-16の候補を確認。厳格デコードと損失なしのバイト列変換で文字化け調査を補助します。

登録不要

最大100,000 UTF-16コード単位（BMP文字は1、 絵文字などは2以上）・変換後1形式あたり256KB。表現できない文字は 「?」へ置換せずエラーにします。

このツールについて問い合わせる →

文字コード判定・変換ツールについて

文字コードと、このツールで確認できること

文字コードは、文字とbyte列の対応方法です。同じ「あ」でも、UTF-8ではE3 81 82、Shift_JIS系では82 A0になります。

このツールは、UnicodeテキストをUTF-8、Shift_JIS系、EUC-JP、ISO-2022-JP、UTF-16 BE/LEのbyte列へ損失なしで表現できる場合だけ変換します。表現できない絵文字などを「?」へ黙って置換しません。

自動判定は候補です

文字コードがファイル内に常に記録されているとは限らないため、byte列だけからの判定は推定です。特にASCII範囲だけの短い入力はUTF-8やShift_JIS等で同じbyte列になり、一意に決められません。

判定候補だけを根拠に保存し直さず、自動判定結果と「各文字コードでの厳格な解釈」を見比べてください。不正なbyte列は置換文字で成功扱いにせず、その文字コードではデコード不可と表示します。

対応範囲と上限

  • UTF-8: 現在のWebで推奨されるUnicode符号化。
  • Shift_JIS系: Windows-31J相当の拡張文字を含むlegacy encoding。
  • EUC-JP / ISO-2022-JP: 既存の日本語データで使われるlegacy encoding。
  • UTF-16 BE / LE: byte orderを明示したUTF-16。BOM付き入力はBE/LEを区別します。

テキスト入力は最大100,000 UTF-16コード単位（BMP文字は1、絵文字などは2以上）、1形式の変換結果・ファイル・16進入力の復元後byte列は最大256KBです。画面負荷を抑えるため、長いデコード結果は先頭20,000 UTF-16コード単位、16進ダンプは先頭4,096byteだけを表示します。

使い方

  1. テキスト → バイト列: テキストを入力し、各文字コードのbyte数と変換可否を確認します。selectで選んだ1形式の16進ダンプを表示します。
  2. 判定 / デコード: 256KB以下のファイルを選ぶか、16進ダンプを入力します。判定候補、自動候補での結果、各文字コードでの厳格な解釈を照合します。

入力した本文やファイルbyteはNanTooの処理APIへ送らず、このページを開いているブラウザ内で処理します。サイト共通のアクセス計測やブラウザ拡張機能など、NanTooの文字コード処理外の通信・動作まで無条件に保証する説明ではありません。

よくある質問

Q. 判定候補が表示されれば、その文字コードで確定ですか?
いいえ。自動判定はbyteの並びから推定した候補です。ASCIIだけの入力や短い入力などは複数の文字コードで同じ内容になります。各文字コードでの解釈と、ファイルを作成したアプリ側の設定を照合してください。
Q. デコードできないbyteは置換文字で表示しますか?
いいえ。各文字コードの厳格なデコーダーで不正なbyte列を検出し、その解釈をデコード不可として表示します。別の有効な文字コード候補まで一律に失敗扱いにはしません。
Q. 絵文字をShift_JISやEUC-JPへ変換できますか?
多くの絵文字はlegacy encodingで表現できません。本ツールは「?」等への黙示置換を変換成功とせず、その文字コードでは表現できないと案内します。UTF-8またはUTF-16を選んでください。
Q. 文字化けしたファイルを元どおりに復元できますか?
元のbyte列が残り、正しい文字コードを特定できれば読める場合があります。一度誤った文字として再保存されて元byteが失われた場合や、複数文字コードで解釈できる短い入力では、このツールだけで元の内容を確定できません。
Q. 入力したテキストやファイルは送信されますか?
文字コードの判定・変換処理では、入力本文やファイルbyteをNanTooの処理APIへ送信しません。ブラウザ内で処理し、画面を閉じるとツールの保持状態は失われます。

関連記事

絵文字 (Emoji) の歴史 ― 1999 年 NTT ドコモ 176 文字から MoMA、Unicode 16 まで

絵文字は1999年に栗田穣崇がNTTドコモのi-modeで設計した176文字に起源を持つ。日本ローカルから始まった文化が、2010年Unicode 6.0で世界標準に、2016年にはMoMA永久コレクション入り。本記事ではUnicode Consortium、MoMA、栗田氏インタビュー等の一次ソースから絵文字史を整理します。

文字コード戦争 — Shift_JIS vs EUC-JP vs UTF-8、日本語Webが経験した混沌

なぜ日本語には3つも文字コードがあったのか。Shift_JISの「5C問題」、EUC-JPのUnix支配、ISO-2022-JPのメール世界、機種依存文字の闇、そして絵文字がUnicodeに統合されるまでの30年史を技術的背景から解説します。

UTF-8 の誕生 — Rob Pike と Ken Thompson がダイナーのランチョンマットに書いた設計

1992 年 9 月、ニュージャージーのダイナーで Rob Pike と Ken Thompson がランチョンマットの裏に書いた符号化方式が、現在 Web の 98% を占める UTF-8 になりました。ASCII 互換・自己同期・バイト順非依存という設計判断の背景を、Pike 本人の証言メール (2003) と RFC 3629 を一次資料に辿ります。

CSV の RFC 4180 と Excel の独自仕様 — なぜ CSV は壊れるのか

CSV は「誰でも扱えるシンプルな形式」と思われがちですが、RFC 4180 の厳密な仕様と Excel の独自仕様には無視できない差があります。BOM・Shift-JIS・改行コード・引用符エスケープの4大トラブルと、実務での回避策を一次資料で解説します。

このツールを評価
3.0(2件)