改行コードにご用心。

ザウルスのソフト「CaTrain」のデータのことで、けっこう悩んだことがありました。

大雑把に説明しておくと。
「CaTrain」とは、時刻表を表示してくれるソフト「NextTrain」の互換ソフトです。

「NextTrain」の互換ソフトは色々出ていて、僕もこれまでに、Palm用「DA TrainTime」、PocketPC用「NextTrain for PocketPC」を使ったことがあります。
互換というだけあって、ザウルス用も（あるいは他のプラットフォーム用も）含めて、データを使い回すことができます。

たとえば、最初に使ったPalmのメモ帳上に作っていたデータを、Mac上でテキストに書き出し、それに「.tbl」と拡張子をつけて、PocketPC用のデータとすれば、ちゃんと表示してくれます。

そのときは、それでオッケーだったんだけど……。

互換性があるだろうからと、PocketPCで使ってたTBL形式のテキストをそのまま流用しようとしたのですが、データとして認識されませんでした。まっしろ。あらー。

で、困ってたら、ザウルス用互換ソフトには「ntrain」というのもあって（フローティングウィンドウ表示もできるなど、これも面白そう）、こちらはJAVAで動作する都合上、文字コードは「UTF-8」に限定されるという制限があることを知りました。

なので、てっきりこれも文字コードが悪いのかと思って、Mac上でmiを使ってUTF-8に変換してみたら、認識はしたけれど、ひどい文字化け。
でも、とにかく認識はしたのだからと、文字コードをJIS、EUC-JP、ISO8859-1等々、選択できる限りのものを取っ換え引っ換え入れ替えてみました。
でも、文字化けの方式が変わっていくだけで、いっこうに改善されません。

なぜ？（るるー）

……と、ひたすら悩んでいたのですが、答えは非常に簡単でした。
問題は文字コードではなく、改行コードの方だったんです。
Mac用の改行コード（CR）になっていたため、認識できなかったのでした。
で、それをWindows用（CR+LF）に変換してやると、あっけなく認識してしまいました。ちゃんちゃん。

逆に言うと、Mac用の改行コードでも、ずっと問題なく認識してくれていたPocketPC用のやつは、なんて偉いんだろうとか思ったりしましたけど。

ちょっと昔は、Windows機やワープロ専用機を使ってる人とのデータのやり取りは、改行コードを直すのが当然の作業というか、一種の儀式になってたんだけど、最近はMacもWindowsも賢くなり、そういうことで頭を悩ませることもなくなってました。
で、忘れちゃってましたね、そういうの。なんかちょっと懐かしい？(笑)

いずれにせよ、こういう問題は、特に「CaTrain」に限定したものではなく、他のソフトでも発生するかもしれませんよね。
なので、「改行コード」というのは、時おりキーワードになるかもしれない、と思いました。