テキストファイル移植性チェック

プレーンテキストを貼り付けるか読み込み、Git、diffツール、CI、Windowsメモ帳、旧Unixツールで動作が変わる文字コード、改行、空白の癖を確認します。エディターでは普通に見える問題も対象です。

解析する内容を貼り付けてください

ブラウザー内でローカルに処理します。ファイルがアップロードされることはありません。

使い方ツール

テキストを貼り付けるか.txt/.csv/.log/プレーンテキストを読み込みます。ブラウザーがローカルで読み込み、アップロードしません。
「互換性を確認」を選びます。
指摘ごとに移植性問題となる理由と影響するツールを確認します。
安全な一括書き換えがあれば使います。改行正規化、先頭BOM除去、末尾空白削除、末尾改行追加、見た目が似た空白文字の修正をまとめて行います。

前提条件

入力はブラウザーがファイルの`.text()`または貼り付けからすでにデコードしたJavaScript文字列です。元の生バイトでなく、そのテキストを検査するため元ファイルのバイト単位文字コードは直接検出できません。
8問題を検出します：CRLF/LF混在、LFを伴わないCR、先頭BOM、Unicode置換文字、末尾空白、末尾改行欠落、タブ/空白の字下げ混在、見た目が似たUnicode空白。ほかの文字コード問題は対象外です。
Unicode置換文字U+FFFDは解析前にデコード失敗が起きた証拠です。テキストから元バイトを復元できず、この問題の書き換えは提案しません。

出典と参考データ

方法論

行へ分割する際、各行の元終端（CRLF、LF、CRのみ、終端なし）を保持します。これにより混在を情報を捨てずに検出します。その後、行・文字単位の8つの対象検査を行います。改行正規化、BOM除去、末尾空白削除、末尾改行追加、見た目が似た空白の置換/削除のみ機械的に安全なため一括書き換えを提案します。置換文字はデータがすでに失われ、混在字下げは意図するタブ幅が不明なため指摘のみです。

計算例

WindowsとUnixで編集しCRLF/LFが混在

入力項目: line one\r\nline two\n

結果: Gitなど行単位diffは終端も比較するため、内容が1行だけ変わっても全行が変更表示される場合があります。エラーとして指摘しすべてLFへ正規化します。

shebangの前にUTF-8 BOM

入力項目: \uFEFF#!/bin/sh\necho "Hello"

結果: `#!/bin/sh`前のBOMにより、多くのUnixシェルがshebangとして認識できません。警告し先頭BOMを安全に削除します。

通常空白の代わりにコピーされた改行なし空白（U+00A0）

入力項目: const total = price + tax;

結果: 多くのエディターでは通常空白に見えますが、完全一致や解析では別文字です。警告し通常のASCII空白へ置換します。

実用的なアドバイス

エディター設定、Gitの`core.autocrlf`、または`.gitattributes`でリポジトリ内の改行規則を統一します。
Unicode置換文字は書式の問題でなくデータ損失です。破損テキストを直そうとせず、正しい文字コードで元ファイルを再出力・再読込してください。
ワープロ、PDF、Webから貼り付けたテキストではエディターの空白可視化を有効にします。NBSPやゼロ幅空白の一般的な発生源です。
プロジェクト規約に従って空白のみ、またはタブのみの字下げにし、フォーマッターで統一します。

よくある間違い

エディター上で問題なく見えるから改行や空白に問題はないと思うこと。多くのエディターはCRLF/LFを正規化し末尾空白を隠すため、GitやCIなどとの不一致に気づきにくくなります。
置換文字による破損後に元ソースへ戻らず手で打ち直すこと。デコード済みテキストから置換された元バイトは復元できません。

よくある質問

混在改行とCRのみはエラーで、末尾空白は情報扱いなのはなぜ？

混在またはCRのみの改行はGit、diff、多くのパーサーなど行単位ツールに構造を誤認させる機能上の問題です。末尾空白は読めるテキスト上は目に見えず、フォーマッターやリンターの不一致で雑音になる程度なので情報扱いです。

タブ/空白混在字下げを自動修正しないのはなぜ？

正しい変換にはタブ幅が2、4、8列などどれか知る必要があります。テキストだけから推定できず、間違えると構造の見た目を黙って変更するため、正確な行を示します。

元ファイルの保存文字コードを検出できますか？

できません。ツールがテキストを受け取る前にブラウザーが推定または指定文字コードでバイトをJavaScript文字列へデコード済みです。残ったU+FFFDでデコード失敗の可能性を検出できますが、生バイトは検査できません。

CRLF/LF混在はなぜdiffを乱し、何を検出しますか？

行単位ツールはテキストが同じでも終端バイトの違いを変更と扱い、小さな編集をファイル全体の変更に見せる場合があります。このチェックはCRLF/LF混在、CRのみ、先頭BOM、末尾空白、末尾改行欠落などを検出します。ブラウザーがデコードしたテキストを解析し、生バイトやすべてのテキスト問題は検査しません。

最終確認日： 2026-09-26

バイト単位文字コード検出器ではなく、行・文字を対象にした限定スキャナーです。ブラウザーがデコード済みのテキストを使うため元文字コードを特定できず、デコード時に失われたデータも復元しません。8問題のみを検出し、サロゲートペア、結合文字正規化、右から左の制御文字などは対象外です。

このツール上記の前提条件に基づく参考値を提示します。

テーマとツールの設定、保存済みリストと最近使用したリストは、このブラウザー内にのみ保存されます。