Javaでバッチ処理を作る際に、固定長ファイル（Fixed Length File）を扱うケースは非常に多い。ところが、見た目は単純でも、実務では落とし穴が山ほどあります。

全角混じりによるズレ、行長の不一致、改行コードの差異など、知らないと簡単にデータ破損が起きてしまいます。
この記事では、Javaで固定長ファイルを読み込むときの典型的な罠と、安全に処理する方法をまとめます。

1. substring() が信用できない理由

● ① 全角文字が混じると桁数がズレる

よくある失敗例：

→ 10バイトではなく10文字で切れるため、全角が1文字=2バイトとして計算されず、想定より短く切れてしまう。

対策

• 仕様がバイト長か文字長かを必ず確認

• String#getBytes("MS932") などでバイト長を基準に処理

• もしくは Commons Lang の FixedWidthParser 的な自作ユーティリティを使う

2. 改行コードの違いでズレる

Windows：CRLF
Linux：LF
古い大手金融系ホスト：CR のみ

BufferedReader は改行コードを吸収するため問題ないが、行末のスペース削除が入る仕組みの場合は危険。

落とし穴例

• ETL や SFTP 転送で自動で改行変換がかかる

• 末尾のスペースが削られる

• 固定長ファイルが固定長じゃなくなる

対策

• 末尾スペースは削除しない設定で転送する

• Java 側で改行コードを意識し、バイナリで読む方法も検討

3. 行長チェックを必ず入れる

実務の事故で最も多いのがこれ。

「1行の長さが定義と違うのに気づかず処理が進む」 → データ崩壊

例：定義：120文字
実データ：118文字（2バイト欠損）

安全チェック例

バイト数で定義されている場合

4. 例外が出たら中断か継続かを設計する

業務システムでは次の判断が重要：

• 1件不正ならスキップして続行？

• 1件でもエラーならファイルごと reject？

• ログ形式は？

特に金融・保険では「厳格なファイル判定」が求められやすい。

5. 安全な固定長パーサー（テンプレ）

実務でよく使われる実装テンプレを載せておく。

これを使えば、定義書に合わせた安全なパースができる。

6. Java 固定長ファイル 読み込みで起きる典型的な落とし穴

7. まとめ

固定長ファイルは一見簡単に見えるが、実務では非常に事故が多い形式。

落とし穴を理解し、行長チェック・バイト長確認・例外方針の整理が必須。

Javaで業務バッチを書く人ほど、こうした基本の「安全処理」がプロジェクト成功を左右する。