database - Caracteres extraños en el texto de la base de datos: Ã, Ã, ¢, â ‚€,

character-encoding prestashop (6)

Aplica estas dos cosas.

utf8 configurar el conjunto de caracteres de su base de datos para que sea utf8 .
mysql_set_charset(''utf8'') llamar a mysql_set_charset(''utf8'') en el archivo donde estableció la conexión con la base de datos y justo después de la selección de la base de datos como mysql_select_db use mysql_set_charset . Eso le permitirá agregar y recuperar datos correctamente en cualquier idioma.

No estoy seguro de cuándo ocurrió esto por primera vez.

Tengo un nuevo sitio web afiliado de envío directo y recibo una copia exportada del catálogo de productos del mayorista. Formateo e importe esto en Prestashop 1.4.4.

La parte frontal del sitio web contiene combinaciones de caracteres extraños dentro del texto del producto: Ã, Ã, ¢, â ‚etc. Aparecen en lugar de caracteres comunes como, -: etc.

Estos caracteres están presentes en aproximadamente el 40% de las tablas de la base de datos, no solo en tablas específicas del producto como ps_product_lang.

Otro hilo del sitio web dice que este mismo problema ocurre cuando la cadena de conexión de la base de datos utiliza un tipo de codificación de caracteres incorrecto .

En /config/setting.inc, no se menciona ninguna cadena de codificación de caracteres, solo el motor MySQL, que está configurado en InnoDB, que coincide con lo que veo en PHPMyAdmin.

Exporté ps_product_lang, reemplacé todas las instancias de estos caracteres con caracteres correctos, guardé el archivo CSV en formato UTF-8 y los reimporté usando PHPMyAdmin, especificando UTF-8 como el idioma.

Sin embargo, después de hacer una nueva búsqueda en PHPMyAdmin, ahora tengo aproximadamente 10 veces más instancias de estos malos caracteres en ps_product_lang de lo que comencé.

Si el problema es tan simple como especificar el atributo de idioma correcto en la cadena de conexión de la base de datos, ¿dónde / cómo configuro esto y a qué?

Incidentalmente, intenté ejecutar este comando en PHPMyAdmin mencionado en este hilo , pero el problema sigue siendo:

SET NAMES utf8

ACTUALIZACIÓN : PHPMyAdmin dice:

Conjunto de caracteres MySQL: UTF-8 Unicode (utf8)

Este es el mismo conjunto de caracteres que usé en el último archivo de importación, lo que causó más daños en los caracteres. UTF-8 se especificó como el conjunto de caracteres del archivo de importación durante el proceso de importación.

Actualización2

Aquí hay una muestra:

las personas realmente viven sin ataduras, comprando y alquilando películas en línea, descargando software, compartiendo y almacenando archivos en La web.

ACTUALIZACIÓN3

Ejecuté un comando SQL en PHPMyAdmin para mostrar los juegos de caracteres:

character_set_client utf8
character_set_connection utf8
character_set_database latin1
character_set_filesystem binary
character_set_results utf8
character_set_server latin1
character_set_system utf8

Entonces, tal vez mi base de datos necesita ser convertida (o eliminada y recreada) a UTF-8. ¿Podría esto plantear un problema si el servidor MySQL es latin1?

¿Puede MySQL manejar la traducción de contenido de servicio como UTF8 pero almacenarlo como latin1? No creo que pueda, ya que UTF8 es un superconjunto de latin1. Mi soporte de alojamiento web no ha respondido en 48 horas. Podría ser demasiado difícil para ellos.

El error generalmente se introduce al crear CSV. Intente usar Linux para guardar el CSV como un TextCSV. Libre Office en Ubuntu puede hacer que la codificación sea UTF-8, funcionó para mí. Perdí mucho tiempo probando esto en Mac OS. Linux es la clave. He probado en Ubuntu.

Buena suerte

Este es seguramente un problema de codificación. Tiene una codificación diferente en su base de datos y en su sitio web y este hecho es la causa del problema. Además, si ejecutó ese comando, debe cambiar los registros que ya están en sus tablas para convertir esos caracteres en UTF-8.

Actualización : según su último comentario, el núcleo del problema es que tiene una base de datos y una fuente de datos (el archivo CSV) que utiliza una codificación diferente. Por lo tanto, puede convertir su base de datos en UTF-8 o, al menos, cuando obtiene los datos que están en el CSV, debe convertirlos de UTF-8 a latin1.

Puedes hacer la conversión siguiendo estos artículos:

Esto parece ser un problema de codificación UTF-8 que puede haber sido causado por una doble codificación UTF8 del contenido del archivo de base de datos.

Esta situación podría ocurrir debido a factores como el conjunto de caracteres que se seleccionó o no (por ejemplo, cuando se creó un archivo de copia de seguridad de la base de datos) y el formato de archivo y el archivo de la base de datos de codificación se guardaron con.

He visto estos extraños caracteres UTF-8 en el siguiente escenario (la descripción puede no ser del todo precisa, ya que ya no tengo acceso a la base de datos en cuestión):

Como recuerdo, allí la base de datos y las tablas tenían una intercalación "uft8_general_ci".
Copia de seguridad se hace de la base de datos.
El archivo de copia de seguridad se abre en Windows en formato de archivo UNIX y con codificación ANSI.
La base de datos se restaura en un nuevo servidor MySQL al copiar y pegar el contenido del archivo de copia de seguridad de la base de datos en phpMyAdmin.

Mirando en el contenido del archivo:

Abrir el archivo de copia de seguridad SQL en un editor de texto muestra que el archivo de copia de seguridad SQL tiene caracteres extraños como "sÃƒÂ ¥". En una nota al margen, puede obtener resultados diferentes si abre el mismo archivo en otro editor. Utilizo TextPad aquí pero abriendo el mismo archivo en SublimeText dijo "så" porque SublimeText codificó correctamente el archivo con UTF8 - aún así, esto es un poco confuso cuando empiezas a intentar solucionar el problema en PHP porque no ves el Datos correctos en SublimeText al principio. De todos modos, eso puede resolverse tomando nota de qué codificación está utilizando su editor de texto al presentar el contenido del archivo.
Los caracteres extraños son caracteres UTF-8 de doble codificación, por lo que en mi caso la primera parte "Ãƒ" es igual a "Ã" y "Â ¥" = "¥" (esta es mi primera "codificación"). Los caracteres "Ã ¥" equivalen al carácter UTF-8 para "å" (esta es mi segunda codificación).

Por lo tanto, el problema es que "falso" (codificado UTF8 dos veces) utf-8 debe volver a convertirse en "correcto" utf-8 (solo codificado UTF8 una vez) .

Tratar de arreglar esto en PHP resulta ser un poco desafiante:

utf8_decode () no puede procesar los caracteres.

// Fails silently (as in - nothing is output) $str = "sÃƒÂ¥"; $str = utf8_decode($str); printf("/n%s", $str); $str = utf8_decode($str); printf("/n%s", $str);

iconv () falla con "Aviso: iconv (): se detectó un carácter no válido en la cadena de entrada".

echo iconv("UTF-8", "ISO-8859-1", "sÃƒÂ¥");

Otra solución fina y posible también falla silenciosamente en este escenario

$str = "sÃƒÂ¥"; echo html_entity_decode(htmlentities($str, ENT_QUOTES, ''UTF-8''), ENT_QUOTES , ''ISO-8859-15'');

mb_convert_encoding () en silencio: #

$str = "sÃƒÂ¥"; echo mb_convert_encoding($str, ''ISO-8859-15'', ''UTF-8''); // (No output)

Intentar arreglar la codificación en MySQL convirtiendo el conjunto de caracteres de la base de datos MySQL y la intercalación en UTF-8 fue infructuoso:

ALTER DATABASE myDatabase CHARACTER SET utf8 COLLATE utf8_unicode_ci; ALTER TABLE myTable CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;

Veo un par de maneras de resolver este problema.

La primera es hacer una copia de seguridad con la codificación correcta (la codificación debe coincidir con la base de datos real y la codificación de la tabla). Puede verificar la codificación simplemente abriendo el archivo SQL resultante en un editor de texto.

La otra es reemplazar los caracteres codificados en doble UTF8 con caracteres codificados en un solo UTF8. Esto se puede hacer manualmente en un editor de texto. Para ayudar en este proceso, puede seleccionar manualmente los caracteres incorrectos de la tabla de depuración de codificación UTF-8 de Try (puede ser una cuestión de reemplazar entre 5 y 10 errores).

Finalmente, un script puede ayudar en el proceso:

$str = "sÃƒÂ¥"; // The two arrays can also be generated by double-encoding values in the first array and single-encoding values in the second array. $str = str_replace(["Ãƒ","Â¥"], ["Ã","¥"], $str); $str = utf8_decode($str); echo $str; // Output: "så" (correct)

Hoy encontré un problema bastante similar: mysqldump volcó mi base utf-8 codificando los caracteres diacríticos utf-8 como dos caracteres latin1, aunque el archivo en sí es utf8 normal.

Por ejemplo: "é" se codificó como dos caracteres "é". Estos dos caracteres corresponden a la codificación utf8 de dos bytes de la letra, pero debe interpretarse como un solo carácter.

Para resolver el problema e importar correctamente la base de datos en otro servidor, tuve que convertir el archivo utilizando la biblioteca de Python de "Fixes Text For You" ( https://github.com/LuminosoInsight/python-ftfy ). La biblioteca hace exactamente lo que espero: transformar mal codificado utf-8 para codificar correctamente utf-8.

Por ejemplo: esta combinación latina "Ã ©" se convierte en "é".

ftfy viene con un script de línea de comandos pero transforma el archivo para que no se pueda volver a importar a mysql.

Escribí un script en python3 para hacer el truco:

#!/usr/bin/python3 # coding: utf-8 import ftfy # Set input_file input_file = open(''mysql.utf8.bad.dump'', ''r'', encoding="utf-8") # Set output file output_file = open (''mysql.utf8.good.dump'', ''w'') # Create fixed output stream stream = ftfy.fix_file( input_file, encoding=None, fix_entities=''auto'', remove_terminal_escapes=False, fix_encoding=True, fix_latin_ligatures=False, fix_character_width=False, uncurl_quotes=False, fix_line_breaks=False, fix_surrogates=False, remove_control_chars=False, remove_bom=False, normalization=''NFC'' ) # Save stream to output file stream_iterator = iter(stream) while stream_iterator: try: line = next(stream_iterator) output_file.write(line) except StopIteration: break

Si el conjunto de caracteres de las tablas es el mismo que su contenido, intente usar mysql_set_charset(''UTF8'', $link_identifier) . Tenga en cuenta que MySQL usa UTF8 para especificar la codificación UTF-8 en lugar de UTF-8 que es más común.

Compruebe mi otra respuesta en una pregunta similar también.