SELECT 0xc390c5b8c390c2b5c391c281c390c2bec391e280a1c390c2bdc390c2b8c391e280a0c390c2b0;

Выполните его в окне SQL запроса в phpMyAdmin и получите желаемые крякозябы. Дальшы вы знаете.

Хорошо.

SELECT 0xc390c5b8c390c2b5c391c281c390c2bec391e280a1c390c2bdc390c2b8c391e280a0c390c2b0;

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

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

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

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

Не понял. Вы хотите чтобы скрипт нормально сохранял данные в БД? Для этого необходимо будет править сам скрипт и составляемые им запросы, да и кодировки таблиц менять. Если сами сможете, то вперед.

Но советую не мучиться. Перекодируйте, как я писал выше и пользуйтесь. Хотя крякозябы - это все-равно плохо. По меньшей мере поиск и сортировка по данным таблицы, работать точно не будут.

Выполнив данный запрос вы получите перекодировку из hex в следующие символы:
???µ?????‡?????†?°
Вставьте данные символы в столбец pl_title и проверьте, что получится.

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

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

Если там будет читаемый 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

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

Я имел в виду попробовать локально установить MediaWiki и создать пару страниц, затем посмотреть, что ложится в таблицу wiki_pagelinks. Если там будет читаемый utf8 - я удивлюсь.

Я не специалист по форумам, поэтому ничего конкретного сказать не могу.

Если возможно, проверьте локально, в каком виде данные записываются в бинарные поля

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

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

1. У MySQL нет понятия предпочтительной кодировки. При правильных настройках работать будут любые кодировки. Про MediaWiki я уже говорил - она некорректно локализована, если вообще локализована (или разработана). Нельзя хранить в таблицах с кодировкой latin1 данные в utf8. В latin1, просто нет символов с такими кодами, отсюда и крякозябы.
2. Делайте дамп с помощью phpMyAdmin, просто убирайте галочку сохранения бинарных полей в шестнадцатиричном виде. Если есть доступ к mysqldump, попробуйте использовать ее. Кстати, MySQL Administrator, также сохраняет поля с бинарным сравнением в шестнадцатиричном виде, но в отличие от phpMyAdmin, не имеет галочки позволяющей сохранение в виде символов.

Да, вы правы, похоже, что это юникод. Постараюсь подумать, как можно его вернуть в нормальное состояние.

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

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

Ниже, это то, что было снято с сервера, после чего сервер перестал существовать, и другого у меня нет
Ниже это только часть одной таблицы где такая вредная перекодировка в 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

Мне кажется у вас произошло двойное преобразование, то есть дамп был снят с hex, затем импортирован и снова снят с hex. Думаю только в этом случае могло получиться что-то вроде 390c.

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

По поводу локализации - видно, что ее никто не делал, иначе как можно кирилицу (тем более в юникоде) сохранять в таблицах с кодировкой latin1!?

Можно попробовать.

Aville
Хорошо, а теперь тот же кусок дампа, но без галочки hex.

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

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

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

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

Сразу скажу, что у вас в кодировках полная каша. Кирилица (cp1251) лежит в таблицах latin1. Скрипт не локализован, либо локализован некомпетентными людьми. Но кирилицу мы вам вернем, во всяком случае в том же виде, в каком она была до экспорта.