Apa perbedaan antara UTF-8 dan UTF-8 tanpa BOM?

Apa perbedaan antara UTF-8 dan UTF-8 tanpa BOM ? Mana yang lebih baik?

BOM UTF-8 adalah urutan byte pada awal aliran teks ( 0xEF, 0xBB, 0xBF) yang memungkinkan pembaca untuk lebih andal menebak file sebagai dikodekan dalam UTF-8.

Biasanya, BOM digunakan untuk menandai endianness dari suatu encoding, tetapi karena endianness tidak relevan dengan UTF-8, BOM tidak diperlukan.

Menurut standar Unicode , BOM untuk file UTF-8 tidak disarankan :

2.6 Skema Pengkodean

... Penggunaan BOM tidak diperlukan atau direkomendasikan untuk UTF-8, tetapi dapat ditemui dalam konteks di mana data UTF-8 dikonversi dari bentuk penyandian lain yang menggunakan BOM atau di mana BOM digunakan sebagai tanda tangan UTF-8 . Lihat subbagian “Tanda Pemesanan Byte” di Bagian 16.8, Spesial , untuk informasi lebih lanjut.

Jawaban bagus lainnya sudah menjawab bahwa:

• Tidak ada perbedaan resmi antara UTF-8 dan BOM-ed UTF-8
• String BOM-ed UTF-8 akan mulai dengan tiga byte berikut. EF BB BF
• Bytes tersebut, jika ada, harus diabaikan ketika mengekstraksi string dari file / stream.

Tetapi, sebagai informasi tambahan untuk ini, BOM untuk UTF-8 bisa menjadi cara yang baik untuk "mencium" jika string dikodekan dalam UTF-8 ... Atau bisa juga string yang sah dalam pengkodean lainnya ...

Misalnya, data [EF BB BF 41 42 43] dapat berupa:

• String ISO-8859-1 yang sah "ï» ¿ABC "
• Senar UTF-8 "ABC" yang sah

Jadi walaupun bisa keren untuk mengenali pengkodean konten file dengan melihat byte pertama, Anda tidak harus bergantung pada ini, seperti yang ditunjukkan oleh contoh di atas

Pengkodean harus diketahui, bukan diramalkan.

Setidaknya ada tiga masalah dengan menempatkan BOM dalam file yang disandikan UTF-8.

1. File yang tidak mengandung teks tidak lagi kosong karena selalu berisi BOM.
2. File yang menyimpan teks yang ada dalam subset ASCII dari UTF-8 tidak lagi menjadi ASCII sendiri karena BOM bukan ASCII, yang membuat beberapa alat yang ada rusak, dan tidak mungkin bagi pengguna untuk mengganti alat warisan tersebut.
3. Tidak mungkin untuk menggabungkan beberapa file bersama karena setiap file sekarang memiliki BOM di awal.

Dan, seperti yang disebutkan orang lain, tidak cukup atau tidak perlu memiliki BOM untuk mendeteksi bahwa ada sesuatu yang UTF-8:

• Itu tidak cukup karena urutan byte sewenang-wenang dapat terjadi untuk memulai dengan urutan yang tepat yang merupakan BOM.
• Ini tidak perlu karena Anda hanya bisa membaca byte seolah-olah mereka UTF-8; jika itu berhasil, itu, menurut definisi, valid UTF-8.

Berikut adalah contoh penggunaan BOM yang sebenarnya menyebabkan masalah nyata dan banyak orang tidak mengetahuinya.

BOM memecah skrip

Skrip shell, skrip Perl, skrip Python, skrip Ruby, skrip Node.js, atau skrip executable lainnya yang perlu dijalankan oleh penerjemah - semuanya dimulai dengan garis shebang yang terlihat seperti salah satu di antaranya:

#!/bin/sh
#!/usr/bin/python
#!/usr/local/bin/perl
#!/usr/bin/env node

Ini memberi tahu sistem penerjemah mana yang perlu dijalankan ketika menjalankan skrip seperti itu. Jika skrip dikodekan dalam UTF-8, seseorang mungkin tergoda untuk memasukkan BOM di awal. Tapi sebenarnya "#!" karakter bukan hanya karakter. Mereka sebenarnya adalah angka ajaib yang kebetulan terdiri dari dua karakter ASCII. Jika Anda meletakkan sesuatu (seperti BOM) di depan karakter-karakter itu, maka file tersebut akan terlihat seperti memiliki angka ajaib yang berbeda dan itu dapat menyebabkan masalah.

Lihat Wikipedia, artikel: Shebang, bagian: Nomor ajaib :

Karakter shebang diwakili oleh dua byte yang sama dalam pengkodean ASCII yang diperluas, termasuk UTF-8, yang biasanya digunakan untuk skrip dan file teks lainnya pada sistem seperti Unix saat ini. Namun, file UTF-8 dapat dimulai dengan tanda urutan byte opsional (BOM); jika fungsi "exec" secara khusus mendeteksi byte 0x23 dan 0x21, maka keberadaan BOM (0xEF 0xBB 0xBF) sebelum shebang akan mencegah penerjemah skrip dieksekusi.Beberapa otoritas merekomendasikan untuk tidak menggunakan tanda urutan byte dalam skrip POSIX (seperti Unix), [14] karena alasan ini dan untuk interoperabilitas yang lebih luas dan masalah filosofis. Selain itu, tanda urutan byte tidak diperlukan dalam UTF-8, karena penyandian itu tidak memiliki masalah endianness; ini hanya berfungsi untuk mengidentifikasi pengkodean sebagai UTF-8. [penekanan ditambahkan]

BOM ilegal di JSON

Lihat RFC 7159, Bagian 8.1 :

Implementasi TIDAK HARUS menambahkan tanda urutan byte ke awal teks JSON.

BOM berlebihan di JSON

Tidak hanya itu ilegal di JSON, itu juga tidak diperlukan untuk menentukan pengkodean karakter karena ada cara yang lebih dapat diandalkan untuk secara jelas menentukan pengkodean karakter dan endianness yang digunakan dalam aliran JSON apa pun (lihat jawaban ini untuk detail).

BOM memecah parser JSON

Tidak hanya itu ilegal di JSON dan tidak diperlukan , itu benar-benar merusak semua perangkat lunak yang menentukan pengkodean menggunakan metode yang disajikan dalam RFC 4627 :

Menentukan pengkodean dan endianness JSON, memeriksa empat byte pertama untuk byte NUL:

00 00 00 xx - UTF-32BE
00 xx 00 xx - UTF-16BE
xx 00 00 00 - UTF-32LE
xx 00 xx 00 - UTF-16LE
xx xx xx xx - UTF-8

Sekarang, jika file dimulai dengan BOM itu akan terlihat seperti ini:

00 00 FE FF - UTF-32BE
FE FF 00 xx - UTF-16BE
FF FE 00 00 - UTF-32LE
FF FE xx 00 - UTF-16LE
EF BB BF xx - UTF-8

Perhatikan bahwa:

1. UTF-32BE tidak dimulai dengan tiga NUL, jadi tidak akan dikenali
2. UTF-32LE byte pertama tidak diikuti oleh tiga NUL, sehingga tidak akan dikenali
3. UTF-16BE hanya memiliki satu NUL dalam empat byte pertama, sehingga tidak akan dikenali
4. UTF-16LE hanya memiliki satu NUL dalam empat byte pertama, sehingga tidak akan dikenali

Tergantung pada implementasinya, semua itu dapat ditafsirkan secara tidak benar sebagai UTF-8 dan kemudian disalahartikan atau ditolak sebagai UTF-8 yang tidak valid, atau tidak diakui sama sekali.

Selain itu, jika tes implementasi untuk JSON yang valid seperti yang saya sarankan, itu akan menolak bahkan input yang memang dikodekan sebagai UTF-8, karena itu tidak dimulai dengan karakter ASCII <128 seperti yang seharusnya sesuai dengan RFC.

Format data lainnya

BOM di JSON tidak diperlukan, ilegal dan merusak perangkat lunak yang berfungsi dengan benar menurut RFC. Seharusnya menjadi seorang bangsawan untuk tidak menggunakannya saat itu, namun, selalu ada orang yang bersikeras melanggar JSON dengan menggunakan BOM, komentar, aturan kutip yang berbeda atau tipe data yang berbeda. Tentu saja siapa pun bebas menggunakan hal-hal seperti BOM atau apa pun jika Anda membutuhkannya - jangan panggil saja JSON.

Untuk format data lain selain JSON, lihat bagaimana tampilannya. Jika satu-satunya penyandian adalah UTF- * dan karakter pertama haruslah karakter ASCII lebih rendah dari 128, maka Anda sudah memiliki semua informasi yang diperlukan untuk menentukan penyandian dan daya tahan data Anda. Menambahkan BOM bahkan sebagai fitur opsional hanya akan membuatnya lebih rumit dan rentan kesalahan.

Penggunaan BOM lainnya

Adapun penggunaan di luar JSON atau skrip, saya pikir sudah ada jawaban yang sangat bagus di sini. Saya ingin menambahkan info yang lebih rinci secara khusus tentang skrip dan serialisasi, karena ini adalah contoh karakter BOM yang menyebabkan masalah nyata.

Apa perbedaan antara UTF-8 dan UTF-8 tanpa BOM?

Jawaban singkat: Dalam UTF-8, BOM dikodekan sebagai byte EF BB BFpada awal file.

Jawaban panjang:

Awalnya, diharapkan Unicode akan dikodekan dalam UTF-16 / UCS-2. BOM dirancang untuk formulir penyandian ini. Ketika Anda memiliki unit kode 2-byte, perlu untuk menunjukkan urutan urutan kedua byte tersebut, dan konvensi umum untuk melakukan ini adalah memasukkan karakter U + FEFF sebagai "Byte Order Mark" di awal data. Karakter U + FFFE secara permanen tidak ditetapkan sehingga keberadaannya dapat digunakan untuk mendeteksi urutan byte yang salah.

UTF-8 memiliki urutan byte yang sama terlepas dari platform endianness, sehingga tanda urutan byte tidak diperlukan. Namun, ini dapat terjadi (sebagai urutan byte EF BB FF) dalam data yang dikonversi ke UTF-8 dari UTF-16, atau sebagai "tanda tangan" untuk menunjukkan bahwa data tersebut adalah UTF-8.

Mana yang lebih baik?

Tanpa. Ketika Martin Cote menjawab, standar Unicode tidak merekomendasikannya. Ini menyebabkan masalah dengan perangkat lunak yang tidak sadar BOM.

Cara yang lebih baik untuk mendeteksi apakah suatu file adalah UTF-8 adalah dengan melakukan pemeriksaan validitas. UTF-8 memiliki aturan ketat tentang urutan byte apa yang valid, sehingga kemungkinan false positive dapat diabaikan. Jika urutan byte terlihat seperti UTF-8, mungkin itu.

UTF-8 dengan BOM lebih baik diidentifikasi. Saya telah mencapai kesimpulan ini dengan cara yang sulit. Saya sedang mengerjakan proyek di mana salah satu hasilnya adalah file CSV , termasuk karakter Unicode.

Jika file CSV disimpan tanpa BOM, Excel menganggapnya ANSI dan menunjukkan omong kosong. Setelah Anda menambahkan "EF BB BF" di bagian depan (misalnya, dengan menyimpannya kembali menggunakan Notepad dengan UTF-8; atau Notepad ++ dengan UTF-8 dengan BOM), Excel membukanya dengan baik.

Membebani karakter BOM ke file teks Unicode direkomendasikan oleh RFC 3629: "UTF-8, format transformasi ISO 10646", November 2003 di http://tools.ietf.org/html/rfc3629 (info terakhir ini ditemukan di: http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM-FEFF-EFBBBF.html )

BOM cenderung boom (tidak ada permainan yang dimaksudkan) di suatu tempat, di suatu tempat. Dan ketika booming (misalnya, tidak dikenali oleh browser, editor, dll.), Itu muncul sebagai karakter aneh di awal dokumen (misalnya, file HTML, respons JSON , RSS , dll.) dan menyebabkan jenis rasa malu seperti masalah pengkodean baru - baru ini dialami selama pembicaraan Obama di Twitter .

Ini sangat menjengkelkan ketika muncul di tempat-tempat yang sulit di-debug atau ketika pengujian diabaikan. Jadi yang terbaik adalah menghindarinya kecuali Anda harus menggunakannya.

Pertanyaan: Apa perbedaan antara UTF-8 dan UTF-8 tanpa BOM? Mana yang lebih baik?

Berikut adalah beberapa kutipan dari artikel Wikipedia tentang byte order mark (BOM) yang saya percaya menawarkan jawaban yang kuat untuk pertanyaan ini.

Tentang arti BOM dan UTF-8:

Standar Unicode mengizinkan BOM di UTF-8 , tetapi tidak mengharuskan atau merekomendasikan penggunaannya. Urutan byte tidak memiliki arti dalam UTF-8, jadi hanya digunakan dalam UTF-8 untuk memberi sinyal pada awal bahwa aliran teks dikodekan dalam UTF-8.

Argumen untuk TIDAK menggunakan BOM:

Motivasi utama untuk tidak menggunakan BOM adalah kompatibilitas ke belakang dengan perangkat lunak yang tidak menyadari Unicode ... Motivasi lain untuk tidak menggunakan BOM adalah untuk mendorong UTF-8 sebagai pengkodean "default".

Argumen UNTUK menggunakan BOM:

Argumen untuk menggunakan BOM adalah bahwa tanpa itu, analisis heuristik diperlukan untuk menentukan karakter pengkodean file apa yang digunakan. Secara historis analisis tersebut, untuk membedakan berbagai pengkodean 8-bit, rumit, rawan kesalahan, dan terkadang lambat. Sejumlah perpustakaan tersedia untuk memudahkan tugas, seperti Mozilla Universal Charset Detector dan International Components for Unicode.

Programmer secara keliru menganggap bahwa deteksi UTF-8 sama sulitnya (itu bukan karena sebagian besar urutan byte tidak sah UTF-8, sedangkan pengkodean perpustakaan ini mencoba untuk membedakan memungkinkan semua urutan byte yang mungkin). Oleh karena itu tidak semua program yang menyadari Unicode melakukan analisis seperti itu dan sebagai gantinya mengandalkan BOM.

Secara khusus, Microsoft kompiler dan juru bahasa , dan banyak perangkat lunak pada Microsoft Windows seperti Notepad tidak akan dengan benar membaca teks UTF-8 kecuali ia hanya memiliki karakter ASCII atau dimulai dengan BOM, dan akan menambah BOM sebagai permulaan saat menyimpan teks sebagai UTF-8. Google Documents akan menambahkan BOM ketika dokumen Microsoft Word diunduh sebagai file teks biasa.

Di mana lebih baik, DENGAN atau TANPA BOM:

The IETF merekomendasikan bahwa jika protokol (a) selalu menggunakan UTF-8, atau (b) memiliki cara lain untuk menunjukkan apa encoding yang digunakan, maka “HARUS melarang penggunaan U + FEFF sebagai tanda tangan.”

Kesimpulan saya:

Gunakan BOM hanya jika kompatibilitas dengan aplikasi perangkat lunak sangat penting.

Juga perhatikan bahwa sementara artikel Wikipedia yang direferensikan menunjukkan bahwa banyak aplikasi Microsoft mengandalkan BOM untuk mendeteksi UTF-8 dengan benar, ini tidak berlaku untuk semua aplikasi Microsoft. Misalnya, seperti keluar menunjuk oleh @barlop , ketika menggunakan Windows Command Prompt dengan UTF-8 ^† , perintah tersebut typedan moretidak mengharapkan BOM untuk hadir. Jika BOM adalah hadir, itu dapat menjadi masalah karena untuk aplikasi lain.

† chcpPerintah ini menawarkan dukungan untuk UTF-8 ( tanpa BOM) melalui halaman kode 65001 .

Pertanyaan ini sudah memiliki jutaan jawaban dan banyak dari mereka cukup bagus, tetapi saya ingin mencoba dan mengklarifikasi kapan BOM harus atau tidak boleh digunakan.

Seperti disebutkan, setiap penggunaan UTF BOM (Byte Order Mark) dalam menentukan apakah suatu string adalah UTF-8 atau bukan merupakan tebakan yang dididik. Jika ada metadata yang tepat tersedia (seperti charset="utf-8"), maka Anda sudah tahu apa yang seharusnya Anda gunakan, tetapi jika tidak, Anda harus menguji dan membuat beberapa asumsi. Ini melibatkan memeriksa apakah file suatu string berasal dimulai dengan kode byte heksadesimal, EF BB BF.

Jika kode byte yang sesuai dengan BOM UTF-8 ditemukan, probabilitasnya cukup tinggi untuk menganggapnya UTF-8 dan Anda dapat pergi dari sana. Namun, ketika dipaksa untuk membuat perkiraan ini, pengecekan kesalahan tambahan saat membaca masih merupakan ide bagus jika ada sesuatu yang kacau. Anda seharusnya hanya menganggap BOM bukan UTF-8 (yaitu latin-1 atau ANSI) jika inputnya tidak boleh UTF-8 berdasarkan sumbernya. Namun, jika tidak ada BOM, Anda bisa menentukan apakah itu seharusnya UTF-8 dengan memvalidasi terhadap penyandian.

Mengapa BOM tidak direkomendasikan?

1. Perangkat lunak yang tidak sadar Unicode atau tidak patuh dapat menganggap itu latin-1 atau ANSI dan tidak akan menghapus BOM dari string, yang jelas dapat menyebabkan masalah.
2. Ini tidak benar-benar diperlukan (cukup periksa apakah kontennya sesuai dan selalu gunakan UTF-8 sebagai cadangan ketika tidak ada pengodean yang sesuai dapat ditemukan)

Kapan sebaiknya Anda menyandikan dengan BOM?

Jika Anda tidak dapat merekam metadata dengan cara lain (melalui tag charset atau sistem file meta), dan program yang digunakan seperti BOM, Anda harus menyandikannya dengan BOM. Ini terutama benar pada Windows di mana segala sesuatu tanpa BOM umumnya dianggap menggunakan halaman kode warisan. BOM memberi tahu program seperti Office bahwa, ya, teks dalam file ini adalah Unicode; inilah pengkodean yang digunakan.

Ketika sampai pada itu, satu-satunya file yang pernah saya benar-benar mengalami masalah adalah CSV. Tergantung pada programnya, ia harus, atau tidak boleh memiliki BOM. Misalnya, jika Anda menggunakan Excel 2007+ di Windows, itu harus dikodekan dengan BOM jika Anda ingin membukanya dengan lancar dan tidak perlu menggunakan impor data.

Perlu dicatat bahwa untuk beberapa file Anda tidak harus memiliki BOM bahkan pada Windows. Contohnya adalah SQL*plusatau VBScriptfile. Seandainya file tersebut berisi BOM Anda mendapatkan kesalahan saat Anda mencoba untuk mengeksekusinya.

UTF-8 dengan BOM hanya membantu jika file tersebut sebenarnya mengandung beberapa karakter non-ASCII. Jika disertakan dan tidak ada, maka itu mungkin akan merusak aplikasi yang lebih tua yang seharusnya menafsirkan file tersebut sebagai ASCII biasa. Aplikasi ini pasti akan gagal ketika mereka menemukan karakter non ASCII, jadi menurut saya BOM hanya boleh ditambahkan ketika file dapat, dan seharusnya, tidak lagi ditafsirkan sebagai ASCII biasa.

Saya ingin menjelaskan bahwa saya memilih untuk tidak memiliki BOM sama sekali. Tambahkan jika ada sampah lama rusak tanpa itu, dan mengganti aplikasi warisan tidak layak.

Jangan membuat apa pun mengharapkan BOM untuk UTF-8.

Dikutip di bagian bawah halaman Wikipedia di BOM: http://en.wikipedia.org/wiki/Byte-order_mark#cite_note-2

"Penggunaan BOM tidak diperlukan atau direkomendasikan untuk UTF-8, tetapi dapat ditemui dalam konteks di mana data UTF-8 dikonversi dari bentuk penyandian lain yang menggunakan BOM atau di mana BOM digunakan sebagai tanda tangan UTF-8"

UTF-8 tanpa BOM tidak memiliki BOM, yang tidak membuatnya lebih baik daripada UTF-8 dengan BOM, kecuali ketika konsumen file perlu tahu (atau akan mendapat manfaat dari mengetahui) apakah file tersebut dikodekan UTF-8. atau tidak.

BOM biasanya berguna untuk menentukan endianness dari pengkodean, yang tidak diperlukan untuk sebagian besar kasus penggunaan.

Juga, BOM dapat menjadi kebisingan / rasa sakit yang tidak perlu bagi konsumen yang tidak tahu atau peduli tentang hal itu, dan dapat menyebabkan kebingungan pengguna.

Saya melihat ini dari sudut pandang yang berbeda. Saya pikir UTF-8 dengan BOM lebih baik karena memberikan informasi lebih lanjut tentang file tersebut. Saya menggunakan UTF-8 tanpa BOM hanya jika saya menghadapi masalah.

Saya menggunakan banyak bahasa (bahkan Cyrillic ) di halaman saya untuk waktu yang lama dan ketika file disimpan tanpa BOM dan saya buka kembali untuk diedit dengan editor (seperti cherouvim dicatat oleh ), beberapa karakter rusak.

Perhatikan bahwa Notepad klasik Windows secara otomatis menyimpan file dengan BOM ketika Anda mencoba menyimpan file yang baru dibuat dengan pengkodean UTF-8.

Saya pribadi menyimpan file skrip sisi server (.asp, .ini, .aspx) dengan file BOM dan .html tanpa BOM .

Saat Anda ingin menampilkan informasi yang dikodekan dalam UTF-8 Anda mungkin tidak menghadapi masalah. Deklarasikan misalnya dokumen HTML sebagai UTF-8 dan Anda akan memiliki semua yang ditampilkan di browser Anda yang terkandung dalam badan dokumen.

Tapi ini tidak terjadi ketika kita memiliki teks, CSV file dan XML, baik di Windows atau Linux.

Misalnya, file teks di Windows atau Linux, salah satu hal termudah yang bisa dibayangkan, itu bukan (biasanya) UTF-8.

Simpan sebagai XML dan nyatakan sebagai UTF-8:

<?xml version="1.0" encoding="UTF-8"?>

Itu tidak akan ditampilkan (tidak akan dibaca) dengan benar, bahkan jika itu dinyatakan sebagai UTF-8.

Saya memiliki serangkaian data yang berisi surat-surat Prancis, yang perlu disimpan sebagai XML untuk sindikasi. Tanpa membuat file UTF-8 dari awal (mengubah opsi di IDE dan "Buat File Baru") atau menambahkan BOM di awal file

$file="\xEF\xBB\xBF".$string;

Saya tidak dapat menyimpan huruf Prancis dalam file XML.

Satu perbedaan praktis adalah bahwa jika Anda menulis skrip shell untuk Mac OS X dan menyimpannya sebagai UTF-8, Anda akan mendapatkan respons:

#!/bin/bash: No such file or directory

sebagai tanggapan terhadap garis shebang yang menentukan shell mana yang ingin Anda gunakan:

#!/bin/bash

Jika Anda menyimpan sebagai UTF-8, tidak ada BOM (katakanlah di BBEdit ) semua akan baik-baik saja.

Seperti disebutkan di atas, UTF-8 dengan BOM dapat menyebabkan masalah dengan perangkat lunak yang tidak sadar BOM (atau kompatibel). Saya pernah mengedit file HTML yang dikodekan sebagai UTF-8 + BOM dengan KompoZer berbasis Mozilla , sebagai klien mengharuskan WYSIWYG program .

Tata letak akan hancur saat menyimpan. Butuh beberapa waktu untuk bermain-main dengan ini. File-file ini kemudian bekerja dengan baik di Firefox, tetapi menunjukkan kekhasan CSS di Internet Explorer, menghancurkan tata letak, lagi. Setelah mengutak-atik file CSS yang terhubung selama berjam-jam tidak berhasil saya menemukan bahwa Internet Explorer tidak menyukai file HTML BOMfed. Tidak akan lagi.

Juga, saya baru saja menemukan ini di Wikipedia:

Karakter shebang diwakili oleh dua byte yang sama dalam pengkodean ASCII yang diperluas, termasuk UTF-8, yang biasanya digunakan untuk skrip dan file teks lainnya pada sistem seperti Unix saat ini. Namun, file UTF-8 dapat dimulai dengan tanda urutan byte opsional (BOM); jika fungsi "exec" secara khusus mendeteksi byte 0x23 0x21, maka keberadaan BOM (0xEF 0xBB 0xBF) sebelum shebang akan mencegah penerjemah skrip dieksekusi. Beberapa otoritas merekomendasikan untuk tidak menggunakan tanda urutan byte dalam skrip POSIX (seperti Unix), [15] karena alasan ini dan untuk interoperabilitas yang lebih luas dan masalah filosofis

FAQ Unicode Byte Order Mark (BOM) memberikan jawaban singkat:

T: Bagaimana saya harus berurusan dengan BOM?

A: Berikut adalah beberapa panduan untuk diikuti:

1. Protokol tertentu (misalnya, konvensi Microsoft untuk file .txt) mungkin memerlukan penggunaan BOM pada aliran data Unicode tertentu, seperti file. Saat Anda perlu menyesuaikan diri dengan protokol semacam itu, gunakan BOM.

2. Beberapa protokol memungkinkan BOM opsional dalam kasus teks yang tidak ditandai. Dalam kasus itu,

   • Di mana aliran data teks dikenal sebagai teks biasa, tetapi dari pengkodean yang tidak diketahui, BOM dapat digunakan sebagai tanda tangan. Jika tidak ada BOM, pengodeannya bisa apa saja.

   • Di mana aliran data teks dikenal sebagai teks Unicode biasa (tapi bukan yang endian), maka BOM dapat digunakan sebagai tanda tangan. Jika tidak ada BOM, teks harus ditafsirkan sebagai big-endian.

3. Beberapa protokol berorientasi byte mengharapkan karakter ASCII di awal file. Jika UTF-8 digunakan dengan protokol-protokol ini, penggunaan BOM sebagai tanda tangan formulir pengkodean harus dihindari.

4. Jika jenis aliran data yang tepat diketahui (mis. Unicode big-endian atau Unicode little-endian), BOM tidak boleh digunakan. Secara khusus, setiap kali aliran data dinyatakan sebagai UTF-16BE, UTF-16LE, UTF-32BE atau UTF-32LE, BOM tidak boleh digunakan.

Dari http://en.wikipedia.org/wiki/Byte-order_mark :

Tanda urutan byte (BOM) adalah karakter Unicode yang digunakan untuk memberi sinyal endianness (urutan byte) dari file teks atau aliran. Titik kodenya adalah U + FEFF. Penggunaan BOM adalah opsional, dan, jika digunakan, akan muncul di awal aliran teks. Di luar penggunaan spesifiknya sebagai indikator urutan-byte, karakter BOM juga dapat menunjukkan representasi Unicode mana yang dikodekan dalam teks.

Selalu menggunakan BOM dalam file Anda akan memastikan bahwa selalu terbuka dengan benar di editor yang mendukung UTF-8 dan BOM.

Masalah sebenarnya saya dengan tidak adanya BOM adalah sebagai berikut. Misalkan kita punya file yang berisi:

abc

Tanpa BOM ini terbuka sebagai ANSI di sebagian besar editor. Jadi pengguna lain dari file ini membukanya dan menambahkan beberapa karakter asli, misalnya:

abg-αβγ

Ups ... Sekarang file tersebut masih dalam ANSI dan coba tebak, "αβγ" tidak menempati 6 byte, tetapi 3. Ini bukan UTF-8 dan ini menyebabkan masalah lain di rantai pengembangan selanjutnya.

Berikut adalah pengalaman saya dengan permintaan tarik Visual Studio, Sourcetree dan Bitbucket, yang telah memberi saya beberapa masalah:

Jadi ternyata BOM dengan tanda tangan akan menyertakan karakter titik merah pada setiap file ketika meninjau permintaan tarik (itu bisa sangat menjengkelkan).

Jika Anda mengarahkannya, itu akan menampilkan karakter seperti "ufeff", tetapi ternyata Sourcetree tidak menunjukkan jenis bytemark ini, sehingga kemungkinan besar akan berakhir pada permintaan tarik Anda, yang seharusnya baik karena itulah bagaimana Visual Studio 2017 mengkodekan file baru sekarang, jadi mungkin Bitbucket harus mengabaikan ini atau membuatnya tampil dengan cara lain, info lebih lanjut di sini:

Penanda titik merah tampilan diff BitBucket

UTF dengan BOM lebih baik jika Anda menggunakan UTF-8 dalam file HTML dan jika Anda menggunakan Bahasa Serbia, Bahasa Latin Serbia, Bahasa Jerman, Bahasa Hongaria atau bahasa eksotik pada halaman yang sama.

Itulah pendapat saya (30 tahun industri komputasi dan TI).