I Unicode er indikatoren for bytebestilling eller BOM (for engelsk ordemarkeringsbyte ) data som indikerer bruk av Unicode-koding og byterekkefølge, vanligvis i begynnelsen av noen filtekst.
Teknisk sett er det et Unicode-tegn med et U + FEFF-kodepunkt (ikke-brutt mellomrom uten bredde eller på engelsk null-bredde no-break-mellomrom ), når dette tegnet brukes til å markere enden på en UCS / Unicode-tegnstreng kodet i UTF-16 eller UTF-32 og / eller som en markør for å indikere at teksten er kodet i UTF-8 , UTF-16 eller UTF-32 . Den offisielle betegnelsen i den franske versjonen av ISO / IEC 10646, som er ISO-motstykke til Unicode, for denne karakteren er en indikator for oktettordre (IOO).
Når den tolkes riktig, blir IOO ikke sett av sluttbrukeren av den kodede teksten. Imidlertid er det to tilfeller der denne karakteren kan tolkes feil:
Bytebestillingsindikatoren for de fleste Unicode- kodinger er en sekvens på noen få byte som kan vises som en uklar tegnrekkefølge hvis programvaren som ble brukt til å lese teksten er feilkonfigurert, eller som et mellomrom hvis programvaren som ble brukt til å lese teksten. vet ikke hvordan jeg skal gjenkjenne denne indikatoren.
Hvis en bytebestillingsindikator feilaktig tolkes som et tegn inne i teksten, vil den være usynlig på grunn av det faktum at det er et ikke-brutt mellomrom uten en ledende (dvs. null bredde). Bruken av U + FEFF-tegnet som et ikke-brytende ikke-ledende rom, det vil si som et ord gluon, ble avskrevet i Unicode versjon 3.2, som gir et U + 2060-alternativ for denne bruken. Dette tegnet skal derfor bare brukes som en byteordreindikator.
I 2001 ble bug 4508058 identifisert i Java. "UTF-8-koding gjenkjenner ikke første BOM". Det ble besluttet å ikke rette opp det. Det ble rettet rundt 2006/2007.
I november 2003, blir BOM-problemet vurdert av RFC 3629.
Mellom Juni 2001og 2009 ble problemet med bytebestillingsindikatoren tatt i betraktning i Python- språket gjennom dokumentet PEP 263 “Defining Python Source Code Encodings” (PEP som betyr Python-forbedringsforslag , det vil si Python-forbedringsforslag).
Før 25. januar 2005, Microsoft introduserte en Unicode-kompatibilitetsfunksjon i notisblokkprogramvaren som bryter interoperabilitet med noe eldre Unix-programvare som ikke var forberedt på det.
I Juli 2005, er et verktøy som kalles bomstrip utviklet for å gi brukere en mulighet for hver enkelt sak å overvinne inkompatibilitet mellom ny programvare som introduserer bruken av BOM-indikatoren og gamle som ikke forventer det.
I August 2005, foreslås en oppdatering for Linux-kjernen som tillater bruk av stykklisten i forbindelse med shebang .
I Oktober 2005, Visual Studio 2005 støtter Unicode-kilder med BOM i kompilatoren og linkeren.
I februar 2007, oppdages en feil i måten Apache-webserveren håndterer konfigurasjonsfiler.
De 8. april 2007Utgivelsen av Etch-versjonen, dvs. 4.0, av Debian finner sted som er forhåndskonfigurert for bruk av UTF-8. de forrige kodingene blir deretter kunngjort som foreldet.
I april 2007, oppdages en feil relatert til manglende aksept av bytebestillingsindikatoren i GCC Fortran-kompilatoren.
I september 2007ble en feil relatert til manglende aksept av bytebestillingsindikatoren oppdaget og rettet i april 2008 i GCC-kompilatoren.
I Mai 2008, ble en lignende feil oppdaget ved import av CSV-filer av OpenOffice, den ble korrigert i april 2011, under navnet dev300_m101.
I utgivelsen av Unicode 6.1, fra januar 2012, denne informasjonen forblir gyldig og er dokumentert i avsnitt “16.8 Spesialer”.
I UTF-16 er bytebestillingsindikatoren representert av en to-bytesekvens FE FF ved starten av den kodede strengen, for å indikere at påfølgende kodede tegn bruker stor endian-orden; eller, hvis sekvensen er FF FE for å indikere liten endian rekkefølge. Fordi Unicode-standarden garanterer at kodepunktet U + FFFE ikke er assosiert med noe Unicode-tegn, og i motsetning til U + FEFF som er et tegn, er denne sekvensen på to byte tilstrekkelig til å bestemme rekkefølgen på byte.
På samme prinsipp kan bytebestillingsindikatoren brukes i UTF-32 .
Mens UTF-8-tegnkoding ikke utgjør et bytebestillingsproblem, brukes byteordreflagget noen ganger for å bestemme at teksten er UTF-8-kodet. Av hensyn til interoperabilitet støtter faktisk noen systemer i tillegg til UTF-8, en eldre tegnkoding, for eksempel ISO / IEC 8859-1 . I dette tilfellet kan flagget brukes på hodet til UTF-8-teksten for å skille det fra teksten ved hjelp av den gamle tegnkodingen.
Denne teknikken er basert på antagelsen om at sekvensen av byte som tilsvarer bytebestillingsindikatoren i UTF-8, har svært lav sannsynlighet for å være til stede i tekst som er kodet i den gamle tegnkodingen. Dette er spesielt tilfelle i ISO 8859-1. Faktisk, i UTF-8, blir bytebestillingsindikatoren kodet av sekvensen EF BB BF, som tilsvarer ISO 8859-1 til teksten “ï” ¿”.
Selv om denne metoden tillater et raskt og presist skille fra UTF-8, gjenkjennes den ikke av all programvare og gir derfor kompatibilitetsproblemer. Unicode-konsortiet definerer tydelig denne bruken av bytebestillingsindikatoren, men har ikke inntatt en sterk posisjon som tar sikte på å forby eller anbefale bruken. Dette ubesluttsomheten har utvilsomt drevet interoperabilitetsproblemene mellom programvaren som gjør en massiv bruk av indikatoren, spesielt under Windows, og programvaren hvis utviklere anser at bruken av den er tilstrekkelig marginal til å være bekymret for den, spesielt under visse Unix.
For eksempel er Unicode-tegnet med kodepunkt U + 233B4 (kinesisk tegn som betyr "stubbe av et tre") når den følger bytebestillingsindikatoren, kodet med følgende bytesekvens:
EF BB BF | F0 A3 8E B4 | ... |
Noe gammel Unix-basert programvare er utviklet for å fungere med utvidet ASCII. Begrepet utvidet ASCII fikser driften av programvaren på ASCII-serien mens den er relativt kompatibel og gjennomsiktig på ikke-ASCII-byte. Derfor, uten å være designet for å behandle UTF-8-filer, er disse programmene relativt kompatible med UTF-8, selv om bytebestillingsindikatoren er en snublestein. Fra et begrepsmessig synspunkt ville aksept av en UTF-8 bytebestillingsindikator utgjøre å gi UTF-8-standarden mer betydning enn andre tegnkodinger, noe som er i strid med orientert logikk. Byte og multikoding som rådet frem til deretter. Noe programvare fra Linux-distribusjoner er likevel tilpasset.
Siden 2005 har denne tilnærmingen blitt konfrontert med den virkeligheten at mange Windows- programvare (inkludert Windows Notisblokk ) og Visual Studio / .NET-miljøet legger til en bytebestillingsindikator i UTF-8-filer.
Denne programvaren anbefales ikke på programvare på Unix- lignende systemer (som bruker tekstfiler mye for konfigurering).
Det kan til og med frarådes når det blir nødvendig å fjerne UTF-8 bytebestillingsflagget for inkompatibel programvare som ikke kan fjerne dem alene. Dette er spesielt tilfelle for skript som bruker shebang i starten av et tolket skript. Det kan også forstyrre leksikalanalyse av programmeringsspråk når kompilatoren deres ikke gjenkjenner det. For eksempel spesifiserer GCC stray-tegn i begynnelsen av kildefilen, og hvis utgangsbuffering er deaktivert i PHP 5, har dette den subtile effekten av at siden starter umiddelbart når den sendes til nettleseren, og forhindrer endring av HTTP-overskrifter ved hjelp av PHP-skriptet.
I tekstredigerere og nettlesere som er dårlig forberedt på å håndtere UTF-8, i ISO-8859-1- koding , vises flagget som "ï" ¿".
De kan også ikke bruke den første regelen i et CSS-ark eller føre til at bruken av visse PHP5-funksjoner (simplexml_load_file () for eksempel) mislykkes.
Problemer med å ikke bruke byteordreflaggetNår bytebestillingsflagget ikke brukes, kan en tekstredigerer ikke gjenkjenne UTF-8-format, endre teksten utenfor UTF-8-format og deretter deaktivere automatisk gjenkjenning av UTF-8.
Alternativer til BOM kan være automatisk gjenkjenning av UTF-8, som statistisk sett skal fungere i de fleste tilfeller på en fil, med sjeldne feil. Imidlertid kan denne teknikken ikke fungere pålitelig på noen strøm fordi det vil kreve å ha mottatt hele strømmen før behandlingen startes. Dette alternativet mislykkes også på en fil som inneholder et samlet antall tekster, hvorav noen er ødelagt eller ikke i UTF-8.
The Unicode Standard FAQ gir fire svar på spørsmålet om bruk av BOM:
Apple har publisert et sett med retningslinjer for programmerere om hvordan en applikasjon oppfører seg når de håndterer en Unicode-tekstfil. Disse direktivene foreskriver dem:
Koding | Bytesekvens (representasjon) |
---|---|
UTF-8 | EF BB BF |
UTF-16 Big Endian | FE FF |
UTF-16 Little Endian | FF FE |
UTF-32 Big Endian | 00 00 FE FF |
UTF-32 Little Endian | FF FE 00 00 |
SCSU | 0E FE FF |
UTF-7 |
2B 2F 76 og en av følgende bytesekvenser: [38 | 39 | 2B | 2 F] |
UTF-EBCDIC | DD 73 66 73 |
BOCU -1 | FB EE 28 |
UTF-1 | F7 64 4C |
Unicode- standarden pålegger ikke bytebestillingsindikatoren ved starten av en Unicode-datastrøm, men tillater det; dette er spesielt tilfelle for UTF-8, der flagget er valgfritt.
Dets akseptabilitet avhenger av protokollene som brukes. Av hensyn til interoperabilitet har programvare en tendens til å gjenkjenne den når den er tilstede, og brukere har en tendens til å fjerne den når den ikke gjenkjennes av programvaren.
P. Andries, Unicode 5.0 i praksis , Paris, Dunod, 2008.