Wat is het verschil tussen UTF-8 en UTF-8 zonder stuklijst?

Wat is het verschil tussen UTF-8 en UTF-8 zonder een stuklijst? Wat is beter?


Antwoord 1, autoriteit 100%

De UTF-8 BOM is een reeks van bytesaan het begin van een tekststroom (0xEF, 0xBB, 0xBF) waarmee de lezer betrouwbaarder kan raden bestand als gecodeerd in UTF-8.

Normaal gesproken wordt de BOMgebruikt om de endiannessvan een codering, maar aangezien endianness niet relevant is voor UTF-8, is de stuklijst niet nodig.

Volgens de Unicode-standaardis de BOM voor UTF-8-bestanden worden niet aanbevolen:

2.6 Coderingsschema’s

… Het gebruik van een stuklijst is niet vereist noch aanbevolen voor UTF-8, maar kan worden aangetroffen in contexten waarin UTF-8-gegevens worden geconverteerd van andere coderingsvormen die een stuklijst gebruiken of waar de stuklijst wordt gebruikt als een UTF -8 handtekening. Zie de subsectie “Byte Order Mark” in Sectie 16.8, Specials, voor meer informatie.


Antwoord 2, autoriteit 30%

De andere uitstekende antwoorden hebben dat al beantwoord:

  • Er is geen officieel verschil tussen UTF-8 en BOM-ed UTF-8
  • Een stuklijst UTF-8-tekenreeks begint met de drie volgende bytes. EF BB BF
  • Deze bytes, indien aanwezig, moeten worden genegeerd bij het extraheren van de string uit het bestand/stream.

Maar als aanvullende informatie hierbij, zou de stuklijst voor UTF-8 een goede manier kunnen zijn om te “ruiken” of een string is gecodeerd in UTF-8… Of het kan een legitieme string zijn in een andere codering. ..

De gegevens [EF BB BF 41 42 43] kunnen bijvoorbeeld zijn:

  • De legitieme ISO-8859-1string “ABC”
  • De legitieme UTF-8-tekenreeks “ABC”

Dus hoewel het cool kan zijn om de codering van de inhoud van een bestand te herkennen door naar de eerste bytes te kijken, moet je hier niet op vertrouwen, zoals blijkt uit het bovenstaande voorbeeld

Coders moeten bekend zijn, niet geraden.


Antwoord 3, autoriteit 17%

Er zijn minstens drie problemen met het plaatsen van een stuklijst in UTF-8-gecodeerde bestanden.

  1. Bestanden die geen tekst bevatten, zijn niet langer leeg omdat ze altijd de stuklijst bevatten.
  2. Bestanden die tekst bevatten die binnen de ASCII-subset van UTF-8 valt, zijn zelf niet langer ASCII omdat de stuklijst geen ASCII is, waardoor sommige bestaande tools kapot gaan en het voor gebruikers onmogelijk kan zijn om dergelijke legacy-tools te vervangen.
  3. Het is niet mogelijk om meerdere bestanden samen te voegen omdat elk bestand nu aan het begin een stuklijst heeft.

En, zoals anderen al hebben gezegd, het is niet voldoende en ook niet nodig om een stuklijst te hebben om te detecteren dat iets UTF-8 is:

  • Het is niet voldoende omdat een willekeurige bytereeks kan beginnen met de exacte reeks waaruit de stuklijst bestaat.
  • Het is niet nodig omdat je de bytes gewoon kunt lezen alsof ze UTF-8 zijn; als dat lukt, is het per definitie geldige UTF-8.

4, Autoriteit 6%

Wat is anders tussen UTF-8 en UTF-8 zonder BOM?

Kort antwoord: in UTF-8 wordt een stuklijst gecodeerd als de bytes EF BB BFaan het begin van het bestand.

Lang antwoord:

Oorspronkelijk werd verwacht dat Unicodezou worden gecodeerd in UTF-16/UCS-2 . De stuklijst is ontworpen voor deze coderingsvorm. Als u 2-byte code-eenheden hebt, is het noodzakelijk om aan te geven in welke volgorde deze twee bytes staan, en een gebruikelijke conventie om dit te doen is om het teken U+FEFF als een “Byte Order Mark” aan het begin van de gegevens op te nemen. Het teken U+FFFE is permanent niet toegewezen, zodat de aanwezigheid ervan kan worden gebruikt om de verkeerde bytevolgorde te detecteren.

UTF-8 heeft dezelfde bytevolgorde, ongeacht de platform-endianness, dus een bytevolgorde is niet nodig. Het kan echter voorkomen (als de bytereeks EF BB FF) in gegevens die zijn geconverteerd naar UTF-8 van UTF-16, of als een “handtekening” om aan te geven dat de gegevens UTF-8 zijn .

Wat is beter?

Zonder. Zoals Martin Cote antwoordde, raadt de Unicode-standaard het niet aan. Het veroorzaakt problemen met niet-BOM-bewuste software.

Een betere manier om te detecteren of een bestand UTF-8 is, is door een geldigheidscontrole uit te voeren. UTF-8 heeft strikte regels over welke bytereeksen geldig zijn, dus de kans op een fout-positief is verwaarloosbaar. Als een bytereeks op UTF-8 lijkt, is dat waarschijnlijk ook zo.


Antwoord 5, autoriteit 4%

UTF-8 met stuklijst is beter te herkennen. Ik ben op de harde manier tot deze conclusie gekomen. Ik werk aan een project waarbij een van de resultaten een CSV-bestand is, inclusief Unicode-tekens.

Als het CSV-bestand zonder stuklijst wordt opgeslagen, denkt Excel dat het ANSI is en wordt er gebrabbel weergegeven. Zodra u “EF BB BF” aan de voorkant toevoegt (bijvoorbeeld door het opnieuw op te slaan met Kladblok met UTF-8; of Notepad++ met UTF-8 met stuklijst), opent Excel het prima.

Het wordt aanbevolen om het stuklijstteken voor Unicode-tekstbestanden te plaatsen door RFC 3629: “UTF-8, a transformation format of ISO 10646”, november 2003
op http://tools.ietf.org/html/rfc3629(deze laatste informatie is te vinden op: http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM -FEFF-EFBBBF.html)


Antwoord 6, autoriteit 2%

BOM heeft de neiging om ergens, ergens, te knallen (geen woordspeling bedoeld (sic)). En wanneer het een hoge vlucht neemt (bijvoorbeeld niet wordt herkend door browsers, editors, enz.), verschijnt het als de vreemde tekens aan het begin van het document (bijvoorbeeld HTML bestand, JSONreactie, RSS, etc.) en veroorzaakt het soort verlegenheid zoals de recent coderingsprobleem ervaren tijdens de toespraak van Obama op Twitter.

Het is erg vervelend wanneer het opduikt op moeilijk te debuggen plaatsen of wanneer testen wordt verwaarloosd. Het is dus het beste om het te vermijden, tenzij je het moet gebruiken.


Antwoord 7

Deze vraag heeft al een miljoen-en-één antwoorden en veel daarvan zijn redelijk goed, maar ik wilde proberen te verduidelijken wanneer een stuklijst wel of niet moet worden gebruikt.

Zoals eerder vermeld, is elk gebruik van de UTF BOM (Byte Order Mark) om te bepalen of een string UTF-8 is of niet, giswerk. Als er goede metadata beschikbaar is (zoals charset="utf-8"), dan weet je al wat je zou moeten gebruiken, maar anders moet je testen en enkele aannames doen. Hierbij wordt gecontroleerd of het bestand waaruit een string afkomstig is, begint met de hexadecimale bytecode, EF BB BF.

Als er een bytecode wordt gevonden die overeenkomt met de UTF-8 BOM, is de kans groot genoeg om aan te nemen dat het UTF-8 is en kunt u vanaf daar verder gaan. Wanneer u echter wordt gedwongen om deze gok te maken, zou extra foutcontrole tijdens het lezen nog steeds een goed idee zijn voor het geval er iets onleesbaars verschijnt. U moet er alleen van uitgaan dat een stuklijst geen UTF-8 is (d.w.z. latin-1 of ANSI) als de invoer zeker nietUTF-8 zou moeten zijn op basis van de bron. Als er echter geen stuklijst is, kunt u eenvoudig bepalen of het UTF-8 moet zijn door te valideren aan de hand van de codering.

Waarom wordt een stuklijst niet aanbevolen?

  1. Niet-Unicode-bewuste of slecht compatibele software kan aannemen dat het latin-1 of ANSI is en zal de stuklijst niet van de string verwijderen, wat uiteraard problemen kan veroorzaken.
  2. Het is niet echt nodig (controleer gewoon of de inhoud compatibel is en gebruik altijd UTF-8 als uitwijkmogelijkheid wanneer er geen compatibele codering kan worden gevonden)

Wanneer moetu coderen met een stuklijst?

Als je de metadata niet op een andere manier kunt vastleggen (via een charset-tag of bestandssysteemmeta), en de programma’s die als stuklijsten worden gebruikt, moet je coderen met een stuklijst. Dit geldt met name voor Windows, waar over het algemeen wordt aangenomen dat alles zonder stuklijst een verouderde codepagina gebruikt. De stuklijst vertelt programma’s zoals Office dat, ja, de tekst in dit bestand Unicode is; hier is de gebruikte codering.

Als het erop aankomt, zijn CSV de enige bestanden waar ik ooit echt problemen mee heb. Afhankelijk van het programma moet het wel of geen stuklijst hebben. Als u bijvoorbeeld Excel 2007+ op Windows gebruikt, moet het worden gecodeerd met een stuklijst als u het soepel wilt openen en geen toevlucht hoeft te nemen tot het importeren van de gegevens.


Antwoord 8

UTF-8 zonder stuklijst heeft geen stuklijst, wat het niet beter maakt dan UTF-8 met stuklijst, behalve wanneer de gebruiker van het bestand moet weten (of er baat bij zou hebben) of het bestand UTF- is 8-gecodeerd of niet.

De stuklijst is meestal handig om de endianness van de codering te bepalen, wat in de meeste gevallen niet vereist is.

Bovendien kan de stuklijst onnodig lawaai/pijn veroorzaken voor consumenten die er niets van weten of er niets om geven, en kan dit leiden tot verwarring bij de gebruiker.


Antwoord 9

Opgemerkt moet worden dat u voor sommige bestanden geende stuklijst mag hebben, zelfs niet op Windows. Voorbeelden zijn SQL*plus– of VBScript-bestanden. Als dergelijke bestanden een stuklijst bevatten, krijgt u een foutmelding wanneer u ze probeert uit te voeren.


Antwoord 10

Geciteerd onderaan de Wikipedia-pagina op BOM: http://en .wikipedia.org/wiki/Byte-order_mark#cite_note-2

“Het gebruik van een stuklijst is niet vereist noch aanbevolen voor UTF-8, maar kan worden aangetroffen in contexten waarin UTF-8-gegevens worden geconverteerd van andere coderingsvormen die een stuklijst gebruiken of waar de stuklijst wordt gebruikt als een UTF-8 handtekening”


Antwoord 11

UTF-8 met stuklijst helpt alleen als het bestand daadwerkelijk enkele niet-ASCII-tekens bevat. Als het is opgenomen en er zijn er geen, dan zal het mogelijk oudere applicaties breken die het bestand anders als gewoon ASCII zouden hebben geïnterpreteerd. Deze toepassingen zullen zeker mislukken als ze een niet-ASCII-teken tegenkomen, dus naar mijn mening moet de stuklijst alleen worden toegevoegd als het bestand niet langer kan en mag worden geïnterpreteerd als gewoon ASCII.

Ik wil duidelijk maken dat ik de stuklijst liever helemaal niet heb. Voeg het toe als er oude rommel kapot gaat zonder, en het vervangen van die oude applicatie is niet haalbaar.

Verwacht niets van een stuklijst voor UTF-8.


Antwoord 12

Ik bekijk dit vanuit een ander perspectief. Ik denk dat UTF-8 met stuklijst beter isomdat het meer informatie over het bestand geeft. Ik gebruik UTF-8 zonder stuklijst alleen als ik problemen heb.

Ik gebruik al heel lang meerdere talen (zelfs Cyrillisch) op mijn pagina’s en wanneer de bestanden worden opgeslagen zonder stuklijst en ik ze opnieuw open voor bewerking met een editor (zoals cherouvimook opmerkte), sommige tekens zijn beschadigd.

Merk op dat Windows’ klassieke Kladblokautomatisch bestanden opslaat met een stuklijst wanneer u een nieuw gemaakt bestand probeert op te slaan met UTF-8-codering.

Ik bewaar persoonlijk server-side scriptbestanden (.asp, .ini, .aspx) met stuklijsten .html-bestanden zonder stuklijst.


Antwoord 13

Als je informatie wilt weergeven die is gecodeerd in UTF-8, heb je misschien geen problemen. Declareer bijvoorbeeld een HTML-document als UTF-8 en u krijgt alles in uw browser weergegeven dat in de hoofdtekst van het document staat.

Maar dit is niet het geval wanneer we tekst-, CSV– en XML-bestanden hebben, hetzij op Windows of Linux.

Bijvoorbeeld een tekstbestand in Windows of Linux, een van de gemakkelijkst denkbare dingen, is (meestal) geen UTF-8.

Sla het op als XML en declareer het als UTF-8:

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

Het wordt niet correct weergegeven (het wordt niet gelezen), zelfs niet als het is gedeclareerd als UTF-8.

Ik had een reeks gegevens met Franse letters die als XML moesten worden opgeslagen voor syndicatie. Zonder vanaf het begin een UTF-8-bestand te maken (opties in IDE wijzigen en “Nieuw bestand maken”) of de stuklijst aan het begin van het bestand toe te voegen

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

Ik kon de Franse letters niet opslaan in een XML-bestand.


Antwoord 14

Een praktisch verschil is dat als je een shellscript voor Mac OS X schrijft en het opslaat als gewone UTF-8, je het antwoord krijgt:

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

in reactie op de shebang-regel die aangeeft welke shell je wilt gebruiken:

#!/bin/bash

Als u opslaat als UTF-8, wordt geen stuklijst (zeg in BBEdit) allemaal goed.


Antwoord 15

De Unicode Veelgestelde vragen over Byte Order Mark (BOM)geeft een beknopt antwoord:

V: Hoe moet ik omgaan met stuklijsten?

A: Hier volgen enkele richtlijnen:

  1. Voor een bepaald protocol (bijv. Microsoft-conventies voor .txt-bestanden) is mogelijk het gebruik van de stuklijst vereist op bepaalde Unicode-gegevensstromen, zoals
    bestanden. Gebruik een stuklijst als u zich aan een dergelijk protocol moet houden.

  2. Sommige protocollen staan optionele stuklijsten toe in het geval van niet-gecodeerde tekst. In die gevallen,

    • Waar bekend is dat een tekstgegevensstroom platte tekst is, maar met onbekende codering, kan stuklijst worden gebruikt als handtekening. Als er geen stuklijst is,
      de codering kan van alles zijn.

    • Waar bekend is dat een tekstgegevensstroom gewone Unicode-tekst is (maar niet welke endian), kan stuklijst worden gebruikt als handtekening. Als er
      is geen stuklijst, de tekst moet worden geïnterpreteerd als big-endian.

  3. Sommige byte-georiënteerde protocollen verwachten ASCII-tekens aan het begin van een bestand. Als UTF-8 wordt gebruikt met deze protocollen, gebruik dan de
    Stuklijst als coderingsformulierhandtekening moet worden vermeden.

  4. Waar het precieze type gegevensstroom bekend is (bijvoorbeeld Unicode big-endian of Unicode little-endian), mag de stuklijst niet worden gebruikt. In
    in het bijzonder, wanneer een datastroom wordt verklaard als UTF-16BE,
    UTF-16LE, UTF-32BE of UTF-32LE een stuklijst mag niet worden gebruikt.


Antwoord 16

Zoals hierboven vermeld, kan UTF-8 met BOM problemen veroorzaken met niet-BOM-bewuste (of compatibele) software. Ik heb ooit HTML-bestanden bewerkt die zijn gecodeerd als UTF-8 + BOM met de op Mozilla gebaseerde KompoZer, als een client had dat WYSIWYG-programma nodig.

Steevers zou de lay-out worden vernietigd bij het sparen. Het kostte mijn tijd om mijn weg hier omheen te viemen. Deze bestanden werkten vervolgens goed in Firefox, maar toonden een CSS-quirk in Internet Explorer die de lay-out vernietigt, opnieuw. Na het vissen met de gekoppelde CSS-bestanden voor uren zonder baten, ontdekte ik dat Internet & Nbsp; Explorer vond het BOMFED HTML-bestand niet leuk. Nooit meer.

Ik heb dit ook gevonden in Wikipedia:

De Shebang-tekens worden weergegeven door dezelfde twee bytes in uitgebreide ASCII-coderingen, waaronder UTF-8, die vaak wordt gebruikt voor scripts en andere tekstbestanden op de huidige UNIX-achtige systemen. UTF-8-bestanden kunnen echter beginnen met het optionele byte-ordermarkering (BOM); Als de functie “Exec” specifiek de bytes 0x23 0x21 detecteert, dan zal de aanwezigheid van de BOM (0xef 0xbb 0xbf) voordat de Shebang de scriptinterpreter van uitvoering wordt uitgevoerd. Sommige autoriteiten adviseren het gebruik van de byte-ordermarkering in POSIX (Unix-achtige) scripts, [15] om deze reden en voor bredere interoperabiliteit en filosofische zorgen


Antwoord 17

Hier is mijn ervaring met Visual Studio, Sourcetreeen Bitbucket pull-verzoeken, die heeft me wat problemen gegeven:

Het blijkt dus dat een stuklijst met een handtekening een rode stip op elk bestand zal bevatten bij het beoordelen van een pull-verzoek (het kan behoorlijk vervelend zijn).

Als je de muisaanwijzer erop plaatst, zal het een karakter als “ufeff” tonen, maar het blijkt dat Sourcetree dit soort bytemarks niet toont, dus het zal hoogstwaarschijnlijk in je pull-verzoeken terechtkomen, wat in orde zou moeten zijn, want dat is hoe Visual Studio 2017 nu nieuwe bestanden codeert, dus misschien moet Bitbucket dit negeren of het op een andere manier laten zien, meer info hier:

Red-dot-markering BitBucket diff-weergave


Antwoord 18

UTF met een stuklijst is beter als u UTF-8 in HTML-bestanden gebruikt en als u Servisch Cyrillisch, Servisch Latijn, Duits, Hongaars of een andere exotische taal op dezelfde pagina gebruikt.

Dat is mijn mening (30 jaar computer- en IT-industrie).

Other episodes