はじめに

このツールを作った理由は単純である。
毎回、だるかったからだ。

社内システムから連携されるCSV、ExcelをCSV化して取り込むファイル、LinuxやWindowsやDBから吐き出された設定ファイル。
出自が違うたびに、文字コードも改行コードもBOMの有無もぶれる。

  • UTF-8だと思ったらShift_JIS
  • LFだと思ったらCRLF
  • BOMありで通るシステムと、BOMありで化けるシステムが混在

この確認と変換を、人間の目と勘で都度やるのは限界がある。
だから「どんな出自でも受け入れて、インポート先の都合に合わせて出力を揃える」ためのツールを作った。

使うのはこれである。

現場で本当に困るのは、1回の文字化けではない

1ファイルだけ壊れるなら、正直どうとでもなる。
面倒なのは、10ファイル、100ファイル、しかも出自がバラバラの状態で同時に来るケースである。

さらに厄介なのは、インポート先ごとに「正義」が違うことだ。

  • システムAはUTF-8（BOMなし）しか受けない
  • システムBはUTF-8（BOMあり）だと安定する
  • システムCはShift_JIS前提で、UTF-8にすると見た目は読めても取り込みで落ちる

このとき「UTF-8に統一すればよい」という一般論は役に立たない。
必要なのは、用途に合わせて安全に揃える運用である。

このツールでやりたかったこと

思想は3つだけである。

  1. どんな出自でも受け入れる
  2. 出口仕様（インポート先要件）に合わせて変換する
  3. 一括処理しても事故を増やさない

つまり、変換技術の自慢ではなく、運用の摩擦を減らすための道具である。

私が実際に回している手順

1. 先に「出口仕様」を決める

最初に決めるのは入力ではなく出力である。
具体的にはこの3項目を固定する。

  • 文字コード（UTF-8 / Shift_JIS など）
  • 改行コード（LF / CRLF）
  • BOM有無（あり / なし）

ここを曖昧にすると、担当者が変わるたびに結果が変わる。

2. 変換対象を小さく分ける

いきなり全量を流さない。
システム別、期間別、ファイル種別別で分割し、最初は小バッチで回す。

これをやる理由は、失敗したときに切り戻せるからである。
全量一発は、成功すれば速いが、失敗したら終わる。

3. 変換条件を固定して一括変換する

文字コード変換ツール で、用途に応じた条件を固定して処理する。
途中で設定をいじらない。毎回同じ条件で回せることが重要である。

4. 成功判定を目視にしない

「開けたからOK」は事故の入口である。
最低限、次は確認する。

  • 行数が前後で一致しているか
  • CSV/TSVの列数が崩れていないか
  • �（置換文字）が増えていないか
  • キー列（IDやコード）の桁数・文字種が維持されているか

この確認を通らないなら、取り込みに進まない。

BOMは宗教ではなく、相手仕様で決める

BOMあり派・なし派の議論は、現場ではあまり意味がない。
相手システムがどう受け取るか、それだけで決めるべきである。

  • 相手がBOMありで安定するなら、BOMありで出す
  • 相手がBOMで化けるなら、BOMなしで出す

「正しい形式」より「相手が壊れない形式」を優先する。運用とはそういうものだ。

このツールの価値は、変換そのものではない

本当の価値は、次の2つだと思っている。

  • 人によって判断がぶれないこと
  • 毎回の確認コストを下げられること

文字コード事故はゼロにできない。
だが、同じ事故を何度も起こす運用は止められる。
そのために「なんでも受け入れて、用途に合わせて揃えて返す」道具を用意した。

結論

このツールは、理想論で作ったものではない。
現場で毎回発生する「だるい文字コード調整」を潰すために作った。

出自の違うファイルを受け入れ、インポート先仕様に合わせて、文字コード・改行コード・BOMを揃えて返す。
この流れを機械化するだけで、運用はかなり楽になる。

文字化け対応は、気合いで乗り切る仕事ではない。
再現可能な手順に落とし、誰がやっても同じ結果を出せる状態にする。そこまでやって、ようやく「安全に一括救済できる」と言える。