テキスト

CRLF ↔ LF Converter

Windows(CRLF)、Unix/macOS(LF)、クラシックMac(CR)の間で改行コードを変換。混在した改行の検出にも対応。

変換先

ブラウザはフィールドに貼り付けられたテキストを自動的にLFに正規化するため、元のCRLF/CRをここで検出することはできません — 実際のCRLF/CRを含むファイルを解析・変換するには、上のファイルアップロードを使用してください。


                    

Windows, Unix/macOS, and the old classic Mac historically use different characters to mark the end of a line — CRLF, LF, and CR respectively. Mixing these styles in one file often causes odd artifacts in diffs or editors. This tool converts line endings to one style and detects mixed ones.

How to use it

Common uses

Things to keep in mind

Git can automate this conversion itself through core.autocrlf or .gitattributes — often more convenient than converting files in a repository by hand.

Mixed line endings in one file aren't always visible at a glance, but they can break parsers or scripts that expect one specific style.

このツールに関する記事: CRLFとLF:改行コードが今も問題を引き起こす理由

よくある質問

なぜ改行はシステムによって異なるのですか?

WindowsはCRLF(\r\n)を使用し、UnixとmacOSはLF(\n)のみを使用し、クラシックMacはCR(\r)のみを使用していました — これらの異なる歴史的慣習が、ファイルがシステム間を移動する際に不整合を引き起こします。

なぜテキストを貼り付ける代わりにファイルをアップロードする必要があるのですか?

ブラウザは入力フィールドに貼り付けられたテキストを自動的にLFに正規化するため、実際の元のCRLFやCR文字は貼り付けた時点で検出不能になります — 分析や変換のために実際の改行を保持するのは直接のファイルアップロードだけです。

この種の問題は実際にいつ重要になりますか?

特に重要なのは、git(改行によるノイズの多い差分)、残ったCRLFで失敗するシェルスクリプト、WindowsとUnix/macOSシステム間でやり取りされるファイルです。アップロードされたファイルはブラウザ内でのみローカルに処理され、サーバーに送信されることはありません。

ファイル内にCRLFとLFが混在している場合はどうすればいいですか?

複数のエディタや異なるOSで編集されたファイルには、両方のスタイルが同時に含まれていることがあります。変換は目に見えて「怪しい」行だけでなく、ファイル全体に適用する必要があります — そうしないと、問題のある改行の一部が気づかれないまま残ってしまいます。

gitで変換を自動化できますか?

はい、gitの<code>core.autocrlf</code>設定はcheckoutとcommit時に改行を自動的に変換し、<code>.gitattributes</code>を使えばリポジトリ内の特定のファイル種別に対して改行スタイルを明示的に指定できます。

記事: テキスト

camelCase、snake_case、kebab-case:どの場面でどれを使うか

なぜcamelCase、snake_case、kebab-caseが存在し、それぞれ普通どこで使われるか。

Text Diff:テキストの差分検出アルゴリズムの仕組み

diffアルゴリズムがテキストの2つのバージョン間の最小変更セットをどう見つけるか。

正規表現:基本と貪欲マッチの罠

正規表現における貪欲マッチと非貪欲マッチの違いと、それが実務でなぜ重要か。

行のソート:アルファベット順と数値順はなぜ違うのか

アルファベット順ソートが数値をテキストとして扱う理由と、数値ソートとの違い。

文字列エスケープ:JS、JSON、シェル、正規表現でルールが異なる理由

あらゆる場面で通用する単一のエスケープルールが存在しない理由 — JS、JSON、シェル、正規表現それぞれに固有のルールがある。

文字数と単語数のカウント:Unicodeがなぜこれを複雑にするか

Unicodeにおいて視覚的に1つの絵文字が複数のコードポイントから成り立つことがある理由。

Lorem Ipsum:このダミーテキストはどこから来て、なぜ意味がないのか

Lorem Ipsumテキストが実際どこから来たのか、そして実際のテキストの代わりに無意味なテキストが使われる理由。

Slugify:タイトルが有効なURLに変換される仕組み

記事タイトルがハイフンで区切られたクリーンで読みやすいURLに変換される仕組み。

Markdown:ドキュメント作成の標準になった理由

HTMLとは違い、Markdownが生のままでも読みやすい理由。

見えない空白文字:見た目が同じテキストの比較がなぜ失敗するのか

見えない空白文字1つが、見た目上同じ2つのテキストの比較を失敗させる仕組み。

テキストの反転:絵文字でなぜ壊れるのか

単純なテキスト反転が、複数のコードポイントから成る絵文字をなぜ壊してしまうのか。

テキスト頻度分析:ワードクラウドから暗号解読まで

文字頻度分析が歴史的にどう単純な換字式暗号の解読に役立ったか。