帳票開発ノウハウ！～ソート処理での出来事

今回は、最近発生したトラブルからご紹介します。

帳票を作成するにあたり、帳票データの中身をソートしたり、帳票アプリが必要とするマスタデータの中身をソートしたりといった作業を、スクリプトなどで自動化するのは一般に行われていると思いますが、今回の騒動はソートの処理で発生しました。システムテストが完了し、本番直前リハーサルの段階、マスタデータのソート処理でエラーが発生したのです。数日後に迫る本番開始を控えて、現場は大騒ぎです。

使用したのは、Windowsのsortコマンド。エラーメッセージは、
「入力レコードが最大長を超えました。より大きい最大長を指定してください。」
です。ソート対象のマスタデータを確認しましたが、これまでテストで正常に処理できていたデータ形式と異なるところが見当たりません。

レコード長も800byteちょっとですべてのレコードで一定です。最大長を超えるような要因は見つかりません。文字コードもShift_JISの範囲を超えるものではありません。

いろいろ試してみたところ、

①1行目を削除すると正常に処理される
②1行目と2行目を入れ替えると正常に処理される
③10行目以降を削除すると、エラーメッセージは出なくなる。

が、結果が文字化けするという結果になりましたので、1行目に何かあるということはわかりましたが、1行目とそれ以降のレコードを、目をこらしてどんなに眺めてみても、形式に違いがありません。こうなると疑うのはsortコマンド。
マイクロソフトに問い合わせたところ、ファイルの先頭512バイトで文字コードを自動認識し、データの並びによっては、UNICODEとして認識されることがあるようです。UNICODEの場合、改行コードは[0D][00][0A][00]です。今回のデータは通常のShift_JISなので、改行コードは[0D][0A]としています。

これをUNICODEとして認識してしまうと、改行コードが存在しないということになり、「入力レコードが最大長を超えました」というエラーになるらしいのです。回避策として考えられるのは、ファイルの先頭512バイト以内にUNICODEではないと判別できるデータを入れておくこと。コマンドの製造元によると、ファイル先頭に英数字を２文字入れるか、改行コードを入れるとよいそうです。古くから存在するOSのコマンドでもこんなことがあるのですね。コマンドが改修される見込みはないものの、先に知っていれば、回避もできます。

今回の事象は、ネット上でも情報が見つからなかったので、こちらに記載してみました。皆様のお役に立てれば幸いです。