テキストおよび日常ツール · テキスト ツールキット
CR、LF、CRLF: 行末の由来と、貼り付けたテキストが改行される理由
· 背景
行末 テキストクリーンアップ データのエクスポート
キャリッジ リターンとライン フィードのテレタイプの起源、オペレーティング システムが異なる規則を選択した理由、およびそれらの選択が貼り付けられたテキスト内で 2 重の空白行や浮遊文字としてどのように表示されるかについて説明します。
各行の後に空白行を含むエクスポート — 別のシステムからのファイルが 2 倍の行数で貼り付けられる理由
3 行のエクスポートを貼り付けると、各レコードの後に空行が表示されます。すぐに Windows CRLF のせいにしたくなりますが、標準に準拠したテキスト領域では通常、正規化された形式で改行が表示されます。行が 2 重になるということは、以前の変換でキャリッジ リターンとライン フィードが 2 つの独立した区切り文字として扱われたか、レコード間に余分な改行が挿入されたことを意味することが多くなります。
どの段階で変更されたかがわかるまで、オリジナルを保管してください。制御文字を表示できるエディターでソースを比較し、貼り付けられた行数を比較します。 ToolAcre は、CRLF、LF、および単独の CR をそれぞれ 1 つの境界として意図的に受け入れるため、変更されていない 3 レコードのファイルは、単に Windows からのものであるという理由だけで 6 行ではなく 3 行を生成するはずです。
余分な空白行は症状であり、CRLF のみが原因であることを証明するものではありません
名前は印刷端末上の物理的な動作を表します。キャリッジ リターンはキャリッジを現在の行の先頭に移動し、ライン フィードは用紙を次の行に進めます。どちらのモーションも独立して要求できるため、これらは別個のコントロールでした。 ASCII では、これらを 10 進数 13 の制御文字 CR および 10 進数 10 の LF として保持しました。
最新の画面では紙は動かなくなりましたが、バイト値はファイル、プロトコル、プログラミング インターフェイスに残されています。 CR と LF が互換性のない句読点である理由、および CRLF が 2 文字のシーケンスである理由は、歴史によって説明されています。これは、すべての最新のアプリケーションがそれらを個別に処理するという意味ではありません。パーサーは通常、このペアを 1 つの論理的な行末として認識します。
3 つの規則 - Unix および最新の macOS の LF、Windows の CRLF、従来の Mac OS の CR、およびそれぞれが合理的であると思われる理由
Unix および Unix 系システムでは、従来、行末に LF が使用されており、最新の macOS もその規則に従っています。 Windows のテキスト ファイルでは、従来、CRLF が使用されています。 Classic Mac OS では CR のみが使用されていましたが、Mac OS X では Unix 基盤と LF が採用されました。ツールが正規化に同意せずにプレーン テキストを交換する場合、これらの選択肢は表示されたままになります。
言葉自体を変える慣例はありません。問題は、読者が 1 つの表現のみを期待する境界、またはすべての制御文字で単純に分割する境界で発生します。堅牢なライン パーサーは、単独の CR または LF をチェックする前に、CRLF をペアとしてチェックします。 ToolAcre は、順序付けされたパターン ` | | ` を使用してまさにそれを実行し、変換された出力を LF で結合します。
ブラウザのテキスト ボックスで何が起こるか - ペースト時に改行が一般的にどのように正規化されるか、またどこに文字が残っているか
HTML は、テキスト コントロール内の改行に対する特別な処理を定義します。 textarea 値では、ブラウザーは公開された値の CRLF および単独 CR を LF に正規化しますが、フォーム送信では改行にフォーム データ ルールを適用できます。したがって、ボックス内では正しく見える貼り付けでも、別のレイヤーによって異なる方法でシリアル化されたり、別の規則でソフトウェアにコピーされたりする可能性があります。
テキストが通常のテキスト領域をバイパスする場合、リテラル文字 `\r` などのエスケープされたバイトが表示される場合、またはパーサーが LF のみで分割して CR を各フィールドに付加したままにする場合、ストレイ CR が依然として表面化する可能性があります。ブラウザはパスの 1 段階であり、ファイル、クリップボード プロデューサ、API、コマンド ライン コンシューマに対する汎用修復サービスではありません。
ブラウザはテキストエリアの改行を正規化しますが、クリップボードとダウンストリームの形式は依然として異なります
空白行と末尾の改行には、異なる診断が必要です。 [空行の削除] は、ToolAcre が 3 つの行末スタイルをすべて認識した後、内容が空または空白の行を削除します。トリムラインは、すべての行から先頭と末尾の空白を削除します。 ToolAcre のスプリッターは実際の CR セパレーターを使用するため、通常はセパレーターを消去するためだけにトリミングは必要ありません。
スペース、タブ、またはリテラルの未使用文字が残っている場合にのみトリミングを使用し、変更する前に意味のあるインデントを検査します。テキストに表示可能な `^M` が含まれている場合は、ビューアが実際の CR をレンダリングしているのか、それともこれら 2 つの印刷可能な文字をレンダリングしているのかを判断します。一括置換すると意図したコンテンツが損傷する可能性がありますが、前後のカウントをチェックするとレビュー可能な結果が得られます。
空行を削除すると空行が修正されます。 ToolAcre が CR を正しく分割した後は、通常、トリミングは不要です
再現可能な例として、破損した中間表現で各名前の間に空の行が含まれる 3 つの名前 (`Ada`、空白、`Grace`、空白、`Linus`) から始めます。 Word and Character Counter は 5 行を報告します。これは意図的に入力が 2 倍になっています。本物の CRLF シーケンスだけでは 1 つの境界として認識され、ToolAcre に空の行は作成されません。
[空行の削除] を選択すると、出力は LF で結合された 3 行になります。カウンターは 3 つを報告するはずです。インポートされた値にもパディングが含まれる場合は、Trim Lines を個別に実行して結果を確認します。これらの操作を分離することで、すべてのクリーンアップを Windows テキストからのあいまいな変換に帰するのではなく、各アクションが修正された欠陥を証明します。
実用的な例: 意図的に倍増したエクスポートをクリーンアップし、行数を確認する
行末クリーンアップでは、1 つの論理文が列幅で意図的に分割されているハード ラップは修復されません。その資料からすべての改行を削除すると、実際の段落とリスト項目も結合されます。ブロック全体に線操作を適用する前に、境界がレコード、段落、または視覚的な折り返しを表すかを決定します。
文字エンコーディングも診断しません。 UTF-8 バイト オーダー マーク、置換ダイアモンド、mojibake、およびデコードの失敗は、CR または LF によって文字が行に分割されるかどうかではなく、バイトがどのように文字になるかに関係します。元のファイルを保存し、適切なファイル対応ツールを使用してそのエンコーディングを識別してから、奇妙な表示記号を行末として扱います。
重要な点 — 行末は目に見える歴史です。 Text Toolkit のライン ツールとカウンターを使用すると、数秒で症状を修正できます
CR、LF、および CRLF は、現在の互換性に影響を与える歴史的なコントロールです。最も安全なメンタル モデルは、複数の物理的表現を持つ 1 つの論理的な境界線です。レコードをカウントし、ソース規約を検査し、何かを削除する前に、空の行が導入されたステージや制御文字が保持されたステージを特定します。
貼り付けられたマテリアルの場合は、`/tools/text/` でテキスト ツールキットを開き、初期行数に注意し、空の行が本当に不要な場合にのみ空行の削除を適用し、周囲の空白に対してのみトリム ラインを使用します。その後、カウントとサンプルのレコードを再確認してください。この短い監査により、目に見えない書式設定の問題が、制御された元に戻せるテキスト変換に変わります。