Problemi di codifica HTML: viene visualizzato il carattere "Â" anziché "& nbsp;"


203

Ho un'app legacy che sta iniziando a comportarsi male, per qualsiasi motivo non ne sono sicuro. Genera un sacco di HTML che viene trasformato in report PDF da ActivePDF.

Il processo funziona in questo modo:

  1. Estrai un modello HTML da un DB con token da sostituire (ad es. "~ CompanyName ~", "~ CustomerName ~", ecc.)
  2. Sostituisci i token con dati reali
  3. Riordina l'HTML con una semplice funzione regex che formatta i valori degli attributi dei tag HTML (garantisce virgolette, ecc., Poiché il motore di rendering di ActivePDF odia qualsiasi cosa tranne le virgolette singole attorno ai valori degli attributi)
  4. Invia l'HTML a un servizio Web che crea il PDF.

Da qualche parte in quel pasticcio, gli spazi non-break dal template HTML (  s) stanno codificando come ISO-8859-1 in modo da apparire erroneamente come un carattere "Â" quando si visualizza il documento in un browser (FireFox). ActivePDF vomita su questi caratteri non UTF8.

La mia domanda: dal momento che non so da dove provenga il problema e non ho tempo di investigarlo, esiste un modo semplice per ricodificare o trovare e sostituire i personaggi cattivi? Ho provato a inviarlo tramite questa piccola funzione che ho messo insieme, ma lo trasforma in un gobbledegook non cambia nulla.

Private Shared Function ConvertToUTF8(ByVal html As String) As String
    Dim isoEncoding As Encoding = Encoding.GetEncoding("iso-8859-1")
    Dim source As Byte() = isoEncoding.GetBytes(html)
    Return Encoding.UTF8.GetString(Encoding.Convert(isoEncoding, Encoding.UTF8, source))
End Function

Qualche idea?

MODIFICARE:

Per ora ci sto cavando, anche se non sembra una buona soluzione:

Private Shared Function ReplaceNonASCIIChars(ByVal html As String) As String
    Return Regex.Replace(html, "[^\u0000-\u007F]", " ")
End Function

2
L'HTML contiene qualche meta-informazione per descrivere il suo set di caratteri?
Rowland Shaw,

1
[Commento precedente eliminato] Risposta breve: no.
Cᴏʀʏ

1
Per me ha funzionato: utf8_decode ()
ursuleacv il

Risposte:


340

Da qualche parte in quel pasticcio, gli spazi non interrotti dal modello (i) HTML vengono codificati come ISO-8859-1 in modo che vengano visualizzati in modo errato come carattere "Â"

Sarebbe quindi la codifica in UTF-8, non in ISO-8859-1. Il carattere di spazio non-break è byte 0xA0 in ISO-8859-1; quando codificato in UTF-8 sarebbe 0xC2,0xA0, che, se lo si visualizza (erroneamente) come ISO-8859-1 viene visualizzato come " ". Ciò include un nbsp finale che potresti non notare; se quel byte non è presente, qualcos'altro ha trasformato il tuo documento e dobbiamo vedere più in alto per scoprire cosa.

Qual è la regexp, come funziona il templating? Sembra che ci sia un vero parser HTML coinvolto da qualche parte se le tue  stringhe vengono (correttamente) trasformate in caratteri U + 00A0 NON-BREAKING SPACE. In tal caso, potresti semplicemente elaborare il tuo modello in modo nativo nel DOM e chiedergli di serializzare utilizzando la codifica ASCII per mantenere i caratteri non ASCII come riferimenti a caratteri. Ciò ti impedirebbe anche di dover eseguire regex post-elaborazione sull'HTML stesso, che è sempre un'attività altamente complicata.

Bene comunque, per ora puoi aggiungere uno dei seguenti al tuo documento <head>e vedere se questo lo fa apparire proprio nel browser:

  • per HTML4: <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
  • per HTML5: <meta charset="utf-8">

Se lo hai fatto, qualsiasi problema rimanente è colpa di ActivePDF.


20
Non lo consiglierei <meta charset="utf-8">ancora. La http-equivversione è ancora valida in HTML5 ed è supportata meglio.
bobince

8
Risposte da quale utilizzare: <meta charset = 'utf-8'> vs <meta http-equiv = 'Content-Type' afferma che la versione breve è ben supportata.
Richard Ayotte,

1
Trovato un'altra fonte Funziona in tutti i browser
Richard Ayotte,

Funziona con tutti i browser moderni . Certamente non funziona su tutti i browser legacy e di nicchia (ad es. Mobile) o su tutti i ragni.
Bobince,

3
"Da qualche parte in quel casino" ... LOL! Bello aperto! Buona risposta! +1
Resist Design

24

Se qualcuno ha avuto lo stesso problema e il set di caratteri era già corretto, basta fare questo:

  1. Copia tutto il codice all'interno del file .html.
  2. Apri il blocco note (o qualsiasi editor di testo di base) e incolla il codice.
  3. Vai "File -> Salva con nome"
  4. Inserisci il nome del tuo file "esempio.html" (Seleziona "Salva come tipo: Tutti i file ( . )")
  5. Seleziona Codifica come UTF-8
  6. Premi Salva e ora puoi eliminare il tuo vecchio file .html e la codifica dovrebbe essere corretta

2
Questo è stato per me. Ora in sublime dice UTF-8 with BOMinvece di UTF-8. Per vederlo nel testo sublime, devi show_encodingimpostare su trueImpostazioni - Utente.
J86

Ho avuto il problema che mostra  invece di », amd Quando si utilizza questa soluzione il problema è stato risolto ma c'è un avviso php: Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at D:\Program Files\wamp\wamp\www\projects\kerala\kerala_public_html\edit\business_details.php:1) in D:\Program Files\wamp\wamp\www\projects\kerala\kerala_public_html\user\include\fg_membersite.php on line 152
SCC

Questa soluzione ha funzionato per me. Stavo lavorando in notepad ++, e quando l'ho salvato in MS Notepad di base come UTF-8, dopo aver aperto il nuovo file in notepad ++, la codifica è stata impostata su UTF-8-BOM (che non sono sicuro di cosa significhi). Comunque, quello sembra essere stato il problema per me.
BoltKey,

Grazie! Questo ha funzionato. Vedo nella richiesta / risposta il file (nel mio caso, ASPX) è stato codificato come UTF-8. Notepad ++ lo aveva anche codificato in UTF-8. Che diamine, vero? Ma la tua soluzione ha fatto il trucco. Per me, era una frase spagnola che non codificava correttamente nella pagina. Ho letto altrove di non usare la BOM UTF-8 per lo spagnolo, ma è stato risolto per me.
user3621633

13

Problema: anche se stavo affrontando il problema in cui stavamo inviando '£' con una stringa nella richiesta POST al sistema CRM, ma quando stavamo facendo la chiamata GET da CRM, stava restituendo '£' con un contenuto di stringa. Quindi quello che abbiamo analizzato è che "£" veniva convertito in "£" .

Analisi: il problema che abbiamo riscontrato dopo aver fatto delle ricerche è che nella chiamata POST abbiamo impostato HttpWebRequest ContentType come "text / xml" mentre in GET Call era "text / xml; charset: utf-8" .

Soluzione: così come parte della soluzione abbiamo incluso il set di caratteri: utf-8 nella richiesta POST e funziona.


0

Nel mio caso questo (a with caret) si è verificato nel codice che ho generato da Visual Studio usando il mio strumento per generare codice. È stato facile da risolvere:

Seleziona spazi singoli () nel documento. Dovresti essere in grado di vedere molti spazi singoli che sembrano diversi dagli altri spazi singoli, non sono selezionati. Seleziona questi altri spazi singoli: sono i responsabili dei caratteri indesiderati nel browser. Vai a Trova e sostituisci con spazio singolo (). Fatto.

PS: è più facile vedere tutti i caratteri simili quando si posiziona il cursore su uno o se lo si seleziona in VS2017 +; Spero che altri IDE possano avere caratteristiche simili


-1

Nel mio caso stavo ottenendo il segno di croce latina invece di nbsp, anche se una pagina era correttamente codificata nell'UTF-8. Nulla di cui sopra ha aiutato a risolvere il problema e ho provato tutto.

Alla fine la modifica del carattere per IE (con CSS specifici del browser) mi ha aiutato, stavo usando Helvetica-Nue come un carattere del corpo che cambia in Arial ha risolto il problema.


Il motivo per cui il cambio di carattere può aver aiutato potrebbe essere perché uno dei caratteri non conteneva il personaggio in questione, quindi quello che hai visto era un personaggio vuoto. Ma questo non ha risolto il problema, lo ha solo coperto.
Oliver Hausler,

-2

Avevo lo stesso tipo di problema. Apparentemente è semplicemente perché PHP non riconosce utf-8.

All'inizio mi stavo strappando i capelli quando un segno di "£" continuava ad apparire come "£", nonostante appaia bene in DreamWeaver. Alla fine mi sono ricordato di aver avuto problemi con i collegamenti relativi al file indice, quando le pagine, se visualizzate direttamente, avrebbero funzionato con le presentazioni, ma non quando utilizzate con un include (ma questo è a parte il punto. Comunque mi chiedevo se questo potesse essere un problema simile, quindi invece di inserire nella pagina con cui ho avuto problemi, l'ho semplicemente inserito nel file index.php - problema risolto dappertutto.



-2

Bene, ho riscontrato questo problema anche nei miei pochi siti Web e tutto ciò che devo fare è personalizzare il fetler dei contenuti per le entità HTML. prima ancora di più li elimino di più, quindi basta cambiarti html fiter o funzione di analisi per la pagina e ha funzionato. È principalmente dovuto agli editor HTML nella maggior parte dei CMS. il modo in cui archiviano analizza i dati ha causato questo problema (Nel mio caso). Che ciò possa aiutare anche nel tuo caso

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.