Membersihkan CSV dari masalah Windows-1251 dan BOM sebelum diimpor

File bisa terlihat baik-baik saja, tetapi memakai encoding yang salah

File CSV yang diekspor dari aplikasi akuntansi atau database lama cukup sering sama sekali bukan UTF-8. Windows-1251 untuk teks Sirilik dan Windows-1252 untuk huruf beraksen Eropa Barat masih sama-sama umum dihasilkan sistem yang dibangun bertahun-tahun lalu. Program spreadsheet sering menampilkan file seperti itu tanpa masalah, karena program itu menebak encoding sendiri secara otomatis. Jadi file tampak normal sampai dibaca oleh sesuatu yang kurang toleran, seperti skrip, pipeline impor, atau pemuat database, yang menganggapnya UTF-8 dan malah mendapat deretan karakter kacau, bukan teks yang semestinya ada di sana.

Penanda tiga byte di awal file bisa merusak parser yang ketat

Byte order mark (BOM) UTF-8 adalah penanda tak terlihat, hanya tiga byte, yang berada di paling awal file untuk memberi tahu bahwa teks setelahnya adalah Unicode. Penanda ini berguna bagi program seperti Excel yang memeriksanya. Namun, penanda ini menjadi masalah begitu tujuannya adalah importir JSON yang ketat atau skrip yang tidak mengharapkannya. Byte tambahan itu akhirnya menempel pada karakter pertama di header kolom pertama, sehingga kolom yang seharusnya dibaca sebagai “id” tidak lagi cocok dengan nama itu di bagian kode mana pun yang mengharapkannya. Mendeteksi dan menghapus penanda itu sebelum konversi, alih-alih membiarkannya di file hasil, menghindarkan ketidakcocokan yang bisa membingungkan saat dilacak belakangan.

Mendapatkan encoding yang benar secara otomatis, tanpa menu pilihan

Deteksi encoding yang andal, seperti yang dijalankan CSV ke JSON sebelum membaca satu baris pun, memeriksa byte order mark lebih dulu, lalu mencoba memvalidasi byte sisanya secara ketat sebagai UTF-8, dan baru beralih ke Windows-1251 atau Windows-1252, berdasarkan sebaran byte bernilai tinggi, jika validasi ketat itu gagal. Urutan itu penting. File yang sudah UTF-8 tidak pernah diragukan lalu salah dibaca sebagai encoding lain, sedangkan file yang bukan UTF-8 dikenali dengan benar, bukan dipaksa dibaca sebagai UTF-8 dan berubah menjadi karakter kacau di tengah jalan. Deteksi yang sama juga dipasang di depan CSV ke Excel, untuk kasus ketika tujuannya spreadsheet, bukan skrip.

Tipe data sama pentingnya dengan encoding karakter

Encoding karakter yang benar hanya menyelesaikan separuh masalah yang muncul saat konversi CSV ke JSON. Separuh lainnya adalah menentukan nilai mana yang harus menjadi angka atau boolean JSON dan mana yang harus tetap berupa teks biasa. Nilai seperti 00123 yang berubah menjadi angka 123 kehilangan nol di depannya secara permanen begitu konversi itu terjadi, dan ID yang lebih panjang dari sekitar lima belas digit langsung dibulatkan begitu menjadi bilangan floating-point standar alih-alih tetap berupa teks. Keduanya harus dibiarkan sebagai string, karena mengonversinya mengubah data itu sendiri, bukan sekadar format atau tampilannya.

Header kembar yang tak disengaja bisa merusak impor dengan cara yang berbeda dari encoding yang salah

Objek JSON tidak bisa menampung dua properti dengan key yang sama. Jadi bila file sumber punya dua kolom yang kebetulan memakai nama header yang sama, hal yang tidak jarang terjadi pada ekspor yang dirakit dari lebih dari satu sistem sumber, nama duplikat itu perlu diganti menjadi nama yang berbeda selama konversi. Jika tidak, data kolom kedua menimpa data kolom pertama di setiap objek hasil, tanpa peringatan apa pun. Ini jenis kegagalan yang terpisah dari encoding atau tipe data, tetapi sama mampunya merusak impor secara diam-diam. Ada baiknya memastikan alat konversi melaporkan kejadian ini, bukan menyelesaikan bentrokan itu tanpa terlihat, dan memeriksa hasilnya dengan JSON formatter membuat key yang diganti namanya langsung terlihat.

Langkah demi langkah: memeriksa file sebelum masuk ke impor

Konversi file ekspor sekali di CSV ke JSON dengan pemisah dan encoding dibiarkan otomatis, lalu periksa kedua tebakannya: kirim hasilnya ke JSON formatter, salah satu langkah berikutnya yang ditawarkan halaman itu, dan baca beberapa record pertama. Huruf Sirilik yang kacau atau aksen yang rusak berarti tebakan encoding salah; satu key panjang yang masih berisi pemisah berarti tebakan pemisahlah yang salah. Atur yang salah secara manual, lalu konversi lagi: menu encoding menawarkan Windows-1251, Windows-1252, UTF-8 dengan atau tanpa BOM, dan UTF-16 LE, sedangkan menu pemisah menawarkan koma, titik koma, tab, garis tegak, atau karakter pilihan Anda sendiri. File dengan pemisah atau encoding yang sama sekali tidak bisa dikenali akan ditolak dengan pesan, bukan diubah menjadi data tak bermakna.

Selanjutnya, tentukan cara nilai diberi tipe: pengaturan bawaan sudah membiarkan nilai dengan nol di depan dan ID panjang sebagai teks, dan untuk file yang berisi kode, nomor telepon, atau nomor rekening, mengatur tipe nilai agar semuanya tetap teks berarti tidak ada yang dikonversi sama sekali. Selagi hasilnya terbuka di JSON formatter, cari dua jejak sumber yang berantakan: dua kolom yang sama-sama berjudul id keluar sebagai id dan id_2, dan baris dengan jumlah kolom lebih banyak daripada header menyimpan kelebihannya di bawah key __extra. Keduanya lebih murah diperbaiki di file sumber daripada di sistem yang nantinya tersendat karenanya. Hingga dua puluh file, total 300 MB, bisa diproses dalam satu kali jalan tanpa meninggalkan tab browser.