Форум MySQL

Ок. Мои рекомендации теперь можете воспринимать столь же образно :)

исправил :)

подправляйте. :)

>Применяя подход из статьи Вы в конечном итоге столкнулись бы с тем же самым.
>substr не будет работать с utf8 независимо от того, как именно это utf8 получено.

Я испробовал все два способа, результат меня не удовлетворил, Вы сделали подсказку, у меня всё получилось (вроде). Пока смотрю, читаю, пробую на практике.....
Ещё раз благодарю.

>За цитату, рвущую страницу в горизонтальный скроллинг, отдельное ..... "мерси".

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

>>Результат чего Вас не удовлетворил?
>
>не удовлетворил потому, что после применения функции substr() последний символ обрезаной строки может выводится как "ромб, в нём ?". Хотя не всегда.

Я спросил не "почему", а "какого этапа" результат.
Каким боком это соотносится с выбранным методом?
Применяя подход из статьи Вы в конечном итоге столкнулись бы с тем же самым.
substr не будет работать с utf8 независимо от того, как именно это utf8 получено.

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

>Результат чего Вас не удовлетворил?

не удовлетворил потому, что после применения функции substr() последний символ обрезаной строки может выводится как "ромб, в нём ?". Хотя не всегда.

>что обычные строковые функции к ним неприменимы
спасибо за подсказку, пытаюсь разобраться с mb_***(), но пока что то не очень получается.

>Но полагаю, что если вы снимаете дамп на сервере с поддержкой кодировок (это версия 4.1 и
>выше) в кодировке latin1 , ТО в самом дампе (пусть даже внутри него текст будет вполне
>адекватным) в описаниях таблиц Вы получите всё ту же установку кодовой страницы в latin1, а
>значит фактически его потом будет не применить.

как раз в статье и говорится, что после снятия дампа надо изменить описание кодировки в самом дампе
цитата из статьи

В файле дампа поправляем операторы CREATE DATABASE и/или CREATE TABLE для создания таблиц в правильной кодировке. Либо меняем настройки database, как это было описано выше.

>Так я и сделал, но результат меня не удовлетворил, почему, я писал здесь
Результат чего Вас не удовлетворил?
Перенос данных был выполнен вполне корректно.
А то что с utf-8 данными на php работать чуть сложнее, чем с однобайтовыми (что обычные строковые функции к ним неприменимы) - еще не повод откатываться на кривую версию базы.

>Поискав ещё в инете, наткнулся на такую статью

Так что залезать в статью о восстановлении данных было вроде как без надобности.

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

Я не смотрел эту статью.
Но полагаю, что если вы снимаете дамп на сервере с поддержкой кодировок (это версия 4.1 и выше) в кодировке latin1 , ТО в самом дампе (пусть даже внутри него текст будет вполне адекватным) в описаниях таблиц Вы получите всё ту же установку кодовой страницы в latin1, а значит фактически его потом будет не применить.
Снимать дамп в такой ситуации нужно в режиме совместимости со старыми версиями сервера (MYSQL 4.0) . И очевидно в этом случае в дампе никаких ремарок о типе кодировки оставлено не будет.

>Вот какой к богу в рай бензин-инжектор, если кодировка latin1 ?!!
я это понял с первого раза, как Вы мне это написали в другой теме.
Но всё это продолжение темы, которая находится здесь и ещё одной, в другой ветке формума.
По поводу дампа базы Вы мне писали:
"Самое честное решение - на php уровне вытащить все вытаскиваемые данные
(и возможно, тут же честно положить их в другую таблицу - корректно описанную, и через корректное подключение подцепленную)". Мне и самому приходила в голову такая мысль, Вы её подтвердили.
Так я и сделал, но результат меня не удовлетворил, почему, я писал здесь
Поискав ещё в инете, наткнулся на такую статью, вот в ней и описывается способ получения дампа, который нормально читается в редакторе, а для этого надо указать кодировку latin1.
Если этого не сделать, то в дампе ни чего нельзя будет прочитать, останутся теже крокозяблы, что и в самой базе.
Я исходил из того, что если в дампе нормально можно будет прочитать информацию, то это может повлиять положительно на результат.
Но, как показал эксперемент, отдельные символы не читаются всё равно. Это происходит после того, как я обрезаю информацию функцией substr() для превью, хотя если вывести польностью информацию, то всё отображается нормально.

>а по поводу остального.... ну тут как посмотреть.

Вот вот. Как посмотреть.
Вот Ваше

mysqldump -u root -p1111 basename table --default-character-set=latin1 > table.sql INSERT INTO `auto_sell` VALUES (401,'TOYOTA','Corolla',2001,'','Бензин-инжектор',

Вот какой к богу в рай бензин-инжектор, если кодировка latin1 ?!!
Нету в latin1 ни единой русской буквы, не было никогда и не будет!

Благодарю за архив, всё работает, сам архивчик припрятал в укромное место :):):):)

а по поводу остального.... ну тут как посмотреть.