Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
Форум PHP-MyAdmin.RU → Настройка phpMyAdmin → Содержимое таблиц отображается кракозяброй.
Возможно проблема в том, что текстовые файлы скрипта phpMyAdmin были залиты на сервер через FTP, как бинарные.
это вряд ли, потому что я просто распаковал архив с пма на своем компьютере.
spendolas
Опишите вашу конфигурацию и операционную систему. Локально, я правильно понял?
Опишите вашу конфигурацию и операционную систему. Локально, я правильно понял?
Прошу прощения,
ОС - Mac OS X 10.4.7
MySQL - 4.1.14-standard
phpMyAdmin 2.5.3-rc3 + второй phpMyAdmin - 2.9.0.2
Локальный сервер Apache 1.3.
spendolas
Удалось ли создать базу данных, если да, то что возвращают другие запросы на выборку из базы?
Cane
Ваша проблема в MySQL 4.0. Я уже писал в другой теме о возможном решении через сохранение данных в бинарном виде. Но лучше смены хостинга, всё-равно ничего не придумать.spendolas
Возможно проблема в том, что текстовые файлы скрипта phpMyAdmin были залиты на сервер через FTP, как бинарные.
Решение оказалось простым: при экспорте дампа необходимо указать в опциях SQL -> совместимость SQL экспорта -> MYSQL323. С MYSQL40 точно не работает.
Удалось ли создать базу данных, если да, то что возвращают другие запросы на выборку из базы?
Любые запросы обрабатываются правильно, и все отлично функционирует как в пма, так и в моем скрипте, кроме одного - русские тексты, получаемые скриптом, так сказать, неадекватны. Т.е., если я изменяю строку с помощью, например, функции ucfirst(), то результат не соответствует ожиданиям: либо все прописные, либо все заглавные, но при этом совершенно нормальные русские буквы, не кракозябры никакие.
После просмотра форума, мне показалось, что скорее всего дело в кодировке этого текста в БД. Во-первых, когда я создаю базу, готов спорить, она создается в дефолтной кодировке latin1, далее я в эту базу ввожу информацию в win1251, она там нормально хранится и извлекается, однако, сортировка по русскому алфавиту не работает, и, как я уже написал, в пхп манипулировать этими текстами не очень-то получается.
Кроме того - если я экспортирую базу с помощью пма в sql-формат, в код создания таблиц пма добавляет DEFAULT CHARSET=latin1. И если эту строчку не удалить вручную, то при импорте этого sql-файла, весь текст превратится в кракозябры, а точнее в знаки вопроса.
spendolas
Если скрипт ваш собственный, то попробуйте перед подключением к MySQL выполнить запрос:
SET NAMES cp1251;
Как правило я использую для подключения к MySQL данную функцию. Возможно она будет вам полезна.
function ConnectDB($dbname) {
$link = mysql_connect('localhost', 'site', 'pass') or header('Location: Error');
mysql_query('SET NAMES cp1251') or header('Location: Error');
mysql_select_db($dbname) or header('Location: Error');
return $link;
}Если скрипт ваш собственный, то попробуйте перед подключением к MySQL выполнить запрос:
SET NAMES cp1251;
Забавно, но после этого запроса текст превратился в знаки вопроса :)
Судя по всему, mysql перекодировала мой русский текст из latin1 в cp1251, совершенно не подозревая о том, что он уже в нужной кодировке. Как я говорил, кодировка таблиц задается latin1. То есть проблема в изначально неправильно созданных таблицах.
spendolas
То есть проблема в изначально неправильно созданных таблицах.
Забавно, но после этого запроса текст превратился в знаки вопроса
Судя по всему, mysql перекодировала мой русский текст из latin1 в cp1251, совершенно не подозревая о том, что он уже в нужной кодировке. Как я говорил, кодировка таблиц задается latin1. То есть проблема в изначально неправильно созданных таблицах.
Всё правильно. Это и должно было произойти. Смысл использования set names при подключении появляется только при использовании данного запроса с самого начала, то есть не только при выборке данных, но при вставке и изменении.
Rash дал вам ссылку на тему, в которой описана возможность перекодирования таблиц. Очень здравая идея, просто перекодировать уже существующие и использовать set names. Думаю проблема с кодировкой исчезнет.
Ребят, позвольте хрюкнуть. У меня тоже кракозябры в таблицах, но вида с...а... Я не пойму, это тоже с кодировками чтото? В браузере данные этих таблиц отображаются нормально, но в самих таблицах и админке движка (EE) именно так, циферками. Где копнуть?;)
Вот, сейчас сюда скопировал проблемный текст из таблицы, и в посте тоже отобразилось нормально. Все таки в кодировках дело?
Ребят, позвольте хрюкнуть. У меня тоже кракозябры в таблицах, но вида с...а... Я не пойму, это тоже с кодировками чтото?
Всё у тебя хорошо, если я не ошибаюсь, это текст представленный с помощью html-сущностей. Так что все у тебя с кодировкой в порядке 
В браузере данные этих таблиц отображаются нормально, но в самих таблицах и админке движка (EE) именно так, циферками. Где копнуть?
Не знаю что такое EE, но в phpMyAdmin добиться отображения текста вместо html-сущностей понятными для тебя символами ты можешь, если используешь опцию "Browser transformation". Для этого выбери таблицу, где содержатся данные, записанные html-сущностями, затем "Structure" (Структура), выбираешь редактирование нужного поля (столбца). В выпадающем списке "Browser transformation" (Трансформация браузера) выбираешь значение "text/plain: external", после сохраняешь изменения.
sunchess
Посмотрите данную тему - http://forum.php-myadmin.ru/viewtopic.php?pid=1209
Уже не впервые слышу этот вопрос, хотелось бы прояснить некоторые моменты.
Причина появления html сущностей в том что кодировка MySQL на хосте - latin1, а данные записываются в cp1251 (Windows Cyrillic). Обязательно необходимо настроить MySQL на cp1251, иначе возникнут множественные проблемы. В частности не будет работать поиск и сортировка. Но намного больше проблем возникнет, если в БД будут вставляться данные фиксированного размера, так как в этом случае один символ займёт несколько символов html сущности, соответственно в поле, которое, к примеру должно включать в себя 10 символов войдёт только, примерно, три html сущности, а обрезанные, не вошедшие по длинне, будут оставлять хвосты, что совершенно не приемлемо, например в имени пользователя, не говоря уже о паролях.
Как я уже сказал проблема заключается в неправильной настройке MySQL, но решить её, если вы не являетесь владельцем выделенного сервера, не так и просто. Скажем если такие настройки MySQL у русского хостинга, то это однозначно плохой хостинг, если у заграничного, то никто для вас менять настройки, или тем более пересобирать MySQL не станет, соответственно единственным решением может быть выполнение запроса SET NAMES cp1251, сразу после соединения к MySQL. Но так как вы используете движок и скорее всего не знаете что в нём изменять и где, советую поискать решение данной проблемы на форумах пользователей данного движка. Как вариант можно так же рассмотреть перевод движка в Юникод, так как в этом случае проблемы с кодировками решаются сами собой.
Расширю горизонты, для более точной обрисовки ситуации. Один и тот же движок (опять таки таинственный EE) установлен на двух машинах. На одной из них - денвер, на второй - скачанные и установленные вручную PHP, MySQL, PHPmyadmin (последние скорее всего версии, качались неделю назад с оффсайтов). На машине с денвером - все в порядке. Поэтому, как мне кажется, в степях движка копаться смысла нет? А значит, виновен MySQL?:)
sunchess
Проверьте наличие директив.
my.ini
[mysql]
default-character-set=cp1251
[mysqld]
default-character-set=cp1251
# Также очень советую вставить это
skip-character-set-client-handshake
# Или это
# init-connect="SET NAMES cp1251"
Для информации: В Денвере MySQL собран с поддержкой кирилицы, поэтому там нет с ней никаких проблем.
Ув. Lokki, Hanut, как говорится, продолжаю подавать признаки жизни. По воле случая, пришлось устанавливать всю эту карусель на чистый винт. И не поверите - если раньше движок отображал все нормально, и проблема была только при отображении в базе (и по словам Lokki - при поиске и сортировке), то установив все заново вновь скачанные компоненты, я получил так любимую многим проблему - вместо html сущностей появились старые добрые вопросики. Добрую часть выходного провозился с пхп-майадмин, в итоге имею: при нажатии "переменные" (кажется, где выводятся настройки - кодировки сервера и т.д.) везде(!) отображается utf-8 (для примера сделал так), как и в настройках движка. Наличие директив my.ini, по совету Hanut, проверено везде, где только можно -и всюду указана utf-8. Как говорится, я напуган и потерян.=) Если при прошлом варианте с html сущностями я хоть видел свет в конце тоннеля, то сейчас я в полной темноте - вроде все нормально, ан-нет. Ах да. Еще пхп админ жалуется, что не находит мбстринг, хотя в настроечном файле он раскомментирован, и длл лежит по адресу(указанном в том же настроечном файле). А еще в нем не пашут кнопки добавления юзера, удаления/добавления записей... Ну не подло ли? Приговор - переустановка?;) Больше мой воспаленный мозг ничего предложить не может.
Наличие директив my.ini, по совету Hanut, проверено везде, где только можно -и всюду указана utf-8.
И что мешает поменять значения этих директив?
Еще пхп админ жалуется, что не находит мбстринг
В php.ini проверить корректность пути и существования там php_mbstring.dll (мой пример из винды):
extension_dir = "D:/Program Files/PHP5/ext"
И раскомментированность данной строки:
extension=php_mbstring.dll
А еще в нем не пашут кнопки добавления юзера, удаления/добавления записей
Этого я совсем не понимаю. Ни разу с таким не сталкивался.
Объясните, почему нельзя продолжать пользоваться Денвером, если в нём всё работает? Установка и настройка связки Apache, php, MySQL - дело не совсем тривиальное. Без опыта можно наплести такого, что потом придётся всё сносить.
Без опыта наплел такого, что все снес.=) Поэтому аккуратно установил все заново и вернулся к штмл-сущностям (все остальное - нормально).
В файл my.ini вписал вот это:
[mysql]
default-character-set=cp1251
skip-character-set-client-handshake
[mysqld]
default-character-set=cp1251
Прилагаю два скриншота настроек(3.89 КБ и 12.5 КБ), может там что-то не так?
В базе русский все еще не виден. В настройках самого движка, который генерит контент, кодировку указал cp1251. Все ли правильно я сделал? Немного смущает mySQL кодировка - utf-8.
Ничего проще придумать не смог, поэтому просто написал примитивный скрипт, выполняющий перекодировку текстового файла дампа из windows-1251 в utf-8. Сразу оговорюсь, что кроме перекодировки выполняется замена только CHARSET=cp1251 на CHARSET=utf8, а этого некоторым дампам будет мало.
Если возникнут предложения на включение дополнительных слов для корректного изменения файла дампа, буду добавлять.
Что надо сделать.
Создать файл с содержимым в рамке код, положить в одну папку сделанный только что файл и ваш дамп, поменять в скрипте file.sql на имя вашего файла дампа, при желании поменять dump_utf8.sql на имя выходного, перекодированного файла дампа. Запустить скрипт. Если вылезли ошибки записи в файл, установить на папку со скриптом разрешение на запись, и повторить снова. Если созданный файл не импортируется, либо работает не всё, найти в файле все вхождения "cp1251" и поменять их на "utf8".Все возникающие проблемы описывайте подробно. Будем вместе их решать.
<?php // Скрипт перекодирования текстового файла из WINDOWS-1251 в UTF-8. $dump_file = 'file.sql'; // Имя исходного файла, который необходимо перекодировать. $output_file = 'dump_utf8.sql'; // Имя выходного файла. $temp_dump = file_get_contents($dump_file); $temp_dump = iconv('WINDOWS-1251', 'UTF-8', $temp_dump); $temp_dump = str_ireplace('CHARSET=cp1251', 'CHARSET=utf8', $temp_dump); $handle = fopen($output_file, 'w'); fwrite($handle, $temp_dump); fclose($handle); echo 'Скрипт выполнен.'; ?>
str_ireplace я бы поменял на eregi_replace иначе не работает, по крайней мере у меня.
В след такой вопрос, будет ли скрипт работать с перекодировкой latin1 iso-8859-1 в utf8_unicode_ci
Я пробывал простой заменой значений - не получается, точнее получается но не то.
Вообщем история простая, есть база в latin1, в нее пишет скрипт на latin1 (iso-8859-1), русский показывает на сайте нормально так как соннект в utf8. Спрашивается как перегнать базу в божеский utf8_unicode_ci (мне нужен именно unicode а не general_ci)
Параметры новой базы:
MySQL charset: UTF-8 Unicode (utf8)
collation utf8_unicode_ci
Variable_name Value
character_set_client utf8
character_set_connection utf8
character_set_database utf8
character_set_filesystem binary
character_set_results utf8
character_set_server latin1
character_set_system utf8
Да, возможности поменять character_set_server latin1 на utf8 нет и не будет, но это и не так важно насколько я понимаю, так как скрипт я буду запускать через set names полюбэ. Спасибо.
Функция str_ireplace существует только в PHP5. Заменить ее можно на str_replace (регистрозависимо, но думаю мало что изменит) или как вы и предложили на
$temp_dump = eregi_replace('CHARSET=cp1251', 'CHARSET=utf8', $temp_dump);
Перекодировка из latin1 в utf8 осуществляется так:
$temp_dump = iconv('ISO-8859-1', 'UTF-8', $temp_dump);
$temp_dump = str_replace('CHARSET=latin1', 'CHARSET=utf8', $temp_dump);
Я не понял ваше упоминание русского языка. Русский язык записывается в БД в кодировке latin1? В БД, которую вы хотите переконвертировать, лежат данные на каком языке? Если можно, подробнее опишите, что вы делаете и что получается.
При использовании "Set names кодировка", настройки сервера роли играть не будут.
Функция str_ireplace существует только в PHP5. Заменить ее можно на str_replace (регистрозависимо, но думаю мало что изменит) или как вы и предложили на
$temp_dump = eregi_replace('CHARSET=cp1251', 'CHARSET=utf8', $temp_dump);Перекодировка из latin1 в utf8 осуществляется так:
$temp_dump = iconv('ISO-8859-1', 'UTF-8', $temp_dump);
$temp_dump = str_replace('CHARSET=latin1', 'CHARSET=utf8', $temp_dump);Я не понял ваше упоминание русского языка. Русский язык записывается в БД в кодировке latin1? В БД, которую вы хотите переконвертировать, лежат данные на каком языке? Если можно, подробнее опишите, что вы делаете и что получается.
При использовании "Set names кодировка", настройки сервера роли играть не будут.
Cпасибо за ответ. Изначально база была установлена по дефолту (сравнение в latin1_swedish и прочие прелести), в нее писал скрипт (немецкого производства, так что я подозреваю что чистейщий iso-8859-1/latin1), на сайте русский отображается нормально, но в myadmin все вот такими закорюками ? ??? ??? ????????.
Пробывал сливать базу в дамп через Navicat клиент, причем не в дефольной кодировке, а в utf-8 - дамп получался читабельный (в томже Notepad++, при условии что кодировка не менялась - ANSI), далее после ручной замены всех latin1 на utf8 в таблицах внутри дампа, пробывал залить через муадмин в новую базу (настроенную как надо (см. мой пост выше)): кодировка utf8, совместимость ставил и NONE и даже 402 ради интереса - все равно или русских слов не видно (сиднром квадративок), или если заливать через клиент - то все равно каракули типа ? ??? ??? ????????.
Этим скриптом тоже пробывал: сливал базу через муадмин в каракулях, перегонял с помошью скрипта - размер дампа увеличивался с 600 до 900 кб, и все равно все было в каракулях но уже типа перечекнутых А.
Вообщем чего токо не пробывал не пойму: если база в latin1 и скрипт пишет в ланит1, то как при выводе русский текст отображается как надо? Толи лыжи не едут, толи я не туда перегоняю...
nuker47
Кажется понял. Вы сохраняете кириллицу cp1251 в БД, в кодировке latin1. На сайте все отображается нормально, вероятно, благодаря set names 1251 при соединении, что игнорирует кодировку БД. Конвертировать впрямую здесь ничего нельзя, ведь в latin1 нет русских символов, и вы просто перекодируете крякозябы. Можно попробовать сделать так. Сперва перекодируйте с помощью phpMyAdmin, все таблицы в бинарный вид (это важно).
Здесь описано как это сделать.http://dev.mysql.com/doc/refman/5.0/en/charset-conversion.html
Должен работать вот этот запрос.
ALTER TABLE t1 CHANGE c1 c1 BLOB;
Затем установите стоявший ранее тип данных и необходимую кодировку.
ALTER TABLE t1 CHANGE c1 c1 VARCHAR(100) CHARACTER SET cp1251;
Для информации: размер дампа при перекодировке увеличился из-за того что был использован Юникод, который является многобайтовой кодировкой.
Внимание! Перед экспериментами резервное сохранение данных, обязательно!
nuker47
Кажется понял. Вы сохраняете кириллицу cp1251 в БД, в кодировке latin1. На сайте все отображается нормально, вероятно, благодаря set names 1251 при соединении, что игнорирует кодировку БД. Конвертировать впрямую здесь ничего нельзя, ведь в latin1 нет русских символов, и вы просто перекодируете крякозябы. Можно попробовать сделать так. Сперва перекодируйте с помощью phpMyAdmin, все таблицы в бинарный вид (это важно).
Здесь описано как это сделать.http://dev.mysql.com/doc/refman/5.0/en/charset-conversion.html
Должен работать вот этот запрос.
ALTER TABLE t1 CHANGE c1 c1 BLOB;Затем установите стоявший ранее тип данных и необходимую кодировку.
ALTER TABLE t1 CHANGE c1 c1 VARCHAR(100) CHARACTER SET cp1251;Для информации: размер дампа при перекодировке увеличился из-за того что был использован Юникод, который является многобайтовой кодировкой.
Внимание! Перед экспериментами резервное сохранение данных, обязательно!
Да у меня для этих целей тестовая база, так что все под контролем=)
Только хотел заметить, что русский на сайте выводится нормально БЕЗ set names 1251 при соединении (!) Я ничего не добавлял, что довольно странно, как Вы думаете?
Значит я так понял - оригинальую базу нужно перегнать в бинарный вид, потом перегнать в cp1251 и уже после этого слить ее через муадмин и перегнать при помощи Ващего скрипта (оригинального, для 1251--->utf)?
nuker47
Почему русский выводится я понять не могу, так как не знаю всей конфигурации и настроек системы. Но думаю это не важно.
Поняли вроде правильно. Весь смысл alter table заключается в том, что переконвертации не происходит, происходит только замена кодировки таблицы с latin1 на cp1251, а коды символов остаются прежними. Но проделать замену кодировки без предварительного перегона в бинарный вид нельзя, так как произойдет переконвертация крякозябов из-за изменения кодов символов. Это и есть основной момент, который надо понять. Для того чтобы переконвертировать в последствии в utf8, обязательно надо привести данные в корректный вид, то есть в ту кодировку, в которой они записываются, в cp1251. Получив корректный дамп вы сможете делать с ним что угодно. Но сам я такими делами не занимался, поэтому точно, по шагам, описать процесс не могу.
Если не трудно, описывайте ваши действия и результат, постараемся отработать механизм перевода некорректных данных для будущих читателей форума.
Cегодня попробывал (Server version: 5.0.30-Debian_3-log # MySQL client version: 5.0.30 phpMyAdmin - 2.9.0.2)
ALTER TABLE t1 CHANGE c1 c1 BLOB;
Я с mysql новичек, так что лучше ALTER TABLE all CHANGE c1 c1 BLOB; - ничего не придумал
Но ругается #1146 - Table 'test_07.t1' doesn't exist . Так же я не могу понять что вставить вместо c1 (колум? тоже all?) - у меня 66 tables, так что руками перегонять это все будет слишком сложно. Что посоветуете?
Точнее я не могу понять, что нужно укзать чтобы были задействованы <all tables> и <all collums> (вопрос может и тупой, но как и сказал, я в msql начинающий, если не сказать больше).
Форум PHP-MyAdmin.RU → Настройка phpMyAdmin → Содержимое таблиц отображается кракозяброй.
Форум работает на PunBB, при поддержке Informer Technologies, Inc
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
