Pendahuluan

Saya membuat alat ini karena satu alasan sederhana. Melakukan semuanya manual setiap kali itu melelahkan.

CSV dari sistem internal, file dari Excel, dan file konfigurasi dari Linux, Windows, atau database. Setiap kali sumber berubah, encoding, line ending, dan BOM ikut berubah.

  • Dikira UTF-8, ternyata Shift_JIS
  • Dikira LF, ternyata CRLF
  • Ada sistem yang stabil dengan BOM, ada yang rusak karena BOM

Pengecekan/konversi dengan mata dan feeling tidak bisa diskalakan. Karena itu saya membuat alat yang menerima file dari sumber apa pun lalu menormalkan output sesuai kebutuhan import.

Masalah sebenarnya bukan satu file rusak

Kalau hanya satu file rusak, biasanya masih bisa ditangani. Yang berat adalah ketika 10 atau 100 file datang bersamaan dari sumber berbeda.

Lebih rumit lagi, setiap sistem tujuan punya definisi “benar” yang berbeda.

  • Sistem A hanya menerima UTF-8 tanpa BOM
  • Sistem B lebih stabil dengan UTF-8 + BOM
  • Sistem C mengasumsikan Shift_JIS; UTF-8 terlihat bisa dibaca tetapi import gagal

Dalam kondisi ini, saran “samakan saja ke UTF-8” tidak membantu. Yang dibutuhkan adalah proses aman dan berulang sesuai kebutuhan tujuan.

Tujuan alat ini

Prinsipnya hanya tiga:

  1. Menerima file dari sumber apa pun
  2. Mengonversi sesuai syarat sistem tujuan
  3. Tidak menambah insiden saat diproses batch

Ini bukan pamer teknik konversi, melainkan alat untuk mengurangi gesekan operasional.

Prosedur yang benar-benar saya pakai

1. Tentukan spesifikasi output terlebih dahulu

Mulai dari output, bukan dari asumsi input. Kunci tiga hal berikut:

  • Encoding (UTF-8 / Shift_JIS, dst.)
  • Line ending (LF / CRLF)
  • BOM (dengan / tanpa)

Jika ini ambigu, hasil berubah setiap operator berganti.

2. Pecah target konversi menjadi bagian kecil

Jangan langsung memproses semuanya. Bagi per sistem, periode, atau jenis file; mulai dari batch kecil.

Alasannya: saat gagal, rollback masih mungkin. One-shot volume penuh hanya cepat jika berhasil.

3. Kunci kondisi lalu jalankan konversi batch

Gunakan alat konversi encoding dengan kondisi tetap per tujuan. Jangan ubah setting di tengah jalan. Kuncinya adalah repeatability.

4. Jangan menilai sukses hanya dari tampilan

“Bisa dibuka berarti aman” adalah awal banyak insiden. Minimal cek:

  • Jumlah baris sebelum/sesudah sama
  • Jumlah kolom CSV/TSV tidak berubah
  • � (replacement character) tidak bertambah
  • Kolom kunci (ID/kode) tetap sama panjang dan jenis karakternya

Kalau verifikasi tidak lolos, jangan lanjut import.

BOM bukan soal keyakinan, tapi spesifikasi lawan sistem

Perdebatan BOM/tanpa BOM biasanya tidak terlalu berguna di lapangan. Yang penting cuma satu: bagaimana sistem penerima membaca file.

  • Jika penerima stabil dengan BOM, keluarkan dengan BOM
  • Jika penerima rusak karena BOM, keluarkan tanpa BOM

Prioritaskan “format yang tidak merusak pihak lain” dibanding “format yang paling benar secara teori”. Begitulah operasi nyata.

Nilai alat ini bukan pada konversinya saja

Nilai utamanya ada dua:

  • Keputusan tidak berubah-ubah antar orang
  • Biaya verifikasi berulang menurun

Insiden encoding tidak bisa dibuat nol mutlak. Tapi kita bisa berhenti mengulang insiden yang sama. Karena itu saya menyiapkan alat yang menerima apa pun lalu mengembalikan format yang sesuai tujuan.

Kesimpulan

Alat ini bukan lahir dari teori ideal. Alat ini lahir untuk menghapus pekerjaan penyesuaian encoding yang berulang dan melelahkan.

Terima file dari berbagai sumber, selaraskan encoding/line ending/BOM dengan kebutuhan tujuan, lalu keluarkan hasil yang konsisten. Mengotomatiskan alur ini saja sudah sangat meringankan operasi.

Menangani mojibake bukan pekerjaan yang harus ditopang “niat kuat”. Ini harus dijadikan prosedur yang bisa direproduksi agar siapa pun menghasilkan hasil yang sama. Baru setelah itu kita bisa menyebutnya pemulihan batch yang aman.