"ファイルの互換性"と聞くと、何を浮かべますでしょうか。
あるアプリケーションで作成したファイルを別のアプリケーションでも利用できたり、ファイルの拡張子や文字コードを思い浮かべたりするかと思います。
そして、記事のタイトルにある"改行コード"もまた、互換性の概念に含まれる大事な要素です。わたしは先日まで改行コードの存在を知りませんでした。
今回の記事は改行コードについて調べた内容をまとめたものです。
改行コードについて調べてみた
■はじめに
改行コードとは各行の終端にある"CRLF"・"LF"や"\r\n"、"⏎""↓"で記される特殊な文字のことです。
OS別でみると、WindowsではCRLF(Carriage Return + Line Feed)、UNIX系ではLF(Line Feed)が改行コードとして採用されております。たかが改行なのですが、CRLFとLFが違うだけでアプリケーションエラーにつながり、かつ文字コードと違ってぱっと見ではわからないため厄介な仕様です。
改行コードが行の終わりを検出するため、データ処理系ツールでは致命的なエラーを引き起こします。
■改行コードの基礎
改行コードはCRLF,LF,CRの3種類があり、そのうちのCRLFとLFについて詳しく見ていきます。
●CRLF (Windows)
- CRLFは、"Carriage Return"（キャリッジリターン、\r、ASCIIコードで13）と"Line Feed"（ラインフィード、\n、ASCIIコードで10）の組み合わせです。
- Windowsオペレーティングシステムでは、テキストファイルの各行はCRLF（\r\n）で終了します。
- キャリッジリターン（CR）は、タイプライターのキャリッジ（紙を挟む部分）を行の始まりに戻す動作を意味し、ラインフィード（LF）は紙を一行分上に送る動作を意味します。古いタイプライターの操作に由来するこれらの用語は、テキスト表示においても行を新しい行に移動するために使われています。
●LF (Unix/Linux/macOS)
- LFは、"Line Feed"（ラインフィード、\n）のみを指します。
- Unix系のオペレーティングシステム（LinuxやmacOSを含む）では、テキストファイルの各行は単にLF（\n）で終了します。
- Unix系システムでは、改行と行の先頭へのキャリッジリターンは通常、一つのステップとしてLFで処理されます。これは、Unix系システムの設計哲学の一部であり、シンプルさと効率性を重視しています。
■異なる環境間での改行コードの扱い
WindowsやUNIX系、MacOSなどの異なる環境間での改行コードの違いによる問題がいくつかあります。
●1. 互換性
異なるオペレーティングシステム間でテキストファイルを交換する際、改行コードの違いが互換性の問題を引き起こす可能性があります。
例えば、Windowsで作成されたファイルをUnix系システムで開くと、行が正しく区切られずに表示されることがあります。これは、システムが改行を正しく認識できないためです。
●2. プログラミングとデータ処理
プログラミング言語やデータ処理ツールは、ファイルを読み書きする際に改行コードを使用して行の終わりを検出します。
改行コードが期待通りでない場合、プログラムやスクリプトが正しく動作しない原因となり得ます。特に、テキストファイルを解析するプログラムや、CSVファイルなどのデータファイルを扱う場合に顕著です。
●3. バージョン管理
ソースコード管理ツール（Gitなど）は、改行コードの違いを変更と見なすことがあります。これにより、実際にはコードに変更がなくても、改行コードの違いだけで差分が発生し、バージョン管理の履歴が乱れる可能性があります。
ここまで改行コードの違いによる問題を3つ紹介しましたが、この中でも「3. バージョン管理」にあるGitが曲者です。
なぜかというと、バージョン管理システム（特にGit）には、改行コードの自動変換機能が備わっているためです。かなりありがたい機能で、「1. 互換性」の問題を自動で解決してくれます。
改行コードの自動変換機能とはどんな機能かというと、 Gitには、core.autocrlf という設定があります。
core.autocrlf がTrueの場合、Windows上でファイルをチェックアウトする際にLFをCRLFに自動変換し、コミットする際にはCRLFをLFに自動変換します。これにより、WindowsユーザーがLinuxやmacOSユーザーとコードを共有する際に改行コードの違いによる問題を防ぎます。
Windowsでgitを操作している場合、おそらくデフォルトでTrueになっているかと思います。
git config --get core.autocrlf
この設定でpushすると、LFに自動変換されます。ためしにWindows上で作成した改行コードCRLFのファイルをGithubにpushし、Githubからテキストファイルをダウンロードしてみたところ、
↓
↓
LFに自動変換されていますね。
■解決策
改行コードは意識しないと気付きにくいので、2つ解決策を考えてみました。
●1. 改行コードの可視化
一番わかりやすい方法が改行コードの可視化です。利用しているテキストエディタにはほぼ標準で備わっているのではないでしょうか。
例えば、わたしが利用しているNotepad++ではつぎのように表示させることができます。
↓[制御文字の表示]→[改行コードを表示]
↓
[CRLF]と表示されました。しかし、慣れないとめちゃくちゃ文字が邪魔です。
↓サクラエディタだと、矢印で教えてくれます。
[CRLF]
[LF]
VScodeだと拡張機能の[ line-endings ]をインストールすることで表示させることが可能です。
●2. .gitattributes ファイルを使った改行コードの管理。
改行コードを可視化していてもミスすることがありますので、gitの設定で自動変換を無効化する方法もあります。
改行コードの管理をするファイル[.gitattributes ]をリポジトリのルートディレクトリやサブディレクトリに配置することで、特定のファイルやファイルパターンに対する設定が可能です。
例えばテキストファイルの自動変換を無効化したい場合、次のような記述が書かれた".gitattributes "ファイルを用意しましょう。
↓このファイルを設定したあと、ためしに改行コードCRLFのテキストファイルをpushしてみて、ファイルを確認してみると、LFに変換されずCRLFのままでした。
しかし、当然ながら自動変換は有用であるがために最初から設定されています。自動変換を無効にすると、異なるオペレーティングシステム間で*.txtファイルを共有する際に改行コードに関する問題が発生する可能性があります。
もし無効化する必要がある場合は、特定のファイルのみに絞って運用しましょう。
test-crlf.txt -text
まとめ:改行コードについて調べてみた
改行コードは、表面的には小さな違いのように見えますが、ファイルの互換性、プログラミング、データ処理、バージョン管理において重要な役割を果たします。
異なる環境間でのスムーズなファイルのやり取り、プログラムの正確な実行、効率的なバージョン管理を実現するためには、改行コードの違いを理解し、適切に扱う必要があります。
不要なトラブルを避け、作業の効率化を図るために、ぜひ改行コードについての理解を深めていきましょう。
参考サイトリンク：ASCII:Windowsにおける改行文字の扱い