Malzeme Listesi olmadan UTF-8 ve UTF-8 arasındaki fark nedir?

Malzeme Listesi olmadan UTF-8 ve UTF-8 arasında ne fark vardır ? Hangisi daha iyi?

UTF-8 BOM, bir metin akışının ( ) başlangıcında , okuyucunun bir dosyayı UTF-8'de kodlanmış olarak daha güvenilir bir şekilde tahmin etmesini sağlayan bir bayt dizisidir 0xEF, 0xBB, 0xBF.

Normalde BOM , bir kodlamanın endianitesini belirtmek için kullanılır , ancak endianite UTF-8 ile alakasız olduğundan BOM gereksizdir.

Göre Unicode standardı , UTF-8 dosyaları için BOM tavsiye edilmez :

2.6 Kodlama Şemaları

... Malzeme Listesi'nin kullanımı ne UTF-8 için ne gerekli değildir, ne de tavsiye edilir, ancak UTF-8 verilerinin Malzeme Listesi kullanan diğer kodlama formlarından dönüştürüldüğü veya Malzeme Listesinin UTF-8 imzası olarak kullanıldığı bağlamlarda karşılaşılabilir. . Daha fazla bilgi için Bölüm 16.8'deki Özel ( Byte Order Mark) alt bölümüne bakınız .

Diğer mükemmel cevaplar zaten şunları yanıtladı:

• UTF-8 ve BOM-ed UTF-8 arasında resmi bir fark yoktur.
• Bir BOM-ed UTF-8 dizesi aşağıdaki üç baytla başlayacaktır. EF BB BF
• Varsa, bu baytlar dosya / akıştan dize çıkarılırken yoksayılmalıdır.

Ancak, buna ek bilgi olarak, UTF-8 için BOM, bir dize UTF-8'de kodlanmışsa "koklamak" için iyi bir yol olabilir ... Veya başka herhangi bir kodlamada meşru bir dize olabilir ...

Örneğin, [EF BB BF 41 42 43] verileri şunlardan biri olabilir:

• Meşru ISO-8859-1 dizesi "ï» ¿ABC "
• Meşru UTF-8 dizesi "ABC"

Bu nedenle, ilk baytlara bakarak bir dosya içeriğinin kodlamasını tanımak güzel olsa da, yukarıdaki örnekte gösterildiği gibi buna güvenmemelisiniz

Kodlamalar bilinmeli, ilahi değil.

UTF-8 kodlu dosyalara ürün ağacı koymanın en az üç sorunu vardır.

1. Metin içermeyen dosyalar artık her zaman ürün ağacı içerdiği için boş bırakılmaz.
2. UTF-8'in ASCII alt kümesinde bulunan metni içeren dosyalar artık ASCII değildir çünkü BOM, mevcut araçların bozulmasına neden olan ASCII değildir ve kullanıcıların bu tür eski araçları değiştirmeleri imkansız olabilir.
3. Her dosyanın başında bir malzeme listesi olduğundan, birkaç dosyayı birlikte birleştirmek mümkün değildir.

Diğerlerinin de belirttiği gibi, bir şeyin UTF-8 olduğunu tespit etmek için bir Malzeme Listesine sahip olmak ne yeterli ne de gerekli:

• Bu yeterli değildir, çünkü keyfi bir bayt sekansı Malzeme Listesini oluşturan tam sekansla başlayabilir.
• Gerekli değildir, çünkü baytları UTF-8miş gibi okuyabilirsiniz; başarılı olursa, tanım gereği geçerli UTF-8'dir.

İşte gerçek sorunlara neden olan Malzeme Listesi kullanımına ilişkin örnekler ve yine de birçok insan bunu bilmiyor.

BOM komut dosyalarını bozuyor

Kabuk komut dosyaları, Perl komut dosyaları, Python komut dosyaları, Ruby komut dosyaları, Node.js komut dosyaları veya bir yorumlayıcı tarafından çalıştırılması gereken diğer yürütülebilir dosyalar - tümü bunlardan birine benzeyen bir shebang satırıyla başlar :

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

Sisteme böyle bir komut dosyası çağrılırken hangi tercümanın çalıştırılması gerektiğini söyler. Komut dosyası UTF-8 olarak kodlanmışsa, başında bir malzeme listesi eklemek cazip gelebilir. Ama aslında "#!" karakterler sadece karakter değildir. Aslında iki ASCII karakterden oluşan sihirli bir sayıdır . Bu karakterlerin önüne bir şey (BOM gibi) koyarsanız, dosya farklı bir sihirli numaraya sahip gibi görünür ve bu da sorunlara yol açabilir.

Vikipedi, makale: Shebang, bölüm: Sihir numarası :

Gizli karakterler, geçerli Unix benzeri sistemlerde komut dosyaları ve diğer metin dosyaları için yaygın olarak kullanılan UTF-8 dahil olmak üzere genişletilmiş ASCII kodlamalarında aynı iki baytla temsil edilir. Ancak, UTF-8 dosyaları isteğe bağlı bayt sırası işaretiyle (BOM) başlayabilir; "exec" işlevi özellikle 0x23 ve 0x21 baytlarını algılarsa, shebang'dan önce BOM'un (0xEF 0xBB 0xBF) varlığı kod yorumlayıcısının yürütülmesini engelleyecektir.Bazı yetkililer POSIX (Unix benzeri) betiklerde [14] bayt sırası işaretini bu nedenle ve daha geniş birlikte çalışabilirlik ve felsefi kaygılar için kullanmamalarını tavsiye etmektedir. Ayrıca, kodlamanın endianness sorunları olmadığı için UTF-8'de bir bayt sırası işareti gerekli değildir; yalnızca kodlamayı UTF-8 olarak tanımlamaya yarar. [vurgu eklendi]

JSON'da BOM yasadışı

Bkz. RFC 7159, Bölüm 8.1 :

Uygulamalar, JSON metninin başına bayt sırası işareti eklememelidir * ZORUNLU *.

JSON'da BOM gereksizdir

Sadece JSON'da yasadışı değildir , aynı zamanda karakter kodlamasını belirlemek de gerekmez , çünkü herhangi bir JSON akışında kullanılan karakter kodlamasını ve endianitesini açık bir şekilde belirlemek için daha güvenilir yollar vardır ( ayrıntılar için bu cevaba bakınız).

BOM, JSON ayrıştırıcılarını bozuyor

Sadece JSON'da yasadışıdır ve gerekli değildir , aslında RFC 4627'de sunulan yöntemi kullanarak kodlamayı belirleyen tüm yazılımları kırar :

JSON kodlaması ve endianitesinin belirlenmesi, NUL baytının ilk dört baytının incelenmesi:

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

Şimdi, dosya BOM ile başlıyorsa şöyle görünecektir:

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

Bunu not et:

1. UTF-32BE üç NUL ile başlamıyor, bu yüzden tanınmayacak
2. UTF-32LE ilk baytı üç NUL izlemez, bu yüzden tanınmaz
3. UTF-16BE'nin ilk dört baytta yalnızca bir NUL'si olduğundan, tanınmayacak
4. UTF-16LE'nin ilk dört baytta yalnızca bir NUL değeri olduğundan, tanınmayacak

Uygulamaya bağlı olarak, bunların hepsi yanlış UTF-8 olarak yorumlanabilir ve daha sonra geçersiz UTF-8 olarak yanlış yorumlanabilir veya reddedilebilir veya hiç tanınmayabilir.

Ek olarak, uygulama geçerli JSON'u önerdiğim gibi test ederse, gerçekten UTF-8 olarak kodlanan girişi bile reddedecektir, çünkü RFC'ye göre olması gerektiği gibi <128 ASCII karakteriyle başlamamaktadır.

Diğer veri formatları

JSON'da BOM gerekli değildir, yasadışıdır ve RFC'ye göre doğru çalışan yazılımı keser. O zaman kullanmamak bir nobrainer olmalı ve yine de, BOM'ları, yorumları, farklı alıntı kurallarını veya farklı veri türlerini kullanarak JSON'u kırmakta ısrar eden insanlar var. Tabii ki kimse ihtiyacınız varsa BOM veya başka bir şey kullanmakta özgürdür - sadece o zaman JSON deme.

JSON dışındaki diğer veri biçimleri için nasıl göründüğüne bir göz atın. Yalnızca kodlamalar UTF- * ise ve ilk karakterin 128'den küçük bir ASCII karakteri olması gerekiyorsa, verilerinizin hem kodlamasını hem de sonlandığını belirlemek için gereken tüm bilgilere zaten sahipsiniz demektir. Malzeme listelerini isteğe bağlı bir özellik olarak bile eklemek yalnızca daha karmaşık ve hataya açık hale gelir.

BOM'un diğer kullanımları

JSON veya script dışındaki kullanımlara gelince, burada çok iyi cevaplar olduğunu düşünüyorum. Özellikle komut dosyası oluşturma ve serileştirme hakkında daha ayrıntılı bilgi eklemek istedim, çünkü gerçek sorunlara neden olan BOM karakterlerinin bir örneği.

Malzeme Listesi olmadan UTF-8 ve UTF-8 arasında ne fark vardır?

Kısa yanıt: UTF-8'de, bir Malzeme Listesi EF BB BFdosyanın başındaki bayt olarak kodlanır .

Uzun cevap:

Başlangıçta Unicode'un UTF-16 / UCS-2'de kodlanması bekleniyordu . Ürün Ağacı bu kodlama formu için tasarlanmıştır. 2 baytlık kod birimleriniz olduğunda, bu iki baytın hangi sırada olduğunu belirtmeniz gerekir ve bunu yapmak için ortak bir kural, verilerin başında "Bayt Sırası İşareti" olarak U + FEFF karakterini dahil etmektir. U + FFFE karakteri kalıcı olarak atanmamış, böylece varlığı yanlış bayt sırasını tespit etmek için kullanılabilir.

UTF-8, platform endianitesinden bağımsız olarak aynı bayt sırasına sahiptir, bu nedenle bir bayt sırası işaretine gerek yoktur. Bununla birlikte, EF BB FFUTF-16'dan UTF-8'e dönüştürülen verilerde (bayt dizisi olarak ) veya verinin UTF-8 olduğunu belirtmek için bir "imza" olarak ortaya çıkabilir .

Hangisi daha iyi?

Olmadan. Martin Cote'un yanıtladığı gibi, Unicode standardı bunu önermez. BOM farkında olmayan yazılımlarda sorunlara neden olur.

Bir dosyanın UTF-8 olup olmadığını tespit etmenin daha iyi bir yolu, geçerlilik kontrolü yapmaktır. UTF-8'in hangi bayt dizilerinin geçerli olduğuna dair katı kuralları vardır, bu nedenle yanlış pozitif olasılığı ihmal edilebilir. Bir bayt dizisi UTF-8'e benziyorsa, büyük olasılıkla öyledir.

BOM'li UTF-8 daha iyi tanımlanır. Bu sonuca zor yoldan ulaştım. Sonuçlardan birinin Unicode karakterler de dahil olmak üzere bir CSV dosyası olduğu bir proje üzerinde çalışıyorum .

CSV dosyası bir Malzeme Listesi olmadan kaydedilirse, Excel bunun ANSI olduğunu düşünür ve anlamsızlık gösterir. Önde "EF BB BF" ekledikten sonra (örneğin, UTF-8 ile Not Defteri veya BOM ile UTF-8 ile Notepad ++ kullanarak yeniden kaydederek), Excel'i açar.

Malzeme Listesi karakterini Unicode metin dosyalarına hazırlamak RFC 3629 tarafından önerilmektedir: "UTF-8, ISO 10646 dönüşüm biçimi", Kasım 2003, http://tools.ietf.org/html/rfc3629 (bu son bilgi şu adreste bulunur: http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM-FEFF-EFBBBF.html )

BOM bir yerde, bir yerde patlama (amaçlanan cinas (sic)) eğilimindedir. Ve patladığında (örneğin, tarayıcılar, editörler vb. Tarafından tanınmazsa), belgenin başlangıcında garip karakterler olarak görünür (örneğin, HTML dosyası, JSON yanıtı, RSS , vb.) ve Obama'nın Twitter'da konuşması sırasında yaşanan son kodlama sorunu gibi utançlara neden oluyor .

Hata ayıklaması zor yerlerde göründüğünde veya testler ihmal edildiğinde çok can sıkıcıdır. Bu yüzden kullanmak zorunda olmadığınız sürece bundan kaçınmak en iyisidir.

Soru: Malzeme Listesi olmadan UTF-8 ve UTF-8 arasında ne fark vardır? Hangisi daha iyi?

İşte bayt sırası işareti (BOM) hakkındaki Wikipedia makalesinden, bu soruya sağlam bir cevap sunduğuna inandığım bazı alıntılar .

Malzeme Listesinin ve UTF-8'in anlamı hakkında:

Unicode Standardı izin BOM içinde UTF-8 , fakat gerektiren veya kullanımını önermez. Bayt sırasının UTF-8'de bir anlamı yoktur, bu nedenle UTF-8'deki tek kullanımı başlangıçta metin akışının UTF-8'de kodlandığını bildirmektir.

Malzeme Listesinin KULLANILMAMASI argümanı :

Bir ürün ağacı kullanmamanın birincil motivasyonu Unicode farkında olmayan yazılımlarla geriye dönük uyumluluktur ... Bir ürün ağacı kullanmamanın bir başka amacı da UTF-8'i "varsayılan" kodlama olarak teşvik etmektir.

Argüman İÇİN Bir BOM kullanılarak:

Malzeme Listesini kullanma argümanı, onsuz, bir dosyayı kodlayan karakteri hangi karakteri kullandığını belirlemek için sezgisel analiz yapılması gerektiğidir. Tarihsel olarak, bu tür analizler, çeşitli 8-bit kodlamaları ayırt etmek için karmaşık, hata eğilimli ve bazen yavaştır. Mozilla Universal Charset Detector ve Unicode Uluslararası Bileşenleri gibi görevi kolaylaştırmak için bir dizi kütüphane mevcuttur.

Programcılar yanlışlıkla UTF-8'in saptanmasının eşit derecede zor olduğunu varsaymaktadır (bayt dizilerinin büyük çoğunluğunun geçersiz UTF-8 olması nedeniyle değildir, bu kütüphanelerin kodlamaları mümkün olan tüm bayt dizilerine izin vermeye çalışmaktadır). Bu nedenle, Unicode kullanan tüm programlar böyle bir analiz yapmaz ve bunun yerine Malzeme Listesine dayanır.

Özellikle, Microsoft derleyicileri ve yorumlayıcıları ve Notepad gibi Microsoft Windows üzerindeki birçok yazılım parçası, yalnızca ASCII karakterleri veya BOM ile başlamadığı sürece UTF-8 metnini doğru bir şekilde okumaz ve kaydetme sırasında bir BOM ekler UTF-8 olarak metin. Bir Microsoft Word belgesi düz metin dosyası olarak indirildiğinde Google Dokümanlar bir ürün ağacı ekler.

Hangi günü, daha da İLE veya OLMADAN BOM:

IETF bir protokol ya (a) her zaman kullanıyorsa UTF-8, veya (b) kodlaması kullanılıyor neyi göstermek için başka bir yol, o zaman sahip önerir “imza olarak U + FEFF kullanımını yasaklamak GEREKEN.”

Kanımca:

Malzeme Listesini yalnızca bir yazılım uygulamasıyla uyumluluk kesinlikle gerekliyse kullanın.

Başvurulan Wikipedia makalesinde, birçok Microsoft uygulamasının UTF-8'i doğru bir şekilde algılamak için Malzeme Listesine dayandığını göstermesine rağmen, bu tüm Microsoft uygulamaları için geçerli değildir . Örneğin, tarafından sivri out gibi @barlop UTF-8 ile İstemi, Windows Command kullanırken, ^† , böyle komutları typeve moreBOM mevcut olması beklemeyin. BOM halinde olan mevcut diğer uygulamalar için olduğu gibi, bu sorun yaratabilir.

† chcpKomut, 65001 kod sayfası aracılığıyla UTF-8 ( BOM olmadan ) desteği sunar .

Bu sorunun zaten bir milyonluk bir cevabı var ve birçoğu oldukça iyi, ama bir ürün ağacının ne zaman kullanılması gerektiğini ya da kullanılmaması gerektiğini açıklığa kavuşturmak istedim.

Belirtildiği gibi, bir dizenin UTF-8 olup olmadığını belirlemede UTF Malzeme Listesinin (Byte Order Mark) herhangi bir kullanımı eğitimli bir tahmindir. Uygun meta veriler varsa (gibi charset="utf-8"), o zaman ne kullanmanız gerektiğini zaten biliyorsunuzdur, ancak aksi takdirde bazı varsayımları test etmeniz ve yapmanız gerekir. Bu, bir dizenin geldiği dosyanın onaltılık bayt kodu EF BB BF ile başlayıp başlamadığını kontrol etmeyi içerir.

UTF-8 BOM'sine karşılık gelen bir bayt kodu bulunursa, bunun UTF-8 olduğunu varsayacak kadar yüksektir ve oradan gidebilirsiniz. Bununla birlikte, bu tahminde bulunmaya zorlandığında, okuma sırasında ek hata kontrolü, bir şeyin bozuk olması durumunda hala iyi bir fikir olacaktır. Yalnızca bir girdinin kaynağına göre UTF-8 olmaması gerektiğinde bir Malzeme Listesinin UTF-8 (yani latin-1 veya ANSI) olmadığını varsaymalısınız . Bununla birlikte, ürün ağacı yoksa, kodlamaya karşı doğrulayarak UTF-8 olması gerekip gerekmediğini belirleyebilirsiniz.

Ürün ağacı neden önerilmiyor?

1. Unicode farkında olmayan veya uyumlu olmayan bir yazılım, latin-1 veya ANSI olduğunu varsayabilir ve ürün ağacını dizeden çıkarmaz; bu da sorunlara neden olabilir.
2. Gerçekten gerekli değildir (içeriklerin uyumlu olup olmadığını kontrol edin ve uyumlu bir kodlama bulunamadığında her zaman UTF-8'i yedek olarak kullanın)

Ne zaman ürün ağacıyla kodlamanız gerekir ?

Meta verileri başka bir şekilde (bir karakter kümesi etiketi veya dosya sistemi meta aracılığıyla) kaydedemiyorsanız ve Malzeme Listeleri gibi kullanılan programları bir Malzeme Listesiyle kodlamanız gerekir. Bu özellikle, ürün ağacı içermeyen herhangi bir şeyin genellikle eski bir kod sayfası kullandığı varsayıldığı Windows için geçerlidir. Malzeme Listesi, Office gibi programlara, evet, bu dosyadaki metnin Unicode olduğunu söyler; İşte kullanılan kodlama.

Konu söz konusu olduğunda, gerçekten sorun yaşadığım dosyalar CSV'dir. Programa bağlı olarak, bir ürün ağacına sahip olmalı ya da olmamalıdır. Örneğin, Windows'ta Excel 2007+ kullanıyorsanız, düzgün bir şekilde açmak ve verileri içe aktarmak için başvurmak zorunda değilseniz, bir Malzeme Listesi ile kodlanmalıdır.

Bazı dosyalar için Windows'ta bile BOM'ye sahip olmamanız gerektiğine dikkat edilmelidir . Örnekler SQL*plusveya VBScriptdosyalar. Bu tür dosyalarda ürün ağacı varsa, bunları yürütmeye çalıştığınızda bir hata alırsınız.

BOM içeren UTF-8 yalnızca dosyada bazı ASCII olmayan karakterler varsa yardımcı olur. Dahil edilirse ve yoksa, dosyayı normalde düz ASCII olarak yorumlayan daha eski uygulamaları bozar. Bu uygulamalar ASCII olmayan bir karakterle karşılaştıklarında kesinlikle başarısız olurlar, bu yüzden BOM sadece dosya ASCII olarak yorumlanabiliyorsa ve yorumlanamazsa eklenmelidir.

Ürün ağacına sahip olmamayı tercih ettiğimi açıkça belirtmek istiyorum. Bazı eski çöpler onsuz kırılırsa ve eski uygulamanın yerine geçmesi mümkün değilse ekleyin.

UTF-8 için bir malzeme listesi beklemeyin.

Malzeme Listesinde Wikipedia sayfasının alt kısmında alıntı: http://en.wikipedia.org/wiki/Byte-order_mark#cite_note-2

"UTF-8 için bir Malzeme Listesinin kullanılması ne gerekli ne de tavsiye edilir, ancak UTF-8 verilerinin bir Malzeme Listesini kullanan veya Malzeme Listesinin UTF-8 imzası olarak kullanıldığı diğer kodlama formlarından dönüştürüldüğü bağlamlarda görülebilir"

BOM'siz UTF-8'in BOM'si yoktur, bu da dosyanın tüketicisinin UTF-8 kodlu olup olmadığını bilmesi (veya bilmekten faydalanması) dışında BOM ile UTF-8'den daha iyi yapmaz. ya da değil.

BOM genellikle, çoğu kullanım durumunda gerekli olmayan kodlamanın endianitesini belirlemek için yararlıdır.

Ayrıca, BOM, bilmeyen veya ilgilenmeyen tüketiciler için gereksiz gürültü / ağrı olabilir ve kullanıcının karışmasına neden olabilir.

Buna farklı bir açıdan bakıyorum. Dosya hakkında daha fazla bilgi sağladığı için BOM ile UTF-8 daha iyi olduğunu düşünüyorum . UTF-8'i BOM olmadan sadece sorunlarla karşılaştığımda kullanırım.

Sayfalarımda uzun süre birden fazla dil ( Kiril bile ) kullanıyorum ve dosyalar BOM olmadan kaydedildiğinde ve bunları bir düzenleyici ile düzenlemek için yeniden açtığımda ( cherouvim de belirtildiği gibi), bazı karakterler bozuk.

Yeni oluşturulan bir dosyayı UTF-8 kodlamasıyla kaydetmeye çalıştığınızda Windows'un klasik Not Defteri uygulamasının dosyaları bir Malzeme Listesiyle otomatik olarak kaydettiğini unutmayın.

Kişisel olarak sunucu tarafı komut dosyası dosyalarını (.asp, .ini, .aspx) BOM ve .html dosyalarını BOM olmadan kaydediyorum .

UTF-8 ile kodlanmış bilgileri görüntülemek istediğinizde sorunlarla karşılaşmayabilirsiniz. Örneğin bir HTML belgesini UTF-8 olarak bildirin; tarayıcınızda belgenin gövdesinde bulunan her şeye sahip olursunuz.

Ancak , Windows veya Linux'ta metin, CSV ve XML dosyalarımız olduğunda durum böyle değildir .

Örneğin, Windows veya Linux'ta akla gelebilecek en kolay şeylerden biri olan bir metin dosyası (genellikle) UTF-8 değildir.

XML olarak kaydedin ve UTF-8 olarak bildirin:

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

UTF-8 olarak bildirilmiş olsa bile doğru şekilde görüntülenmeyecek (okunmayacak).

Sendikasyon için XML olarak kaydedilmesi gereken Fransız harfleri içeren bir dizi veri vardı. En baştan bir UTF-8 dosyası oluşturmadan (IDE ve "Yeni Dosya Oluştur" daki seçenekleri değiştirme) veya dosyanın başına ürün ağacı ekleme

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

Fransızca harfleri bir XML dosyasına kaydedemedim.

Pratik bir fark, Mac OS X için bir kabuk komut dosyası yazar ve düz UTF-8 olarak kaydederseniz, yanıtı alırsınız:

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

hangi kabuğu kullanmak istediğinizi belirten shebang hattına yanıt olarak:

#!/bin/bash

UTF-8 olarak kaydederseniz, hiçbir BOM ( BBEdit'te söyleyin ) hepsi iyi olmayacaktır.

Yukarıda belirtildiği gibi, BOM'li UTF-8, BOM farkında olmayan (veya uyumlu) yazılımlarda sorunlara neden olabilir. Bir keresinde Mozilla tabanlı KompoZer ile UTF-8 + BOM olarak kodlanan HTML dosyalarını WYSIWYG programının gerektirdiği bir istemci olarak düzenledim .

Tasarruf sırasında düzen her zaman yok olur. Bu konuda yolumu açmak biraz zaman aldı. Bu dosyalar daha sonra Firefox'ta iyi çalıştı, ancak Internet Explorer'da düzeni bozan bir CSS tuhaflığı gösterdi. Bağlantılı CSS dosyalarıyla saatlerce uğraştıktan sonra Internet Explorer'ın BOMfed HTML dosyasını beğenmediğini keşfettim. Bir daha asla.

Ayrıca, bunu Wikipedia'da buldum:

Gizli karakterler, geçerli Unix benzeri sistemlerde komut dosyaları ve diğer metin dosyaları için yaygın olarak kullanılan UTF-8 dahil olmak üzere genişletilmiş ASCII kodlamalarında aynı iki baytla temsil edilir. Ancak, UTF-8 dosyaları isteğe bağlı bayt sırası işaretiyle (BOM) başlayabilir; "exec" fonksiyonu özellikle 0x23 0x21 baytlarını algılarsa, shebang'dan önce BOM (0xEF 0xBB 0xBF) varlığı kod yorumlayıcısının yürütülmesini engelleyecektir. Bazı yetkililer POSIX (Unix benzeri) komut dosyalarında, bu nedenle [15] ve daha geniş birlikte çalışabilirlik ve felsefi kaygılar için bayt sırası işaretinin kullanılmamasını önermektedir

Unicode Bayt Sipariş İşareti (BOM) SSS kısa bir cevap verir:

S: Malzeme Listeleri ile nasıl başa çıkmalıyım?

C: İzlenmesi gereken bazı yönergeler:

1. Belirli bir protokol (örneğin .txt dosyaları için Microsoft kuralları) BOM'un dosyalar gibi belirli Unicode veri akışlarında kullanılmasını gerektirebilir. Böyle bir protokole uymanız gerektiğinde bir ürün ağacı kullanın.

2. Bazı protokoller, etiketsiz metin durumunda isteğe bağlı Malzeme Listelerine izin verir. Bu durumlarda,

   • Metin veri akışının düz metin olduğu, ancak bilinmeyen kodlaması olduğu bilinen yerlerde, Malzeme Listesi imza olarak kullanılabilir. BOM yoksa, kodlama herhangi bir şey olabilir.

   • Bir metin veri akışının düz Unicode metin olduğu biliniyorsa (ancak hangi endian değil), BOM imza olarak kullanılabilir. Malzeme Listesi yoksa, metin big-endian olarak yorumlanmalıdır.

3. Bazı bayt odaklı protokoller, dosyanın başında ASCII karakterleri bekler. Bu protokollerle UTF-8 kullanılırsa, ürün ağacını kodlama formu imzası olarak kullanmaktan kaçınılmalıdır.

4. Veri akışının kesin türü bilindiğinde (örn. Unicode big-endian veya Unicode little-endian), BOM kullanılmamalıdır. Özellikle, bir veri akışı UTF-16BE, UTF-16LE, UTF-32BE veya UTF-32LE olarak bildirildiğinde, bir Malzeme Listesi kullanılmamalıdır.

Gönderen http://en.wikipedia.org/wiki/Byte-order_mark :

Bayt sırası işareti (BOM), bir metin dosyasının veya akışın endianitesini (bayt sırası) belirtmek için kullanılan bir Unicode karakteridir. Kod noktası U + FEFF'dir. Malzeme Listesi kullanımı isteğe bağlıdır ve kullanılıyorsa metin akışının başında görünmelidir. Bayt sırası göstergesi olarak özel kullanımının ötesinde, Malzeme Listesi karakteri metnin çeşitli Unicode gösterimlerinden hangisinin kodlandığını da gösterebilir.

Dosyanızda her zaman bir ürün ağacı kullanmak, UTF-8 ve BOM'yi destekleyen bir düzenleyicide her zaman doğru şekilde açılmasını sağlar.

Ürün ağacının yokluğu ile ilgili gerçek sorunum şudur. Diyelim ki aşağıdakileri içeren bir dosyamız var:

abc

Malzeme Listesi olmadan bu, çoğu editörde ANSI olarak açılır. Bu dosyanın başka bir kullanıcısı dosyayı açar ve bazı yerel karakterler ekler, örneğin:

abg-αβγ

Hata! Şimdi dosya hala ANSI'da ve tahmin edin ne "αβγ" 6 bayt, ama 3 işgal etmez. Bu UTF-8 değildir ve bu daha sonra geliştirme zincirinde başka sorunlara neden olur.

İşte bana bazı sorunlar veren Visual Studio, Sourcetree ve Bitbucket çekme istekleriyle ilgili deneyimim:

Böylece bir BOM imzası ile bir çekme isteği gözden geçirirken her dosya üzerinde kırmızı bir nokta karakteri içerdiği ortaya çıkıyor (oldukça can sıkıcı olabilir).

Üzerine geldiyseniz, "ufeff" gibi bir karakter gösterecektir, ancak Sourcetree'nin bu tür bytemarks göstermediği ortaya çıkıyor, bu yüzden büyük olasılıkla çekme isteklerinizle sonuçlanacaktır, 2017 şimdi yeni dosyaları kodlıyor, belki Bitbucket bunu görmezden gelmeli veya başka bir şekilde göstermelidir, daha fazla bilgi burada:

Kırmızı nokta işaretleyici BitBucket fark görünümü

HTML dosyalarında UTF-8 kullanıyorsanız ve aynı sayfada Sırp Kiril, Sırp Latin, Almanca, Macarca veya egzotik bir dil kullanıyorsanız, Malzeme Listeli UTF daha iyidir.

Benim düşüncem bu (30 yıllık bilgi işlem ve bilişim endüstrisi).