Странные символы в тексте базы данных: Ã, Ã, ¢, â €, - PullRequest
25 голосов
/ 22 октября 2011

Я не уверен, когда это произошло впервые.

У меня есть новый аффилированный сайт с доставкой груза, и я получаю экспортированную копию каталога товаров от оптовика. Я форматирую и импортирую это в Prestashop 1.4.4.

Внешний интерфейс сайта содержит комбинации странных символов в тексте продукта: Ã, Ã, ¢, â ‚и т. Д. Они появляются вместо общих символов, таких как, -: и т. Д.

Эти символы присутствуют примерно в 40% таблиц базы данных, а не только в таблицах конкретных продуктов, таких как ps_product_lang.

Другой поток веб-сайта говорит такая же проблема возникает, когда строка подключения к базе данных использует неправильный тип кодировки символов .

В /config/setting.inc не упоминается ни одна строка кодировки символов, только MySQL Engine, который установлен на InnoDB, что соответствует тому, что я вижу в PHPMyAdmin.

Я экспортировал ps_product_lang, заменил все экземпляры этих символов на правильные символы, сохранил файл CSV в формате UTF-8 и заново импортировал их, используя PHPMyAdmin, указав UTF-8 в качестве языка.

Однако после нового поиска в PHPMyAdmin у меня теперь примерно в 10 раз больше этих плохих символов в ps_product_lang, чем я начал.

Если проблема так проста, как указание правильного языкового атрибута в строке подключения к базе данных, где / как я могу установить это и что?

Кстати, я попытался запустить эту команду в PHPMyAdmin, упомянутом в этой теме , но проблема остается:

SET NAMES utf8

ОБНОВЛЕНИЕ : PHPMyAdmin говорит:

MySQL charset: UTF-8 Unicode (utf8)

Это тот же набор символов, который я использовал в последнем файле импорта, что вызвало больше повреждений символов. UTF-8 был указан как кодировка файла импорта во время процесса импорта.

UPDATE2

Вот пример:

люди по-настоящему живут неприязненно. ƑÆ ƒ ƒ ¢ ¢ â Å Ã ¡Ã ‚¯ ¯ ¯ ¬ • Покупка и аренда фильмов онлайн, загрузка программного обеспечения и обмен и хранение файлов в Интернете.

Update3

Я запустил команду SQL в PHPMyAdmin для отображения наборов символов:

  • character_set_client utf8
  • character_set_connection utf8
  • символьная_сеть_базы_данных1
  • символьный_системный бинарный файл
  • character_set_results utf8
  • символ_сервера_сервер латинский1
  • character_set_system utf8

Итак, возможно, моя база данных должна быть преобразована (или удалена и воссоздана) в UTF-8. Может ли это создать проблему, если сервер MySQL - latin1?

Может ли MySQL обрабатывать перевод обслуживающего контента как UTF8, но сохранять его как latin1? Я не думаю, что это возможно, так как UTF8 является надмножеством latin1. Моя поддержка веб-хостинга не ответила в течение 48 часов. Для них это может быть слишком сложно.

Ответы [ 6 ]

17 голосов
/ 25 октября 2011

Если кодировка таблиц совпадает с ее содержимым, попробуйте использовать mysql_set_charset('UTF8', $link_identifier).Обратите внимание, что MySQL использует UTF8 для указания кодировки UTF-8 вместо UTF-8, что более распространено.

Проверьте мой другой ответ на аналогичный вопростоже.

5 голосов
/ 22 октября 2011

Это, безусловно, проблема с кодировкой. У вас есть другая кодировка в вашей базе данных и на вашем сайте, и этот факт является причиной проблемы. Кроме того, если вы выполнили эту команду, вы должны изменить записи, которые уже есть в ваших таблицах, чтобы преобразовать этот символ в UTF-8.

Обновление : Основываясь на вашем последнем комментарии, суть проблемы заключается в том, что у вас есть база данных и источник данных (файл CSV), которые используют разные кодировки. Следовательно, вы можете конвертировать свою базу данных в UTF-8 или, по крайней мере, когда вы получаете данные, которые находятся в CSV, вы должны конвертировать их из UTF-8 в латиницу 1.

Вы можете сделать преобразование, следуя этой статье:

2 голосов
/ 12 февраля 2016

Это, похоже, проблема с кодировкой UTF-8, которая могла быть вызвана двойным кодированием UTF8 содержимого файла базы данных.

Такая ситуация может возникать из-за таких факторов, как набор символов, который был или не был выбран (например, при создании файла резервной копии базы данных), а также формат файла и файл базы данных кодирования, сохраненные с помощью.

Я видел эти странные символы UTF-8 в следующем сценарии (описание может быть не совсем точным, поскольку у меня больше нет доступа к рассматриваемой базе данных):

  • Насколько я помню, в базе данных и таблицах имелось сопоставление "uft8_general_ci".
  • Сделано резервное копирование базы данных.
  • Файл резервной копии открывается в Windows в формате UNIX и в кодировке ANSI.
  • База данных восстанавливается на новом сервере MySQL путем копирования содержимого из файла резервной копии базы данных в phpMyAdmin.

Просмотр содержимого файла:

  • Открытие файла резервной копии SQL в текстовом редакторе показывает, что файл резервной копии SQL содержит странные символы, такие как «sॻ. С другой стороны, вы можете получить другие результаты, если откроете тот же файл в другом редакторе. Я использую TextPad здесь, но открытие того же файла в SublimeText говорит «sà ¥», потому что SublimeText правильно кодировал файл в UTF8 - тем не менее, это немного сбивает с толку, когда вы начинаете пытаться исправить проблему в PHP, потому что вы не видите Правильные данные в SublimeText в первую очередь. В любом случае, это можно решить, заметив, какую кодировку использует ваш текстовый редактор при представлении содержимого файла.
  • Странные символы представляют собой символы UTF-8 с двойным кодированием, поэтому в моем случае первая часть «Ã» равна «Ã» и «Â ¥» = «¥» (это моя первая «кодировка»). Символы «Ã ¥» равны символу UTF-8 для «å» (это моя вторая кодировка).

Итак, проблема в том, что «false» (дважды кодированный в UTF8) utf-8 необходимо преобразовать обратно в «правильный» utf-8 (только один раз кодированный в UTF8) .

Попытка исправить это в PHP оказывается немного сложной задачей:

utf8_decode () не может обрабатывать символы.

// 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 () завершается с ошибкой «Примечание: iconv (): обнаружен недопустимый символ во входной строке».

echo iconv("UTF-8", "ISO-8859-1", "så");

Другое прекрасное и возможное решение тоже не работает в этом сценарии

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

mb_convert_encoding () молча: #

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

Попытка исправить кодировку в MySQL с помощью , преобразующей набор символов и сопоставление базы данных MySQL в UTF-8 , оказалась безуспешной:

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

Я вижу несколько способов решить эту проблему.

Первое - сделать резервную копию с правильной кодировкой (кодировка должна соответствовать фактической базе данных и кодировке таблицы). Вы можете проверить кодировку, просто открыв полученный файл SQL в текстовом редакторе.

Другой способ - заменить символы с двойным UTF8 на символы с одиночным UTF8. Это можно сделать вручную в текстовом редакторе. Чтобы помочь в этом процессе, вы можете вручную выбрать неправильные символы из Диаграммы отладки кодировки Try UTF-8 (это может быть заменой 5-10 ошибок).

Наконец, скрипт может помочь в этом процессе:

    $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)
2 голосов
/ 09 сентября 2014

Примените эти две вещи.

  1. Вам необходимо установить набор символов вашей базы данных равным utf8.

  2. Вам необходимо вызвать mysql_set_charset('utf8') в файле, где вы установили соединение с базой данных, и сразу после выбора базы данных, например mysql_select_db, использовать mysql_set_charset. Это позволит вам правильно добавлять и извлекать данные на любом языке.

1 голос
/ 25 июля 2017

Сегодня я столкнулся с довольно похожей проблемой: mysqldump выгрузил мою базовую кодировку utf-8 utf-8 в виде двух символов latin1, хотя сам файл является обычным utf8.

Например: «é» был закодирован как два символа «Ã ©». Эти два символа соответствуют двухбайтовой кодировке буквы utf8, но ее следует интерпретировать как один символ.

Чтобы решить эту проблему и правильно импортировать базу данных на другой сервер, мне пришлось преобразовать файл, используя ftfy (расшифровывается как «Fixes Text For You». (https://github.com/LuminosoInsight/python-ftfy) библиотека python. Библиотека делает именно то, что Я ожидаю: преобразовать плохо кодированный utf-8 в правильно кодированный utf-8.

Например: эта латинская комбинация "Ã ©" превращается в "é".

ftfy поставляется со скриптом командной строки, но он преобразует файл, поэтому его нельзя импортировать обратно в mysql.

Я написал скрипт на python3, чтобы добиться цели:

#!/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
1 голос
/ 12 июня 2014

Ошибка обычно появляется при создании CSV. Попробуйте использовать Linux для сохранения CSV как TextCSV. Libre Office в Ubuntu может использовать кодировку UTF-8, сработало для меня. Я потратил много времени, пытаясь это сделать на Mac OS. Linux является ключом. Я тестировал на Ubuntu.

Удачи

...