У вас, наверное, две проблемы. Но давайте отступим... Мы не можем сказать, был ли текст неправильно импортирован, неправильно экспортирован или просто отображен дурацким образом.
Во-первых, я собираюсь обсудить "импорт"...
Не пытайтесь изменить кодировку. Вместо этого живите с кодировкой. Но сначала разберитесь, что такое кодировка. Это может быть latin1 или utf8. (Или любой из множества менее вероятных кодировок.)
Узнайте шестнадцатеричный код входящего файла. В Python код для дампа шестнадцатеричного кода (и т. д.) для строки u
выглядит примерно так:
for i, c in enumerate(u):
print i, '%04x' % ord(c), unicodedata.category(c),
print unicodedata.name(c)
Вы можете здесь просмотреть список шестнадцатеричные значения для всех символов latin1 вместе с шестнадцатеричным значением utf8. Например, ó
— это latin1 F3
или utf8 C2B3
.
Теперь, вооружившись знанием кодировки, сообщите об этом MySQL.
LOAD DATA INFILE ...
...
CHARACTER SET utf8 -- or latin1
...;
Между тем, не имеет значения, что CHARACTER SET ...
определяет таблица или столбец; mysql перекодирует при необходимости. Все испанские символы доступны в latin1 и utf8.
Перейдите к этим вопросам и ответам< /эм>а> .
Я предположил, что у вас есть две ошибки, одна из которых - упомянутый там случай «черного бриллианта»; там другое что-то другое. Но... Следуйте упомянутой "лучшей практике".
Вернемся к вопросу об "экспорте"...
Опять же, вам нужно проверить шестнадцатеричный код выходного файла. Опять же не важно, латиница1 или utf8. Однако... Если шестнадцатеричный код равен C383C2B3
для простого ó
, у вас "двойное кодирование". Если у вас есть это, убедитесь, что вы удалили все вызовы функций ручного преобразования и просто сказали MySQL, что к чему.
Вот еще несколько советов по utf8+Python, которые вы может понадобиться.
Если вам нужна дополнительная помощь, следуйте тексту шаг за шагом. Покажите нам код, используемый для его перемещения/преобразования на каждом этапе, и покажите нам HEX на каждом этапе.
person
Rick James
schedule
25.10.2016