文字エンコーディング検出器
貼り付けたテキストまたはアップロードされたファイルの文字エンコーディングを検出 — BOM スニッフィング（UTF-8/UTF-16/UTF-32）、実際の UTF-8 連続バイト検証器、ASCII 検出、および BOM がなくバイトが有効な UTF-8 ではない場合の Windows-1252 や ISO-8859-1（Latin-1）などの単一バイト レガシー文字セットのバイト周波数ヒューリスティック。
入力
任意のファイル型。ブラウザで局所的に読み取られます。テキスト ボックスが空の場合にのみ使用されます。
出力
| Property | Value |
|---|---|
| No data yet | |
検討されたすべての候補
| Encoding | Confidence | Signals |
|---|---|---|
| No data yet | ||
このツールを使う他の方法
REST API
curl -X POST https://api.iotools.cloud/v1/tool/character-encoding-detector \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"inputText": "Hello, World!",
"file": ""
}'ご自身のアカウントのキーに差し替えてください。ツールのフィールドがそのままリクエストボディになります——ラッパーはありません。
AIエージェントに依頼する
Use the IOTools `character-encoding-detector` tool (Character Encoding Detector) on this input:
YOUR_INPUT_HEREIOTools MCPサーバーに接続された任意のエージェントにこれを貼り付け、入力内容を追加してください。
埋め込みウィジェット
<iframe
src="https://iotools.cloud/embed/character-encoding-detector/"
width="100%" height="520" frameborder="0" scrolling="no" loading="lazy"
title="文字エンコーディング検出器 — iotools.cloud"
sandbox="allow-scripts allow-forms allow-same-origin allow-downloads allow-popups allow-popups-to-escape-sandbox"
allow="clipboard-write"
style="width:100%;border:1px solid #e5e7eb;border-radius:12px;overflow:hidden"></iframe>
<script src="https://iotools.cloud/embed.js" async></script>ご自身のページに貼り付けるだけ——無料、キー不要、リンクを掲載するだけです。
| API/MCP 1回あたりの費用 | 5クレジットから |
|---|
次の方法でも利用可能
ガイド
文字化け — アクセント記号が付いた文字であるべき位置に疑問符があったり、é の代わりに é のような文字列があったりする — ほとんどの場合、ファイルが 1 つの文字エンコーディングで書き込まれ、別のエンコーディングで読み戻されたことを意味します。文字エンコーディング検出器は、貼り付けたテキストまたはアップロードされたファイルの未加工バイトを検査し、その最も可能性が高いエンコーディングを報告し、その推測の背後にあるバイト レベルの証拠を提供します。
使用方法
テキストを 入力テキスト に貼り付けるか、ファイルをアップローダーにドラッグしてそれの未加工バイトを検査します。結果は自動的に更新され、検出されたエンコーディング、確信度 の割合、見つかった BOM、バイト数、および 推論 行を平易な言語で表示します。その下の 検討されたすべての候補 テーブルには、検出器が考慮したすべてのエンコーディングが一覧表示され、それぞれに独自の確信度と推論があるため、次点の推測とそれらがなぜ低いスコアを得たかを確認できます。
検出の仕組み
検出は、最も確実なものから最も確実でないものへと、固定の確認順序を通じて実行されます。
- バイト オーダー マーク（BOM）。 一部のエンコーディングはファイルに固定バイト シーケンスを付加します — UTF-8 の場合は
EF BB BF、UTF-16 の場合はFF FE/FE FF、UTF-32 の場合は 4 バイトのバリアント。1 つ見つけることはほぼ確実です：99% の確信度。 - 純粋な ASCII。 すべてのバイトが
0x00–0x7Fの範囲内である場合、それは有効な ASCII です — そして、ASCII は UTF-8 の厳密なサブセットであるため、同時に有効な UTF-8 です。100% の確信度で報告されます。 - 有効な UTF-8。 BOM なしで、実際の UTF-8 検証器がバイト ストリームをウォークスルーします。継続バイトが正しい高ビットを持っているかを確認し、「オーバーロング」エンコーディング（コードポイントが必要とするより多くのバイト）を拒否し、範囲外のコードポイントまたは孤立した UTF-16 サロゲート ハーフを拒否します。これは単なる「デコードが例外を発生させたか」ではなく、本物の文法チェックです — そのため、寛容なデコーダーが無言で受け入れるであろう不正な形式のシーケンスをキャッチします。きれいに合格したテキストは、UTF-8 として 97% の確信度で報告されます。
- 単一バイト レガシー文字セット推測。 バイトが UTF-8 検証に失敗した場合、検出器は Windows-1252 と ISO-8859-1（Latin-1）間のバイト周波数ヒューリスティックにフォールバックします。これらは 2 つの最も一般的な単一バイト西部エンコーディングです。
0x80–0x9F範囲内のバイトは Latin-1 では未定義の制御コード ですが、Windows-1252 ではそれらのテキストが印字可能な句読点（カール記号付き引用符、ダッシュ）であるため、これらのバイトの存在は Windows-1252 を示しています。このブランチは 70% の確信度をはるかに下回る上限があります。なぜなら、これは統計的推測であり、確実性ではないからです — 同じバイトが複数の文字セットで有効な場合がよくあります。
私のデータはどこかにアップロードされますか？
いいえ。検出はブラウザ内で完全に実行されます（または、API を介して、リクエスト ハンドラーで） — サード パーティ サービスには何も送信されません。
ファイルが Shift_JIS、Big5、または別の CJK エンコーディングとして検出されないのはなぜですか？
これらのレガシー マルチバイト アジア エンコーディングはカバーされていません — バイト範囲だけから推測すると、BOM チェックや UTF-8 文法チェックと異なり、多くの誤検知が発生します。ファイルが Shift_JIS または GBK であることがわかっている場合は、検出に頼るのではなく、そのラベルで直接デコードしてください。