MySQL и CP-1252

0

0

Помогите, пожалуйста, расшифровать экзотическую кодировку.

На сервере стоит Джумла + MySQL, всё работает нормально, русские буквы отображаются как русские буквы. Всё это дело ставил не я.

Вчера мне понадобилось массово изменить в одной из таблиц кучу записей. Я решил сделать дамп, воспользоваться sed'ом и закачать таблицу обратно.

Однако... при попытке посмотреть дамп я увидел зябу и вопросики. Вот что выдал мне mysqldump:

-- MySQL dump 10.10
--
-- Host: localhost Database: airrideru
-- ------------------------------------------------------
-- Server version 5.0.26-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Table structure for table `jos_vm_category`
--

DROP TABLE IF EXISTS `jos_vm_category`;
CREATE TABLE `jos_vm_category` (
`category_id` int(11) NOT NULL auto_increment,
`vendor_id` int(11) NOT NULL default '0',
`category_name` varchar(128) NOT NULL default ",
`category_description` text,
`category_thumb_image` varchar(255) default NULL,
`category_full_image` varchar(255) default NULL,
`category_publish` char(1) default NULL,
`cdate` int(11) default NULL,
`mdate` int(11) default NULL,
`category_browsepage` varchar(255) NOT NULL default 'browse_6',
`products_per_row` tinyint(2) NOT NULL default '1',
`category_flypage` varchar(255) NOT NULL default ",
`list_order` int(11) NOT NULL default '0',
PRIMARY KEY (`category_id`),
KEY `idx_category_vendor_id` (`vendor_id`),
KEY `idx_category_name` (`category_name`)
) ENGINE=MyISAM AUTO_INCREMENT=147 DEFAULT CHARSET=utf8 COMMENT='????????? ??????? ???????? ????';

--
-- Dumping data for table `jos_vm_category`
--

LOCK TABLES `jos_vm_category` WRITE;
/*!40000 ALTER TABLE `jos_vm_category` DISABLE KEYS */;
INSERT INTO `jos_vm_category` VALUES (1,1,'????????? ??????????????',",",",'Y',1223051783,1268669121,'browse_1',1,",3),(2,1,'??????? ????????? Chassistech','??????? ?????????

Ну, вы поняли идею. Вместо русских букв — вопросики. Баловство с iconv и с --default-character-set=cp1252 ни к чему не привело.

Что забавно, из phpMyAdmin отображаются не вопросики, а зяба — то есть, я не исключаю, что именно экзотическая 1252 там и есть.

Вопроса у меня, собственно, два.

1. Можно ли как-то это дело сдампить в человеческой кодировке?
2. Можно ли как-то дать команду MySQL изменить одно поле по маске? Мне нужно всего навсего заменить в записях все вхождения «browse_[0-9]» на «browse_6».

Ссылка

←	HTML][FLASH] флеш поверх изображения

[JavaScript] Application Design Patterns

→

Делаешь дамп в кодировке базы. Судя по DEFAULT CHARSET=utf8, это utf8 и есть. У тебя задача - сдампить базу без перекодирования, поэтому и дампить надо в той кодировке, какая указана в таблицах.

Смотришь этот дамп в HEX-виде. Если там физически знаки вопроса ("???", 0x3F, 0x3F...) - то или сдампил криво, или убита уже сама база.

Если там хранятся реальные данные, то разбираешься, что это за кодировка, и или перекодируешь в utf8 из неё дамп, или меняешь записи «DEFAULT CHARSET» на эту кодировку. И втягиваешь дамп.

Можно ли как-то дать команду MySQL изменить одно поле по маске?

Вроде бы, нет. Не знаю такого. Но если browse_[0-9], то можно сделать тупо 10 реплейсов:
UPDATE jos_vm_category SET category_browsepage = REPLACE(category_browsepage, 'browse_0', 'browse_6');

потом стрелку вверх (подразумевается, что работа в консоли), меняем _0 на _1 и Enter. Повторяем до _9.

~~KRoN73~~ ★★★★★
(16.03.10 16:37:52 MSK)

Ответ на: комментарий от KRoN73 16.03.10 16:37:52 MSK

Сделал дамп, указав --default-character-set=utf8. Нашёл участок «COMMENT='????????? ??????? ???????? ????'». Расшифровал вопросы.

«63 63 63 63 63 63 63 63 63 32 63 63 63 63 63 63 63 32 63 63 63 63 63 63 63 63 32 63 63 63 63»

Вопросы в других местах — то же самое. char (63).

База сама убита очень вряд ли, так как она работает и отображает на сайте русский текст корректно. Более того, в ней есть поля, которые я лично правил вчера вечером — то есть, это актуальная база.

Так что, вероятно, я таки криво дамплю. Дам делаю командой

mysqlbase airrideru jos_vm_category > temp.txt

Сейчас попробую сделать резервную копию базы и replace.

Ritz
(16.03.10 16:58:23 MSK) автор топика

Ответ на: комментарий от Ritz 16.03.10 16:58:23 MSK

>Нашёл участок «COMMENT

Не, comment не катит :) Там при проблемах кодировки записи пропадают почти всегда. Смотри в самих данных.

Вопросы в других местах — то же самое. char (63).

Если так - то проблема или с дампом, или с базой. На счёт последнего можно проверить вручную посмотрев файлы mysql из /var/lib/mysql/<имя-базы>/<имя-таблицы>.MYI

База сама убита очень вряд ли, так как она работает и отображает на сайте русский текст корректно.

Тогда экспериментируй с параметрами дампа. У тебя задача сейчас - спросить дамп без перекодировки. Дальше будет просто.

Дам делаю командой mysqlbase airrideru jos_vm_category > temp.txt

? Может, не mysqlbase (я такой не знаю), а mysqldump? :)

Сделал дамп, указав --default-character-set=utf8

А если попробовать сделать дамп не указывая кодировку?

~~KRoN73~~ ★★★★★
(16.03.10 17:04:19 MSK)

Ответ на: комментарий от KRoN73 16.03.10 17:04:19 MSK

Огромное спасибо за replace: всё заработало. Несколько странно, что MySQL не поддерживает регекспы, но, в любом случае, нажать несколько раз клавишу «вверх» мне не сложно.

Дамп без указания кодировки (или с указанием любой другой) даёт те же вопросики. Такое чувство, что mysqldump просто игнорирует этот ключ.

А вот в phpMyAdmin картина иная:

Создан: phpMyAdmin 2.11.9.1 / MySQL 5.0.26-log
SQL-запрос: SELECT COUNT(*) AS `Строки`, `category_description` FROM `jos_vm_category` GROUP BY `category_description` ORDER BY `category_description` LIMIT 0, 50 ;
Строки: 4
Строки category_description
3 NULL
109
1 Ãîòîâûå êîìïëåêòû Chassistech
1 Óíèâåðñàëüíûå êîìïëåêòû äëÿ ñàìîñòîÿòåëüíîé óñòàíî...

Ritz
(16.03.10 17:16:20 MSK) автор топика

Ответ на: комментарий от Ritz 16.03.10 17:16:20 MSK

>Несколько странно, что MySQL не поддерживает регекспы

Поддерживает, но только в сравнениях, не в заменах.

Такое чувство, что mysqldump просто игнорирует этот ключ.

Попробуй поиграть с /etc/mysql/my.cnf:

[mysqldump]
character-sets-dir=/usr/share/mysql/charsets
default-character-set=utf8

и т.п.

Ãîòîâûå êîìïëåêòû Chassistech

Это нормально. Похоже на windows-1251, выданный в latin1.

...

Кстати, можешь попробовать ещё сдампить в кодировке latin1.

~~KRoN73~~ ★★★★★
(16.03.10 17:33:36 MSK)

Ответ на: комментарий от Ritz 16.03.10 17:16:20 MSK

Расшифровал через кодировщик Лебедева. Там и в самом деле был CP1252.

1 Готовые комплекты Chassistech
1 Универсальные комплекты для самостоятельной устано...

Проблема в том, что на ключ --default-character-set=cp1252 идёт отлуп:

mysqldump: Character set 'cp1252' is not a compiled character set and is not specified in the '/usr/local/share/mysql/charsets/Index.xml' file

Впрочем, по крайней мере, теперь я могу делать дампы через phpMyAdmin, перекодировать их cp1252->UTF8, править что надо и загружать через phpMyAdmin обратно.

Ritz
(16.03.10 17:35:09 MSK) автор топика

Ссылка

Ответ на: комментарий от KRoN73 16.03.10 17:33:36 MSK

Увы, у меня на этом хостинге нет прав заглядывать в /etc и в /usr/share

В latin1 идут, как ни странно, те же вопросики.

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

Ritz
(16.03.10 17:39:01 MSK) автор топика

Ответ на: комментарий от Ritz 16.03.10 17:39:01 MSK

>благо черезжопный метод дампа найден.

А! Я проглядел. Из phpMyAdmin удаётся сделать нормальный дамп? Тогда всё ок, делай из него и дальше - как я предлагал выше.

~~KRoN73~~ ★★★★★
(16.03.10 17:55:32 MSK)

Ссылка

>Мне нужно всего навсего заменить в записях все вхождения «browse_[0-9]» на «browse_6».

UPDATE table SET field=«browse_6» WHERE field REGEXP «browse_[0-9]»
Если ничего кроме цифр в конце поля гарантировано нет, то лучше даже так:
UPDATE table SET field=«browse_6» WHERE field LIKE «browse\__»

nu11 ★★★★★
(16.03.10 20:31:57 MSK)