文字コード検出 | ファイルのエンコードと BOM を確認

エンコードブラウザ内で処理(アップロードなし)

CSV、ログ、翻訳ファイル、顧客エクスポートを取り込む前に、文字コード、BOM(Byte Order Mark)、UTF-8/UTF-16/ASCII の可能性をブラウザ内で確認できます。文字化けの原因切り分けや、最初の列名に余計な文字が混ざる問題の確認に役立ちます。

次に行うこと

関連する作業フローを続けるか、この作業の次によく使うツールを開きます。

このツールの使い方

CSV、ログ、テキスト、翻訳ファイルなど、確認したいファイルをドロップするかクリックして選択します。

検出された文字コード、信頼度、BOM の有無、補足メッセージを確認します。

取り込み先が求める形式と比べます。たとえば UTF-8 でも BOM あり/なしで結果が変わることがあります。

文字化けしている場合は、エディタやデータ取り込み画面で検出結果に近い文字コードを選んで開き直します。

大きな移行や一括インポートの前に、代表的な複数ファイルで同じ確認を行います。

このツールを使う場面

CSV インポート前の文字化け対策

表計算ソフトや管理画面に CSV を取り込む前に、UTF-8 か、BOM があるか、最初の列名に隠れた文字が混ざる可能性がないかを確認します。

サポートログの文字化け調査

問い合わせログ、決済ログ、監査ログで日本語や記号が崩れて見えるとき、ファイル自体の文字コードと読み込み設定のどちらが怪しいかを切り分けます。

レガシーファイル移行の事前確認

古いシステムから受け取ったファイルを UTF-8 へ統一する前に、BOM の有無や UTF-8 としての妥当性を確認して変換対象を絞り込みます。

開発・翻訳ファイルの受け渡し確認

翻訳 JSON、字幕、設定ファイル、ソースコードを共有する前に、想定外の BOM や非 UTF-8 データが混ざっていないかを確認します。

よくあるミス

すべてのテキストファイルを UTF-8 だと思い込む

社内システムや Windows ツールの出力には UTF-16、BOM 付き UTF-8、古い単一バイト系のデータが残っていることがあります。インポート側の不具合と決める前に、まず元ファイルのバイト列を確認しましょう。

BOM の有無を見落とす

UTF-8 の BOM は一部の表計算ソフトでは問題になりませんが、CSV ヘッダーやスクリプトでは最初のフィールド名に隠れた文字として残ることがあります。取り込み先が BOM を許容するか確認してください。

検出結果を絶対的な答えとして扱う

ASCII だけの短いサンプルや、似たバイトパターンを持つレガシー文字コードは完全には判定できません。信頼度とプレビューを手がかりに、代表的なデータで再確認するのが安全です。

異なる文字コードのファイルをそのまま結合する

複数の CSV やログを結合するとき、UTF-8 と UTF-16、BOM あり/なしが混ざると後続処理で文字化けや列ずれが起きます。結合前に各ファイルの形式をそろえましょう。

CSV エクスポートをアップロード前に確認する

顧客データをデータベースやスプレッドシートに取り込む前に、BOM と文字コードを確認します。

入力
customers-export.csv
先頭バイト: EF BB BF 69 64 2C 6E 61 6D 65
出力
文字コード: UTF-8
BOM: あり
信頼度: 1
次の確認: 取り込み先が最初の列名を id と読む場合は、BOM なし UTF-8 として保存し直します。

文字化けした多言語ログを診断する

ログや問い合わせファイルの文字が崩れて見えるとき、UTF-8 として妥当か、別の読み方が必要かを切り分けます。

入力
support-log.txt
表示例: 안녕하세요
出力
可能性: UTF-8 のバイト列が別の文字コードとして表示されています
次の確認: エディタや取り込み設定で UTF-8 を選んで開き直します。

非 UTF-8 の可能性があるファイルを見分ける

古い業務システムから受け取ったテキストが UTF-8 ではない疑いがある場合、取り込み前の判断材料を集めます。

入力
legacy-report.txt
検出結果: Unknown / Binary / ISO-8859-1
メッセージ: Contains non-ASCII characters but is not valid UTF-8.
出力
次の確認: 元システムの出力設定を確認し、必要なら変換ツールで UTF-8 にそろえてから再インポートします。

文字コード検出の仕組み

このツールはブラウザ内でファイルのバイト列を読み取り、先頭に UTF-8、UTF-16LE、UTF-16BE の BOM があるかを確認します。BOM が見つかった場合は文字コードの強い手がかりになります。

BOM がない場合は、すべてのバイトが ASCII 範囲内か、または UTF-8 として妥当な並びかを検証します。妥当な UTF-8 であれば高い信頼度で報告します。

UTF-8 として成立しない非 ASCII バイト列は、バイナリデータやレガシー文字コードの可能性として扱います。この場合は元システムの出力設定、エディタのプレビュー、取り込み先の指定文字コードを合わせて確認してください。

短い英数字だけのファイルでは、複数の文字コードで同じように読めるため判定材料が少なくなります。日本語、記号、アクセント文字など実際に問題が出る文字を含むサンプルで確認すると精度が上がります。

よくある質問

文字コード確認のためにファイルはアップロードされますか?

いいえ。ファイルはブラウザの FileReader で読み取り、手元の端末内で解析されます。CSV、ログ、顧客エクスポートなど、外部に送る前に確認したいデータの一次チェックに向いています。

すべての文字コードを正確に判定できますか?

完全ではありません。BOM 付き UTF-8、UTF-16LE、UTF-16BE、ASCII、妥当な UTF-8 は比較的安定して判定できますが、似たバイト列を持つレガシー文字コードは信頼度付きの手がかりとして見てください。

BOM(Byte Order Mark)とは何ですか?

BOM はファイル先頭に置かれる隠れたバイト列です。UTF-8 や UTF-16 の種類を示す助けになりますが、CSV では最初の列名に混ざって見えることがあります。

CSV を開くと日本語や記号が文字化けするのはなぜですか?

元ファイルの文字コードと、インポート時に選ばれた文字コードが一致していない可能性があります。検出結果と信頼度を見て、エディタや取り込み画面で該当する文字コードを選んで開き直してください。

UTF-8 の BOM は削除すべきですか?

取り込み先が BOM を誤って列名の一部として扱う場合は、BOM なし UTF-8 として保存し直すと解決することがあります。逆に Windows 系のツールでは BOM 付き UTF-8 のほうが扱いやすい場合もあります。

関連作業ガイド

ツールを開く前に、よくある作業フローと例を確認できます。

関連ツール

他の開発者ツールも確認できます

すべてのツールを見る