契約書の修正箇所を見つける
ベンダー契約のV1を左に、修正済みのV2を右に貼り付けます。補償、支払、解約の条項のうち、こっそり変更された部分がすぐに浮かび上がります。相手側が変更履歴オフのクリーンコピーを送ってきた場合に役立ちます。
入力
出力
テキスト比較とは？
テキスト比較は、2つのテキストを受け取り、その間で何が変わったかを正確に表示するオンラインツールです。古いバージョンを片側に、新しいバージョンをもう片側に貼り付けると、違いが色で強調されます。緑が追加、赤が削除です。
プレーンテキストならなんでも対応します。文章、コードスニペット、設定ファイル、契約書の条項、翻訳など。一致する行はそのまま表示されるので、変わった箇所にすぐ目が行きます。
デスクトップツールを開きたくないけれどワンクリックで正確な結果が欲しい場面に最適です。登録もアップロードも、比較内容の記録もありません。
できること
Compare Textは2つのテキストを受け取り、追加された部分を緑、削除された部分を赤でハイライトします。文字単位で処理するため、コンマ1つの欠落や変数名の変更も明確に表示されます。エンジンはGoogleのdiff-match-patchライブラリ(Apache 2.0)です。この一般的な技術はdiffと呼ばれ、その背後にある問題(2つの文字列間の最小編集セットを求めること)は、古典的な最長共通部分列問題に帰着します。
このエンジンは自然言語とコードの両方を同等にうまく扱います。ドキュメントエディタの変更履歴を支えているのと同じ種類のアプローチです。散文ではなく構造化データを比較するなら、JSON diffツールを使ってください。両側を先にパースしてキー順序を無視します。問題が違えば、ツールも違います。
サーバーは介在しません。JavaScriptがFileReader APIでテキストを読み取り、比較し、結果をページに描画します。タブを閉じれば消えます。
2つのテキストを比較する手順
3ステップです。入力中に差分が自動更新されるので「比較」ボタンはありません。
- 1
元のテキストを入れる
左側のパネルに貼り付けるか、アップロードで.txtや.mdファイルを開きます。サンプルを押すと短い例が読み込まれます。
- 2
更新版を入れる
右側に貼り付けるかアップロードします。両方のパネルにテキストが入ると、左側の削除部分は赤、右側の追加部分は緑で表示されます。
- 3
変更を確認
どちらかをスクロールすると両方が同期します。ヘッダーには検出された変更数が表示されます。コピーやダウンロードでテキストを保存できます。
こんな場面で便利
原稿と校正の確認
自分の原稿と編集者の修正版を比較したり、ブログ記事を校正前後で並べたりできます。変わった単語がすべて表示されるので、抜け落ちた一文を探すために全文を読み直す必要はありません。
翻訳パスのレビュー
原文を片側に、翻訳者の修正をもう片側に置きます。どの慣用表現が書き直され、レビュアーが直訳をどこで押し戻したかが分かります。レビュアーを信頼している場合、文書全体を二度読みしなくて済みます。
設定ファイルの差分を取る
nginx.conf、systemdのユニットファイル、.envテンプレート。2つのバージョンを左右に並べて数秒で確認。両方のファイルがすでにチャットからクリップボードにある場合、ターミナルでdiffを起動するより速いです。
ログファイルのスナップショット比較
昨日のデプロイログと今日のログ、あるいは2回のCI実行での同じジョブの出力。安定した行は背景に沈み、新しいエラーパターンが浮かび上がります。数MBのログでは、まずgrepで関連箇所に絞り込んでください。
テキストdiffのクイックリファレンス
このツールが最もよく表面化させるエッジケースと、その理由。
| トピック | このツールができること |
|---|---|
| 改行コード | LF、CRLF、CRはそれぞれ別の文字です。Windowsファイル(CRLF)をUnixファイル(LF)と比較すると、すべての行が異なって見えます。両方のソースをLFに揃えるか、比較前にキャリッジリターンを取り除いてください。 |
| 行末の空白 | 実際の差分として表示され、ハイライトが可視文字の先まで伸びます。YAMLやCSVでパーサーを密かに壊す末尾スペースの検出に役立ちます。 |
| Unicode正規化 | 合成済みのé(U+00E9)を含むcaféは1文字ですが、分解形のe + 結合用アクセント(U+0301)は2文字です。表示は同じでもdiffでは別物として扱われます。Unicode正規化形式CをString.prototype.normalize()で適用すれば一致します。 |
| マッチの粒度 | 内部的には文字レベルで、可能な場合は単語境界で変更をまとめる意味的クリーンアップ処理が入ります。だから関連のないテキスト間でも、短い共通単語がマッチして見えることがあります。 |
| ファイルエンコーディング | アップロードされたファイルはFileReader APIによってUTF-8として読み込まれます。他のエンコーディングは文字化けします。事前に変換するか、すでにファイルをデコード済みのツールから貼り付けてください。 |
| 大きな入力 | 数百KBまでは1秒未満です。1〜2MBは目に見えて遅くなります。5MBを超えると、ボトルネックはdiffアルゴリズムではなく描画です。貼り付ける前に絞り込んでください。 |
| 片側が空 | 片方のペインが空の場合、もう一方は丸ごと追加(または削除)として表示されます。これはdiffの正しい挙動で、バグではありません。 |
| 同一の入力 | 両側が完全に一致する場合(空白、改行コード、Unicode正規化形式を含めて)、変更はゼロで、ヘッダーには件数が表示されません。 |
よくある質問
入力したテキストは保存されますか?
いいえ。比較処理はすべてブラウザ内で行われます。サーバーへの送信、ログ記録、保存は一切ありません。DevToolsを開いてNetworkタブを見れば分かりますが、比較時に外部への通信はありません。タブを閉じればテキストは消えます。
これとJSONのdiffの違いは何ですか?
テキストdiffは文字を順序通りに比較するため、JSONのキーの並び替えや空白の整形は、データが同じでも差分として表示されます。JSONを比較するなら、Compare JSONツールを使ってください。両側を先にパースし、順序を考慮します。散文、設定ファイル、プレーンなコード、構造化データ以外なら、テキストdiffが適しています。
WindowsとUnixの改行コード(CRLFとLF)は扱えますか?
そのまま比較するため、Windowsファイル(CRLF)とUnixファイル(LF)を貼り付けると、内容が一致していても全行が違うように見えます。これはdiffが正しく動作している結果で、実際に入力が異なっています。直すには、両方のソースで改行コードを揃えるか、貼り付ける前にキャリッジリターンを除去してください。
サイズの上限はありますか?
実用上の上限はデバイスのメモリ次第です。数百KBまでのテキストは1秒未満で比較できます。1MBを超えると、ハイライトの描画コストが増えるため、ブラウザが重く感じ始めます。巨大なログファイルや書籍まるごとの原稿は、まず必要な箇所に絞り込んでください。
なぜdiffが断片的に見えることがあるのですか?
文字レベルのdiffは、できる場所で短い共通部分文字列(冠詞、a、単独の文字、句読点)を整列させます。意味的なクリーンアップ処理で可能な限り単語単位のまとまりにグループ化しますが、関連のない2つの段落では結果はやはり断片的になります。アルゴリズムには、2つのテキストが比較を意図したものかどうかを判断する手段がありません。
異なるエンコーディングのファイルを比較できますか?
アップロードボタンから読み込んだファイルはUTF-8として読み込まれます(FileReaderのデフォルト)。Latin-1、Shift-JIS、Windows-1252など他のエンコーディングのファイルは文字化けして見えます。先にUTF-8に変換してください。すでにクリップボードにあるテキストは、貼り付ける前にOSがエンコーディングを解決しているので、たいていそのまま動きます。