ShopCMS полностью в кодировке utf-8 (Нужна помощь)
#1
Отправлено 30 June 2013 - 04:13 PM
Перелистал кучу тем здесь по переделыванию скрипта полностью на utf-8. Видимо информации много-поэтому в голове каша. Буду рад любому совету или подсказке.
Начнем.
Раньше я пользовался коммерческим зазенденным скриптом (не VIP).
Порядок установки того скрипта был таков:
1)На хостинге, в настройках вэб сервера установил кодировку по умолчанию CP 1251. Или же, аналогично прописываю кодировку CP1251 в файле .htaccess
2) Создавал базу mysql в кодировке cp1251
3) Раскомментировал строки в файле /core/includes/database/mysql.php
mysql_query('set names cp1251');
mysql_query('set character set cp1251');
mysql_query('set character_set_client=cp1251');
mysql_query('set character_set_results=cp1251');
mysql_query('set character_set_connection=cp1251');
mysql_query('set character_set_database=cp1251');
mysql_query('set character_set_server=cp1251');
если я правильно понял, при раскомментировании этих строк, скрипт будет подключаться к базе в CP1251 и создавать там соответственно таблицы в CP1251 (если я не прав - поправьте)
4) Ну и все файлы шаблонов, модулей, языковой файл - все в кодировке CP 1251 ( Тоесть здесь я ничего не менял)
Теперь к главному. Приобрел здесь скрипт ShopCMS VIP. Наконец то избавился от zenda и приобрел поддержку скриптом php 5.3 - чему безгранично рад.
!!! Требуется полностью перейти на кодировку UTF-8 и уйти от CP1251.
Значит порядок моих действий будет таков:
1) На хостинге, в настройках вэб сервера устанавливаю кодировку по умолчанию UTF8. Или же, аналогично прописываю кодировку UTF8 в файле .htaccess
2) Создаю базу mysql в кодировке Utf-8 general ci
3) Ничего не надо раскомментировать в файле /core/includes/database/mysql.php (все и так подключится в utf8 и новые таблицы создадутся в utf-8)
4) Все файлы шаблонов, модулей, языковой файл и т.д - все нужно перекодировать из CP1251 (по умолчанию) в UTF-8
Причем мало перекодировать все файлы в utf8, нужно еще искать во всех файлах любое упоминание о cp1251 и менять его на utf-8.
Прошу совета-правильны ли мои действия?
И что будет если при установке вип-версии, базу допустим я создал в utf-8 а все остальное (кодировку файлов скрипта и содержимое файлов я не менял)?
#2
Отправлено 30 June 2013 - 05:01 PM
#3
Отправлено 30 June 2013 - 05:03 PM
#4
Отправлено 30 June 2013 - 05:36 PM
#5
Отправлено 30 June 2013 - 05:52 PM
ну а чтобы мне развеять мою кашу, все таки при кодировке файлов скрипта cp1251 - базы делать тоже cp 1251 и раскомментировать строки (пункт 3) или же базы делать utf-8 и ничего не раскомментировать? объясните пожалуйста разжеванно разницу. Заранее спасибо
Почему возник спор в голове. Потому что на форуме офф сайта все твердят про базы ТОЛЬКО в cp1251, а тут говорят что можно и utf-8 Голова кругом.
#6
Отправлено 30 June 2013 - 11:03 PM
перекодируй файлы, и пройдись поиском на предмет 1251. Больше вроде ничего делать не нужно, у меня давно работает движок, переведенный аналогичным образом.
#7
Отправлено 30 June 2013 - 11:23 PM
Нужно . Как минимум, убрать все перекодировки, которые требовались при применении AJAX-запросов. Да и еще грабель по мелочи насыплется. А вообще я тоже не понимаю, нафига оно надо кроме как для самореализации. Единственный вариант, когда оно мне ЧУТЬ-ЧУТЬ понадобилось, так это когда я прикручивал к shopCMS форум, работающий принципиально в UTF8. ДА и то отдельную базу создать было проще.Больше вроде ничего делать не нужно
#8
Отправлено 01 July 2013 - 10:01 AM
Потому что это - правильноА вообще я тоже не понимаю, нафига оно надо кроме как для самореализации.
1251 - анахронизм, от которого нужно избавляться (если есть на это время, конечно )
или хотя бы затем, чтоб в будущем не иметь проблем с тем же аяксом или сторонними скриптами.
#9
Отправлено 01 July 2013 - 10:07 AM
Потому что это - правильно 1251 - анахронизм, от которого нужно избавляться (если есть на это время, конечно ) или хотя бы затем, чтоб в будущем не иметь проблем с тем же аяксом или сторонними скриптами.
Глупости.
У тебя были хоть раз проблемы с аяксом или сторонними скриптами из-за кодировки?
у меня с 2006 года не было ни разу. В КРАЙНЕМ случае тот файл где возникнут проблемы можно и перевести, не вижу особой проблемы.
А гемороя безсмысленного по переводу на ЮТФ а потом еще и ошибок неочевидных будет дохуху .......
#10
Отправлено 01 July 2013 - 10:09 AM
ShopCMS весь целиком - анахронизм, от которого нужно избавляться . А переводить его в UTF это примерно как 408-му Москвичу делать покраску металликом и менять барабанные тормоза на современные дисковые. Современная машина из него все равно не получится, а "полчаса позора и на даче" он прекрасно выполняет и так .1251 - анахронизм, от которого нужно избавляться
#11
Отправлено 01 July 2013 - 10:10 AM
Да ничего подобного, все нормально работает уже который год.А гемороя безсмысленного по переводу на ЮТФ а потом еще и ошибок неочевидных будет дохуху
Хотя да, делалось тогда на чистом энтузиазме, без конкретной цели. Но не жалею
Тут ты абсолютно прав но привыкли уже, жалко выброситьShopCMS весь целиком - анахронизм, от которого нужно избавляться
#12
Отправлено 01 July 2013 - 10:22 AM
Оно нормально работает только до тех пор, пока ты сам этим занимаешься и понимаешь, что и как переделано и - главное! - что и как переделывать в случае проблем. Как только таким сайтом занимается кто-то другой и этому "другому" надо поставить какой-либо дополнительный модуль (с аяксом или еще какими извращениями по перекодировке), то будет он плеваться, ругаться и поминать автора перевода в UTF добрым словом. Понятно, что из этого модуля надо всего-лишь "убрать лишние перекодировки", только сначала до этого нужно догадаться, а потом еще и проделать лишнюю работу.Да ничего подобного, все нормально работает уже который год.
Ну вот положа руку на сердце - НАХЕРА в двуязычном интерфейсе многоязычный UTF?
#13
Отправлено 01 July 2013 - 07:59 PM
Раз скрипт полностью на cp1251-то зачем базы тогда в utf -8 создавать? сделал в 1251 и делов то. Как проявит себя и где различие баз (в cp1251 и utf8) ?
#14
Отправлено 01 July 2013 - 11:14 PM
Ну так и делайте, кто ж мешает? Если SQL-сервер свой и Вы сами определяете character-set-server. Будет не по два байта на символ, а по одному, т.е. база будет занимать в два раза меньше места и быстрее работать. А хостер держит SQL-сервер с UTF-8 по умолчанию потому, что понятия не имеет, в какой кодировке вы предпочитаете работать. Но UTF-8 нынче самая распространенная, а однобайтовые кодировки прекрасно в ней хранятся, просто с избыточностью.Раз скрипт полностью на cp1251-то зачем базы тогда в utf -8 создавать? сделал в 1251 и делов то
Мне думается, что если вопрос интересен, то про кодировки SQL-сервера (а там весьма хитрая мешанина кодировок может быть) в интернете имеется огромное количество статей на любой уровень понимания. А если разбираться не хочется, то надо ставить продукт в том виде, в каком он штатно есть. Дешевле выйдет, особенно потом.