encoding utf-8 mojibake

encoding - "''Mostrando en la página en lugar de'' '''' ''



utf-8 mojibake (11)

’ se muestra en mi página en lugar de '' .

Tengo el Content-Type configurado en UTF-8 tanto en mi etiqueta <head> como en mis encabezados HTTP:

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

Además, mi navegador está configurado en Unicode (UTF-8) :

Entonces, ¿cuál es el problema y cómo puedo solucionarlo?


Entonces, cuál es el problema,

Es un carácter '' ( RIGHT SINGLE QUOTATION MARK - U + 2019) que ha sido codificado como CP-1252 lugar de UTF-8 . Si comprueba la tabla de codificaciones , verá que este carácter está en UTF-8 compuesto por los bytes 0xE2 , 0x80 y 0x99 . Si comprueba el diseño de la página de códigos CP-1252 , verá que cada uno de esos bytes representa los caracteres individuales â , y .

y como puedo arreglarlo?

Use UTF-8 en lugar de CP-1252 para leer, escribir, almacenar y mostrar los caracteres.

Tengo el Tipo de contenido configurado en UTF-8 tanto en mi etiqueta <head> como en mis encabezados HTTP:

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

Esto solo le indica al cliente qué codificación usar para interpretar y mostrar los caracteres. Esto no indica a su propio programa qué codificación usar para leer, escribir, almacenar y mostrar los caracteres. La respuesta exacta depende de la plataforma / base de datos / lenguaje de programación del servidor utilizado. Tenga en cuenta que el conjunto en el encabezado de respuesta HTTP tiene prioridad sobre la metaetiqueta HTML. La metaetiqueta HTML solo se usaría cuando la página se abra desde el sistema de archivos del disco local en lugar de hacerlo desde HTTP.

Además, mi navegador está configurado en Unicode (UTF-8) :

Esto solo obliga al cliente a usar la codificación para interpretar y mostrar los caracteres. Pero el problema real es que ya está enviando ’ (codificado en UTF-8) al cliente en lugar de '' . El cliente está mostrando correctamente ’ utilizando la codificación UTF-8. Si el cliente fue mal informado para usar, por ejemplo ISO-8859-1, es probable que haya visto ââ¬â¢ lugar.

Estoy usando ASP.NET 2.0 con una base de datos.

Esto es más probable donde se encuentra su problema. Debe verificar con una herramienta de base de datos independiente cómo son los datos.

Si el carácter '' está allí, entonces no se está conectando a la base de datos correctamente. Necesita decirle al conector de la base de datos que use UTF-8.

Si su base de datos contiene ’ , entonces es su base de datos la que está mal. Lo más probable es que las tablas no estén configuradas para usar UTF-8 . En cambio, usan la codificación predeterminada de la base de datos, que varía según la configuración. Si este es su problema, generalmente basta con modificar la tabla para usar UTF-8. Si su base de datos no es compatible con eso, deberá volver a crear las tablas. Es una buena práctica establecer la codificación de la tabla cuando la cree.

Probablemente esté usando SQL Server, pero aquí hay un código MySQL (copiado de este artículo ):

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

Si su tabla ya es UTF-8, entonces necesita dar un paso atrás. Quién o qué puso los datos allí. Ahí es donde está el problema. Un ejemplo serían los valores enviados por formulario HTML que están codificados / decodificados incorrectamente.

Aquí hay algunos enlaces más para aprender más sobre el problema:


Asegúrese de que el navegador y el editor estén usando codificación UTF-8 en lugar de ISO-8859-1 / Windows-1252.

O usa &rsquo; .


Debe tener copiar / pegar texto del documento de Word. Word document use Smart Quotes. Puede reemplazarlo con un carácter especial (& rsquo;) o simplemente escriba su editor de HTML ('').

Estoy seguro de que esto resolverá tu problema.


En lugar del signo de Pound, utilicé: & pound; sin espacio. Esto resolvió este problema para mí.

Para Euro: y euro; sin espacio.


Esto sucede a veces cuando una cadena se convierte de Windows-1252 a UTF-8 dos veces .

Tuvimos esto en una aplicación Zend / PHP / MySQL donde personajes como ese aparecían en la base de datos, probablemente debido a la conexión MySQL que no especificaba el conjunto de caracteres correcto. Tuvimos que:

  1. Asegurarse de que Zend y PHP se estaban comunicando con la base de datos en UTF-8 ( no era por defecto)

  2. Reparar los caracteres rotos con varias consultas SQL como esta ...

    UPDATE MyTable SET MyField1 = CONVERT(CAST(CONVERT(MyField1 USING latin1) AS BINARY) USING utf8), MyField2 = CONVERT(CAST(CONVERT(MyField2 USING latin1) AS BINARY) USING utf8);

    Haga esto para tantas tablas / columnas como sea necesario.

También puede corregir algunas de estas cadenas en PHP si es necesario. Tenga en cuenta que debido a que los caracteres han sido codificados dos veces , en realidad necesitamos hacer una conversión inversa de UTF-8 a Windows-1252, lo que me confundió al principio.

mb_convert_encoding(''’'', ''Windows-1252'', ''UTF-8''); // returns ’


Me pasó lo mismo con el carácter ''-'' (signo menos largo).
Usé este simple reemplazo para resolverlo:

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


Si alguien obtiene este error en el sitio web de WordPress, debe cambiar wp-config db charset:

define(''DB_CHARSET'', ''utf8mb4_unicode_ci'');

en lugar de:

define(''DB_CHARSET'', ''utf8mb4'');


Si su tipo de contenido ya es UTF8, entonces es probable que los datos ya estén llegando con una codificación incorrecta. Si obtiene los datos de una base de datos, asegúrese de que la conexión de la base de datos use UTF-8.

Si se trata de datos de un archivo, asegúrese de que el archivo esté codificado correctamente como UTF-8. Por lo general, puede configurar esto en el cuadro de diálogo "Guardar como ..." del editor de su elección.

Si los datos ya están rotos cuando lo ve en el archivo fuente, es probable que solía ser un archivo UTF-8 pero se guardó en la codificación incorrecta en algún punto del camino.


Tengo algunos documentos donde se mostraba como … y ê se mostraba como ê . Así es como llegó allí (código python):

# 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

Para solucionar el problema, utilicé el código de Python como este:

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)

(Debido a que alguien había insertado la versión twingled en un documento UTF-8 correcto, en realidad tuve que extraer solo la parte twingled, desenroscarlo e insertarlo de nuevo. Utilicé BeautifulSoup para esto).

Es mucho más probable que tenga un Charlie en la creación de contenido que que la configuración del servidor web sea incorrecta. También puede forzar a su navegador web a twinglear la página seleccionando la codificación windows-1252 para un documento utf-8. Su navegador web no puede ignorar el documento que Charlie guardó.

Nota : el mismo problema puede ocurrir con cualquier otra página de códigos de un solo byte (por ejemplo, latin-1) en lugar de windows-1252.


Tienes una falta de coincidencia en la codificación de tu personaje; su cadena está codificada en una codificación (UTF-8) y lo que sea que esté interpretando esta página está usando otra (por ejemplo, ASCII).

Siempre especifique su codificación en sus encabezados http y asegúrese de que coincida con la definición de codificación de su infraestructura.

Muestra del encabezado http:

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

Configuración de codificación en asp.net

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

Configuración de codificación en jsp


'' (El punto de código Unicode U+2019 RIGHT SINGLE QUOTATION MARK ) está codificado en UTF-8 como bytes:

0xE2 0x80 0x99 .

’ (Los puntos de código Unicode U+00E2 U+20AC U+2122 ) están codificados en UTF-8 como bytes:

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

Estos son los bytes que su navegador recibe en realidad para producir ’ cuando se procesa como UTF-8.

Esto significa que sus datos de origen pasan por dos conversiones de caracteres antes de enviarlos al navegador:

  1. El carácter fuente ( U+2019 ) primero se codifica como bytes UTF-8:

    0xE2 0x80 0x99

  2. esos bytes individuales fueron mal interpretados y decodificados a puntos de código Unicode U+00E2 U+20AC U+2122 por uno de los conjuntos de caracteres de Windows-125X (1252, 1254, 1256 y 1258 todos los mapas 0xE2 0x80 0x99 a U+00E2 U+20AC U+2122 ), y luego esos puntos de código se codifican como bytes UTF-8:

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

Debe encontrar dónde se realiza la conversión adicional en el paso 2 y eliminarla.