要約：手作業で何百行にも同じプレフィックスやサフィックスを追加するのは遅く、エラーが起きやすい——一括処理ツールなら一度で済むが、リテラルテキストが必要か正規表現パターンが必要かを知ることが、結果が実際に正しいかどうかを決める。このガイドはDuplicate Finder、Remove Extra Spaces、Text Difference、Character Counterと組み合わせて使ってください。
一括プレフィックス/サフィックスツールは、行のリストを受け取り、それぞれの先頭または末尾に固定テキストを追加する——これは、同じ既存テキストにのみ機能する検索置換や、スプレッドシートで一行ずつ行うのと同じ操作だ。
これが実際にどこで使われるか
一般的なケース：各行を引用符で囲み末尾にカンマを追加することで、単純な値のリストをSQLのIN (...)句に変換する。共有ディレクトリのプレフィックスを追加することでファイル名のリストを完全なパスに変換する。ドメインを先頭に追加することでスラグのリストからURLのリストを構築する。あるいは、列の各行にファイル拡張子や通貨記号のような共有サフィックスを追加することでCSVの値を準備する、などだ。
リテラルなプレフィックス/サフィックス対パターンベースの挿入
リテラルなプレフィックス/サフィックスツールは、すべての行にまったく同じテキストを追加する——追加内容が本当に変わらない場合に有用だ。追加内容が行の内容に応じて変わる必要がある瞬間（行にまだサフィックスがない場合にのみ追加する、あるいは行の中のパターンに応じて異なるテキストを追加する）、実際には正規表現ベースの検索置換が必要になる。リテラルな一括追加ツールには条件ロジックの概念がまったくないため、すでにサフィックスを持つ行にも喜んで重複したサフィックスを追加してしまうからだ。
結果を静かに壊すフォーマットの間違い
ソースリストの末尾のスペースが一貫していない場合——ある行はスペースで終わり、別の行はそうでない——一括サフィックス操作は値 ,サフィックスのような結果を生み出すことがある。追加されたテキストが値のすぐ後ろではなく、余分なスペースの後に追加されてしまうのだ。これは、SQLクエリやAPIキーのリストのように、厳密な文字列一致が重要な場所で結果が使われるまで、しばしば見えないままになる。プレフィックスやサフィックスを追加する前にRemove Extra Spacesを実行すれば、これを完全に回避できる。
驚きを避けるワークフロー
- まずソースリストから末尾/先頭のスペースをクリーンにする——一貫しないスペースは、"正しく見える"一括編集がわずかに誤った結果を生む最も一般的な原因だ。
- すべての行が本当に同一の追加を必要とするか、それとも一部の行はスキップするか別の方法で扱う必要があるかを決める——これがリテラルツールかパターンベースツールかを決定する。
- 一括操作を実行し、均一な成功を想定する代わりに、最初、最後、そして中間から任意の1行を抜き取ってチェックする。
- 結果がコードやクエリに入る場合は、最後の行の後に余分なカンマや区切り文字がないか確認する。これはリストから句への変換に残された一般的な off-by-one エラーだ。
避けるべきよくある間違い
- 先にスペースを取り除かないこと。これは、テキストエディタで見える兆候もないまま、サフィックスを間違った場所に挿入することがある。
- すでにサフィックスが付いている行があるリストに対して、リテラルな一括追加を使用すること。テキストが重複してしまう。
- リストをSQLやコードの句に変換した後、末尾の区切り文字を取り除き忘れること。
- "ほんの数行だから"と手作業で行い、始めてみたらリストに40件のエントリがあることが判明すること。
操作自体は些細なものだ——価値は、手動編集の60行目あたりに忍び込む疲労由来のタイプミスなしに、すべての行にわたって一貫してそれを行うことにある。