Windows Info 第128回

Windows 10 RS5では「メモ帳」がCR＋LF以外の行末記号に対応

　Windows 10の次期アップデートであるRS5（予定としてはWindows10 Ver.1809）では、標準のメモ帳アプリが改良される。メモ帳は、Windows 1.x時代からある“由緒ある”Windowsアプリケーションで、Vistaで改良されたあと、これまで大きな変化はなかった。

　しかし、RS5では、行末が「LF」のみ、「CR」のみのテキストファイル形式に対応する。これまでメモ帳は、行末が「CR＋LF」のテキストファイルにのみ対応していた。インターネットからダウンロードしたテキストファイルをメモ帳で開いたら、行が全部繋がって、まともに読めないという経験をしたことはないだろうか？　これは、従来のメモ帳アプリは、テキストファイルの行の区切り（行末記号）として、CR＋LFという形式しか対応していなかったからだ。

Windows 10 RS5ではメモ帳が改良され、UNIX系OSなどで使うテキストファイルに対応するようになった

そもそもCR＋LFって何なの？

　いわゆるASCIIコードには、制御記号というコードがある。00～31までのコードは制御文字、あるいはコントロールコードなどと呼ばれ、文字や記号ではなく、行末などを表現するために使われていた。文字コードとは、文字や記号などを数値として表現したもので、ASCIIコードは、0～127までの数値にアルファベットや数字、記号などを割り当てている。

　「CR」は「復帰コード」、「キャリッジリターン（carriage return）などと呼ばれ数値としては13、「LF」は「ラインフィード（Line Feed）」「ニューライン（New Line）」などという名称があり数値としては10が割り当てられている。

　ASCIIコードは、7ビットで定義されているので、ビットパターンとしてはCRは「0001101」、LFは「0001010」となる。2進数表現はわかりにくいため、16進数では「0D」と「0A」となる。

　一般にテキストファイルは、ASCIIなどの文字コードでテキストを表現したもので、このときに行を示すために、行末に「改行」コードをおく。この改行コードは、プラットフォーム（OS）により違いがあり、WindowsやMS-DOSなどマイクロソフト系では、「CR」と「LF」を組にして使う。

　簡単に言えば、行末には「0x0D0A」という数値がついている。これに対して、UNIX系OSではLFのみを改行コードとしている。これらのプラットフォームを前提にしたテキストファイルの行末は、「0x0A」のみになっているため、これをメモ帳で見ると行がつながって見えるわけだ。

　そもそも、こうした制御コードは、コンピュータの出力にプリンタを使っていたときの名残だ。コンピューターができたとき、コンピュータ用の入出力装置はなく、当時電信で使われていた「TeleTypewriter」（TTYと略されることが多い）を接続して利用した。

　これをコンピュータでは、端末、Terminalと呼んだ。当初の端末は、プリンタとキーボード（そして紙テープの読み取り機と鑽孔機）をセットにしたもので、コンピュータから送られてくる文字をプリンタに印刷して表示していた。

　TTYは、送られてきた文字を1つ1つ紙に印字していく「シリアルプリンタ」で、用紙の規格から1行に80文字、132文字の印刷ができた。行を変える場合、「CR」コードを送り、印字ヘッドを行頭まで戻し、「LF」コードで紙を1行分送り出していた。こうした歴史があるため、CR＋LFは、過去においてはポピュラーな「行末」コードだったのだ。

　マイクロプロセッサが登場する以前のOSでは、ソフトウェアが端末に依存しないように、内部的に使う「改行コード」と、実際に端末に送る「改行コード」を別のものにしていた。実際にさまざまな制御コードを使う端末が多く存在し、端末に出力する段階で制御コードを変更するようになっていた。UNIX系OSでは、こうした機能をやはり実装しており、これを手本としたLinuxにも引き継がれている。UNIX系OSでは、テキストファイルの行末コードには「LF」のみを使うことにしていた。

　8bitのマイクロプロセッサが登場し、コンピューターのシステムが作られると、最初は当時のコンピューターと同じく、端末を接続していたが、そのうちCRTを使った表示装置やキーボードが一体となった現在のパソコンの原型のようなマシンが登場する。

　このとき、CP/MやマイクロソフトのBASICインタプリタなどは、改行コードとして「CR＋LF」を使った。当時のコンピューター言語は、端末が使われていた時代に作られたもので、たとえば、BASICのPrint文などもプリンタのような出力デバイスを想定したものだった。このため、行頭に戻るだけのCRと次の行へ進むLFにそれぞれの役割を持たせたほうが、画面を制御しやすかった。

　たとえば「PRINT CHR$(13)+"ノコリ:";p;"パーセント　　";」のようなステートメントを繰り返すことで、画面をスクロールさせることなく同じ行に進行状態を表示し続けることができた。

　MS-DOSが登場したとき、やはりテキストファイルの行末コードには「CR＋LF」が引き続き使われ、これがWindowsにも引き継がれる。そしてメモ帳アプリもこの仕様で作られたわけである。

　しかし、インターネットの普及で、LFのみのテキストファイルがWindowsユーザーの元に届く機会が増えても、マイクロソフトは、メモ帳アプリやテキストファイルの仕様を変えることはなかった。もちろんWindows上には、LFのみの行末記号に対応したサードパーティ製プログラムが多数あったし、Internet Explorerなども問題なく表示することができた。

　また、コンソールでは、CRは同じ行の行頭にカーソル位置を変更するが、LFは次の行の先頭にカーソルを移動する。このため、LFのみのテキストファイルをコマンドプロンプトのTYPEコマンドで表示させてもユーザーは問題を感じることはない。

コンソールでは、LFで新しい行の先頭に移動するため、実際にはCRはなくても問題ないが、CRを使うことで同じ行に重ねてテキスト行を表示させることもできる

　RS5に付属するメモ帳では、読み込んだファイルの行末コードが「CR+LF」、「LF」のみ、 「CR」のみのどれでも動作するようになった。また、ステータスラインに編集中のファイルの行末コードを表示できる。

RS5に付属するメモ帳では、ステータスバーに行末記号の種類を表示できるようになった

　これでようやくメモ帳で、UNIX系OS由来のテキストファイルなどを扱えるようになった。なお、新しいメモ帳には、レジストリによる設定変更が可能で、現在の行末記号と異なる行末記号のテキストを貼り付けたときの処理、エンターキーを押したときに挿入される行末記号をファイルに合わせるか、CR＋LFに固定するかを指定できる。

　デフォルトでは、どちらも現在開いているファイルの行末記号に合わせるようになっている。

レジストリの設定で、行末記号を含むテキストの貼り付け、エンターキーを押したときに挿入されるコードを設定できる。ただし、エンターキーでCR＋LFのみを挿入するように設定すると、メモ帳はRS4までと同じくCR＋LFのみを行末記号として受け付けるようになる

　些細な改良ではあるが、これまで、テキストファイルを開いたら行がつながっていて、別のアプリで開き直すようなことをしなくて済むようになる。というか、ここまで頑なにCR＋LFを維持してきたかのほうが謎だが、おそらくは誰もなんとかしようと思わなかったというのが正しいところなのだろう。

　WSL（Windows Subsystem for Linux）などの関係で、コンソールやコマンドプロンプトなどに責任を持つ部署ができ、ようやくテキストファイルやメモ帳アプリをどうにかしようという状態になったのだと思われる。