“— wordt weergegeven op pagina in plaats van “ ‘ ”

’wordt weergegeven op mijn pagina in plaats van .

Ik heb het Content-Typeingesteld op UTF-8in zowel mijn <head>-tag als mijn HTTP-headers:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Bovendien is mijn browser ingesteld op Unicode (UTF-8):

Dus wat is het probleem en hoe kan ik het oplossen?


Antwoord 1, autoriteit 100%

Zorg ervoor dat de browser en editor UTF-8-codering gebruiken in plaats van ISO-8859-1/Windows-1252.

Of gebruik &rsquo;.


Antwoord 2, autoriteit 96%

Dus wat is het probleem,

Het is een (RIGHT SINGLE QUOTATION MARK– U+2019) teken dat wordt gedecodeerd als CP-1252in plaats van UTF-8. Als u de tabel coderingenbekijkt, ziet u dat dit teken is in UTF-8 samengesteld uit de bytes 0xE2, 0x80en 0x99. Als u de CP-1252 codepagina-indelingbekijkt, ziet u dat elk van die bytes staat voor de afzonderlijke tekens â, en .


en hoe kan ik dit oplossen?

Gebruik UTF-8 in plaats van CP-1252 om de tekens te lezen, schrijven, opslaan en weergeven.


Ik heb het Content-Type ingesteld op UTF-8 in zowel mijn <head>-tag als mijn HTTP-headers:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Dit instrueert de client alleen welke codering moet worden gebruikt om de tekens te interpreteren en weer te geven. Dit instrueert uw eigen programma niet welke codering moet worden gebruikt om de tekens te lezen, te schrijven, op te slaan en weer te geven. Het exacte antwoord hangt af van het server-side platform/database/programmeertaal die wordt gebruikt. Houd er rekening mee dat degene die is ingesteld in de HTTP-responsheader voorrang heeft op de HTML-metatag. De HTML-metatag zou alleen worden gebruikt wanneer de pagina wordt geopend vanaf het lokale schijfbestandssysteem in plaats van vanuit HTTP.


Bovendien is mijn browser ingesteld op Unicode (UTF-8):

Dit dwingt de client alleen welke codering te gebruiken om de tekens te interpreteren en weer te geven. Maar het eigenlijke probleem is dat je al ’(gecodeerd in UTF-8) naar de client stuurt in plaats van . De client geeft correct ’weer met behulp van de UTF-8-codering. Als de client verkeerde instructies had gekregen om bijvoorbeeld ISO-8859-1 te gebruiken, had u waarschijnlijk in plaats daarvan ââ¬â¢gezien.


Ik gebruik ASP.NET 2.0 met een database.

Hier zit waarschijnlijk uw probleem. U moet met een onafhankelijke databasetool verifiëren hoe de gegevens eruitzien.

Als het teken aanwezig is, maakt u geen juiste verbinding met de database. U moet de databaseconnector vertellen om UTF-8 te gebruiken.

Als uw database ’bevat, dan is het uw database die in de war is. Hoogstwaarschijnlijk zijn de tabellen niet geconfigureerd om UTF-8te gebruiken. In plaats daarvan gebruiken ze de standaardcodering van de database, die varieert afhankelijk van de configuratie. Als dit uw probleem is, is het meestal voldoende om de tabel aan te passen om UTF-8 te gebruiken. Als uw database dat niet ondersteunt, moet u de tabellen opnieuw maken. Het is een goede gewoonte om de codering van de tabel in te stellen wanneer u deze aanmaakt.

U gebruikt waarschijnlijk SQL Server, maar hier is wat MySQL-code (gekopieerd van dit artikel):

CREATE DATABASE db_name CHARACTER SET utf8;
CREATE TABLE tbl_name (...) CHARACTER SET utf8;

Als uw tafel echter al UTF-8 is, moet u een stap terug doen. Wieof watheeft de gegevens daar geplaatst. Dat iswaar het probleem zit. Een voorbeeld zijn in HTML-formulier ingediende waarden die onjuist zijn gecodeerd/gedecodeerd.


Hier zijn nog enkele links voor meer informatie over het probleem:


Antwoord 3, autoriteit 29%

(Unicode-codepunt U+2019 RIGHT SINGLE QUOTATION MARK) is gecodeerd in UTF-8 als bytes:

0xE2 0x80 0x99.

’(Unicode-codepunten U+00E2 U+20AC U+2122) is gecodeerd in UTF-8 als bytes:

0xC3 0xA2  0xE2 0x82 0xAC  0xE2 0x84 0xA2.

Dit zijn de bytes die uw browser daadwerkelijk ontvangt om ’te produceren bij verwerking als UTF-8.

Dat betekent dat uw brongegevens tweetekensetconversies ondergaan voordat ze naar de browser worden verzonden:

  1. Het bronteken (U+2019) wordt eerst gecodeerd als UTF-8 bytes:

    0xE2 0x80 0x99

  2. die individuele bytes werden vervolgens verkeerd geïnterpreteerden gedecodeerd tot Unicode-codepunten U+00E2 U+20AC U+2122door een van de Windows-125X-tekensets (1252, 1254, 1256 en 1258 wijzen allemaal 0xE2 0x80 0x99toe aan U+00E2 U+20AC U+2122), en vervolgens die codepunten worden gecodeerd als UTF-8 bytes:

    0xE2-> U+00E2-> 0xC3 0xA2
    0x80-> U+20AC-> 0xE2 0x82 0xAC
    0x99-> U+2122-> 0xE2 0x84 0xA2

Je moet zoeken waar de extra conversie in stap 2 wordt uitgevoerd en deze verwijderen.


Antwoord 4, autoriteit 27%

Ik heb enkele documenten waarin werd weergegeven als …en êwerd weergegeven als ê. Zo kwam het daar (pythoncode):

# Adam edits original file using windows-1252
windows = '\x85\xea' 
# that is HORIZONTAL ELLIPSIS, LATIN SMALL LETTER E WITH CIRCUMFLEX
# Beth reads it correctly as windows-1252 and writes it as utf-8
utf8 = windows.decode("windows-1252").encode("utf-8")
print(utf8)
# Charlie reads it *incorrectly* as windows-1252 writes a twingled utf-8 version
twingled = utf8.decode("windows-1252").encode("utf-8")
print(twingled)
# detwingle by reading as utf-8 and writing as windows-1252 (it's really utf-8)
detwingled = twingled.decode("utf-8").encode("windows-1252")
assert utf8==detwingled

Om het probleem op te lossen, heb ik python-code als volgt gebruikt:

with open("dirty.html","rb") as f:
    dt = f.read()
ct = dt.decode("utf8").encode("windows-1252")
with open("clean.html","wb") as g:
    g.write(ct)

(Omdat iemand de twingled-versie in een correct UTF-8-document had ingevoegd, moest ik eigenlijk alleen het twingled-gedeelte extraheren, het ontrafelen en er weer insteken. Ik heb hiervoor BeautifulSoup gebruikt.)

Het is veel waarschijnlijker dat je een Charlie hebt bij het maken van inhoud dan dat de configuratie van de webserver verkeerd is. U kunt uw webbrowser ook dwingen om de pagina te laten twinkelen door windows-1252-codering te selecteren voor een utf-8-document. Je webbrowser kan het document dat Charlie heeft opgeslagen niet ontrafelen.

Opmerking: hetzelfde probleem kan optreden met elke andere codepagina van één byte (bijv. latin-1) in plaats van Windows-1252.


5, Autoriteit 15%

U hebt een mismatch in uw karaktercodering; Uw string is gecodeerd in één codering (UTF-8) en wat dan ook interpreteert Deze pagina gebruikt een ander (zeg ASCII).

Geef altijd uw codering in uw HTTP-headers op en zorg ervoor dat dit overeenkomt met de definitie van uw framework van codering.

Voorbeeld HTTP-header:

Content-Type    text/html; charset=utf-8

instelling Codering in ASP.NET

<configuration>
  <system.web>
    <globalization
      fileEncoding="utf-8"
      requestEncoding="utf-8"
      responseEncoding="utf-8"
      culture="en-US"
      uiCulture="de-DE"
    />
  </system.web>
</configuration>

-instelling Codering in JSP


6, Autoriteit 12%

Als uw inhoudstype al UTF8 is, dan is het waarschijnlijk de gegevens al aankomen in de verkeerde codering. Als u de gegevens uit een database krijgt, moet u ervoor zorgen dat de databaseverbinding UTF-8 gebruikt.

Als dit gegevens uit een bestand is, moet u ervoor zorgen dat het bestand correct is gecodeerd als UTF-8. U kunt dit meestal in het dialoogvenster “Opslaan als …” instellen van de redacteur van uw keuze.

Als de gegevens al zijn verbroken wanneer u het in het bronbestand ziet, is de kans groot dat het een UTF-8-bestand was, maar in de verkeerde codering ergens onderweg is opgeslagen.


7, Autoriteit 7%

Als iemand deze foutmelding krijgt op WordPress-website, moet u WP-Config DB Charset wijzigen:

define('DB_CHARSET', 'utf8mb4_unicode_ci');

In plaats van:

define('DB_CHARSET', 'utf8mb4');

8, Autoriteit 2%

Als de andere antwoorden niet hebben geholpen, wilt u misschien controleren of uw database daadwerkelijk de Mojibake-tekens opbergt. Ik bekeek de tekst in UTF-8, maar ik zag nog steeds de Mojibake en het bleek dat de tekst als gevolg van een database-upgrade permanent “mojibaked” was geweest.

In dit geval is één optie om de tekst met Python’s ftfy pakket ( of JavaScript verion hier ).


9

In DBeAver (of andere editors) Het scriptbestand dat u werkt, kan vragen om op te slaan als UTF8 en die de CHARS zal wijzigen:

â € “

in

–

of

–

10

U moet tekst uit Word-document kopiëren/plakken. Word-document gebruik slimme aanhalingstekens. U kunt het vervangen door een speciaal teken (&rsquo;) of gewoon in uw HTML-editor (‘) typen.

Ik weet zeker dat dit je probleem zal oplossen.


Antwoord 11

Ik heb hetzelfde meegemaakt met het teken ‘–’ (lang minteken).
Ik heb deze eenvoudige vervanging gebruikt, dus los het op:

htmlText = htmlText.Replace('–', '-');

Other episodes