Problèmes D'encodage HTML-le caractère" Â " apparaît au lieu de " "
j'ai une application héritée qui commence à mal se comporter, pour une raison que je ne sais pas. Il génère un tas de HTML qui est transformé en rapports PDF par ActivePDF.
le procédé fonctionne comme ceci:
- tirer un modèle HTML d'un DB avec des tokens dedans pour être remplacé (par exemple" ~CompanyName~"," ~CustomerName~", etc.)
- remplacer les Jetons par des données réelles
- Tidy le HTML avec un simple fonction regex qui formate les valeurs d'attribut des balises HTML (garantit les guillemets, etc., puisque le moteur de rendu ActivePDF déteste tout sauf les guillemets simples autour des valeurs d'attribut)
- envoyez le HTML à un service web qui crée le PDF.
quelque part dans ce gâchis, les espaces non cassés du modèle HTML (les s) sont encodés comme ISO-8859-1 de sorte qu'ils apparaissent incorrectement comme un caractère" Â " lors de la visualisation de la document dans un navigateur (FireFox). ActivePDF pukes sur ces caractères non-UTF8.
ma question: comme je ne sais pas d'où vient le problème et que je n'ai pas le temps de l'étudier, y a-t-il un moyen facile de ré-encoder ou de trouver-et-remplacer les mauvais caractères? J'ai essayé de l'Envoyer à travers cette petite fonction que j'ai lancée ensemble, mais il transforme tout en livre gobé ne change rien.
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
des idées?
EDIT:
Je m'en sors pour l'instant, bien que cela ne semble pas être une bonne solution:
Private Shared Function ReplaceNonASCIIChars(ByVal html As String) As String
Return Regex.Replace(html, "[^u0000-u007F]", " ")
End Function
7 réponses
quelque part dans ce désordre, les espaces non-cassants du modèle HTML (le s) sont codés comme ISO-8859-1 de sorte qu'ils apparaissent incorrectement comme un" Â "caractère
qui serait codant pour UTF-8 alors, pas ISO-8859-1. Le caractère d'espace non-cassant est l'octet 0xA0 dans la norme ISO-8859-1; lorsqu'il est encodé à L'UTF-8,il serait 0xC2, 0xA0, ce qui, si vous le voyez (incorrectement) comme ISO-8859-1 sort comme "Â " . Cela comprend une traînée qui vous ne le remarquerez peut-être pas; si cet octet n'est pas là, alors quelque chose d'autre a abîmé votre document et nous avons besoin de voir plus loin pour savoir quoi.
Qu'est-ce que le regexp, comment fonctionne le templating? Il semblerait qu'il y ait un analyseur HTML approprié impliqué quelque part si vos chaînes sont (correctement) transformées en U+00A0 des caractères D'espace ne cassant pas. Si c'est le cas, vous pouvez simplement traiter votre modèle nativement dans le DOM, et lui demander de sérialiser en utilisant L'ASCII l'encodage de garder les caractères non-ASCII comme des références. Cela vous éviterait également d'avoir à faire le post-traitement regex sur le HTML lui-même, qui est toujours une entreprise très douteuse.
Eh bien, pour l'instant, vous pouvez ajouter un des suivants à votre document <head> et voir si cela le fait regarder à droite dans le navigateur:
- pour HTML4:
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" /> - pour HTML5:
<meta charset="utf-8">
si vous avez fait cela, alors tout problème restant est de la faute D'ActivePDF.
si quelqu'un avait le même problème que moi et que le jeu de caractères était déjà correct, faites simplement ceci:
- copiez tout le code à l'intérieur du .fichier html.
- ouvrir bloc-notes (ou tout éditeur de texte de base) et coller le code.
- Go "Fichier" - > "Enregistrer Sous"
- Entrez votre nom de fichier "exemple.html" (sélectionnez " Enregistrer sous le type: Tous les fichiers ( . )")
- sélectionner L'encodage UTF-8
- cliquez sur Enregistrer et vous pouvez maintenant supprimer votre ancien .le fichier html et l'encodage doivent être corrigés
problème: Même moi je faisais face au problème où nous envoyions '£' avec une certaine chaîne de caractères dans la demande POST au système CRM, mais quand nous faisions l'appel GET du CRM , il retournait '£' avec un certain contenu de chaîne de caractères. Donc, ce que nous avons analysé est que '£' allait être converti en 'â£' .
analyse: Pépin ce que nous avons trouvé après avoir fait des recherches, c'est que dans POST call nous avons défini HttpWebRequest ContentType comme "text/xml" alors que dans GET Call il était "text/xml; charset:utf-8" .
Solution: Ainsi comme partie de la solution nous avons inclus le jeu de caractères: utf-8 dans la demande de poste et cela fonctionne.
dans mon cas je recevais le signe de croix latine au lieu de, même qu'une page était correctement encodée dans L'UTF-8. Rien de ce qui précède n'a aidé à résoudre le problème et j'ai tout essayé.
à la fin changer la police pour IE (avec CSS spécifique au navigateur) aidé, J'utilisais Helvetica-Nue comme une police de corps changeant à L'Arial résolu le problème .
Eh bien, j'ai eu ce problème aussi dans mes quelques sites Web et tout ce que je dois faire est de personnaliser le fetler de contenu pour les entités HTML. avant que plus je les supprime plus j'ai eu, donc juste changer vous HTML fiter ou la fonction de parsing pour la page et cela a fonctionné. Il est principalement dû aux éditeurs HTML dans la plupart des CMSs. la façon dont ils enregistrent les données a causé ce problème (dans mon cas). Que cela vous aide aussi dans votre cas
j'avais le même genre de problème. Apparemment, C'est simplement parce que PHP ne reconnaît pas utf-8.
j'étais en train de déchirer mes cheveux au début quand un signe de " £ "apparaissait sans cesse comme"£", bien qu'il parût correct dans DreamWeaver. Finalement, je me suis souvenu que j'avais eu des problèmes avec les liens relatifs au fichier index, quand les pages, si vues directement fonctionnaient avec des diaporamas, mais pas quand elles étaient utilisées avec un include (mais c'est à côté du point. De toute façon, je me demandais si cela pourrait être un problème similaire, donc au lieu de mettre dans la page que j'ai eu des problèmes avec, j'ai simplement mis dans l'index.fichier php-problème corrigé dans l'ensemble.
la raison en est que PHP ne reconnaît pas utf-8.
ici, vous pouvez le vérifier pour tous les caractères spéciaux en HTML