Проблема после восстановления дампа MediaWiki

вот что я получил когда выгрузил с галочкой hex / это кусок дампа одной таблицы
где видно, что вот по этой строке
[mono]pl_title` varchar(255) character set latin1 collate latin1_bin NOT NULL default[/mono]
phpMyAdmin только эти поля перекодировал.

[mono]
CREATE TABLE `wiki_pagelinks` (
  `pl_from` int(8) unsigned NOT NULL default '0',
  `pl_namespace` int(11) NOT NULL default '0',
  `pl_title` varchar(255) character set latin1 collate latin1_bin NOT NULL default '',
  UNIQUE KEY `pl_from` (`pl_from`,`pl_namespace`,`pl_title`),
  KEY `pl_namespace` (`pl_namespace`,`pl_title`,`pl_from`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

--
-- Дамп данных таблицы `wiki_pagelinks`
--
INSERT INTO `wiki_pagelinks` (`pl_from`, `pl_namespace`, `pl_title`) VALUES
(1, 0, 0xc390c5b8c390c2b5c391c281c390c2bec391e280a1c390c2bdc390c2b8c391e280a0c390c2b0),
(1, 1, 0xc390e28094c390c2b0c390c2b3c390c2bbc390c2b0c390c2b2c390c2bdc390c2b0c391c28f5fc391c281c391e2809ac391e282acc390c2b0c390c2bdc390c2b8c391e280a0c390c2b0),
(1, 4, 0xc390c5bec390c2bfc390c2b8c391c281c390c2b0c390c2bdc390c2b8c390c2b5),
(1, 4, 0xc390c5b8c390c2bec391e282acc391e2809ac390c2b0c390c2bb5fc391c281c390c2bec390c2bec390c2b1c391e280b0c390c2b5c391c281c391e2809ac390c2b2c390c2b0),
(9, 0, 0xc390c2a1c391e2809ac390c2b0c391e282acc391e280b9c390c2b95fc390c2b2c390c2b0c391e282acc390c2b8c390c2b0c390c2bdc391e2809a5fc390c2b1c391c692c390c2bac390c2bbc390c2b5c391e2809ac390c2b05fc390c2bec391e2809a5f323030355fc390c2b3c390c2bec390c2b4c390c2b0),
(13, 4, 0xc390c5b8c390c2bec391e282acc391e2809ac390c2b0c390c2bb5fc391c281c390c2bec390c2bec390c2b1c391e280b0c390c2b5c391c281c391e2809ac390c2b2c390c2b0),
(18, 0, 0x44656269616e),
(18, 0, 0x474e4f4d45),
(18, 0, 0x4c6976652d4344),
(18, 0, 0xc390c593c390c2b0c391e282acc390c2ba5fc390c2a8c390c2b0c391e2809ac391e2809ac390c2bbc390c2b2c390c2bec391e282acc391e2809a),
(20, 4, 0xc390c5bec390c2bfc390c2b8c391c281c390c2b0c390c2bdc390c2b8c390c2b5),
(20, 14, 0xc390cb9cc390c2a22fc390cb9cc390c2bdc391c281c391e2809ac391e282acc391c692c390c2bac391e280a0c390c2b8c390c2b8),
(20, 14, 0xc390cb9cc390c2a22fc390c5b8c391e282acc390c2b0c390c2b2c390c2b8c390c2bbc390c2b0),
(20, 14, 0xc390c593c390c2bec390c2b1c390c2b8c390c2bbc391c592c390c2bdc390c2b0c391c28f5fc390c2a1c390c2b2c391c28fc390c2b7c391c592),
(20, 14, 0xc390c5b8c390c2b5c391e282acc391c281c390c2bec390c2bdc391e280b9),
(20, 14, 0xc390c2a0c391c692c390c2bac390c2bec390c2b2c390c2bec390c2b4c391c281c391e2809ac390c2b2c390c2b0),
(20, 14, 0xc390c2a1c390c2bbc390c2bec390c2b2c390c2b0c391e282acc391c592),
(20, 14, 0xc390c2a2c391e282acc390c2b5c390c2b1c391c692c390c2b5c391e2809a5fc390c2bfc391e282acc390c2b0c390c2b2c390c2bac390c2b8),
(25, 2, 0x4d6f72696b6f6666),
(26, 0, 0xc390cb9cc390c2a2),
[/mono]

и вот что получается на страницах

Дык, проблема-то в том, что нет такого дампа как без галочки hex! (только с галочкой)
Если бы такой был, то всё легло бы обратно простым способом. Я проверял уже потом.

Но я могу развернуть новую базу wiki, сделать пару статей и выгрузить без галочки hex, и будет видно какая должна быть "казябазя".

Так подойдёт?

А вот по поводу локализации: а её никто и не делал, MediaWiki установлена как есть с поддержкой UTF / MySQL установлен так же по умолчанию на сервере Debian. И Debiane по-моему русский язык на UTF замешан.

Ниже, это то, что было снято с сервера, после чего сервер перестал существовать, и другого у меня нет
Ниже это только часть одной таблицы где такая вредная перекодировка в hex
Меня такой полный файл со всеми таблицами в архиве gz весит ~3Mb а распакованный ~26Mb

[mono]--
-- Структура таблицы `wiki_pagelinks`
--

CREATE TABLE `wiki_pagelinks` (
  `pl_from` int(8) unsigned NOT NULL default '0',
  `pl_namespace` int(11) NOT NULL default '0',
  `pl_title` varchar(255) character set latin1 collate latin1_bin NOT NULL default '',
  UNIQUE KEY `pl_from` (`pl_from`,`pl_namespace`,`pl_title`),
  KEY `pl_namespace` (`pl_namespace`,`pl_title`,`pl_from`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

--
-- Дамп данных таблицы `wiki_pagelinks`
--

INSERT INTO `wiki_pagelinks` (`pl_from`, `pl_namespace`, `pl_title`) VALUES
(1, 0, 0xc390c5b8c390c2b5c391c281c390c2bec391e280a1c390c2bdc390c2b8c391e280a0c390c2b0),
(1, 1, 0xc390e28094c390c2b0c390c2b3c390c2bbc390c2b0c390c2b2c390c2bdc390c2b0c391c28f5fc391c281c391e2809ac391e282acc390c2b0c390c2bdc390c2b8c391e280a0c390c2b0),
(1, 4, 0xc390c5bec390c2bfc390c2b8c391c281c390c2b0c390c2bdc390c2b8c390c2b5),
(1, 4, 0xc390c5b8c390c2bec391e282acc391e2809ac390c2b0c390c2bb5fc391c281c390c2bec390c2bec390c2b1c391e280b0c390c2b5c391c281c391e2809ac390c2b2c390c2b0),
(9, 0, 0xc390c2a1c391e2809ac390c2b0c391e282acc391e280b9c390c2b95fc390c2b2c390c2b0c391e282acc390c2b8c390c2b0c390c2bdc391e2809a5fc390c2b1c391c692c390c2bac390c2bbc390c2b5c391e2809ac390c2b05fc390c2bec391e2809a5f323030355fc390c2b3c390c2bec390c2b4c390c2b0),
(13, 4, 0xc390c5b8c390c2bec391e282acc391e2809ac390c2b0c390c2bb5fc391c281c390c2bec390c2bec390c2b1c391e280b0c390c2b5c391c281c391e2809ac390c2b2c390c2b0),
(18, 0, 0x44656269616e),
(18, 0, 0x474e4f4d45),
(18, 0, 0x4c6976652d4344),
(18, 0, 0xc390c593c390c2b0c391e282acc390c2ba5fc390c2a8c390c2b0c391e2809ac391e2809ac390c2bbc390c2b2c390c2bec391e282acc391e2809a),
(20, 4, 0xc390c5bec390c2bfc390c2b8c391c281c390c2b0c390c2bdc390c2b8c390c2b5),
(20, 14, 0xc390cb9cc390c2a22fc390cb9cc390c2bdc391c281c391e2809ac391e282acc391c692c390c2bac391e280a0c390c2b8c390c2b8),
(20, 14, 0xc390cb9cc390c2a22fc390c5b8c391e282acc390c2b0c390c2b2c390c2b8c390c2bbc390c2b0),
(20, 14, 0xc390c593c390c2bec390c2b1c390c2b8c390c2bbc391c592c390c2bdc390c2b0c391c28f5fc390c2a1c390c2b2c391c28fc390c2b7c391c592),
(20, 14, 0xc390c5b8c390c2b5c391e282acc391c281c390c2bec390c2bdc391e280b9),
(20, 14, 0xc390c2a0c391c692c390c2bac390c2bec390c2b2c390c2bec390c2b4c391c281c391e2809ac390c2b2c390c2b0),
(20, 14, 0xc390c2a1c390c2bbc390c2bec390c2b2c390c2b0c391e282acc391c592),
(20, 14, 0xc390c2a2c391e282acc390c2b5c390c2b1c391c692c390c2b5c391e2809a5fc390c2bfc391e282acc390c2b0c390c2b2c390c2bac390c2b8),
(25, 2, 0x4d6f72696b6f6666),
(26, 0, 0xc390cb9cc390c2a2),
(26, 0, 0xc390c5bec391e2809ac390c2b4c390c2b5c390c2bb5fc390c2bfc391e282acc390c2bec390c2b3c391e282acc390c2b0c390c2bcc390c2bcc390c2bdc390c2bec390c2b3c390c2be5fc390c2bec390c2b1c390c2b5c391c281c390c2bfc390c2b5c391e280a1c390c2b5c390c2bdc390c2b8c391c28f),
(26, 0, 0xc390c5bec391e2809ac390c2b4c390c2b5c390c2bb5fc391e2809ac390c2b5c391e280a6c390c2bdc390c2b8c391e280a1c390c2b5c391c281c390c2bac390c2bec390c2b3c390c2be5fc390c2bec390c2b1c391c281c390c2bbc391c692c390c2b6c390c2b8c390c2b2c390c2b0c390c2bdc390c2b8c391c28f),
(26, 0, 0xc390c5bec391e2809ac390c2b4c390c2b5c390c2bb5fc391e2809ac390c2b5c391e280a6c390c2bdc390c2b8c391e280a1c390c2b5c391c281c390c2bac390c2bec390c2b95fc390c2bfc390c2bec390c2b4c390c2b4c390c2b5c391e282acc390c2b6c390c2bac390c2b8),
(26, 0, 0xc390c5bec391e2809ac390c2b4c390c2b5c390c2bb5fc391c28dc390c2bac391c281c390c2bfc390c2bbc391c692c390c2b0c391e2809ac390c2b0c391e280a0c390c2b8c390c2b85fc390c2b85fc391e282acc390c2b0c390c2b7c390c2b2c390c2b8c391e2809ac390c2b8c391c28f5fc390c2b2c391e280b9c391e280a1c390c2b8c391c281c390c2bbc390c2b8c391e2809ac390c2b5c390c2bbc391c592c390c2bdc391e280b9c391e280a65fc391c281c390c2b5c391e2809ac390c2b5c390c2b9),
(26, 0, 0xc390c2a0c391c692c390c2bac390c2bec390c2b2c390c2bec390c2b4c391c281c391e2809ac390c2b2c390c2be5fc390c2a3c390c2bfc391e282acc390c2b0c390c2b2c390c2bbc390c2b5c390c2bdc390c2b8c391c28f5fc390cb9cc390c2a2),
(29, 0, 0xc390c290c390c2b4c390c2bcc390c2b8c390c2bdc390c2b8c391c281c391e2809ac391e282acc390c2b0c391e2809ac390c2bec391e282ac),
(29, 0, 0xc390c5b8c390c2b5c391c281c390c2bec391e280a1c390c2bdc390c2b8c391e280a0c390c2b0),
(38, 0, 0xc390cb9cc390c2a2),
(54, 2, 0x4d6f72696b6f6666),
(55, 0, 0xc390cb9cc390c2a23ac390c2a1c390c2b1c390c2bec390c2b8),
(55, 0, 0xc390c5b8c391e282acc390c2bec390c2b3c391e282acc390c2b0c390c2bcc390c2bcc390c2b05fc390c2a1c390e28098c390c5bec390cb9c),
[/mono]

Сообщение добавлено Fri Jun  1 16:14:02 2007
не берусь утверждать, но скорее всего это UTF8 перекодированный в HEX

Попутно у меня возникли некоторые вопросы.
[listo][li]Какая кодировка предпочтительнее всего для MySQL сервера и почему, если у меня Linux/Ubuntu на UTF8 и MediaWiki тоже так же?[/li][li]Как лучше всего делать дамп базы если с phpMyAdmin могут быть казусы?[/li][/listo]

я не очень понял, что мне сделать. знаю, что wiki отображается в UTF кодировке, я думаю что вводимый в поля форм текст, также и попадает в базу. (версия MediaWiki 1.9.3)

А что скажите про SMF, как этот форум локализован и на сколько корректно работает с кириллицей если по-умолчанию выбрана кодировка UTF8?

Удивляться не нужно, там вот что:

[mono]???????µ??_???????µ??_???‚???°?????†?°[/mono]

это так отображает phpMyAdmin используемый по-умолчанию с параметрами:
# Версия сервера: 5.0.32-Debian_7etch1-log
# Версия протокола: 10
# Сервер: Localhost via UNIX socket
# Пользователь: root@localhost
# MySQL-кодировка: UTF-8 Unicode (utf8)
# Сопоставление соединения с MySQL: utf8_general_ci
# phpMyAdmin - 2.10.0.2
# Версия MySQL-клиента: 5.0.32
# Использованы расширения PHP: mysql

О да! как Вы такое сделали? Всё стало читаемым на сайте, в данном случае это "Песочница", а phpMyAdmin отображается, что и вставил т.е. это: ???µ?????‡?????†?°

Интересно, а как теперь такое запустить на перекодировку?

я готов всё ручками проделать, вот только я не понимаю, что это такое, см. цитату.
кодировки таблиц тоже могу с помощью phpMyAdmin

Сообщение добавлено Sat Jun  9 13:54:49 2007

однако поиск работает, так как поиск происходит по содержанию статей