PR

 UNIX系のOSで構築されたシステムの場合,利用されるOSが1種類のみであることはあまりない。たとえ,サービスを提供するサーバー群がUNIX系OSで統一されていても,管理用端末や開発用端末のOSはWindowsというケースが多い。異なる種類のOSで作業をするにあたり,気をつけなくてはいけないことの一つが,OS間での改行コードの違いだ。改行コードは,UNIX系OSでは「LF」,Windowsでは「CR+LF」となる(CR:Carriage Return(0x0A),LF:Line Feed(0x0D))。

 端末間のファイル転送時に,シェル・スクリプトやperlスクリプトをテキスト・ファイルのまま転送していないだろうか。これらのスクリプトは,可読性のあるテキスト形式で記載されるが,実行時にはプログラムが翻訳して実行されるため,改行コードが異なれば実行できないことがある。

 ファイル転送ツールの中には,テキスト形式のファイルの改行コードを自動変換する機能を持つものがあるため,テキスト・ファイルをそのまま転送するときは注意が必要だ。実際,開発環境のUNIX系OSマシンで作成し,試験を通過したものをWindows経由で実環境に転送して動作確認しようとしたところ,改行コードが変わってしまって実行できないといったケースがあった(図1)。

図1●転送モードの設定ミスにより発生する問題
図1●転送モードの設定ミスにより発生する問題

拡張子によって転送モードを切り替える

 ファイル転送には転送用プロトコルであるFTPやSCPを用いることが多いが,これらのプロトコルに対応するクライアント・ツールの多くは「アスキー転送モード」と「バイナリ転送モード」の2種類の転送方式を提供する。Windows上で動作するクライアントでは,ファイルの拡張子によってモードを切り換える実装が多いため,注意しなくてはいけない。

 具体的には,「README.txt」というファイルは,改行コードを変換されて転送され,「README」というファイルは変換されずに転送されるといったことが起こる。READMEファイルのように人が見るためのテキスト・ファイルであればそれほど深刻なことにはならないが,スクリプト・ファイルの場合は,改行コードが異なると実行できないといった事態となる。

 FTPやSCPのアスキー転送モードでファイル転送を行った場合には,常に転送後にファイルの改行コードが意図したものとなっているのか確認作業を実施するようにしてほしい。

改行コードの影響を受けない電子メール

 電子メールに添付して異なるOS間でファイルを送信する場合は,基本的に添付ファイルはバイナリ形式のまま送付され,OSの改行コードの影響は受けないと考えてよい。メールの添付ファイルは,メール転送プロトコル(SMTP)で添付ファイルを扱うための拡張規格であるMIMEにより転送されるからだ。

 SMTP では基本的に7ビット以下のコードのみを扱う制約があるため,MIMEエンコードにより,バイナリ・ファイルをいったん7ビット以内のASCIIコードに変更し送付する。受信側はそれをデコードすることでバイナリ・データとして復元する。

 MIMEでは,添付されるファイルの種別を示すためのContent-Typeにテキスト・ファイルであることを示す「text」を指定することもできるが,メーラーでこのContent-Typeを解釈し,改行コードを変換するような処理をするものは見当たらない(しかし,そのような実装が考えられないわけではないため,全くないとは言い切れない)。

 このように,転送に用いるツールにより,改行コードが変更されるリスクが存在する。これらを回避し,確実に改行コードを保持したまま対象マシンにファイルを渡せるようにするには,ファイルを作成したマシン上でtarやzipといったコマンドで転送対象ファイルを圧縮してからバイナリ・ファイルとして転送し,対象マシン上で解凍するといったルールを定めることが効果的だ。

ログファイルやソースコードにも要注意

 OSが多種混在するシステムを開発する際は,文字コードにも注意が必要だ。ユーザーが目にするUIまわりは当然として,ネットワーク的にやり取りするデータの内容や,データベースの設計では文字コードの設計は神経質になる部分であろう。その半面,ログやソースコードにおいては文字コードの設計がおろそかになりがちだ。プログラムの保守性の観点から,ログやソースコードの文字コードも明確に規定すべきである。

 ログ出力の際,ローカルのログ・ファイルに出力する場合には,OS内で利用可能な文字コードで出力するため,問題となることは少ないが,ログ集約サーバーを設ける場合には問題となる。ログの送信元,もしくは,ログ・サーバーの受信側で文字コードの変換処理が必要となるため,対応している文字コードを調査し,送信側,受信側のどちらで,変換するのかを決めておく。そもそも,ログ出力には多バイトコードを用いず,ASCIIコードのみとするという設計も有効である。

 ソースコードは,構成管理ソフトを用いた管理で問題がおきやすい。開発機のOS種別によって文字コードが異なる状態で,リポジトリにコミットされる事態は避けたい。統合開発環境によっては,リポジトリからソースコードを取得した時点で,自動的に文字コードや改行コードを環境に合わせたものに変更するものがある。自動で変換されていることに気がつかず,変換されたままコミットしてしまうと,その統合開発環境以外では,ビルドできないといった事態になることもあるため特に注意が必要だ。

大上 貴充(おおがみ たかみつ)
NTTデータ 基盤システム事業本部 システム方式技術ビジネスユニット OSS技術統括 アソシエイトITスペシャリスト(プラットフォーム)
日頃はオリジナルOSSを中心に,技術開発やそのビジネス化に従事。OSをはじめ、Javaやクラスタミドルといった,アプリケーションの基礎となる技術分野を極めるべく,日夜奮闘中。