テキスト診断

機能

• 不可視文字を位置付きで検出：ゼロ幅スペース・接合子、BOM、ソフトハイフン、方向上書き、ノーブレークスペース、全角スペースなど 30 種
• 紛らわしい文字（キリル・ギリシャのラテン同形字）を検出し、それが本当は何なのかと、どのラテン文字に似ているかを表示
• 紛らわしい文字を原文の中に、不可視文字と同じ `⟦…⟧` 記法で明示：`раypal` → `⟦U+0440 Cyrillic→p⟧⟦U+0430 Cyrillic→a⟧ypal`。3 文字目が実はキリル文字だと一目で分かります
• 文字体系ごとに文字数を集計 —— 混在していれば余分な字母がすぐ分かります
• NFC / NFD / NFKC / NFKD の 4 形式を個別に確認し、「NFC だが NFKC ではない」の意味も説明
• 改行コード（LF / CRLF / CR）を検出し、混在している場合は個別に警告 —— 奇妙な位置の構文エラーとして現れます
• 4 通りの文字数を並記：書記素クラスタ、符号位置、UTF-16 符号単位（JavaScript の length）、UTF-8 バイト
• 不可視文字と紛らわしい文字を ⟦U+200B⟧ / ⟦U+0430 Cyrillic→a⟧ のようなマーカーに置き換えたテキストも表示可能

使い方

1. テキストを貼り付けます
2. 「不可視文字」と「紛らわしい文字」のグループを確認します
3. 必要ならマーカー表示を有効にし、その結果を他所へコピーして調査します

よくある質問

絵文字の「長さ」が 4 通りあるのはなぜですか？

「長さ」の数え方が 4 通りあるからです。`👍` は人にとって 1 文字（書記素クラスタ）、Unicode では 1 符号位置、JavaScript の文字列では 2 符号単位（サロゲートペア）、UTF-8 では 4 バイトです。場面に合わない数え方をすると、典型的には「切り詰めで絵文字が真っ二つ」になります。`👨‍👩‍👧` はさらに極端で、1 文字・5 符号位置・8 符号単位です。

ゼロ幅スペースはどこから入ってくるのですか？

よくある 3 つの経路：Web ページからコピーすると禁則処理用のゼロ幅文字が付いてくる、iOS や macOS のソフトキーボードが特定の入力方式で挿入する、メッセージアプリが転送時に方向制御文字を付ける。表示は変わりませんが識別子の一部になってしまい、「同じに見える変数名」がコンパイルを通らなくなります。

「NFC だが NFKC ではない」とはどういう意味ですか？

NFKC はさらに互換分解を行い、全角英数字・合字（fi）・上付き文字（²）を通常の表記に畳み込みます。つまり正準等価でありながら全角文字を含むテキストがあり得ます —— そして全角の ａ は検索・比較・識別子としては半角の a と等価ではありません。データクリーニングには NFKC、アクセントの表記を揃えたいだけなら NFC で十分です。

改行コードの混在が構文エラーを起こすのはなぜですか？

多くのパーサーは改行を空白として扱いますが、一部のツール（古いシェルスクリプト、Makefile、特定のテンプレートエンジン）は CR を内容の一部として扱います。すると `\r\n` の余分な CR が文字列や変数名の末尾に入り込み、まったく筋の通らない位置でエラーが報告されます。Git の autocrlf 設定がマシンごとに違うのが、そうしたファイルの典型的な出所です。

全角文字や日本語の「ー」が紛らわしい文字として報告されないのはなぜですか？

判定を意図的に保守的にしているからです。疑わしいとみなすのは、形が似ている相手が別の文字体系に属する場合だけです。キリルの `а` はラテンの `a` に似ており（キリル ≠ ラテン）、ギリシャの `Ο` はラテンの `O` に似ています（ギリシャ ≠ ラテン）—— これらが本当の同形字攻撃です。一方、全角 `ａ` と半角 `a` はどちらもラテン文字で、幅の形式が違うだけ —— それは正規化の問題（NFKC が扱い、本ツールは「正規化形式」のグループで別に報告します）で、フィッシングの問題ではありません。日本語の「ー」も何らかの記号に似ているだけで、文字体系をまたぐ同形ではありません。報告が少し少なくても、中国語のテキストにある全角文字ごとに警告を出すより、本当に見るべきキリル文字を埋もれさせないほうがよいと考えています。代償として、本物のロシア語やギリシャ語の文章では字母も報告されますが、このツールの想定場面ではほとんどありません。