Ik heb een verouderde app die zich net begint te misdragen, om welke reden dan ook, ik weet het niet zeker. Het genereert een heleboel HTML die door ActivePDF wordt omgezet in PDF-rapporten.
Het proces werkt als volgt:
- Trek een HTML-sjabloon uit een database met tokens erin die moeten worden vervangen (bijvoorbeeld “~CompanyName~”, “~CustomerName~”, enz.)
- Vervang de tokens door echte gegevens
- Ruim de HTML op met een eenvoudige regex-functie die eigenschapswaarden van HTML-tags opmaakt (zorgt voor aanhalingstekens, enz., aangezien de weergave-engine van ActivePDF alles haat behalve enkele aanhalingstekens rond attribuutwaarden)
- Stuur de HTML naar een webservice die de PDF maakt.
Ergens in die puinhoop worden de vaste spaties van de HTML-sjabloon (de s) gecodeerd als ISO-8859-1, zodat ze ten onrechte worden weergegeven als een “Â ” teken bij het bekijken van het document in een browser (FireFox). ActivePDF kotst op deze niet-UTF8-tekens.
Mijn vraag: aangezien ik niet weet waar het probleem vandaan komt en ik geen tijd heb om het te onderzoeken, is er dan een gemakkelijke manier om de slechte karakters opnieuw te coderen of te vinden en te vervangen? Ik heb geprobeerd het door deze kleine functie te sturen die ik bij elkaar heb gegooid, maar het verandert het allemaal in gobbledegookverandert niets.
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
Enig idee?
BEWERKEN:
Voorlopig red ik het wel, hoewel het nauwelijks een goede oplossing lijkt:
Private Shared Function ReplaceNonASCIIChars(ByVal html As String) As String
Return Regex.Replace(html, "[^\u0000-\u007F]", " ")
End Function
Antwoord 1, autoriteit 100%
Ergens in die puinhoop worden de vaste spaties van de HTML-sjabloon (de s) gecodeerd als ISO-8859-1, zodat ze onjuist worden weergegeven als een “”-teken
Dat zou dan codering zijn naar UTF-8, niet naar ISO-8859-1. Het vaste spatieteken is byte 0xA0 in ISO-8859-1; wanneer gecodeerd naar UTF-8, zou het 0xC2,0xA0 zijn, wat, als je het (onjuist) als ISO-8859-1 ziet eruit komt als "Â ". Dat omvat een trailing nbsp die u misschien niet opmerkt; als die byte er niet is, dan heeft iets anders je document verscheurd en moeten we verder kijken om erachter te komen wat.
Wat is de regexp, hoe werkt de template? Het lijkt erop dat er ergens een goede HTML-parser bij betrokken is als uw -tekenreeksen (correct) worden omgezet in U+00A0 NON-BREAKING SPACE-tekens. Als dat zo is, kunt u uw sjabloon gewoon native in de DOM verwerken en deze vragen om te serialiseren met behulp van de ASCII-codering om niet-ASCII-tekens als tekenreferenties te behouden. Dat zou ook voorkomen dat u regex-nabewerking op de HTML zelf hoeft uit te voeren, wat altijd een zeer onbetrouwbare zaak is.
Tja, voor nu kun je een van de volgende dingen toevoegen aan de <head>van je document en kijken of het er daardoor goed uitziet in de browser:
- voor HTML4:
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" /> - voor HTML5:
<meta charset="utf-8">
Als je dat hebt gedaan, is elk overblijvend probleem de schuld van ActivePDF.
Antwoord 2, autoriteit 7%
Als iemand hetzelfde probleem had als ik en de tekenset was al correct, doe dan dit:
- Kopieer alle code in het .html-bestand.
- Open Kladblok (of een andere eenvoudige teksteditor) en plak de code.
- Ga naar “Bestand -> Opslaan als”
- Voer uw bestandsnaam “example.html” in (Selecteer “Opslaan als type: Alle bestanden (.)”)
- Selecteer codering als UTF-8
- Klik op Opslaan en je kunt nu je oude .html-bestand verwijderen en de codering moet worden hersteld
Antwoord 3, autoriteit 4%
Probleem:
Zelfs ik werd geconfronteerd met het probleem waarbij we ‘£’met een string in POST-verzoek naar CRM-systeem stuurden, maar toen we de GET-oproep van CRM deden, keerde het terug ‘£ ‘met wat tekenreeksinhoud. Dus wat we hebben geanalyseerd, is dat ‘£’werd geconverteerd naar ‘£’.
Analyse:
De glitch die we hebben gevonden na onderzoek te hebben gedaan, is dat we in POST-aanroep HttpWebRequest ContentType als “text/xml”hebben ingesteld, terwijl het in GET Call “text/xml; charset:utf- was 8”.
Oplossing:
Dus als onderdeel van de oplossing hebben we de charset:utf-8in het POST-verzoek opgenomen en het werkt.
Antwoord 4
In mijn geval gebeurde dit (met een caret) in code die ik vanuit Visual Studio heb gegenereerd met mijn eigen tool voor het genereren van code. Het was gemakkelijk op te lossen:
Selecteer enkele spaties ( ) in het document. Je zou veel enkele spaties moeten kunnen zien die er anders uitzien dan de andere enkele spaties, ze zijn niet geselecteerd. Selecteer deze andere afzonderlijke spaties – zij zijn degenen die verantwoordelijk zijn voor de ongewenste tekens in de browser. Ga naar Zoeken en vervangen met enkele spatie ( ). Klaar.
PS: Het is gemakkelijker om alle gelijkaardige karakters te zien als je de cursor op een karakter plaatst of als je het selecteert in VS2017+; Ik hoop dat andere IDE’s vergelijkbare functies hebben
Antwoord 5
In mijn geval kreeg ik een Latijns kruisteken in plaats van nbsp, zelfs dat een pagina correct was gecodeerd in de UTF-8. Niets van het bovenstaande hielp bij het oplossen van het probleem en ik heb alles geprobeerd.
Uiteindelijk hielp het wijzigen van het lettertype voor IE (met browserspecifieke css), ik gebruikte Helvetica-Nue als een body-lettertype dat veranderde in de Arial en loste het probleem op.
Antwoord 6
Nou, ik heb dit probleem ook op mijn weinige websites en ik hoef alleen maar de content-fetler voor HTML-entiteiten aan te passen. daarvoor verwijder ik ze meer, dus verander gewoon je html-fiter of parseerfunctie voor de pagina en het werkte. Het is voornamelijk te wijten aan HTML-editors in de meeste CMS’en. de manier waarop ze de gegevens opslaan, veroorzaakte dit probleem (in mijn geval). Moge dit ook in jouw geval helpen
Antwoord 7
Ik had hetzelfde soort probleem. Blijkbaar is het simpelweg omdat PHP utf-8 niet herkent.
Ik was eerst mijn haar aan het uittrekken toen een ‘£’-teken bleef verschijnen als ‘£’, ondanks dat het er goed uitzag in DreamWeaver. Uiteindelijk herinnerde ik me dat ik problemen had met koppelingen met betrekking tot het indexbestand, wanneer de pagina’s, als ze rechtstreeks werden bekeken, zouden werken met diavoorstellingen, maar niet wanneer ze werden gebruikt met een include (maar dat doet er niet toe. Hoe dan ook, ik vroeg me af of dit een soortgelijk probleem, dus in plaats van het in de pagina te plaatsen waar ik problemen mee had, plaatste ik het gewoon in het index.php-bestand – probleem overal opgelost.