CSV ke Excel dan sebaliknya tanpa merusak data

Masalah pemisah dimulai bahkan sebelum file dibuka

Excel menentukan cara memecah CSV menjadi kolom berdasarkan pemisah daftar dari pengaturan wilayah sistem operasi, bukan dengan melihat isi file. Di komputer dengan pengaturan wilayah Eropa, pemisah itu secara default adalah titik koma, sehingga ekspor biasa yang dipisahkan koma masuk ke satu kolom berisi teks yang tidak terpecah. Di komputer dengan pengaturan AS, hal sebaliknya terjadi pada file bertitik koma. Kedua hasil itu tidak berarti file rusak. Artinya, Excel menebak dari pengaturan yang tidak ada hubungannya dengan cara file itu ditulis. Konverter seperti CSV ke Excel mengurai file dengan beberapa calon pemisah dan memeriksa mana yang menghasilkan jumlah kolom yang konsisten di semua baris sampel. Dengan begitu, tebakan itu dihindari sepenuhnya, tanpa bergantung pada ekstensi file ataupun pengaturan sistem.

Angka nol di depan dan angka panjang menjadi korban yang tidak disadari

Hal paling merusak yang bisa terjadi saat konversi CSV ke Excel adalah terlalu bersemangat mengubah teks menjadi angka. Kode produk yang ditulis 00123 menjadi angka 123 begitu spreadsheet menganggapnya tampak seperti angka, dan angka nol di depannya tidak bisa dipulihkan setelah itu. Nol itu hilang begitu saja. Pengenal yang lebih panjang rusak dengan cara lain. Nomor kartu atau barcode enam belas digit kehilangan beberapa digit terakhirnya tanpa peringatan apa pun, karena angka standar di spreadsheet tidak bisa menyimpan lebih dari sekitar lima belas angka penting tanpa pembulatan. Keduanya harus tetap menjadi teks, tidak dikonversi, dan aturan yang sama berlaku bila tujuannya adalah program, bukan Excel: CSV ke JSON menyimpannya sebagai string. Nilai yang memang berupa angka, seperti jumlah barang, harga, dan total, tetap harus dikonversi seperti biasa agar bisa dijumlahkan dan dipakai dalam perhitungan.

Data non-Inggris biasanya rusak karena encoding

File yang diekspor dari sistem akuntansi atau database lama sering kali sama sekali bukan UTF-8. Kasus yang umum adalah Windows-1251 untuk teks Sirilik dan Windows-1252 untuk huruf beraksen Eropa Barat. Bila file seperti itu dibuka dengan anggapan yang salah, muncullah deretan karakter acak yang sudah tidak asing lagi. Masalah ini tertangkap otomatis bila encoding yang sebenarnya dideteksi dengan urutan berikut: periksa dulu byte order mark, lalu validasi secara ketat sebagai UTF-8, dan bila gagal, pilih encoding cadangan berdasarkan sebaran byte bernilai tinggi. Tidak ada yang perlu menebak dari menu pilihan encoding.

Byte order mark sendiri bisa menimbulkan kerusakan yang tidak kentara

Byte order mark (BOM) UTF-8 adalah tiga byte tak terlihat di awal file yang memberi tahu Excel bahwa teks setelahnya adalah Unicode. Ini berguna bila tujuannya Excel. Masalah muncul begitu file ditujukan ke tempat lain selain Excel. Alat baris perintah atau alur data lama yang tidak membuang byte tersebut akan mendapati byte itu menempel pada karakter pertama di sel header pertama, sehingga kolom yang seharusnya bernama “id” tidak lagi cocok dengan apa pun yang mengharapkan nama persis itu. Perlu tidaknya BOM dipertahankan sepenuhnya bergantung pada apa yang membaca file berikutnya, bukan pada satu pengaturan default yang berlaku untuk semua.

Arah sebaliknya punya keputusan sendiri

Mengubah spreadsheet kembali ke CSV dengan Excel ke CSV memunculkan pertanyaan yang tidak pernah muncul pada arah sebaliknya. Sel yang berisi rumus punya dua nilai, yaitu teks rumusnya sendiri dan angka hasil perhitungan terakhirnya, sedangkan CSV hanya bisa membawa salah satunya. Nilai hasil perhitungan adalah yang diharapkan sebagian besar sistem saat mengimpor. Sebaliknya, teks rumus adalah yang ingin dibaca oleh orang yang memeriksa file. Tanggal juga butuh perhatian yang sama jelasnya. Menuliskannya dalam satu format tetap yang dipilih, alih-alih memercayai apa pun yang kebetulan ditampilkan spreadsheet, mencegah file yang sama menghasilkan tanggal yang tampak berbeda, tergantung pengaturan wilayah komputer yang memformatnya.

Kesalahan umum dan pengaturan yang mencegahnya

Membiarkan pemisah desimal pada titik. Ekspor dengan titik koma dari negara yang menulis satu setengah sebagai 1,50 perlu pemisah desimal diatur ke “Koma” di CSV ke Excel; bila tidak, setiap harga tetap menjadi string dan tidak bisa dijumlahkan. Mengandalkan deteksi tipe otomatis untuk kode pengenal. Deteksi ini melindungi angka nol di depan dan semua angka yang lebih dari lima belas digit, tetapi nomor pesanan atau kode pos tanpa nol di depan tetap menjadi angka; bila tidak ada kolom yang perlu dihitung, atur tipe sel ke “Semua sebagai teks” agar setiap nilai tetap persis seperti yang ditulis. Memaksakan ekspor beberapa juta baris ke dalam satu buku kerja. XLSX berhenti di 1.048.576 baris, jadi CSV yang lebih panjang ditolak dengan tautan ke Pisahkan CSV, bukan dipotong diam-diam.

Saat mengekspor kembali, cocokkan tiga pengaturan default di Excel ke CSV dengan apa pun yang akan membaca file berikutnya. Encoding keluaran adalah UTF-8 dengan BOM, bentuk yang dibutuhkan Excel; skrip atau pemuat database biasanya menginginkan UTF-8 biasa. Format tanggal adalah ISO 8601, sehingga 14 Maret 2026 menjadi 2026-03-14 di setiap komputer, dengan pilihan lain 14.03.2026, 03/14/2026, dan nomor seri Excel. Akhir baris adalah CRLF untuk Windows, dengan LF untuk alat Unix. Pengaturan keempat mudah terlewat: secara default hanya sheet pertama yang diekspor, jadi buku kerja dengan tab kedua perlu opsi “Semua sheet”, yang menghasilkan ZIP berisi satu CSV per sheet.