Apakah BOM merusak parsing JSON

Q: Apakah BOM merusak parsing JSON?

Ya. BOM UTF-8 adalah urutan tiga byte EF BB BF di awal berkas, yang didekode menjadi U+FEFF. RFC 8259 menyatakan teks JSON tidak boleh diawali BOM; parser boleh mengabaikannya tetapi tidak diwajibkan. Browser dan Node tidak melewatinya, sehingga JSON.parse gagal pada karakter pertama dengan "Unexpected token \uFEFF in JSON at position 0". Perbaiki dengan menyimpan sebagai UTF-8 tanpa BOM, atau menghapus U+FEFF di awal sebelum parsing.

Intinya: BOM UTF-8 adalah tiga byte tak terlihat, sehingga JSON.parse gagal pada karakter pertama dan melaporkan baris 1 kolom 1, yang membuat berkas tampak kosong atau terpotong.

Pemula±4 menit bacaDiterbitkan 2026-10-30Diperbarui 2026-10-30

Bagaimana BOM merusak parsing JSON dan cara menghapusnya

Intinya: periksa tiga byte pertama untuk EF BB BF dan simpan ulang sebagai UTF-8 tanpa BOM; di server, hapus U+FEFF di awal sebelum mem-parsing berkas unggahan atau berkas pihak ketiga apa pun, alih-alih melakukan debugging setelah kegagalan terjadi.

Ya — dan ia menghasilkan kesalahan parse paling membingungkan di antara semuanya, karena berkasnya tampak sepenuhnya baik-baik saja.

Apa yang Anda lihat

复制SyntaxError: Unexpected token  in JSON at position 0
Unexpected character '\uFEFF'

Karakter dalam pesan itu tak terlihat. Posisi 0 berarti byte paling awal.

cat tidak menunjukkan hal aneh. hexdump -C file.json | head -1 menunjukkannya:

复制00000000  ef bb bf 7b 0a 20 20 22  61 22 3a 20 31 0a 7d 0a  |...{  "a": 1.}.|

7b adalah {. Tiga byte sebelumnya adalah BOM.

Dari mana BOM berasal

Byte order mark ada untuk UTF-16, ketika urutan byte memang bervariasi. UTF-8 hanya memiliki satu urutan byte, sehingga BOM murni overhead — namun Notepad di Windows, sebagian ekspor Excel, dan beberapa IDE lama masih menuliskannya secara default.

RFC 8259 tidak ambigu: JSON yang dipertukarkan antar sistem harus UTF-8, dan implementasi tidak boleh menambahkan BOM. Parser boleh mengabaikan BOM di awal tetapi tidak diwajibkan. Browser dan Node memilih untuk tidak melakukannya.

Tiga cara menghilangkannya

Simpan tanpa BOM. Di VS Code, klik encoding di status bar dan pilih "Save with Encoding → UTF-8", bukan "UTF-8 with BOM".

Hapus dari shell.

复制sed -i '1s/^\xEF\xBB\xBF//' data.json

Hapus saat membaca. Ini perbaikan yang bertahan lama untuk apa pun yang menerima berkas unggahan atau berkas pihak ketiga:

复制const text = require('node:fs').readFileSync('data.json', 'utf8').replace(/^\uFEFF/, '');
JSON.parse(text);

Di Python, open(path, encoding='utf-8-sig') menanganinya secara otomatis.

Dua masalah yang mirip

Zero-width space (U+200B) — terbawa saat menyalin JSON dari halaman web; gejalanya identik, code point-nya berbeda.
Tanda kutip lebar penuh — IME Tionghoa mengubah "key" menjadi “key”, yang tampak hampir identik tetapi gagal sebagai Unexpected token “.

Ketiganya adalah bug karakter tak terlihat. Diagnostiknya selalu sama: buang byte pertama dalam bentuk hex alih-alih menatap teksnya.

FAQ

Bagaimana cara mengetahui apakah berkas diawali BOM?

cat tidak menunjukkan apa pun, jadi jalankan hexdump -C file.json | head -1. Jika output diawali ef bb bf, berkas memiliki BOM; 7b (yaitu {) seharusnya muncul lebih dulu pada berkas UTF-8 yang bersih.

Mengapa error selalu menunjuk baris 1, kolom 1?

BOM berada sebelum segalanya, sehingga karakter pertama yang dibaca parser adalah U+FEFF. Kegagalan karena itu terjadi di awal berkas, yang membuat berkas tampak kosong.

Haruskah saya menghapus BOM sebelum parsing?

Ya. Ketika server membaca konfigurasi atau mem-parsing berkas unggahan, hapus U+FEFF di awal lebih dulu — replace(/^\uFEFF/, '') di Node, encoding='utf-8-sig' di Python — yang jauh lebih murah daripada mendiagnosisnya nanti.