HULFT配信時の改行コード変換

HULFT（ハルフト）の大きな強みのひとつである「TEXT変換送信」。異なるOS間でファイルを送る際、文字コードや改行コードを自動でターゲット環境に合わせてくれる便利な機能ですよね。

しかし、この自動変換の「裏側の仕組み」を正しく理解していないと、良かれと思ってやった事前準備が原因で、転送後のファイルが悲惨な状態（文字化けや謎の空行の発生）になってしまうことがあります。

今回は、HULFTの改行コード変換の仕組みと、よくある失敗パターン、そして気になる「メインフレーム（ホスト）の改行コード事情」について解説します！

1. HULFTの改行コード変換は、驚くほど「まんま」処理している
2. 良かれと思った事前準備が仇になる「CRCRLF」の罠
3. 【深掘り】メインフレーム（ホスト）には改行コードがないって本当？
1. メインフレームはどうやって行を区切っているの？
まとめ

1. HULFTの改行コード変換は、驚くほど「まんま」処理している

例えば、Linux（改行コードは LF ）から、Windows（改行コードは CRLF ）へTEXT変換送信を行うとき、HULFTの内部では一体何が行われているのでしょうか？

実は、驚くほど直球でストレートな処理をしています。

HULFTがやっていること（Linux ➔ Windowsの場合） ファイル内にある LF（0x0A）を一旦すべて「削除」し、その位置に Windowsの改行コードである CRLF（0x0D 0A）を機械的に「付与」する。

まさに「見つけた改行マークを、力技でターゲットOSのものに置き換えている」だけなのです。

※参考

HULFT　改行コード

2. 良かれと思った事前準備が仇になる「CRCRLF」の罠

この仕組みを知らないと、以下のようなトラブル（大失敗）を引き起こします。

❌ よくある失敗パターン

Linuxサーバー上で動くシステムだけど、最終的にファイルをWindowsに送るからといって、気を利かせて最初から「CRLF」の改行コードでファイルを作成した。 そして、HULFTの設定はデフォルトのまま「改行コード変換：あり」でWindowsへ送信した。

➔ その結果、ファイルはどうなる？

先ほどの「HULFTの機械的な処理」を思い出してください。 HULFTはLinuxからの送信なので、ファイル内にある LF だけを探して削除し、代わりに CRLF をくっつけます。

最初から CRLF（\r\n）で書かれているファイルに対してこの処理を行うと……

LF（\n）の手前にある CR（\r）は削除されずにそのまま残る。
LF（\n）だけが消されて、新しく CRLF（\r\n）が追加される。
結果として、改行部分が CR ＋ CRLF（\r\r\n） という、世にも奇妙な二重改行コードに化けてしまう！

こうして届いたファイルをWindows側で開くと、「なんか変な制御文字が混ざっている！」「行間がめちゃくちゃ空いている！」といったデータ破損トラブルに繋がります。

💡 鉄則：データ出力は「OSネイティブ」に任せるのが一番安全

トラブルを防ぐ基本の運用スタイルは非常にシンプルです。

ファイルを出力するプログラムは、そのOSの標準（ネイティブ）の改行コードでそのまま吐き出す（LinuxならLF、WindowsならCRLF）。
異OS間のコード変換は、余計な先回りをせず、HULFTの自動変換機能に100%丸投げする。

お互いが自分の仕事をシンプルにこなすのが、システム連携で一番エラーが出ない形です。

3. 【深掘り】メインフレーム（ホスト）には改行コードがないって本当？

HULFTの仕様書やFAQ（技術資料）を読んでいると、汎用機（Mainframe）やIBMi（旧AS/400）系の機種に関する、以下のような少し特殊な記述を見かけることがあります。

UNIX/Linux ➔ Mainframe/IBMi：「LF（0x0A）を削除」

Windows ➔ Mainframe/IBMi：「CRLF（0x0D0A）またはLF（0x0A）を削除」

「えっ？付与するんじゃなくて、削除して終わり？ メインフレームって改行コードの概念がないの？」と不思議に思いますよね。

結論から言うと、メインフレーム（ホスト世界）には、私たちが普段使っているような「テキストファイルの中に改行コード（制御文字）を埋め込む」という概念が基本的にありません。

メインフレームはどうやって行を区切っているの？

オープン環境（WindowsやLinux）のファイルは、すべての文字が横一列に繋がっていて、改行コードを見つけて初めて「ここで改行なんだな」と判断します。

しかし、メインフレームのファイル（データセット）は、最初から「1行の長さ（レコード長）が〇〇バイト」と厳格に箱のサイズが決まっている（固定長データ）ため、改行コードという『目印』を入れる必要がそもそもないのです。

そのため、HULFTがWindows/Linuxからメインフレームにテキストを送る際は、「オープン環境側の目印だった改行コード（CRLFやLF）をただ綺麗に消し去り、1行分のデータをメインフレームの1レコード（箱）にスポット嵌め込む」という処理を行います。資料にある「削除」という表現は、こういう意味だったんですね。

※参考

(HULFT_#110_HUL_\211\374\215s\220\335\222\350_2.xls)