charset mysql

[duddits1 0]

Неплохо бы было устанавливать клиентский чарсет. Так как весь текст в магазине в ср1251, то, наверно, логично бы ср1251 и ставить. И сортировки. А то столкнулся - на хостинге дефолтная утф8 и всё - коннект по дефолту считается в утф8. Если неправ-поправьте.

[support 447]

Не знаю, вроде магазин ведь не только в России используют, а например в Германии, в Польше.

Я завёл в faq вопрос такой - http://vamshop.ru/support/modules/smartfaq/faq.php?faqid=3

А вот добавлять по умолчанию в магазин, даже не знаю, правильно ли.

[duddits1 0]

надо конфигурируемо сделать.

угу, тока я еще и SET NAMES сделал

[support 447]

Нужно будет подумать, как правильно сделать.

[ABerezin 0]

На utf-8 переходить надо, как ни крути. Всё равно ajax заставит.

[duddits1 0]

Вот как только будет сборка с языком в утф8, так сразу. И следующие патчи, версии, свн тот же самый

[support 447]

ABerezin

Так я ж непротив, мне тоже UTF-8 кажется правильным подходом,чем постоянная путаница с кодировками.

Только я вот боюсь, а никаких подводных камней не будет?

Ведь перевести все тексты и базу в UTF8 не сложно.

Но что-то боюсь, что наверняка проблемы вылезут.

[ABerezin 0]

Один из "подводных" камней, который, впрочем, лежит на поверхности, - длина полей в БД. Для кириллицы надо увеличить их размеры в 2 раза.

Размеры страниц, объёмы передачи информации от/к серверу БД увеличатся. Но не существенно.

Могут возникнуть проблемы корректировкой скриптов, если редактор настроен неправильно.

Возникнут проблемы с функциями типа перекодировки в транслит, если забыть её перекодировать в utf-8. Но это потому что функция, точнее таблица символов, находится не в языковом файле.

Конечно ещё вылезут мелкие ошибки, но это хорошо - это позволит вычистить магазин от некорректностей.

Зато какие преимущества!

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

При создании сайтов в utf-8 я столкнулся с ситуацией, когда большинство доморощенных сео-сервисов не понимали эту кодировку. Но ведь это их беда :)

[ABerezin 0]

Кстати, переход на utf-8 не отменяет актуальности темы обсуждения :)

[duddits1 0]

Один из "подводных" камней, который, впрочем, лежит на поверхности, - длина полей в БД. Для кириллицы надо увеличить их размеры в 2 раза.

Размеры страниц, объёмы передачи информации от/к серверу БД увеличатся. Но не существенно.

Длина полей. Убить бы того мудрака, кто придумал использовать варчар ограниченной длины! Да и вообще того, кто придумал использовать базовой мискль. А объемы передачи - не думаю, что они кого-то в современных условия в современных магазинах волнуют, особенно учитывая то, что хост бд и веб сервера либо расположены впритык друг к другу, либо на одном тазике.

[ABerezin 0]

duddits1,

Про varchar ограниченной длины почти согласен (за исключением формирования индексов на некоторые поля, где без ограничения длины не обойтись).

[ABerezin 0]

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

[duddits1 0]

всё-равно с утф8 не вполне комфортно работать. мало пока что (мне так каэца) инструментов, которые могут прожевать утф8 после того, как сделаешь дамп бд и решишь на досуге с трубкой в нем поковыряться. разве что каждый раз конвертить туда-сюда.

[ABerezin 0]

Не знаю. Ни разу не приходилось ковыряться в дампе БД. Предпочитаю ковыряться в самой БД :)

Максим (maxsite.org) сделал такую, странную на мой взгляд, штуку - база в cp1251, сайт в utf-8, перекодировка "на лету". Мне не нравится, но можно рассматривать как один из вариантов.

[support 447]

Если делать на utf-8, это ж будет большая проблема с обновлением уже работающих магазинов, как я понимаю. Что-то я даже сомневаюсь в этой затеи, т.е. она правильная, но уже работающие магазины, что с ними делать.

[ABerezin 0]

Я проблем не вижу. Ничего не делать с работающими магазинами. Пусть работают. Или пусть решают админы/владельцы.

Или ты считаешь что иметь два варианта кодировки это очень заморочно?

[support 447]

Ну так многие ведь патчами обновляются.

Как уже работающий магазин перевести на utf-8?

т.е. не всеж в курсе как это делается, т.е. я ж так понимаю, с языковыми файлами и просто файлами понятно, их все перевести в utf-8 и добавить в патч.

А как быть с базой данных, как её перевести у работающих магазинов с минимумом затрат, т.е. по идее, можно через dumper сделать backup, сохранить его, открыть, перевести в utf-8, сохранить, восстановить в админке.

Если магазин с нуля ставится, с этим вроде бы понятно, с нуля всё в utf-8 будет.

Я даже не представляю сколько писем получу после такого патча.

[ABerezin 0]

Вариант с перекодировкой дампа БД не проходит - кроме перезагрузки БД нужно ещё CHARSET и collation поменять, увеличить размеры полей. "Автоматом" это может сделать только скрипт (надо будет - скажи, я скину тебе).

Писем получишь много. Причём только процентов 10 по делу :)

Я так понимаю ты не хочешь поддерживать два варианта. Да, наверное заморочно это. На старом форуме, если помнишь, несколько лет назад обсуждали варианты перехода на utf-8. Я тогда предлагал вариант похожий на упомянутый выше (maxsite.org). Но это какие-то полумеры, дающие полурезультаты :)

[support 447]

Два варианта я конечно не хочу, как-то неправильно.

Я лишь хочу минимизировать возможные проблемы при переходе на utf-8 для уже работающих магазинов, что б обновление гладко прошло.

Я пока что сейчас на локалке у себя потестирую с utf-8 как будет работать.

Спасибо Андрей, насчёт скриптика напишу, если всё-таки решусь перевести всё на utf-8.

[geval 3]

а что же делать- если на хостинге кодировка utf-8 по умолчанию  ( поменять невозможно), базу данных перевожу в utf, через phpmyadmin все видно по русски, а на сайте знаки вопроса пресловутые..

[duddits1 0]

Ну как что? Скрипт апгрейда-конвертации и всё ;) Да ничего нет странного в таком. У меня у самого есть парочка таких мест. В основном в базе лежит, правда, кои8 да и базы постгрес, а вот морда - ср1251, ибо дизайнеры/верстаки больше ничего не умеют.

[support 447]

geval

Если знаки вопроса, то, по идее, вот это помогает: http://vamshop.ru/support/modules/smartfaq/faq.php?faqid=3

Bububu

Ну как это не надо?

Если сайт (тексты, meta charset) будет в UTF-8, а данные в базе записаны в cp1251, ничего хорошего ведь не получится.

[duddits1 0]

geval, и что, даже alter database <bambucha> set charset=cp1251; не помогает? и при заливке дампа каждую таблицу если создавать с нужной кодировкой и коллэйшином - тоже? ни в жисть не поверю.

[ABerezin 0]

На самом деле нужно начать с темы топика - создание константы в config для определения charset и collate БД.

[duddits1 0]

или даже двух - кодировка хранимая в базе и кодировка клиента (т.е. магазина самого).

p.s. эх, насколько бы было проще, если б пользовали мы латиницу ;)

p.p.s. хорошо, что мы не китайцы ;)