Probleme mit der HTML-Codierung - Das Zeichen "Â" wird anstelle von "& nbsp;" angezeigt.


203

Ich habe eine Legacy-App, die sich gerade schlecht benimmt, aus welchem ​​Grund auch immer ich nicht sicher bin. Es generiert eine Reihe von HTML-Code, der von ActivePDF in PDF-Berichte umgewandelt wird.

Der Prozess funktioniert folgendermaßen:

  1. Ziehen Sie eine HTML-Vorlage aus einer Datenbank mit darin zu ersetzenden Token (z. B. "~ Firmenname ~", "~ Kundenname ~" usw.).
  2. Ersetzen Sie die Token durch echte Daten
  3. Räumen Sie den HTML-Code mit einer einfachen Regex-Funktion auf, mit der die Eigenschaft HTML-Tag-Attributwerte formatiert (stellt Anführungszeichen usw. sicher, da die Rendering-Engine von ActivePDF alles andere als einfache Anführungszeichen um Attributwerte hasst).
  4. Senden Sie den HTML-Code an einen Webdienst, der die PDF-Datei erstellt.

Irgendwo in diesem Durcheinander werden die nicht unterbrechenden Leerzeichen aus der HTML-Vorlage (den HTML-Vorlagen  ) als ISO-8859-1 codiert, sodass sie beim Anzeigen des Dokuments in einem Browser (FireFox) fälschlicherweise als "Â" angezeigt werden. ActivePDF kotzt auf diese Nicht-UTF8-Zeichen.

Meine Frage: Da ich nicht weiß, woher das Problem stammt und keine Zeit habe, es zu untersuchen, gibt es eine einfache Möglichkeit, die fehlerhaften Zeichen neu zu codieren oder zu finden und zu ersetzen? Ich habe versucht, es durch diese kleine Funktion zu senden, die ich zusammengeschmissen habe, aber es verwandelt alles in ein verschlungenes Buch, das nichts ändert.

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

Irgendwelche Ideen?

BEARBEITEN:

Damit komme ich vorerst zurecht, obwohl es kaum eine gute Lösung zu sein scheint:

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

2
Enthält der HTML-Code Metainformationen zur Beschreibung seines Zeichensatzes?
Rowland Shaw

1
[Vorheriger Kommentar gelöscht] Kurze Antwort: Nein.
22.

1
Für mich gearbeitet: utf8_decode ()
ursuleacv

Antworten:


339

Irgendwo in diesem Durcheinander werden die nicht unterbrechenden Leerzeichen aus der HTML-Vorlage (den HTML-Vorlagen) als ISO-8859-1 codiert, sodass sie fälschlicherweise als "Â" angezeigt werden

Das wäre dann eine Kodierung nach UTF-8, nicht nach ISO-8859-1. Das nicht unterbrechende Leerzeichen ist in ISO-8859-1 das Byte 0xA0. Wenn es in UTF-8 codiert ist, ist es 0xC2,0xA0. Wenn Sie es (fälschlicherweise) als ISO-8859-1 ansehen, wird es als ausgegeben " ". Dazu gehört ein nachfolgender nbsp, den Sie möglicherweise nicht bemerken. Wenn dieses Byte nicht vorhanden ist, hat etwas anderes Ihr Dokument beschädigt, und wir müssen weiter oben nachsehen, um herauszufinden, was passiert.

Was ist der reguläre Ausdruck, wie funktioniert das Templating? Es scheint irgendwo einen richtigen HTML-Parser zu geben, wenn Ihre  Zeichenfolgen (korrekt) in U + 00A0 NON-BREAKING SPACE-Zeichen umgewandelt werden. In diesem Fall können Sie Ihre Vorlage einfach nativ im DOM verarbeiten und sie bitten, mithilfe der ASCII-Codierung zu serialisieren, um Nicht-ASCII-Zeichen als Zeichenreferenzen beizubehalten. Das würde auch verhindern, dass Sie Regex-Nachbearbeitung für HTML selbst durchführen müssen, was immer ein sehr zweifelhaftes Geschäft ist.

Nun, für den Moment können Sie Ihrem Dokument eines der folgenden Elemente hinzufügen <head>und prüfen, ob es im Browser richtig aussieht:

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

Wenn Sie dies getan haben, ist das verbleibende Problem die Schuld von ActivePDF.


20
Ich würde es noch nicht empfehlen <meta charset="utf-8">. Die http-equivVersion ist weiterhin in HTML5 gültig und wird besser unterstützt.
Bobince

8
Antworten, von denen verwendet werden soll: <meta charset = 'utf-8'> vs <meta http-equiv = 'Content-Type' geben an, dass die Kurzversion gut unterstützt wird.
Richard Ayotte

1
Eine andere Quelle gefunden Dies funktioniert in allen Browsern
Richard Ayotte

Es funktioniert in allen modernen Browsern. Es funktioniert sicherlich nicht in allen Legacy- und Nischenbrowsern (z. B. mobilen Browsern) oder auf allen Spinnen.
Bobince

3
"Irgendwo in diesem Durcheinander" ... LOL! Schön offen! Gute Antwort! +1
Resist Design

24

Wenn jemand das gleiche Problem wie ich hatte und der Zeichensatz bereits korrekt war, tun Sie einfach Folgendes:

  1. Kopieren Sie den gesamten Code in die HTML-Datei.
  2. Öffnen Sie den Editor (oder einen beliebigen einfachen Texteditor) und fügen Sie den Code ein.
  3. Gehen Sie zu "Datei -> Speichern unter"
  4. Geben Sie Ihren Dateinamen "example.html" ein (Wählen Sie "Dateityp: Alle Dateien ( . )")
  5. Wählen Sie Codierung als UTF-8
  6. Klicken Sie auf Speichern und Sie können jetzt Ihre alte HTML-Datei löschen und die Codierung sollte korrigiert werden

2
Das hat es für mich getan. Jetzt im Erhabenen heißt es UTF-8 with BOMstatt UTF-8. Um dies in erhabener Text zu sehen, müssen Sie show_encodingfestlegen truein Einstellungen - Benutzer.
J86

Ich hatte das Problem, dass anstelle von »und amd angezeigt wurde. Bei Verwendung dieser Lösung wurde das Problem behoben, aber es gibt eine PHP-Warnung: 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

Diese Lösung hat bei mir funktioniert. Ich habe in Notepad ++ gearbeitet, und als ich es in Basic MS Notepad als UTF-8 gespeichert habe, wurde nach dem Öffnen der neuen Datei in Notepad ++ die Codierung auf UTF-8-BOM gesetzt (was ich nicht sicher bin, was das bedeutet). Jedenfalls scheint das das Problem für mich gewesen zu sein.
BoltKey

Danke dir! Das hat den Trick gemacht. Ich sehe in der Anfrage / Antwort, dass die Datei (in meinem Fall ASPX) als UTF-8 codiert wurde. Notepad ++ hatte es auch in UTF-8 codiert. Was zum Teufel, richtig? Aber Ihre Lösung hat es geschafft. Für mich war es eine spanische Phrase, die auf der Seite nicht richtig codiert war. Ich habe an anderer Stelle gelesen, dass UTF-8 BOM nicht für Spanisch verwendet werden soll, aber es wurde für mich behoben.
user3621633

13

Problem: Sogar ich hatte das Problem, dass wir '£' mit einer Zeichenfolge in der POST-Anforderung an das CRM-System gesendet haben, aber als wir den GET-Aufruf aus CRM ausführten, gab es '£' mit einem Zeichenfolgeninhalt zurück. Wir haben also analysiert, dass '£' in '£' umgewandelt wurde .

Analyse: Der Fehler, den wir nach Recherchen festgestellt haben, ist, dass wir im POST-Aufruf HttpWebRequest ContentType als "text / xml" festgelegt haben, während es im GET-Aufruf "text / xml; Zeichensatz: utf-8" war .

Lösung: Als Teil der Lösung haben wir den Zeichensatz utf-8 in die POST-Anfrage aufgenommen und er funktioniert.


0

In meinem Fall trat dies (a mit Caret) in Code auf, den ich aus Visual Studio mit meinem eigenen Tool zum Generieren von Code generiert habe. Es war leicht zu lösen:

Wählen Sie einzelne Leerzeichen () im Dokument aus. Sie sollten in der Lage sein, viele einzelne Räume zu sehen, die sich von den anderen einzelnen Räumen unterscheiden. Sie sind nicht ausgewählt. Wählen Sie diese anderen einzelnen Leerzeichen aus - sie sind für die unerwünschten Zeichen im Browser verantwortlich. Gehen Sie zu Suchen und durch ein einzelnes Leerzeichen ersetzen (). Getan.

PS: Es ist einfacher, alle ähnlichen Zeichen zu sehen, wenn Sie den Cursor auf eines setzen oder wenn Sie es in VS2017 + auswählen. Ich hoffe, dass andere IDEs ähnliche Funktionen haben


-1

In meinem Fall bekam ich ein lateinisches Kreuzzeichen anstelle von nbsp, obwohl eine Seite korrekt in UTF-8 codiert war. Nichts von oben half bei der Lösung des Problems und ich versuchte alles.

Am Ende half das Ändern der Schriftart für IE (mit browserspezifischem CSS). Ich verwendete Helvetica-Nue als Body-Schriftart, die auf Arial geändert wurde, um das Problem zu beheben.


Der Grund, warum das Wechseln der Schriftart möglicherweise geholfen hat, kann sein, dass eine der Schriftarten das betreffende Zeichen nicht enthielt. Sie haben also stattdessen ein leeres Zeichen gesehen. Aber das hat das Problem nicht gelöst, sondern nur vertuscht.
Oliver Hausler

-2

Ich hatte das gleiche Problem. Anscheinend liegt es einfach daran, dass PHP utf-8 nicht erkennt.

Ich riss mir zuerst die Haare aus, als ein £ -Zeichen immer wieder als £ angezeigt wurde, obwohl es in DreamWeaver in Ordnung zu sein schien. Schließlich erinnerte ich mich, dass ich Probleme mit Links in Bezug auf die Indexdatei hatte, wenn die Seiten, wenn sie direkt angezeigt wurden, mit Diashows funktionieren würden, aber nicht, wenn sie mit einem Include verwendet würden (aber das ist nebensächlich. Wie auch immer, ich fragte mich, ob dies eine sein könnte ähnliches Problem, also anstatt es auf die Seite zu setzen, mit der ich Probleme hatte, habe ich es einfach in die Datei index.php eingefügt - das Problem wurde durchgehend behoben.



-2

Nun, ich habe dieses Problem auch auf meinen wenigen Websites und alles, was ich tun muss, ist den Content Fetler für HTML-Entites anzupassen. davor lösche ich sie mehr, als ich habe, also ändere einfach deinen HTML-Fiter oder die Parsing-Funktion für die Seite und es hat funktioniert. Dies liegt hauptsächlich an HTML-Editoren in den meisten CMS. Die Art und Weise, wie sie die Daten analysieren, hat dieses Problem verursacht (in meinem Fall). Möge dies auch in Ihrem Fall helfen

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.