左側のパネルにテキストを貼り付けてください。結果パネル上部のフラグが問題の種類数を示し、クリックすると最初の出現位置へ移動します。下部の文字ごとの表示では、疑わしいコードポイントがクリック可能なマーカーとして表示され、選択するとその正体と対処法が表示されます。

幅をまったく持たない書式制御文字で、本来は改行位置を示すためのものです。人間には存在しないように見えますが、プログラムにとっては文字列内のもう 1 つのコードポイントです。そのため、途中にゼロ幅スペースが入ったメールアドレスや API キーは画面上は正しく見えても、保存された値と一致することはありません。

実際によく現れるのは 5 つです。U+200B ゼロ幅スペースとその仲間、Web ページのコピーで混入する U+00A0 ノーブレークスペース、ファイル先頭の U+FEFF BOM、東アジアの入力メソッドが生む U+3000 全角スペース、そしてラテン文字を模したキリル文字やギリシャ文字です。本ツールはこれらに加えて、C0 / C1 制御文字や thin space などの組版用スペースも検出します。

通常のスペースはスペースキーで入力される U+0020 です。ノーブレークスペースは U+00A0 で、見た目は同じですがそこで改行しないよう指示するもので、Web ページからのコピーで混入しがちです。全角スペースは U+3000 で、明らかに幅が広く、東アジアの入力メソッドが生成します。3 つとも空白として描画されますが、ASCII スペースのパターンに一致するのは U+0020 だけなので、残りの 2 つは trim・split・列の解析を静かに壊します。

原因は独立した 2 つです。1 つは片方に不可視文字が紛れ込んでいること（ゼロ幅スペース、ノーブレークスペース、BOM など）。もう 1 つは Unicode 正規化です。文字 é は単一のコードポイント（NFC）でも、e と結合アクセント（NFD）の組み合わせでも表せます。見た目は同じでも並びが異なるため、バイト単位の比較は一致しません。macOS のファイル名や一部の入力メソッドは NFD を生成するため、システム間を移動する際に静かに形式が変わることがあります。本ツールは両方を検出します。

問題を起こすことが分かっている文字（ゼロ幅・双方向の書式制御文字、BOM、非 ASCII のスペース、C0 / C1 制御文字、キリル文字やギリシャ文字の同形異字）に加えて、文字列全体の改行混在と NFC 以外の正規化を検査します。入力を書き換えることはなく、内容を送信することもありません。完全な Unicode リンターでもないため、この選定範囲外の稀な問題や特定の文字体系固有の問題は検出されません。「クリーン済みテキストをコピー」は補助機能であり、主たる結果は診断そのものです。