改行 & BOM コンバーター
正規化前に CRLF、単独 CR、単独 LF を別々にカウントするため、規約が混在しているファイル(汚れた git diff や Windows で失敗する Bash スクリプトのよくある原因)を発見できる。出力バイト数は BOM を含めて報告されるため、ディスクに正確に何が書き込まれるかが分かる。すべての処理はブラウザでローカル。
—
ターゲット改行コード
UTF-8 BOM
出力
入力統計
- LF の数1
- CRLF の数1
- 単独 CR の数0
- 総行数3
- 出力バイト数(UTF-8)28
- BOM ありいいえ
改行が混在したファイルは、通常複数のプラットフォームで編集された結果 — 正規化すれば「なぜ diff が爆発するのか」問題の大半が解決する。
使い方
- 入力欄にテキストを貼り付けるか、ファイルの内容をドラッグ。
- ターゲット改行コードを選択(LF:Unix/macOS、CRLF:Windows、CR:レガシー Mac)。
- BOM ポリシーを選んで出力をコピー。
よくある質問
- BOM はいつ保持すべき?
- 一部の古い Windows ツールと一部の Excel CSV インポートが BOM に依存している。それ以外(特にシェルスクリプト、JSON、現代のビルドチェーンのソースコード)は削除。
- 改行が混在したファイルとは?
- LF/CRLF/CR のうち複数が含まれるファイル。プラットフォームをまたいでテキストが編集されたり、ジェネレーターが異なるソースからのフラグメントを連結したときによく発生する。単一スタイルへの正規化で git diff やダウンストリームのパーサーが正常に動作する。
- gitがファイル全体を変更として表示するのはなぜ?
- すべての行が変わっているからです。ある改行方式でコミットされたファイルを別の方式で保存すると、変わっていない行がひとつも残らず、差分が拠り所を失います。一度そろえてその状態をコミットし、次のチェックアウトで変換が再び適用されないよう、リポジトリの改行方針を決めておいてください。
- 最終行の末尾にも改行は必要ですか?
- 多くのUnix系のツールにとっては必要です。行は改行で終わるものと見なされるので、差分が「ファイル末尾に改行がありません」と告げますし、そうしたファイルを二つ連結すると、前のファイルの最終行と次のファイルの一行目がくっついてしまいます。どの改行方式を使うかとは別の話です。
関連ツール
ファイル文字コード判定ツール
任意のテキストファイルをアップロードして文字コードを判定 — UTF-8·UTF-16 LE/BE·UTF-32·Latin-1·ASCII — BOM判定·バイト信号分析·16進プレビュー付き。
ファイル 0 0
テキストエンコーディング変換
Shift_JIS・EUC-JP・Windows-1252 など非 UTF-8 のテキストを UTF-8 で読める形に。
ファイル 0 0
CSV ↔ JSON 変換ツール
CSV を JSON に、JSON を CSV に変換(区切り文字を選択可)。
ファイル 0 0
Excel(XLSX)→CSV・JSON・Markdown 変換
ブラウザで .xlsx を開き、任意のシートを CSV・JSON・Markdown 表として書き出します。ファイルは端末から出ません。
ファイル 0 0
CSV → Excel(XLSX)変換
CSV・TSV をブラウザ内で本物の .xlsx に変換します。先頭のゼロ、長い ID、SEPT1 のようなコードも入力どおりに保たれます。
ファイル 0 0
画像 → PDF 変換
複数の JPG / PNG 画像を 1 つの PDF に結合 — ページサイズ・向き・フィット調整可能。
ファイル 0 0