Конвертиране на низове с грешно кодиране, върнати от MySQL

След мигриране от ruby1.8/mysql gem към ruby1.9/mysql2 получавам низове от наследената db, за които се съобщава, че са utf8, но изглеждат като кодирани с latin1 (или вероятно имат някакво двойно кодиране, както прави straight force_encoding не помага).

Пример за низ:

Ñ„Ñ‹Ð²Ð°Ð¿Ñ€Ð¾Ð»Ð´Ð¶Ñ - just a test string - йцукенгшщзхъ

Искам да мога да го конвертирам в

фывапролджэ - just a test string - йцукенгшщзхъ

Може ли някой да помогне с преобразуването a) с ruby ​​код и/или b) с SQL?

Тъй като копирането и поставянето може да загуби част от информацията, байтове от върнатия низ: [195, 145, 226, 128, 158, 195, 145, 226, 128, 185, 195, 144, 194, 178, 195, 144, 194, 176, 195, 144, 194, 191, 195, 145, 226, 130, 172, 195, 144, 194, 190, 195, 144, 194, 187, 195, 144, 194, 180, 195, 144, 19 4, 182, 195, 145, 194, 141, 32, 45, 32, 106, 117, 115, 116, 32, 97, 32, 116, 101, 115, 116, 32, 115, 116, 114, 105, 110, 103, 32, 45, 32, 195, 144, 194, 185, 195, 145, 226, 128, 160, 195, 145, 198, 146, 195, 144, 194, 186, 195, 144, 194, 181, 195, 144, 194, 189, 195, 144, 194, 179, 195, 145, 203, 134, 195, 145, 226, 128, 176, 195, 144, 194, 183, 195, 145, 226, 12 8, 166, 195, 145, 197, 160]


person UncleGene    schedule 19.04.2013    source източник
comment
Имал съм това в миналото. Лесно е на ruby ​​1.8 да изпраща UTF8 байтове и да ги съхранява неправилно като Latin 1. Трябва да коригирате проблема от страна на MySQL, като първо преобразувате колоната в петно ​​и след това обратно в utf8 низ/текстова колона. Това кара MySQL да интерпретира повторно данните   -  person Frederick Cheung    schedule 19.04.2013
comment
Благодаря за намека в правилната посока. Моля, вижте отговора ми по-долу (съдържанието не можа да се побере в коментара)   -  person UncleGene    schedule 19.04.2013


Отговори (2)


Добре, намерих SQL решение за това в Как да коригирам двойно кодирани UTF8 знаци (в utf-8 таблица).

CONVERT(CAST(CONVERT(field USING latin1) AS BINARY) USING utf8)

Има ли желаещи за Ruby?

person UncleGene    schedule 19.04.2013
comment
Ако съдържанието на вашата база данни е повредено, трябва да го отстраните там. Никакво суетене в Ruby няма да го поправи. - person tadman; 19.04.2013
comment
Ползата от рубинното преобразуване е, че може да се обработва лениво (очевидно подходът е идемпотентен). Преобразуването на база данни е трудно с времето - с всяка стратегия за внедряване имате стари клиенти, които търсят нови записи и/или нови клиенти, които търсят стари. - person UncleGene; 19.04.2013
comment
Не обръщайте внимание на коментара за идемпотентност, той се отнася до грешно решение - person UncleGene; 19.04.2013
comment
Можете да направите UPDATE на място, ако искате да коригирате проблема за постоянно. Бих предложил да направите това на тестово копие на базата данни, преди да преминете към вашите производствени данни. Преди имах данни, двойно кодирани като UTF-8 поради неправилна конфигурация на връзката. Досадно за коригиране, но необходимо. В зависимост от количеството данни, което трябва да конвертирате, това може да отнеме от минути до часове. - person tadman; 19.04.2013

Може да искате да зададете кодирането на вашата връзка с база данни в config/database.yml, експериментирайте с различни настройки, докато получите желания резултат.

Възможно е вашата връзка по подразбиране да е latin1 по някаква причина, но вътрешно да се интерпретира като UTF8.

person tadman    schedule 19.04.2013
comment
Опитах всички възможни настройки за кодиране на връзката и получавам боклук за всички тях. Освен това искам кодът да използва utf8 - всички нови записи се записват/извличат правилно, проблемът е само с наследени записи - person UncleGene; 19.04.2013