Приветствую!
С yii работу только начинаю, хотел сделать на yii сайт в кодировке 1251 (БД и интерфейс). Будут ли у меня проблемы? Пока столкнулся только с грозной надписью в messages: "NOTE, this file must be saved in UTF-8 encoding". Это действительно важно? Есть ли подводные камни при использовании в yii кодировок, отличных от utf-8?
С уважением.
не пробовал и не собираюсь.
А зачем делать себе лишний гемор? Даже еси есть база в ср1251, проще ее перекодировать в утф8 и не иметь ни с чем траблов.
Просто все скрипты Yii в утф8. Будут ли траблі неизвестно, там текст только английский в исходном коде.
Но я бы не проверял на вашем месте 
Т.е. прямо так все в utf и пишут? Опыта использования yii с другими кодировками ни у кого нет?
какие преимущества у ср1251? по моему не стоит возвращаться к тому от чего так долго отказывались
Все пишут проекты с планами на будущее. А у всех в планах - поддержка многоязычности.
Поэтому все выбирают более “умную” кодировку, при этом не теряют ничего. От выбора utf8 вам хуже не будет, только лучше. Поверьте мне! 
Понял, спасибо
Нужно будет перекодировать файл локализаций самого Yii в CP1251
проставить кодировку в app
наблюдать периодические глюки когда одна страница отображается в браузерах нормально, вторая ни с того ни с сего определяется как utf-8 хотя в мета всё верно прописано
Вобщем utf-8 куда как удобнее получается во всём.
Вполне успешно написал проект с использованием cp 1251. Немного действий в конфиге, и порядок.
Были попытки перейти на utf8. Всё прошло удачно, правда пришлось помучиться со сторонним spreadshit_excel_reader.
Но решили вернуться к cp1251, из-за возникших в других проектах проблем с регулярными выражениями. Но это уже проблема не Yii, а php.
А в чем проблема регулярок?
Я, если честно, не очень в курсе. Этим не я занимался. Но там что-то вроде того, что пятый пхп не поддерживат регулярные выражения в utf8 с кириллицей. Вернее, не то, что не поддерживает, а они как-то не так отрабатывают.
аа… ну это уже решаемо
С регулярками в utf плохо работают ereg функции, preg_ работаю как нужно.
Заметил, что тема устаревшая. Пришел сюда из поисковика. Отписался, для таких же)
@ Demyan:
таки-щито нужно сделать, уважаемый, подскажите, молю
…config/main.php
return array(
'basePath'=>dirname(__FILE__).DIRECTORY_SEPARATOR.'..',
'name'=>'Справочник по борьбе с клиентами',
'charset' => 'Windows-1251',
...blah...
и .htaccess в вебруте с
AddDefaultCharset Windows-1251
всё равно content-type приходит с utf-8
искал по всему yii строки с header - не нашёл где выставляется контент тайп 8(
Интересно кто отказался от cp1251?
UTF8 - 2 байта. Работа с cp1251 нам нет необходимости ставить mbstring и работать с неудобными mb_substr, mb_strlen, mb_strpos, mb_strstr, mb_strtolower, и десятками другими функциями. Так же получение данных в cp1251 - быстрей в 2 раза. Необходимость в UTF8 проявляется только если вы делаете сайт на языке который не поддерживается в cp.
Она и так в анси
Ни разу такого не наблюдал…
Думаю все останавливаются на русском и английском.
Посмотрите какие заголовки и какой контент выдает сервер.
Вы подправили дефолтные установки в protected -> views -> layouts -> main.php ??
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="language" content="en" />
Вы так уверенно отвечаете за всех…
Не знаю как у вас, а у нас в России в обозримом будущем китайский не планируют делать родным языком, поэтому преждевременные проблемы с utf8 никому не нужны. cp1251 с головой устраивает.
[quote name=‘Zolter’]Поэтому все выбирают более “умную” кодировку, при этом не теряют ничего. От выбора utf8 вам хуже не будет, только лучше. Поверьте мне!
[/quote]
Мда… вот и верь после этого людям.
бОльший объем памяти плюс падение производительности минимум в 2 раза - это "только лучше"?
Например, разработчики MySQL (в штатной документации) рекомендуют экономить на объеме данных в базе, например, не использовать int там, где достаточно smallint, а вы по широте душевной предлагаете тупо увеличить объем базы в 2 раза за счет хранения данных в 2-байтовой кодировке. Тем более в подавляющем большинстве проектов, где оно 300 лет никому не надо.
Точно так же эта "умная" кодировка отражается и на объеме потребляемой оперативной памяти, торможения в любых строковых операциях (сортировки, поиск, …).
UTF - буду использовать только тогда, когда реально понадобится поддержка многоязычности (ну, например, аналог мыло-ру захочу сделать), а в других случаях мне тормоза и прочие сложности не нужны.
Сразу скажу, что спорить и переубеждать никого ни в чем я не собираюсь. Хочу только внести некоторую ясность, связанную с якобы большим объемом используемой памяти.
Не стоит путать UTF-8 с UTF-16. Во втором случае действительно все символы представляются в виде двухбайтовых кодов, а вот с UTF-8 всё немного хитрее (прочитать можно на википедии). Если кратко, то английские буквы, цифры и различные стандартные символы (точка, тире, пробел и т.д.) занимают один байт.
Что из этого следует? Только то, что на самом деле потери в памяти будут не столь большими (ведь значительная часть HTML документа - это теги + яваскрипты + css). Зато если вам вдруг захочется вставить в текст какой-нибудь экзотический символ (α), то не придется писать что-то вроде α.
В общем, всё как всегда зависит от задачи, а подобные вечные споры не кончатся никогда (но всё-таки надеюсь, что кончатся ). Вот ещё небольшая статейка: http://denvor.ru/art/misc/windows-1251_vs_utf-8.htm
Подскажите те, кто использует в своих проектах 1251. Как вы боритесь с кодировкой js-скриптов?
в стандартном блоге yii прописал везде 1251. база mssql. Данные отображаются нормально. Проблемы появились на странице админа, где выводится таблица с фильтрами, которые аяксом подгружают фильтрованные данные. аякс отправляет данные в utf-8. на стороне сервера я iconv’ом перевел в 1251. данные стали нормально фильтроваться, но после генерации в поле фильтра появляется текст в utf-8.
Объект XmlHttpRequest в JavaScript работает только с UTF8. Инструменты многие в php - типа json_encode - работают тоже только с utf-8. Есть куча костылей, которые помогут работать с 1251 кодировками.
Есть неплохая статья http://habrahabr.ru/blogs/webdev/17640/
Но зачем это все? Ради символичного выигрыша в весе документа - используйте gzip, сжимает он текст очень хорошо. Ради старой базы данных - да переконвертить гораздо быстрее, чем латать глюки в js. Не нравится mb_* - много ли вы их используете? Обычно все сводится к проверкам. В свое время я попал на проект с кучей js и кодировкой 1251 - затрат н исправление багов получалось слишком много - интеграция с вебсервисами, Ajax, использование сторонних компонент - все было утыкано iconv.
Не в весе дело, а дело в работе с базой.
Нормально ли mssql работает с utf-8?
так же с этой базой будет работать 1с. сможет ли она работать с mssql в которой данные в utf-8?
А возможно ли организовать работу сайта в UTF-8, а в базе хранить в 1251?