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


818

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


77
UTF-8 dapat dideteksi secara otomatis dengan konten yang lebih baik daripada dengan BOM. Metode ini sederhana: cobalah membaca file (atau string) sebagai UTF-8 dan jika itu berhasil, anggaplah bahwa datanya adalah UTF-8. Kalau tidak asumsikan bahwa itu adalah CP1252 (atau penyandian 8 bit lainnya). Pengkodean delapan bit non-UTF-8 hampir pasti akan berisi urutan yang tidak diizinkan oleh UTF-8. Pure ASCII (7 bit) ditafsirkan sebagai UTF-8, tetapi hasilnya juga benar.
Tronic

39
Memindai file besar untuk konten UTF-8 membutuhkan waktu. BOM membuat proses ini lebih cepat. Dalam praktiknya Anda sering perlu melakukan keduanya. Pelakunya saat ini adalah bahwa masih banyak konten teks bukan Unicode, dan saya masih menemukan alat yang mengatakan mereka melakukan Unicode (misalnya UTF-8) tetapi memancarkan konten mereka dengan codepage yang berbeda.
Jeroen Wiert Pluimers

10
@Tronic Saya tidak benar-benar berpikir bahwa "lebih baik" cocok dalam kasus ini. Itu tergantung lingkungan. Jika Anda yakin bahwa semua file UTF-8 ditandai dengan BOM daripada memeriksa BOM adalah cara yang "lebih baik" , karena lebih cepat dan lebih dapat diandalkan.
mg30rg

32
UTF-8 tidak memiliki BOM. Saat Anda meletakkan titik kode U + FEFF di awal file UTF-8, perhatian khusus harus diberikan untuk mengatasinya. Ini hanyalah salah satu kebohongan penamaan Microsoft, seperti memanggil pengkodean "Unicode" ketika tidak ada hal seperti itu.
tchrist

7
"Mainframe modern (dan AIX) sedikit sadar UTF-8 " UTF-8 tidak memiliki akhiran ! tidak ada pengocokan byte untuk menempatkan pasangan atau kelompok empat ke dalam "urutan" yang tepat untuk sistem tertentu! Untuk mendeteksi urutan UTF-8 byte mungkin berguna untuk mencatat bahwa byte pertama dari urutan multi-byte "codepoint" (byte yang BUKAN yang "biasa" ASCII) memiliki bit MS set dan semua satu hingga tiga lagi. bit berturut-turut kurang signifikan diikuti oleh bit reset. Jumlah total set bit tersebut adalah satu byte lebih sedikit yang ada dalam codepoint itu dan mereka SEMUA akan memiliki set MSB ...
SlySven

Jawaban:


773

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.


114
Ini mungkin tidak direkomendasikan tetapi dari pengalaman saya dalam konversi bahasa Ibrani, BOM terkadang penting untuk pengenalan UTF-8 di Excel, dan mungkin membuat perbedaan antara Jibrish dan Ibrani
Matanya

26
Ini mungkin tidak direkomendasikan tetapi memang membuat keajaiban pada skrip powershell saya ketika mencoba menampilkan "æøå"
Marius

63
Terlepas dari itu tidak direkomendasikan oleh standar, itu diperbolehkan, dan saya lebih suka memiliki sesuatu untuk bertindak sebagai tanda tangan UTF-8 daripada alternatif asumsi atau tebakan. Perangkat lunak yang kompatibel dengan Unicode harus / harus mampu menangani kehadirannya, jadi saya pribadi mendorong penggunaannya.
martineau

30
@ bames53: Ya, di dunia yang ideal menyimpan penyandian file teks sebagai metadata sistem file akan menjadi cara yang lebih baik untuk melestarikannya. Tetapi kebanyakan dari kita yang hidup di dunia nyata tidak dapat mengubah sistem file OS (s) program kita dijalankan - jadi menggunakan tanda tangan BOM platform-independen standar Unicode tampaknya seperti IMHO alternatif terbaik dan paling praktis.
martineau

34
@martineau Baru kemarin saya menemukan file dengan UTF-8 BOM yang bukan UTF-8 (itu CP936). Apa yang disayangkan adalah bahwa mereka yang bertanggung jawab atas sejumlah besar rasa sakit yang disebabkan oleh BOM UTF-8 sebagian besar tidak mengetahuinya.
bames53

243

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:

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.


60
@Alcott: Anda mengerti dengan benar. String [EF BB BF 41 42 43] hanya sekelompok byte. Anda memerlukan informasi eksternal untuk memilih cara menafsirkannya. Jika Anda yakin byte tersebut dikodekan menggunakan ISO-8859-1, maka stringnya adalah "ï» ¿ABC ". Jika Anda yakin byte tersebut dikodekan menggunakan UTF-8, maka itu adalah "ABC". Jika Anda tidak tahu, maka Anda harus berusaha mencari tahu. BOM bisa menjadi petunjuk. Tidak adanya karakter yang tidak valid ketika diterjemahkan sebagai UTF-8 bisa menjadi yang lain ... Pada akhirnya, kecuali Anda dapat menghafal / menemukan pengkodean entah bagaimana, array byte hanyalah sebuah array byte.
paercebal

19
@paercebal Sementara "ï» ¿"valid latin-1, sangat tidak mungkin file teks dimulai dengan kombinasi itu. Hal yang sama berlaku untuk marker ucs2-le / be ÿþ dan þÿ. Anda juga tidak akan pernah tahu.
user877329

16
@menerima Ini mungkin tidak secara bahasa: Pertama ï (yang ok), lalu beberapa tanda kutip tanpa spasi di antara (tidak ok). ¿Menunjukkan itu bahasa Spanyol tetapi ï tidak digunakan dalam bahasa Spanyol. Kesimpulan: Ini bukan latin-1 dengan kepastian jauh di atas kepastian tanpa itu.
user877329

20
@ Pengguna Tentu, itu tidak selalu masuk akal. Tetapi jika sistem Anda bergantung pada menebak , di situlah ketidakpastian masuk. Beberapa pengguna jahat mengirimkan teks yang dimulai dengan 3 huruf ini dengan sengaja, dan sistem Anda tiba-tiba menganggap sedang melihat UTF-8 dengan BOM, memperlakukan teks sebagai UTF-8 di mana harus menggunakan Latin-1, dan beberapa injeksi Unicode dilakukan. Hanya contoh hipotetis, tetapi tentu saja mungkin. Anda tidak dapat menilai pengkodean teks berdasarkan isinya, titik.
tipuan

40
"Pengkodean harus diketahui, bukan diramalkan." Hati dan jiwa dari masalah. +1, tuan yang baik. Dengan kata lain: lakukan standarisasi konten Anda dan katakan, "Kami selalu menggunakan penyandian ini. Periode. Tulis dengan cara itu. Baca seperti itu," atau kembangkan format yang diperluas yang memungkinkan untuk menyimpan penyandian sebagai metadata. (Yang terakhir mungkin membutuhkan beberapa "bootstrap standard encoding," juga. Seperti mengatakan "Bagian yang memberitahu Anda bahwa encoding selalu ASCII.")
jpmc26

135

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.

8
Poin 1 "File yang tidak mengandung teks tidak lagi kosong karena selalu mengandung BOM", ini (1) mengonfigurasi level sistem file OS dengan level konten yang diinterpretasikan, ditambah lagi (2) salah berasumsi bahwa menggunakan BOM seseorang harus meletakkan BOM juga di setiap file yang kosong. Solusi praktis untuk (1) adalah tidak melakukan (2). Pada dasarnya keluhan mengurangi menjadi "mungkin untuk secara tidak praktis menempatkan BOM dalam file yang kosong, sehingga mencegah deteksi yang paling mudah dari file yang kosong secara logis (dengan memeriksa ukuran file)". Perangkat lunak yang baik tetap harus dapat menghadapinya, karena ia memiliki tujuan.
Ceria dan hth. - Alf

7
Poin 2, "File yang menahan teks ASCII bukan lagi ASCII sendiri", ini mengonfigurasi ASCII dengan UTF-8. File UTF-8 yang menyimpan teks ASCII bukan ASCII, itu UTF-8. Demikian pula, file UTF-16 yang menyimpan teks ASCII bukan ASCII, itu UTF-16. Dan seterusnya. ASCII adalah kode byte tunggal 7-bit. UTF-8 adalah ekstensi panjang variabel 8-bit dari ASCII. Jika "alat mogok" karena nilai> 127 maka mereka tidak cocok untuk dunia 8-bit. Salah satu solusi praktis yang sederhana adalah dengan hanya menggunakan file ASCII dengan alat yang memecah untuk nilai byte non-ASCII. Solusi yang mungkin lebih baik adalah membuang alat-alat yang tidak baik itu.
Ceria dan hth. - Alf

8
Poin 3, "Tidak mungkin untuk menggabungkan beberapa file bersama karena setiap file sekarang memiliki BOM di awal" hanya salah. Saya tidak punya masalah menggabungkan file UTF-8 dengan BOM, jadi sangat mungkin. Saya pikir mungkin Anda maksudkan tanah Unix cattidak akan memberi Anda hasil bersih , hasil yang memiliki BOM hanya pada awalnya. Jika Anda bermaksud demikian, maka itu karena catbekerja pada level byte, bukan pada level konten yang ditafsirkan, dan dengan cara yang sama cattidak dapat menangani foto, katakanlah. Tetap saja tidak banyak merugikan. Itu karena BOM mengkodekan nol-lebar ruang tanpa melanggar.
Ceria dan hth. - Alf

20
@ Cheersandhth.-Alf Jawaban ini benar. Anda hanya menunjukkan bug Microsoft.
tchrist

9
@ brighty: Situasinya tidak membaik dengan menambahkan bom sekalipun.
Deduplicator

84

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.


5
rfc7159 yang menggantikan rfc4627 sebenarnya menunjukkan mendukung BOM mungkin tidak begitu jahat. Pada dasarnya tidak memiliki BOM hanyalah sebuah ambigu ambigu sehingga Windows lama dan perangkat lunak Unix yang tidak sadar Unicode masih dapat memproses utf-8.
Eric Grange

2
Kedengarannya seperti JSON perlu memperbarui untuk mendukungnya, sama dengan skrip Perl, skrip Python, skrip Ruby, Node.js. Hanya karena platform ini memilih untuk tidak menyertakan dukungan, tidak serta merta mematikan penggunaan untuk BOM. Apple telah mencoba untuk membunuh Adobe selama beberapa tahun sekarang, dan Adobe masih ada. Tapi pos yang mencerahkan.
htm11h

13
@EricGrange, Anda tampaknya sangat mendukung BOM, tetapi gagal untuk menyadari bahwa ini akan membuat semua format "teks biasa" yang serba ada, yang secara universal berguna, optimal-minimum, menjadi peninggalan masa lalu pra-UTF8! Menambahkan segala jenis header (dalam-band) ke aliran teks biasa , menurut definisi, akan memaksakan protokol wajib ke file teks paling sederhana, menjadikannya tidak pernah lagi "paling sederhana"! Dan untuk apa untungnya? Untuk mendukung yang lainnya , penyandian CP kuno yang juga tidak memiliki tanda tangan, jadi Anda mungkin salah mengartikannya dengan UTF-8? (BTW, ASCII juga UTF-8. Jadi, BOM juga untuk mereka?;) Ayo.)
Sz.

2
Jawaban ini adalah alasan mengapa saya sampai pada pertanyaan ini! Saya membuat skrip bash saya di Windows dan mengalami banyak masalah saat menerbitkan skrip tersebut ke Linux! Hal yang sama dengan file jason.
Tono Nam

2
Saya berharap saya dapat memilih jawaban ini sekitar lima puluh kali. Saya juga ingin menambahkan bahwa pada titik ini, UTF-8 telah memenangkan perang standar, dan hampir semua teks yang diproduksi di Internet adalah UTF-8. Beberapa bahasa pemrograman paling populer (seperti C # dan Java) menggunakan UTF-16 secara internal, tetapi ketika para programmer yang menggunakan bahasa-bahasa itu menulis file ke stream stream, mereka hampir selalu menyandikannya sebagai UTF-8. Oleh karena itu, tidak lagi masuk akal untuk memiliki BOM untuk menandai file UTF-8; UTF-8 harus menjadi default yang Anda gunakan saat membaca, dan hanya mencoba penyandian lain jika decoding UTF-8 gagal.
rmunn

51

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.


8
ini juga akan membatalkan valid UTF-8 dengan satu byte yang salah di dalamnya, meskipun: /
endolith

8
-1 re "Ini menyebabkan masalah dengan perangkat lunak yang tidak sadar-BOM.", Itu tidak pernah menjadi masalah bagi saya, tetapi sebaliknya, tidak adanya BOM menyebabkan masalah dengan perangkat lunak yang sadar-BOM (khususnya Visual C ++) telah menjadi masalah. Jadi pernyataan ini sangat spesifik platform , sudut pandang Unix-land yang sempit, tetapi disajikan secara keliru seolah-olah itu berlaku secara umum. Yang mana tidak.
Ceria dan hth. - Alf

6
Tidak, UTF-8 tidak memiliki BOM. Jawaban ini salah. Lihat Standar Unicode.
tchrist

2
Anda bahkan dapat berpikir Anda memiliki file ASCII murni ketika hanya melihat byte. Tapi ini bisa berupa file utf-16 juga di mana Anda harus melihat kata-kata dan bukan pada byte. Perangkat lunak modern harus menyadari tentang BOM. Masih membaca utf-8 dapat gagal jika mendeteksi urutan tidak valid, codepoint yang dapat menggunakan urutan yang lebih kecil atau codepoint yang merupakan pengganti. Untuk utf-16 membaca mungkin gagal juga ketika ada pengganti yatim.
brighty

1
@Alf, saya tidak setuju dengan interpretasi Anda tentang sikap non-BOM sebagai " platform-spesifik , sudut pandang Unix-land yang sempit." Bagi saya, satu-satunya cara yang sempit itu bisa berbohong dengan "Unix land" adalah jika MS dan Visual C ++ datang sebelum * NIX, yang tidak. Fakta bahwa MS (saya asumsikan sadar) mulai menggunakan BOM dalam UTF-8 bukan UTF-16 menunjukkan kepada saya bahwa mereka dipromosikan melanggar sh, perl,g++ dan banyak alat bebas dan kuat, lainnya. Ingin semuanya bekerja? Beli saja versi MS. MS menciptakan masalah khusus platform, seperti halnya bencana pada rentang \ x80- \ x95 mereka.
bballdave025

30

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 )


6
Terima kasih atas tip yang luar biasa ini seandainya seseorang membuat file UTF-8 untuk digunakan oleh Excel. Namun dalam keadaan lain, saya masih akan mengikuti jawaban lain dan melewati BOM.
barfuin

5
Ini juga berguna jika Anda membuat file yang hanya mengandung ASCII dan nantinya mungkin ditambahkan non-ascii. Saya baru saja mengalami masalah seperti itu: perangkat lunak yang mengharapkan utf8, membuat file dengan beberapa data untuk diedit pengguna. Jika file awal hanya berisi ASCII, dibuka di beberapa editor dan kemudian disimpan, berakhir di latin-1 dan semuanya rusak. Jika saya menambahkan BOM, itu akan terdeteksi sebagai UTF8 oleh editor dan semuanya berfungsi.
Roberto Alsina

1
Saya telah menemukan beberapa alat terkait pemrograman yang membutuhkan BOM untuk mengenali file UTF-8 dengan benar. Visual Studio, SSMS, SoureTree ....
kjbartel

5
Di mana Anda membaca rekomendasi untuk menggunakan BOM ke dalam RFC itu? Paling-paling, ada rekomendasi kuat untuk tidak melarangnya dalam keadaan tertentu di mana hal itu sulit.
Deduplicator

8
Excel berpikir itu ANSI dan menunjukkan omong kosong maka masalahnya ada di Excel.
Isaac

17

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.


Ya, hanya menghabiskan waktu berjam-jam mengidentifikasi masalah yang disebabkan oleh file yang dikodekan sebagai UTF-8 bukannya UTF-8 tanpa BOM. (Masalahnya hanya muncul di IE7 sehingga membawa saya pada pengejaran yang cukup angsa. Saya menggunakan Django "termasuk".)
user984003

Pembaca masa depan: Perhatikan bahwa masalah tweet yang saya sebutkan di atas tidak sepenuhnya terkait dengan BOM, tetapi jika itu, maka tweet akan kacau dengan cara yang sama, tetapi pada awal tweet.
Halil Özgür

12
@ user984003 Tidak, masalahnya adalah Microsoft telah menyesatkan Anda. Apa yang disebutnya UTF-8 bukan UTF-8. Apa yang disebutnya UTF-8 tanpa BOM adalah apa sebenarnya UTF-8.
tchrist

apa yang ditambahkan "sic" ke "no pun intended"
JoelFan

2
@ JoelFan Saya tidak bisa mengingat lagi, tapi saya kira permainan kata-katanya mungkin dimaksudkan meskipun ada klaim penulis :)
Halil Özgür

17

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 .


5
Lebih baik aku tegas pada TANPA BOM . Saya menemukan bahwa .htaccessdan gzip compressiondalam kombinasi dengan UTF-8 BOM memberikan kesalahan pengkodean Ubah ke Pengkodean di UTF-8 tanpa BOM mengikuti saran seperti yang dijelaskan di sini menyelesaikan masalah
Chetabahana

1
'Motivasi lain untuk tidak menggunakan BOM adalah untuk mendorong UTF-8 sebagai pengkodean "default".'- Argumen yang sangat kuat & valid, sehingga Anda bisa benar-benar menghentikan jawaban di sana! ...; -o Kecuali Anda punya ide yang lebih baik untuk representasi teks universal, yaitu. ;) (Saya tidak tahu berapa usia Anda, berapa tahun Anda harus menderita di era pra-UTF8 (ketika ahli bahasa dengan putus asa mempertimbangkan bahkan mengubah huruf mereka), tetapi saya dapat memberi tahu Anda bahwa setiap detik kita semakin dekat dengan penghapusan kekacauan semua pengkodean byte-tunggal-tanpa-metadata kuno, alih-alih memiliki "yang" adalah sukacita murni.)
Sz.

Lihat juga komentar ini tentang cara menambahkan BOM (atau apa pun!) Ke format file teks yang paling sederhana, "teks biasa", berarti mencegah persis format penyandian teks universal terbaik dari menjadi "biasa", dan "sederhana" (yaitu "overheadless")! ...
Sz.

BOM sebagian besar bermasalah di Linux karena banyak utilitas tidak benar-benar mendukung Unicode untuk memulainya (mereka dengan senang hati akan memotong di tengah codepoints misalnya). Untuk sebagian besar lingkungan perangkat lunak modern lainnya, gunakan BOM setiap kali pengkodean tidak ambigu (melalui spesifikasi atau metadata).
Eric Grange

9

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.


2
Bagian terakhir dari jawaban Anda adalah 100% benar: satu - satunya alasan untuk menggunakan BOM adalah ketika Anda harus beroperasi dengan perangkat lunak buggy yang tidak menggunakan UTF-8 sebagai standarnya untuk mem-parsing file yang tidak dikenal.
rmunn

8

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.


8

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.


7

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"


2
Apakah Anda memiliki contoh di mana perangkat lunak membuat keputusan apakah akan menggunakan UTF-8 dengan / tanpa BOM, berdasarkan pada apakah pengkodean sebelumnya adalah pengkodean, memiliki BOM atau tidak ?! Itu seperti klaim yang absurd
barlop

7

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.


2
"Yang tidak digunakan untuk UTF-8 karena itu adalah 8-bit per mesin terbang." Eh ... tidak, hanya ASCII-7 mesin terbang yang 8-bit dalam UTF-8. Apa pun di luar itu akan menjadi 16, 24, atau 32 bit.
Powerlord

3
"BOM biasanya berguna untuk menentukan endianness dari encoding, yang tidak diperlukan untuk sebagian besar kasus penggunaan." ... endianness tidak berlaku untuk UTF-8, terlepas dari use case
JoelFan

6

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 .


4
Terima kasih atas tip luar biasa tentang Windows Notepad klasik. Saya sudah menghabiskan waktu mencari tahu hal yang persis sama. Konsekuensi saya adalah untuk selalu menggunakan Notepad ++ daripada Windows klasik Notepad. :-)
barfuin

Anda lebih baik menggunakan madedit. Ini satu-satunya Editor yang - dalam mode hex - menunjukkan satu karakter jika Anda memilih urutan utf-8 byte bukannya 1: 1 Dasar antara byte dan karakter. Hex-Editor yang mengetahui tentang file UTF-8 seharusnya sudah seperti madedit!
brighty

@ brighty Saya tidak berpikir Anda perlu 1-1 demi BOM. tidak masalah, tidak perlu banyak untuk mengenali BOM utf-8 adalah efbbbf atau fffe (dari fffe jika dibaca salah). Seseorang dapat dengan mudah menghapus byte-byte itu. Ini tidak buruk meskipun memiliki pemetaan untuk sisa file, tetapi juga dapat menghapus byte demi byte juga
barlop

@barlop Mengapa Anda ingin menghapus BOM utf-8 jika konten file disandikan utf-8? BOM dikenali oleh Penampil Teks modern, Kontrol Teks serta Editor Teks. Tampilan satu ke satu dari urutan utf-8 tidak masuk akal, karena n byte menghasilkan satu karakter. Tentu saja editor teks atau hex editor harus mengizinkan untuk menghapus byte apa pun, tetapi ini dapat menyebabkan urutan utf-8 yang tidak valid.
brighty

@brighty utf-8 dengan bom adalah sebuah encoding, dan utf-8 tanpa bom adalah sebuah encoding. Permintaan cmd menggunakan utf8 tanpa bom .. jadi jika Anda memiliki file utf8, Anda menjalankan perintah chcp 65001untuk dukungan utf8, itu utf8 tanpa bom. Jika Anda melakukannya type myfilehanya akan ditampilkan dengan benar jika tidak ada bom. Jika Anda melakukan echo aaa>a.aatau echo אאא>a.a untuk mengeluarkan karakter ke file aa, dan Anda memiliki chcp 65001, itu akan dihasilkan tanpa BOM.
barlop

6

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.


1
FTM, dalam XML, saya pikir Anda harus menyimpan file sebagai ASCII dan menggunakan entitas .
Alois Mahdal

4
Saya tahu ini adalah jawaban lama, tetapi saya hanya ingin mengatakan bahwa itu salah. File teks di Linux (tidak dapat berbicara untuk Unix lain) biasanya / adalah / UTF-8.
Functino

6

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.


8
Itu karena Microsoft telah bertukar arti dari apa yang dikatakan standar. UTF-8 tidak memiliki BOM: mereka telah menciptakan Microsoft UTF-8 yang menyisipkan BOM palsu di depan aliran data dan kemudian memberi tahu Anda bahwa tidak, ini sebenarnya UTF-8. Bukan itu. Itu hanya memperluas dan merusak.
tchrist

4

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


4

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.


1

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.


9
Memastikan bahwa byte palsu muncul di awal perangkat lunak yang tidak sadar BOM. Yay.
Romain

1
@ Domain Muller: mis. PHP 5 akan menimbulkan kesalahan "tidak mungkin" ketika Anda mencoba mengirim header setelah BOM.
Piskvor meninggalkan gedung

5
αβγ bukan ascii, tetapi dapat muncul dalam pengkodean based 8bit-ascii. Penggunaan BOM menonaktifkan manfaat utf-8, kompatibilitasnya dengan ascii (kemampuan untuk bekerja dengan aplikasi lagacy di mana ascii murni digunakan).
ctrl-alt-delor

1
Ini jawaban yang salah. Tali dengan BOM di depannya adalah sesuatu yang lain. Seharusnya tidak ada di sana dan hanya mengacaukan semuanya.
tchrist

Tanpa BOM ini terbuka sebagai ANSI di sebagian besar editor. Saya setuju sepenuhnya. Jika ini terjadi, Anda beruntung jika Anda berurusan dengan Codepage yang benar tetapi memang itu hanya tebakan, karena Codepage bukan bagian dari file. BOM adalah.
brighty

1

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).

Masukkan deskripsi gambar di sini

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


-4

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).


1
Saya menemukan ini juga benar. Jika Anda menggunakan karakter di luar set ASCII 255 pertama dan Anda mengabaikan BOM, browser menafsirkannya sebagai ISO-8859-1 dan Anda mendapatkan karakter kacau. Mengingat jawaban di atas, ini tampaknya pada vendor browser melakukan hal yang salah ketika mereka tidak mendeteksi BOM. Tetapi kecuali jika Anda bekerja di Microsoft Edge / Mozilla / Webkit / Blink, Anda tidak punya pilihan selain bekerja dengan cacat yang dimiliki aplikasi ini.
asontu

UTF apa? UTF-8? UTF-16? Sesuatu yang lain
Peter Mortensen
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.