Странные символы в тексте базы данных: Ã, Ã, ¢, â, €,
Я не уверен, когда это произошло.
У меня есть новый партнерский веб-сайт для отправки и отправки экспортированной копии каталога продуктов у оптовика. Я форматирую и импортирую это в 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
- character_set_database latin1
- character_set_filesystem двоичный
- character_set_results utf8
- character_set_server latin1
- character_set_system utf8
Итак, возможно, моя база данных должна быть преобразована (или удалена и воссоздана) в UTF-8. Может ли это возникнуть, если сервер MySQL является latin1?
Может ли MySQL обрабатывать перевод обслуживающего контента как UTF8, но хранить его как latin1? Я не думаю, что это возможно, так как UTF8 является надмножеством latin1. Моя поддержка веб-хостинга не ответила через 48 часов. Может быть, слишком сложно для них.
Ответы
Ответ 1
Если кодировка таблиц совпадает с содержимым, попробуйте использовать mysql_set_charset('UTF8', $link_identifier)
. Обратите внимание, что MySQL использует UTF8
, чтобы указать кодировку UTF-8 вместо UTF-8
, которая является более распространенной.
Отметьте мой другой ответ по аналогичному вопросу.
Ответ 2
Это, безусловно, проблема с кодировкой. У вас есть другая кодировка в вашей базе данных и на вашем сайте, и этот факт является причиной проблемы. Также, если вы запустили эту команду, вам нужно изменить записи, которые уже есть в ваших таблицах, для преобразования этих символов в UTF-8.
Обновление. Основываясь на вашем последнем комментарии, ядро проблемы заключается в том, что у вас есть база данных и источник данных (файл CSV), которые используют различную кодировку. Следовательно, вы можете конвертировать вашу базу данных в UTF-8 или, по крайней мере, когда вы получаете данные, находящиеся в CSV, вам необходимо преобразовать их из UTF-8 в latin1.
Вы можете выполнить преобразование следующих статей:
Ответ 3
Примените эти две вещи.
-
Вам нужно установить набор символов вашей базы данных utf8
.
-
Вам нужно вызвать mysql_set_charset('utf8')
в файле, где вы установили соединение с базой данных, и сразу после выбора базы данных, например mysql_select_db
, используйте mysql_set_charset
. Это позволит вам правильно добавлять и извлекать данные на любом языке.
Ответ 4
Это, по-видимому, проблема с кодировкой 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 с двойным кодированием, поэтому в моем случае первая часть "Ã part" равна "Ã" и "Â ¥" = "¥" (это моя первая "кодировка" ). Символы "Ã ¥" равны символу 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() завершается с ошибкой "Notice: 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 Encoding Debugging Chart (это может быть вопрос замены 5- 10 ошибок).
Наконец, script может помочь в этом процессе:
$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)
Ответ 5
Ошибка обычно вводится при создании CSV. Попробуйте использовать Linux для сохранения CSV в качестве TextCSV. Libre Office в Ubuntu может обеспечить кодирование UTF-8, работал у меня.
Я потратил много времени на это в Mac OS. Linux - это ключ. Я тестировал Ubuntu.
Удача
Ответ 6
Сегодня у меня возникла довольно схожая проблема: mysqldump сбрасывал мои базовые кодировки utf-8 с utf-8 как два латинских символа, хотя сам файл является обычным utf8.
Например: "é" был закодирован как два символа "Ã ©". Эти два символа соответствуют двоичной кодировке буквы utf8, но ее следует интерпретировать как один символ.
Чтобы решить проблему и правильно импортировать базу данных на другой сервер, мне пришлось преобразовать файл с помощью ftfy (означает "Исправляет текст для вас" ). (https://github.com/LuminosoInsight/python-ftfy). Библиотека выполняет именно то, что я ожидаю: преобразовать плохо кодированный utf-8 в правильно кодированный utf-8.
Например: Эта комбинация latin1 "Ã ©" превращается в "é".
ftfy поставляется с командной строкой script, но он преобразует файл, поэтому его нельзя импортировать обратно в mysql.
Я написал python3 script, чтобы сделать трюк:
#!/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