改行・空白・不可視文字を正規化する

改行コード・BOM・空白を正規化する

見た目が同じテキストでも、内部の文字や改行コードが違うと、 Gitの差分が大きくなったり、検索に一致しなかったりすることがあります。このツールは、まず入力を検出し、その後で必要な項目だけを選んで正規化します。

改行には主にLF、CRLF、CRがあります。現在の環境では意識することが少なくても、WindowsとmacOS/Linuxの間でファイルを受け渡したり、異なるエディタを使ったりすると混在することがあります。

特にGitでは、改行コードの違いによって本来は一部だけ変更したファイルが全行変更されたように見えることがあります。コードそのものを変更していないのに大量の差分が出た場合は、まず改行コードを確認すると原因を絞れます。

このツールでは混在している場合も検出結果に明示します。変換する場合は、LF、CRLF、CRのいずれかを選択してください。

Webページや文書からコピーした文字列には、画面上では見えない文字が混ざることがあります。ゼロ幅スペース（U+200B）やノーブレークスペース（U+00A0）は、その代表例です。

見た目は普通のスペースに見えても、プログラムから見ると別の文字なので、検索に一致しなかったり、文字列比較が失敗したりすることがあります。検出結果ではコードポイントと名前を表示するため、どの文字が混入しているか確認できます。

ゼロ幅接合子（U+200D）は常に削除してよい文字ではありません。絵文字の書記素クラスタを結合するためにも使われます。例えば家族を表す絵文字などでは、複数の絵文字の間にU+200Dが入っています。

そのため、このツールでは絵文字クラスタ内部で正常に使われている U+200Dを不可視文字として削除しません。一方、単独で使われている U+200Dは削除対象として扱います。

BOM（Byte Order Mark）は、ファイルの先頭に置かれる特殊な文字です。 UTF-8では必須ではありませんが、環境によっては文字コードの判定に利用されることがあります。

特にExcelでCSVを開く用途では、UTF-8のCSVを正しく認識させるために BOMが役立つ場合があります。一方、一般的なUTF-8のテキストファイルでは BOMを付けない運用も一般的です。

ブラウザのtextareaに貼り付けた文字列では、入力時に先頭BOMが失われる場合があります。このため、このツールでは検出できた先頭BOMを表示し、出力にBOMを付ける場合はダウンロード時に付与します。

BOMは文字としてコピーできないため、BOMを付ける場合はファイルとしてダウンロードしてください。

Gitではリポジトリ内の改行コードを一定にする方法として、 .gitattributes を利用できます。例えばテキストファイルをLFとして管理する方針を明示すれば、開発者の環境による差を小さくできます。

ただし、既存リポジトリで改行設定を変更すると、大量の差分が発生することがあります。変更する場合は、設定だけを変更するコミットと、実際の改行変換を行うコミットを分けると、レビューしやすくなります。

よく使う設定には「Git向け」「Windows向け」「文章向け」「すべて正規化」のプリセットがあります。プリセットを選んだ後に個別の設定を変更することもできます。

可視化をオンにすると、スペースやタブ、不可視文字を印で確認できます。表示上の印は元の文字列そのものを書き換えたものではありません。コピーされるのは元の入力文字列です。

正規化後も問題が残る場合は、まず検出結果を確認してください。特に改行コードの混在、U+00A0、U+200Bなどは見た目だけでは判別しにくいため、検出結果と可視化を併用すると原因を特定しやすくなります。

入力は10万文字までです。大量のテキストを扱う場合は、ファイル全体ではなく問題が発生している範囲を分けて確認すると扱いやすくなります。