ダブルクリックで英日反転
Applied Sciences · Engineering
Line Endings: LF, CR, and CRLF
Every text file contains invisible control characters that mark line breaks. Three standards exist — LF (Unix), CR (old Mac), and CRLF (Windows) — and mixing them causes real problems in team development.
The three line-ending types
- LF (0x0A, \n) — Unix / Linux / modern macOS
- CR (0x0D, \r) — Classic Mac OS 9 and earlier
- CRLF (0x0D 0x0A, \r\n) — Windows
- Names come from typewriter mechanics: CR returns print head; LF advances paper
Why mixing them causes problems
- Git shows massive diffs even when content is identical — every line appears changed
- Shell scripts gain a stray \r on Windows, causing syntax errors when run on a server
- A CRLF file opened in an LF-only app may render as one long line
Git's autocrlf warning
- Warning 'LF will be replaced by CRLF' fires when core.autocrlf = true
- true: converts CRLF→LF on commit, LF→CRLF on checkout (Windows default)
- input: converts CRLF→LF on commit only (Linux/Mac recommended)
- The warning is harmless, but can produce unintended diffs across the team
Best practice: .gitattributes
- Place a .gitattributes file at the repo root to fix line endings per repository
- Use: * text=auto eol=lf to standardise everything to LF
- Overrides each developer's personal core.autocrlf setting
- Windows editors still display as CRLF internally, so practical impact is minimal
→ Commit a .gitattributes with eol=lf to end line-ending chaos across OS boundaries.
応用科学 · エンジニアリング
改行コード LF・CR・CRLF の違いと Git 警告の意味
テキストファイルには「行の終わり」を示す不可視の制御文字が存在する。LF（Unix系）・CR（旧Mac）・CRLF（Windows）の3種が混在すると、チーム開発でさまざまな不具合を引き起こす。
3種の改行コード
- LF（0x0A、\n）— Unix / Linux / 現代の macOS
- CR（0x0D、\r）— Classic Mac OS（OS 9以前）
- CRLF（0x0D 0x0A、\r\n）— Windows
- 名前はタイプライターの動作に由来：CR＝キャリッジ戻し、LF＝紙送り
混在すると起きる問題
- 内容が同一でも Git の差分（diff）が全行変更扱いになる
- Windows で編集したシェルスクリプトに \r が残り、サーバーで構文エラーになる
- LF 前提のアプリで CRLF ファイルを開くと改行が認識されず1行に見える
Git の警告「LF will be replaced by CRLF」
- core.autocrlf（自動改行変換設定）が true の時に表示される
- true: コミット時に CRLF→LF、チェックアウト時に LF→CRLF へ変換（Windows推奨）
- input: コミット時のみ CRLF→LF 変換（Linux/Mac推奨）
- 警告自体は無害だが、意図しない差分を生む可能性があるため統一が望ましい
推奨：.gitattributes で明示的に統一
- .gitattributes をリポジトリルートに置き、改行コードをリポジトリ単位で固定
- 設定例：* text=auto eol=lf（テキストファイルをすべて LF に統一）
- 開発者個人の core.autocrlf 設定を上書きできる
- Windows エディタは内部表示を CRLF のままにできるので実害はほぼない
→ .gitattributes に eol=lf を1行追加するだけで、OS混在チームの改行コード問題を根絶できる。
Applied Sciences · Engineering
Line Endings: LF, CR, and CRLF
Every text file contains invisible control characters that mark line breaks. Three standards exist — LF (Unix), CR (old Mac), and CRLF (Windows) — and mixing them causes real problems in team development.
The three line-ending types
- LF (0x0A, \n) — Unix / Linux / modern macOS
- CR (0x0D, \r) — Classic Mac OS 9 and earlier
- CRLF (0x0D 0x0A, \r\n) — Windows
- Names come from typewriter mechanics: CR returns print head; LF advances paper
Why mixing them causes problems
- Git shows massive diffs even when content is identical — every line appears changed
- Shell scripts gain a stray \r on Windows, causing syntax errors when run on a server
- A CRLF file opened in an LF-only app may render as one long line
Git's autocrlf warning
- Warning 'LF will be replaced by CRLF' fires when core.autocrlf = true
- true: converts CRLF→LF on commit, LF→CRLF on checkout (Windows default)
- input: converts CRLF→LF on commit only (Linux/Mac recommended)
- The warning is harmless, but can produce unintended diffs across the team
Best practice: .gitattributes
- Place a .gitattributes file at the repo root to fix line endings per repository
- Use: * text=auto eol=lf to standardise everything to LF
- Overrides each developer's personal core.autocrlf setting
- Windows editors still display as CRLF internally, so practical impact is minimal
→ Commit a .gitattributes with eol=lf to end line-ending chaos across OS boundaries.
応用科学 · エンジニアリング
改行コード LF・CR・CRLF の違いと Git 警告の意味
テキストファイルには「行の終わり」を示す不可視の制御文字が存在する。LF（Unix系）・CR（旧Mac）・CRLF（Windows）の3種が混在すると、チーム開発でさまざまな不具合を引き起こす。
3種の改行コード
- LF（0x0A、\n）— Unix / Linux / 現代の macOS
- CR（0x0D、\r）— Classic Mac OS（OS 9以前）
- CRLF（0x0D 0x0A、\r\n）— Windows
- 名前はタイプライターの動作に由来：CR＝キャリッジ戻し、LF＝紙送り
混在すると起きる問題
- 内容が同一でも Git の差分（diff）が全行変更扱いになる
- Windows で編集したシェルスクリプトに \r が残り、サーバーで構文エラーになる
- LF 前提のアプリで CRLF ファイルを開くと改行が認識されず1行に見える
Git の警告「LF will be replaced by CRLF」
- core.autocrlf（自動改行変換設定）が true の時に表示される
- true: コミット時に CRLF→LF、チェックアウト時に LF→CRLF へ変換（Windows推奨）
- input: コミット時のみ CRLF→LF 変換（Linux/Mac推奨）
- 警告自体は無害だが、意図しない差分を生む可能性があるため統一が望ましい
推奨：.gitattributes で明示的に統一
- .gitattributes をリポジトリルートに置き、改行コードをリポジトリ単位で固定
- 設定例：* text=auto eol=lf（テキストファイルをすべて LF に統一）
- 開発者個人の core.autocrlf 設定を上書きできる
- Windows エディタは内部表示を CRLF のままにできるので実害はほぼない
→ .gitattributes に eol=lf を1行追加するだけで、OS混在チームの改行コード問題を根絶できる。
Related notes
- Agentic Commerce — ACP and Visibility into Being 'Bought by AI'
- AI Search Evaluation: The 12 Metrics — Gateway
- AI Search Evaluation ①Citation Rate — How Many URLs Are Pulled In Per Answer
- AI Search Evaluation ②Source Diversity — How Unskewed the Cited Sources Are
- AI Search Evaluation ③Accuracy Score — How Often It Answers Factual Questions Correctly
- AI Search Evaluation ④Answer Length — How Many Characters It Returns to the User on Average