データとスプレッドシート · CSV クリーナー
スプレッドシート ユーザー向けの文字エンコーディング: ASCII、Windows-1252 および UTF-8
· 背景
csv エンコード データ形式
エンコーディングは、どのバイトがどの文字を意味するかについての合意であり、CSV ファイルではどの文字が使用されるかについては決して記述されません。この投稿では、ASCII、Windows-1252、UTF-8、なぜ UTF-8 が勝ったのか、そしてそれが輸出に何を意味するのかをわかりやすく説明します。
何も説明していない説明としての「エンコーディングの問題です」 - エンコーディングとは実際には何なのか
「エンコーディングの問題」と言うと、境界は特定されますが、解決策は特定されません。ファイルにはバイトが格納されます。ページが区切り文字と引用符を認識するには、文字が必要です。バイトと文字の一致が間違っている場合、CSV ステート マシンが記述どおりに動作しているにもかかわらず、パーサーは置換マークを受け取る可能性があります。
ToolAcre の合意は明示的です。選択されたテキストは UTF-8 として読み取られ、先頭の UTF-8 バイト オーダー マークのみが特別な処理を受けます。この狭い規約は、CSV にエンコード ラベルが付いているように見せるよりも便利です。構造上のクリーンアップを信頼するには、輸出者と受取人が同意する必要があります。
ASCII: 共有コア — 7 ビット、英語のアルファベットと句読点、そしてそれがほぼすべてのエンコーディングに共通する理由
ASCII 文字は、ほとんどの CSV 構文で使用されるよく知られた英語の文字、数字、句読点の UTF-8 と重複します。このため、顧客名またはシンボルに共有範囲外のバイトが導入されるまで、ファイルは正常に表示されます。このリポジトリはこの実際的な観察をサポートしていますが、ASCII の歴史や正確な設計年表の主要な情報源ではありません。
したがって、1 つの名前がすでに破損している場合でも、カンマと引用符は正しく解析できます。構造的な成功は、性格の忠実さではありません。すべて英語のサンプルでは国際データにとって重要なエンコード境界を行使できないため、エクスポートをテストする場合は非 ASCII フィクスチャを含めてください。
ASCII オーバーラップは便利なコンテキストですが、ビット数と履歴には外部ソースが必要です
従来のコード ページはリージョン テーブルでバイト値を割り当て、間違ったテーブルを使用すると文字が変更されます。ワークブックは Windows-1252 詳細を要求しましたが、ToolAcre には選択可能なデコーダーまたはマッピング テーブルが含まれていません。その構成では、Windows-1252 および Shift-JIS が UTF-8 として読み取られ、置換文字が表示されることを警告します。
プロデューサー設定または未処理のバイトから動作するエンコード対応インスペクターを通じて、レガシー ソースを識別します。このクリーナーに名前からテーブルを推測するよう依頼しないでください。 `File.text()` が破損した文字列を返すと、パーサーはデコードによって破棄されたバイトの区別を回復できなくなります。
従来のコードページの詳細はリポジトリの証拠の外にあります。 ToolAcre はそれらをデコードしません
UTF-8 は、共通の構文文字を変更せずに、ASCII のオーバーラップを超えるテキストを表すことができます。ブラウザーは、ワーカーが解析する前に、選択されたバイトを JavaScript 文字列に変換します。テストが示すように、その文字列内では、Unicode 名と絵文字が ToolAcre のパーサーとシリアライザーを往復します。
この証拠は、モジュールを完全な Unicode 説明にするものではありません。それは、ルートが有効なデコードされた文字列、引用符で囲まれたフィールド、およびエクスポートテキストを保持すると述べています。正規化形式、書記素クラスター、またはすべての Unicode 変換に関する質問はコードの外にあり、1 回の成功した往復から推測すべきではありません。
ToolAcre は、完全な Unicode エンコード モデルではなく、UTF-8 テキスト処理を示します。
プロジェクトは UTF-8 を選択します。これは、それが構成された入力および出力コントラクトであるためです。リポジトリ ファイルは、広範な Web が UTF-8 を採用した歴史的な理由を確立していないため、この記事では要求された主張を省略しています。製品の真実を実用化するには、普遍的な採用の物語は必要ありません。
オペレーターにとって、標準化とは、ロードする前に UTF-8 にエクスポートまたは変換し、代表的な多言語値を検証し、レビューされたテーブルをシリアル化することを意味します。受信スクリプトも UTF-8 を期待し、BOM を受け入れるかどうかを決定する必要があります。債務不履行に関する一般的な声明よりも、双方の合意が重要です。
リポジトリは UTF-8 をこのツールのコントラクトとして確立しますが、より広範な Web がそれを選択した理由ではありません
先頭の U+FEFF は区切り文字検出の前に削除され、結果は `hadBom` を記録するため、インターフェイスはそれを報告できます。エクスポートでは、訪問者がオプションを選択したときに同じマークを先頭に追加できます。この選択をしないと、出力は最初のヘッダー文字から直接始まります。
マークは、一部のスプレッドシート ワークフローで UTF-8 を認識するのに役立ちますが、厳密なスクリプトまたはデータベース インポートによって最初のヘッダーにマークが付加される可能性があることが構成によって警告されます。このオプションは、一般的な清潔さとしてではなく、既知の消費者に対して使用してください。 BOM ポリシーはインターフェイス契約の一部です。
これでカバーされないもの — UTF-16 エクスポート、東アジアのエンコーディング、合成文字の正規化
UTF-16、東アジアのレガシー エンコーディングと Unicode 正規化はここでは実装されていません。どちらも、バイトオーダーの検出や置換文字の修復ではありません。これらの省略に名前を付けると、ユーザーはダウンロードの成功を元のキャラクターがすべて生き残ったことの証拠として扱うことができなくなります。
サポートされていないバイトが含まれている場合は、元のバイトを保存し、そのソース用に設計されたデコーダを使用します。検証済みの UTF-8 に変換した後、ToolAcre は文書化された CSV 構造を処理できるようになります。文字のデコードを行の解析から分離すると、障害の診断が容易になり、破壊的な推測が回避されます。
すべてのエクスポート UTF-8 を作成してそう言います — ToolAcre CSV Cleaner のエンコード修復がブラウザーでレガシー エクスポートを UTF-8 に変換する方法
UTF-8 を明示的な交換要件にし、データセットで使用される実際の文字クラスでテストします。 ToolAcre は、先頭の UTF-8 BOM を削除または追加し、有効な Unicode セル文字列を保持し、CSV 引用符を正規化できます。元のアウトラインで約束されていたレガシー変換を実行できません。
置換文字が表示された場合は、クリーニングまたは再保存する前に停止してください。元のバイトから回復し、名前を確認してから戻ります。この順序により情報が保護されます。区切り文字、重複、および空白の操作によって信頼できる出力が生成される前に、エンコードが正しく行われている必要があります。