OSのシスログに書き込まれていた"^M"の正体

最近、面白くなってきたjqコマンドをイジり倒していた時に、なんだか読み込みエラーがでる事が会った。 それも-sオプションをつけた時にのみ発生するエラーで、原因がわからずにいたんだけど、viコマンドでエラー行を見たら"^M"という文字列を見つけた・・・ 不自然な文字だったので調べて見たら、どうやら"CR"文字だという事がわかった。

^M文字の正体

CRっていったい何かと言うと、CRLFのCRの部分で、エンジニアの人であれば、馴染み深い文字列だけれど、あまりデータを扱わないクリエーターやフロントエンジニアの場合は、「なんじゃそりゃ」となるかもしれません。 CRLFは、言い換えれば「\r\n」なのです。 そう改行コードですね。 CRは「キャリッジリターン」でLFは「ラインフィールド」という事らしいです。 「\r」と「\n」は「リターン」と「ニューライン」と覚えているんですが、合ってるかな？ ※違ってたら教えてください。

覚えて起きたいOS毎の改行コードの違い

その昔、インターネットでホームページを作る時にperlを使ってCGIをコーディングしていた人であれば、おなじみなのですが、CRLFはそもそもWindowsOS専用の改行コードなんですね。

Linux : LF MacOS : CR Windows : CRLF

何故こうした事を覚えて置かなければ行けないかというと、GUIブラウザをそのOSで使った時に入力される改行コードがソレになるからですね。

今時の改行コード

OS毎の改行コードが理解できても、実は、最近のテキストエディタは、どの改行コードでも対応できるように作られているのが増えてきています。 ユーザーエージェントでOSを判定して対応するなんてのは、システムとしてはナンセンスです。 一番オーソドックスな改行コードは、LF(\n)のみに合わせるのが一番使い勝手がいいようですね。 多くのシステムがそうしているのと、サーバーOSをLinuxにすると、明らかに管理が楽になるからです。 そこで考えたいのが、CRFLやCRの改行コードの対応についてですが、以下のポリシーで行うのが良さそうです。

1. "CRLF"を"LF"に変換 2. "CR"をLFに変換

この手順で、全てを一旦LFコードにしておいて、必ずシステム内では、LFベースで使用するというルールにしてしまうわけですね。 めんどくさくても、登録文字列は一度この変換を通すようにするのがセオリーなのです。

データに含まれてしまった"^M"文字の対応

データベースであれば、全てのレコードに対して、"^M"を"\n"に文字列置換して上げる必要がありますが、ログデータのようなテキストログの場合は、以下のコードで一発置換する事ができます。 awk '{gsub("^M","\n"); print $0}' input.log > output.log ^Mの含まれる"input.log"を文字列置換して"output.log"を出力し直します。 必要があれば、その後にフィアルメイ変換してあげるといいでしょう。 調査していく事で、色々わかってくると、OSの歴史や特性なども掴めてよりスキルアップできて楽しくないですか？