すべてのテキストファイルを UTF-8 だと思い込む
社内システムや Windows ツールの出力には UTF-16、BOM 付き UTF-8、古い単一バイト系のデータが残っていることがあります。インポート側の不具合と決める前に、まず元ファイルのバイト列を確認しましょう。
CSV、ログ、翻訳ファイル、顧客エクスポートを取り込む前に、文字コード、BOM(Byte Order Mark)、UTF-8/UTF-16/ASCII の可能性をブラウザ内で確認できます。文字化けの原因切り分けや、最初の列名に余計な文字が混ざる問題の確認に役立ちます。
関連する作業フローを続けるか、この作業の次によく使うツールを開きます。
CSV を JSON 配列へ変換する前に、列名、空セル、数値扱い、文字コード、不要な列を安全に確認する手順です。
開く関連ツールBase64 を UTF-8 対応でエンコード/デコード。Base64URL の確認にも使えます。すべてブラウザ内で処理します。
開く関連ツールヘッダー、区切り、妥当性チェック対応の CSV ↔ JSON 変換。ローカル処理で安全。
開く関連ツールURL をエンコード/デコードして、クエリ文字列や API パラメータを安全に扱えます。
開くCSV、ログ、テキスト、翻訳ファイルなど、確認したいファイルをドロップするかクリックして選択します。
検出された文字コード、信頼度、BOM の有無、補足メッセージを確認します。
取り込み先が求める形式と比べます。たとえば UTF-8 でも BOM あり/なしで結果が変わることがあります。
文字化けしている場合は、エディタやデータ取り込み画面で検出結果に近い文字コードを選んで開き直します。
大きな移行や一括インポートの前に、代表的な複数ファイルで同じ確認を行います。
表計算ソフトや管理画面に CSV を取り込む前に、UTF-8 か、BOM があるか、最初の列名に隠れた文字が混ざる可能性がないかを確認します。
問い合わせログ、決済ログ、監査ログで日本語や記号が崩れて見えるとき、ファイル自体の文字コードと読み込み設定のどちらが怪しいかを切り分けます。
古いシステムから受け取ったファイルを UTF-8 へ統一する前に、BOM の有無や UTF-8 としての妥当性を確認して変換対象を絞り込みます。
翻訳 JSON、字幕、設定ファイル、ソースコードを共有する前に、想定外の BOM や非 UTF-8 データが混ざっていないかを確認します。
社内システムや Windows ツールの出力には UTF-16、BOM 付き UTF-8、古い単一バイト系のデータが残っていることがあります。インポート側の不具合と決める前に、まず元ファイルのバイト列を確認しましょう。
UTF-8 の BOM は一部の表計算ソフトでは問題になりませんが、CSV ヘッダーやスクリプトでは最初のフィールド名に隠れた文字として残ることがあります。取り込み先が BOM を許容するか確認してください。
ASCII だけの短いサンプルや、似たバイトパターンを持つレガシー文字コードは完全には判定できません。信頼度とプレビューを手がかりに、代表的なデータで再確認するのが安全です。
複数の CSV やログを結合するとき、UTF-8 と UTF-16、BOM あり/なしが混ざると後続処理で文字化けや列ずれが起きます。結合前に各ファイルの形式をそろえましょう。
顧客データをデータベースやスプレッドシートに取り込む前に、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 ではない疑いがある場合、取り込み前の判断材料を集めます。
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 はファイル先頭に置かれる隠れたバイト列です。UTF-8 や UTF-16 の種類を示す助けになりますが、CSV では最初の列名に混ざって見えることがあります。
元ファイルの文字コードと、インポート時に選ばれた文字コードが一致していない可能性があります。検出結果と信頼度を見て、エディタや取り込み画面で該当する文字コードを選んで開き直してください。
取り込み先が BOM を誤って列名の一部として扱う場合は、BOM なし UTF-8 として保存し直すと解決することがあります。逆に Windows 系のツールでは BOM 付き UTF-8 のほうが扱いやすい場合もあります。
ツールを開く前に、よくある作業フローと例を確認できます。
他の開発者ツールも確認できます
Base64 を UTF-8 対応でエンコード/デコード。Base64URL の確認にも使えます。すべてブラウザ内で処理します。
ヘッダー、区切り、妥当性チェック対応の CSV ↔ JSON 変換。ローカル処理で安全。
URL をエンコード/デコードして、クエリ文字列や API パラメータを安全に扱えます。
JSON 構文をブラウザ内で検証し、エラーの行・列と原因を確認できます。
行頭番号だけを削除し、本文中の数字は残すローカル処理ツール。