Qual è la differenza tra UTF-8 e UTF-8 senza BOM?

https://stackoverflow.com/questions/2223882

19-09-2019
|

Domanda

Cosa c'è di diverso tra UTF-8 e UTF-8 senza BOM?Quale è meglio?

Soluzione

Il BOM UTF-8 è una sequenza di byte all'inizio di un testo-stream (EF BB BF), che permette al lettore di indovinare in modo più affidabile di un file come in fase di codifica UTF-8.

Normalmente, la distinta viene utilizzata per segnalare l'endian di una codifica, ma poiché endianness è irrilevante per UTF-8, la distinta è inutile.

Secondo il standard Unicode, il BOM per UTF-8 file non è raccomandato :

  Schemi
2,6 Encoding

... L'utilizzo di una distinta base non è né necessario né raccomandato per UTF-8, ma può essere   incontrato in contesti in cui UTF-8 i dati vengono convertiti da altri   forme di codifica che usano una distinta o dove la distinta viene utilizzato come UTF-8   firma. Vedere la sottosezione “Byte Order Mark” in Sezione 16.8,   Speciali ,   per ulteriori informazioni.

Altri suggerimenti

Le altre risposte eccellenti già risposto che:

Non v'è alcuna differenza ufficiale tra UTF-8 e BOM-ed UTF-8
Una BOM-ed UTF-8 stringa inizierà con le seguenti tre byte. EF BB BF
Quei byte, se presenti, devono essere ignorati durante l'estrazione la stringa dal file / flusso.

Ma, come informazioni aggiuntive rispetto a questo, la distinta per UTF-8 potrebbe essere un buon modo per "odore" se una stringa è stato codificato in UTF-8 ... Oppure potrebbe essere una stringa legittima in qualsiasi altra codifica. ..

Ad esempio, i dati [EF BB BF 41 42 43] potrebbe essere:

ISO-8859-1 stringa "ï» ¿ABC"
UTF-8 stringa "ABC"

Così, mentre può essere fresco di riconoscere la codifica di un file di contenuti, cercando nei primi byte, non si dovrebbe fare affidamento su questo, come profili per l'esempio precedente

codifiche dovrebbero essere noti, non intuito.

Ci sono almeno tre problemi con mettere una distinta in file codifica UTF-8.

I file che non tengono testo non sono vuoti perché contengono sempre la distinta base.
I file che contengono il testo che è all'interno del sottoinsieme ASCII di UTF-8 non è più se stessi ASCII perché la distinta non è ASCII, il che rende alcuni strumenti esistenti abbattere, e può essere impossibile per gli utenti di sostituire tali strumenti legacy.
Non è possibile concatenare più file insieme perché ogni file ha ora una BOM all'inizio.

E, come altri hanno già detto, non è né sufficiente né necessario avere una distinta base per rilevare che qualcosa sta UTF-8:

Non è sufficiente perché una sequenza di byte arbitrario può accadere per iniziare con la sequenza esatta che costituisce la distinta.
Non è necessario perché si può solo leggere i byte come se fossero UTF-8; se questo riesce, è, per definizione, valida UTF-8.

It'a una vecchia domanda con molte risposte, ma una cosa deve essere aggiunto.

Tutte le risposte sono molto generali.Quello che vorrei aggiungere sono esempi di BOM uso che effettivamente causare problemi reali, e ancora molte persone non sanno su di esso.

BOM pause script

Gli script di Shell, Perl, Python script, script Ruby, Node.js script o qualsiasi altro eseguibile che deve essere eseguito da un interprete - tutto inizia con un shebang linea che assomiglia a una di quelle:

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

Si indica al sistema quale interprete deve essere eseguito quando si richiama ad uno script.Se lo script è codificato in UTF-8, si può essere tentati di includere un BOM all'inizio.Ma in realtà il "#!" caratteri non sono solo i personaggi.Sono, infatti, una numero magico che succede ad essere composta di due caratteri ASCII.Se ci metti qualcosa (come un BOM) prima di quei personaggi, quindi il file sarà simile a avuto un diverso numero magico e che può portare a problemi.

Vedi Wikipedia, articolo:Inserita sezione:Numero magico:

La shebang i personaggi sono rappresentati con le stesse due byte in ASCII esteso codifiche, tra cui la codifica UTF-8, che è comunemente usato per script e altri file di testo attuali sistemi Unix-like.Tuttavia, I file UTF-8 può iniziare con le opzionale BOM (byte order mark);se il "exec" la funzione rileva in particolare il byte 0 x 23 e 0x21, quindi il presenza della DISTINTA base (0xEF 0xBB 0xBF) prima che la shebang impedirà l'interprete di script venga eseguito. Alcune autorità consigliano di contro l'uso del contrassegno di ordine di byte in POSIX (Unix-like), script,[14] per questo motivo, e per una più ampia interoperabilità e filosofico le preoccupazioni.Inoltre, un byte order mark non è necessaria in UTF-8, come tale codifica non hanno le modalita ' di problemi;essa serve solo a identificare la codifica UTF-8.[enfasi aggiunta]

BOM è illegale in JSON

Vedere RFC 7159, Sezione 8.1:

Implementazioni NON DEVE aggiungere un contrassegno di ordine di byte all'inizio di un testo JSON.

BOM è ridondante in JSON

Non solo è illegale in JSON, è anche non necessario per determinare il carattere di codifica perché ci sono più affidabili modi per determinare senza ambiguità sia la codifica dei caratteri e le modalita ' utilizzato in qualsiasi file JSON (vedere questa risposta per i dettagli).

BOM pause JSON parser

Non solo è illegale in JSON e non necessario, è in realtà interruzioni di tutti i software che determinare la codifica utilizzando il metodo presentato in RFC 4627:

Determinare la codifica e le modalita ' di JSON, esaminando i primi 4 byte per 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

Ora, se il file inizia con DISTINTA base sarà simile a questo:

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

Nota che:

UTF-32BE non inizia con tre NULs in modo da non essere riconosciuto
UTF-32LE il primo byte non è seguito da 3 NULs in modo da non essere riconosciuto
UTF-16BE ha solo 1 NUL nei primi 4 byte in modo da non essere riconosciuto
UTF-16LE ha solo 1 NUL nei primi 4 byte in modo da non essere riconosciuto

A seconda dell'implementazione, tutti quelli che possono essere interpretati erroneamente come UTF-8 e quindi mal o respinto come non valido UTF-8, o non riconosciuto a tutti.

Inoltre se la realizzazione di test per la JSON valido come vi consiglio, rifiuterà anche l'ingresso che è codificato in UTF-8, perché non iniziare con un carattere ASCII < 128 come dovrebbe secondo l'RFC.

Altri formati di dati

BOM in JSON non è necessario, è illegale e si rompe il software che funziona correttamente secondo la RFC.Dovrebbe essere un nobrainer di non utilizzare dopo e poi ancora, ci sono sempre persone che insistono su breaking JSON tramite Distinte base, commenti, diversi citazione regole o diversi tipi di dati.Naturalmente chiunque è libero di usare cose come Distinte materiali o quant'altro, se ne avete bisogno, proprio non la chiamate JSON poi.

Per altri formati di dati di JSON, date un'occhiata come sembra veramente.Se il solo codifiche UTF-* e il primo carattere deve essere un carattere ASCII inferiore a 128, allora hai già tutte le informazioni necessarie per determinare sia la codifica e il formato di rappresentazione dei dati.L'aggiunta di Distinte base, anche come funzionalità opzionale sarebbe solo rendere più complicato e soggetto a errori.

Altri usi di BOM

Come per gli usi al di fuori di JSON o script, penso che ci sono già molto buone risposte qui.Volevo aggiungere informazioni più dettagliate, in particolare, sulle scripting e la serializzazione, perché è un esempio di caratteri BOM causando problemi reali.

Che cosa c'è di diverso tra UTF-8 e UTF-8 senza BOM?

Risposta breve:. In UTF-8, una distinta è codificato come il EF BB BF byte all'inizio del file

Risposta lunga:

In origine, ci si aspettava che Unicode verrebbe codificato in UTF-16 / UCS-2 . Il BOM è stato progettato per questa forma di codifica. Quando si dispone di unità di codice di 2 byte, è necessario indicare quali ordinare i due byte sono in, e una convenzione comune per fare questo è quello di includere il carattere U + FEFF come un "Ordine Mark Byte" all'inizio dei dati. Il carattere U + FFFE è permanentemente assegnato in modo che la sua presenza può essere utilizzato per rilevare l'ordine dei byte errato.

UTF-8 ha lo stesso ordine dei byte, indipendentemente dalla piattaforma endianness, quindi un byte order mark non è necessario. Tuttavia, può verificarsi (come la sequenza di byte EF BB FF) nei dati che è stato convertito in UTF-8 da UTF-16, o come una "firma" per indicare che i dati sono UTF-8.

Che è meglio?

Senza. Come rispose Martin Cote, lo standard Unicode lo sconsiglia. Essa provoca problemi con software non-BOM-aware.

Un modo migliore per rilevare se un file è UTF-8 è quello di eseguire un controllo di validità. UTF-8 ha regole severe su ciò che le sequenze di byte sono validi, quindi la probabilità di un falso positivo è trascurabile. Se una sequenza di byte assomiglia UTF-8, probabilmente lo è.

UTF-8 con BOM è meglio identificati. Ho raggiunto questa conclusione nel modo più duro. Sto lavorando su un progetto in cui uno dei risultati è un file CSV , compresi i caratteri Unicode.

Se il file CSV viene salvato senza una distinta base, Excel pensa che sia ANSI e mostra senza senso. Una volta aggiunto "EF BB BF" nella parte anteriore (per esempio, da ri-salvarlo utilizzando il blocco note con UTF-8, o Notepad ++ con UTF-8 con BOM), Excel apre bene

Anteporre il carattere BOM ai file di testo Unicode è raccomandato da RFC 3629: "UTF-8, un formato di trasformazione della norma ISO 10646", Novembre 2003 a http://tools.ietf.org/html/rfc3629 (quest'ultimo informazioni disponibili all'indirizzo: http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM -FEFF-EFBBBF.html )

BOM tende ad espandersi (no pun intended (sic)) da qualche parte, da qualche parte. E quando si sfili (ad esempio, non viene riconosciuto dai browser, editori, ecc), si presenta come i personaggi strani ï»¿ all'inizio del documento (ad esempio, file HTML, JSON risposta , RSS , etc.) e fa sì che il tipo di imbarazzi come il questione codifica recente sperimentato durante la parlare di Obama su Twitter .

E 'molto fastidioso quando si presenta in luoghi difficili da eseguire il debug o quando il test viene trascurata. Quindi è meglio evitare a meno che non è necessario utilizzarlo.

Domanda: Cosa c'è di diverso tra UTF-8 e UTF-8 senza BOM? Quale è meglio?

Ecco alcuni estratti dell'articolo Wikipedia sul byte order mark (BOM) che credo offrono una risposta solida a questa domanda.

Sul significato della distinta base e UTF-8:

Lo standard Unicode permette la BOM in UTF-8 , ma non richiede o raccomandare l'uso. l'ordine dei byte non ha alcun significato in UTF-8, quindi la sua utilizzare solo in UTF-8 è quello di segnalare alla partenza che il flusso di testo è codificato in UTF-8.

Argomento per non con una distinta base:

La motivazione principale per non usare una distinta base è retrocompatibilità con il software che non è Unicode-aware ... Un'altra motivazione per non aver utilizzando una distinta base è quello di incoraggiare UTF-8 come codifica "default".

Argomento per con una distinta base:

L'argomento per l'utilizzo di una distinta base è che senza di essa, analisi euristica è   necessaria per determinare quali di carattere codifica di un file utilizza.   Storicamente tale analisi, distinguere varie codifiche a 8 bit, è   complicato e soggetto a errori, e talvolta lento. Un certo numero di librerie   sono a disposizione per facilitare il compito, come Mozilla universale Charset   Componenti Detector e internazionale per Unicode.

programmatori erroneamente supporre che il rilevamento di UTF-8 è ugualmente   difficile (non è perché la maggior parte delle sequenze di byte   non sono validi UTF-8, mentre le codifiche queste librerie stanno cercando di   distinguere consentire tutte le possibili sequenze di byte). Quindi non tutto   programmi Unicode-aware eseguire tale analisi e invece si affidano a   la distinta base.

In particolare, Microsoft compilatori e interpreti, e molti   pezzi di software in Microsoft Windows, come Notepad non lo farà   leggere correttamente testo UTF-8 a meno che non ha soltanto caratteri ASCII o si   inizia con la distinta base, e aggiungerà una distinta base per l'avvio durante il salvataggio di testo   come UTF-8. Google Documenti aggiungerà una distinta quando un documento Microsoft Word è   scaricato come un file di testo.

su cui è meglio, CON o SENZA il BOM:

Il IETF raccomanda che se un protocollo (a) utilizza sempre UTF-8, o (b) presenta qualche altro modo per indicare quale codifica viene utilizzato, allora “dovrebbe vietare l'uso di U + FEFF come una firma.”

La mia conclusione:

Utilizzare il BOM solo se la compatibilità con un software è assolutamente essenziale.

Si noti inoltre che mentre l'articolo di Wikipedia riferimento indica che molte applicazioni Microsoft si basano sulla distinta di rilevare correttamente UTF-8, questo non è il caso di tutti applicazioni Microsoft. Ad esempio, come sottolineato da @barlop , quando si utilizza il prompt dei comandi di Windows con UTF-8 ^†, comandi quali type e more non aspettatevi la distinta di essere presenti. Se la distinta è presente, può essere problematico come lo è per altre applicazioni.

chcp offre supporto per UTF-8 ( senza il BOM) tramite la pagina codice 65001 .

Citato nella parte inferiore della pagina Wikipedia su BOM: http: // it .wikipedia.org / wiki / Byte-order_mark # cite_note-2

"Uso di una distinta non è richiesto né consigliato per UTF-8, ma possono essere incontrate in contesti in cui UTF-8 dati vengono convertiti da altre forme di codifica che usano una distinta o dove la distinta viene utilizzato come UTF-8 firma "

Si deve notare che per alcuni file che non deve hanno la distinta anche su Windows. Esempi sono i file SQL*plus o VBScript. Nel caso in cui tali file contiene una distinta base si ottiene un errore quando si tenta di eseguire loro.

Questa domanda ha già un milione e uno-risposte e molti di loro sono abbastanza buoni, ma ho voluto provare a chiarire quando dovrebbe o non dovrebbe essere utilizzata una distinta base.

Come accennato, qualsiasi uso delle UTF BOM (Byte Order Mark) nel determinare se una stringa è UTF-8 o non è educato congetture. Se non v'è una corretta metadati disponibili (come charset="utf-8"), allora sapete già ciò che si suppone di utilizzare, ma per il resto è necessario per testare e fare alcune ipotesi. Si tratta di verificare se il file di una stringa viene dal inizia con il codice esadecimale di byte, EF BB BF.

Se viene rilevato un byte di codice corrispondente alla UTF-8 BOM, la probabilità è abbastanza alto per scontato che sia UTF-8 e si può passare da lì. Quando è costretto a fare questa ipotesi, tuttavia, errore addizionale verifica durante la lettura sarebbe comunque una buona idea nel caso in cui qualcosa viene in su incomprensibili. Si dovrebbe presumere solamente una distinta base non è UTF-8 (vale a dire latin-1 o ANSI) se l'ingresso sicuramente non deve essere UTF-8 sulla base di essa la fonte. Se non c'è BOM, tuttavia, si può semplicemente determinare se si suppone che sia UTF-8 convalidando contro la codifica.

Perché è una distinta base non è raccomandato?

Il software non-Unicode-aware o scarsamente compatibile può assumere è latin-1 o ANSI e non metterà a nudo la distinta dalla stringa, che può ovviamente causare problemi.
Non è veramente necessario (basta controllare se i contenuti sono conformi e sempre utilizzare UTF-8 come ripiego quando nessuna codifica compatibile può essere trovata)

Quando dovrebbe si codifica con una distinta base?

Se siete in grado di registrare i metadati in altro modo (attraverso un tag charset o del file system meta), ei programmi in uso come distinte base, si dovrebbe codificare con una distinta base. Ciò è particolarmente vero in Windows in cui nulla senza un BOM Generalmente si ritiene di utilizzare una pagina di codice legacy. Il BOM racconta programmi come Office che, sì, il testo di questo file è Unicode; ecco la codifica utilizzata.

Quando si scende ad esso, gli unici file che io abbia mai veramente hanno problemi con sono CSV. A seconda del programma, esso sia deve, o non deve avere una distinta base. Ad esempio, se si sta utilizzando Excel 2007+ su Windows, esso deve essere codificato con una distinta base, se si desidera aprire agevolmente e non devono ricorrere a importare i dati.

UTF-8 con BOM aiuta solo se il file contiene in realtà alcuni caratteri non-ASCII.Se è incluso e non ci sono, quindi sarà possibile rompere le vecchie applicazioni che altrimenti avrebbero interpretato il file come file di testo ASCII.Queste applicazioni sarà sicuramente non quando si imbatte in una non di caratteri ASCII, quindi, a mio parere la DISTINTA deve essere aggiunto solo quando il file può, e deve, più essere interpretato come testo ASCII.

Edit:Voglio solo mettere in chiaro che io preferisco non avere il BOM a tutti, aggiungete se qualche vecchio spazzatura interruzioni con e di sostituzione che di applicazioni legacy non è fattibile.

Non fanno nulla da aspettarsi una DISTINTA base UTF8.

UTF-8 senza BOM BOM non ha, che non ha di meglio da UTF-8 con BOM, tranne quando il consumatore del file ha bisogno di sapere (o potrebbe beneficiare di sapere) se il file è UTF 8-codificati o meno.

Il BOM è generalmente utile per determinare l'endianness della codifica, che non è richiesto per la maggior parte dei casi di utilizzo.

Inoltre, la distinta può essere inutile rumore / dolore per quei consumatori che non sanno o cura su di esso, e può causare confusione dell'utente.

guardo questo da una prospettiva diversa. Credo che UTF-8 con BOM è meglio in quanto fornisce ulteriori informazioni sul file. Io uso UTF-8 senza BOM solo se mi trovo di fronte problemi.

Sto usando più lingue (anche cirillico ) nelle mie pagine per lungo tempo e quando i file vengono salvati senza BOM e li ri-aperto per la modifica con un editor (come cherouvim anche notato), un po ' caratteri sono danneggiati.

Si noti che Notepad salva automaticamente i file con una distinta quando si tenta di salvare un file appena creato con codifica UTF-8.

Io personalmente risparmio lato server File di scripting (ASP, .ini, aspx) con BOM e file .html senza BOM .

Quando si desidera visualizzare le informazioni codificate in UTF-8 non si possono affrontare i problemi. Dichiarare ad esempio un documento HTML come UTF-8 e avrete tutto quello visualizzato nel browser che è contenuto nel corpo del documento.

Ma questo non è il caso quando abbiamo testo, CSV e file XML, sia su Windows o Linux.

Ad esempio, un file di testo in Windows o Linux, una delle cose più facili che si possa immaginare, non è (di solito) UTF-8.

Salva come XML e dichiararla come UTF-8:

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

Non verrà visualizzato (non sarà essere letto) in modo corretto, anche se è dichiarato come UTF-8.

ho avuto una serie di dati contenenti lettere francesi, che aveva bisogno di essere salvati in formato XML per la sindacazione. Senza creare un file UTF-8 fin dall'inizio (cambiando le opzioni in IDE e "Crea nuovo file") o l'aggiunta del BOM all'inizio del file

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

Non ero in grado di salvare le lettere francesi in un file XML.

Una differenza pratico è che se si scrive uno script di shell per Mac OS X e salvarlo come semplice UTF-8, si otterrà la risposta:

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

in risposta alla linea shebang specificando quali shell che si desidera utilizzare:

#!/bin/bash

Se si salva come UTF-8, senza BOM (voce in BBEdit ) tutto sarà bene.

Come menzionato sopra, UTF-8 con BOM può causare problemi con software non-BOM-consapevole (o compatibile). una volta ho modificato i file HTML codificati come UTF-8 + BOM con la KompoZer , come cliente ha richiesto che WYSIWYG programma.

Invariabilmente il layout otterrebbe distrutto durante il salvataggio. Ha preso il mio po 'di tempo per giocherellare il mio modo per aggirare questo. Questi file poi lavorato bene in Firefox, ma ha mostrato una stranezza CSS in Internet Explorer distruggere il layout, ancora una volta. Dopo giocherellare con i file CSS collegati per ore inutilmente ho scoperto che Internet Explorer non piaceva il file BOMfed HTML. Mai più.

Inoltre, ho appena trovato questo in Wikipedia:

I caratteri shebang sono rappresentati dagli stessi due byte in codifiche ASCII estesi, tra cui UTF-8, che è comunemente usato per gli script e altri file di testo su attuali sistemi Unix-like. Tuttavia, UTF-8 file possono iniziare con il byte order mark opzionale (BOM); se la funzione "exec" rileva in particolare il byte 0x23 0x21, allora la presenza del BOM (0xEF 0xBB 0xBF) prima della shebang impedirà l'interprete di script venga eseguito. Alcune autorità raccomandano di non utilizzare il marchio ordine dei byte a POSIX (Unix-like) script, [15] per questo motivo e per una più ampia interoperabilità e le preoccupazioni filosofiche

Il Byte Order Mark (BOM) FAQ Unicode fornisce una risposta concisa :

D: Come devo trattare con distinte base

A: Qui ci sono alcune linee guida da seguire:



Un particolare protocollo (ad esempio le convenzioni Microsoft per i file .txt) possono richiedere l'uso della distinta su alcuni flussi di dati Unicode, come ad esempio   File. Quando è necessario conformarsi a tale protocollo, utilizzare una distinta base.



Alcuni protocolli consentono distinte componenti opzionali nel caso del testo senza tag. In questi casi,



Quando un flusso di dati di testo è noto per essere testo normale, ma di codifica sconosciuta, BOM può essere utilizzato come una firma. Se non c'è BOM,   la codifica potrebbe essere qualsiasi cosa.



Quando un flusso di dati di testo è noto per essere semplice testo Unicode (ma non che endian), quindi BOM può essere utilizzato come una firma. Se ci   non è BOM, il testo dovrebbe essere interpretato come big-endian.





Alcuni protocolli byte orientati aspettano caratteri ASCII all'inizio di un file. Se UTF-8 viene utilizzato con questi protocolli, l'uso del   BOM come firma forma di codifica dovrebbe essere evitato.



Se è noto il tipo preciso del flusso di dati (ad esempio Unicode big-endian o Unicode little endian), la distinta non deve essere utilizzato. Nel   particolare, ogni volta che un flusso di dati viene dichiarato UTF-16 BE   UTF-16, UTF-32BE o UTF-32LE una distinta base non deve essere utilizzato.

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

Il byte order mark (BOM) è un Unicode carattere utilizzata per segnalare endianness (ordine dei byte) di un file di testo o lo streaming. Il suo punto di codice è U + FEFF. uso BOM è opzionale, e, se utilizzato, dovrebbe apparire all'inizio del testo ruscello. Al di là del suo utilizzo specifico come Indicatore byte-ordine, la distinta carattere può anche indicare quale le varie rappresentazioni Unicode il testo è codificato in.

Sempre utilizzando un BOM nel file farà in modo che si apre sempre correttamente in un editor che supporta UTF-8 e BOM.

Il mio vero problema con l'assenza di distinta base è il seguente. Supponiamo che abbiamo un file che contiene:

abc

Senza BOM questo si apre come ANSI nella maggior parte degli editor. Così un altro utente di questo file apre e aggiunge alcuni caratteri nativi, ad esempio:

abg-αβγ

Spiacenti ... Ora il file è ancora in ANSI e indovinate un po ', "αβγ" non occupa 6 byte, ma 3. Questo non è UTF-8 e questo provoca altri problemi più avanti nella catena di sviluppo.

Ecco la mia esperienza con Visual Studio richieste di pull, SourceTree e bitbucket, che mi è stato dando qualche problema:

Così scopre distinta con la firma includerà un rosso carattere punto su ogni file in sede di revisione di una richiesta di pull (può essere molto fastidioso).

Se si passa su di esso, mostrerà un personaggio come "ufeff", ma si rivela Sorgenti non mostra questi tipi di bytemarks, quindi molto probabilmente a finire in vostre richieste di pull, che dovrebbe essere ok perché è così che VS 2017 codificare i file nuovi, in modo forse bitbucket dovrebbe ignorare questo o renderlo mostrare in un altro modo, maggiori informazioni qui:

visualizzare Red marker dot diff bitbucket

UTF con BOM è meglio se si utilizza UTF-8 nel file HTML, se si utilizza serbo cirillico, serbo latino, tedesco, lingua esotica ungherese o qualcosa nella stessa pagina. Questa è la mia opinione (30 anni di computing e settore IT).

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow