データとスプレッドシート · CSV クリーナー
UTF-8 と Windows-1252 の混同: Mojibake CSV エクスポートの修復
· 仕組み
csv エンコード データクリーニング
「José」が「José」になると、バイトは問題ありませんが、解釈は間違っています。この投稿では、2 つの最も一般的なエンコーディングがどのように衝突するか、症状を認識する方法、および再デコードによって問題が修復される方法について説明します。
アクセント付きの名前と中引用符がシンボル スープに変わりました — UTF-8 ファイルの明らかなパターンは Windows-1252 として読み取られ、その逆も可能です
ロード後に顧客名が交換ダイヤモンドになることは、CSV Cleaner が間違った従来のコード ページを検出したという証拠にはなりません。構成はその逆です。UTF-8 のみが理解され、Windows-1252 または Shift-JIS ファイルは UTF-8 として読み取られます。したがって、無効なバイト シーケンスは、CSV パーサーが文字を認識する前にすでに置換されている可能性があります。
アウトラインは José などのおなじみの mojibake を中心としていますが、ブラウザの読み取りパスは `File.text()` を使用し、エンコード セレクターを提供しません。この記事はその約束を訂正します。このツール内で対処可能な症状は、置換文字またはその他の破損したテキストであり、元のファイルのバイトは他の場所で回復するために保存されています。
UTF-8 以外のファイルは、検証済みの文字化けパターンではなく、置換文字としてこのツールに到達します。
区切り文字で区切られたファイルはディスク上のバイト数ですが、パーサーは JavaScript 文字列で動作します。エンコーディングは、これらのレイヤー間のマッピングを定義します。 CSV 構文はカンマ、引用符、およびレコード境界を指定しますが、どのレガシー マッピングがすべての非 ASCII バイトを作成したかを `File.text()` に伝える信頼性の高いディスク上の宣言はありません。
デコードによって U+FFFD 置換文字が生成されると、その後の CSV 操作はそれらのプレースホルダーを通常のテキストとして受け取ります。トリミングまたはエクスポートでは、元のバイト シーケンスまたは文字がそこに属していたのかを推測することはできません。だからこそ、損傷したディスプレイから組み立てられた検索と置換のリストよりも、手つかずのソースの方が重要なのです。
よくある 2 つの疑わしいもの — UTF-8 のマルチバイト シーケンスと Windows-1252 のシングル バイト、およびスワップ時に予測可能なガベージが生成される理由
UTF-8 は、マルチバイト シーケンスを持つ非 ASCII 文字を表します。 Windows-1252 は、多くの欧文文字を個々のバイト値に割り当てます。ある規則を別の規則に基づいて読み取ると、失敗したり、誤解を招くテキストが作成されたりする可能性がありますが、このルートでは、代替デコーダーのテスト、妥当な言語のスコア付け、または Windows-1252 の選択の提供は行われません。
唯一のエンコード固有のパーサー動作は、テキスト デコード後の先頭の U+FEFF UTF-8 バイト オーダー マークの削除です。これにより、マーカーが最初のヘッダーに参加できなくなります。これは一般的なエンコード検出ではなく、実装のどこにも記載されていない Shift-JIS、UTF-16、または地域コード ページをサポートしません。
ToolAcre は UTF-8 テキストを受け入れ、Windows-1252 候補を比較しません
置換文字は、テキスト デコーダが選択された解釈で一部の入力バイトをマップできなかったことを示します。以前の非可逆エクスポートによって疑問符が挿入された可能性があります。その場合、元の文字はすでに使用できなくなっている可能性があります。認識可能な Ã シーケンスは他のワークフローでも発生する可能性がありますが、このページではその履歴を診断しません。
1 つの姓だけからソース エンコーディングを決定しないでください。エクスポートするアプリケーションの設定、ファイルの出自、およびソースを変更しないバイト認識インスペクターを確認してください。クリーナーの行警告は、引用符の終了と列幅に関するものです。文字エンコーディングが正しいという証拠にはなりません。
検索と置換ではなく再デコード — 文字を 1 つずつパッチするのではなく、正しいエンコードでバイトを読み取り、UTF-8 を書き込むことが修正の理由です
確実な修復は、元のバイトに戻し、文書化されたソース エンコーディングで一度デコードしてから、UTF-8 を書き込むことです。この操作は、UTF-8 のみのテキスト パスを介して開く前に実行する必要があります。デコード後に目に見えるガベージ フラグメントを置き換えると、正当な文字列が破損する可能性があり、1 つのプレースホルダーに折りたたまれた複数の元の文字を区別できなくなります。
CSV Cleaner にはバイトレベルの再デコード制御がないため、アウトラインで約束された変換を実行できません。信頼できるソース対応の変換方法を使用し、代表的な名前をソース システムと比較して、区切り文字、引用符、空白、重複作業のために UTF-8 の結果をここに取り込みます。
このツールの外部で元のバイトから復元します。ここでの文字置換は復元できません
安全なデモンストレーションのために、アクセント付きの名前を 1 つ含む小さなレガシー エンコード ファイルを作成し、16 進数のコピーを保持します。これをツールにロードし、置換文字が表示されるかどうかを確認します。この観察により、UTF-8 境界が確立されます。予想される名前がわかっているだけで、元のコード ページが確立されるわけではありません。
次に、ToolAcre の外部で明示的に選択したデコーダーを使用して未処理のバイトを変換し、UTF-8 を保存し、その結果をロードします。 CSV パーサーが区切り文字を通常どおり処理している間、名前はそのままの状態で届くはずです。これら 2 つのパスを比較すると、クリーナー自体が回復を実行したと主張することなく、正しい教訓が得られます。
成功した例: サポートされていない修理を主張せずに UTF-8 境界を実証する
二重エンコードされたファイルでは、以前の変換を再構築する必要がある場合があり、文字通りの疑問符付きで既に保存されているデータは、別のソースがなければ回復できない場合があります。この実装にはエンコード履歴やバイト保存回復機能が含まれていないため、この記事では普遍的な反転については規定していません。
また、UTF-16、東アジアのエンコーディング、または正規化形式のサポートを主張することも避けられます。これらが重要な場合は、それらに名前を付けてテストするコンバータを選択してください。 CSV 解析が成功すると、区切り文字ステート マシンが行を検出したことが証明されるだけです。その段階以前の文字デコードが忠実であるかどうかについては何も述べていません。
解釈を一度修正します — ToolAcre CSV Cleaner のエンコード修復がデバイス上のエクスポートを再デコードおよび再エンコードする方法
ToolAcre は、先頭の UTF-8 BOM を削除し、ブラウザのダウンロード パスを通じて結果の文字列を UTF-8 CSV としてシリアル化できます。任意のレガシー バイトを正しい Unicode に変換することはできません。これらのバイトは、ユーザーが選択したデコーダなしでブラウザの固定テキスト読み取り境界をすでに超えているからです。
置換マークを停止信号として扱います。ソースを保存し、プロデューサーからそのエンコーディングを識別し、適切なバイト認識ツールで一度変換し、重要な名前を検証します。その場合にのみ、その構成が実際に約束する構造ジョブに対して CSV Cleaner を使用してください。