Кодировка

Большое спасибо за ответы.

В целом я тоже склоняюсь к Юникоду. Плюс к сказанному у него есть еще два положительных момента (по-крайней мере - в моём случае).

1.Сегодня мультиязычность не нужна, но это не значит, что она не будет нужна никогда - всё может быть, а при прочих равных всё же нет, очевидно, смысла упускать дополнительную функциональную возможность.

2.Не знаю, так это или нет, но это то, что мне сказал админ хостинга. MySQL 5 сам контент хранит в юникоде по-любому, и если мы желаем выдачу видеть в windows-1251, то это - лишняя перекодировка на стороне сервера, соответственно - лишняя нагрузка.

Кстати, тут в разделе "web-строительство" мы обсуждали вопрос collation, и тогда как-то тема оказалась не особо раскрыта. Так вот (это я говорю для тех, кто, как и я, этого не знал) - именно этот параметр и определяет, в какой же кодировке будет восприниматься контент базы. Если задаем utf8_unicode_ci, то это Юникод, мультиязычность нормально поддерживается, когда же, например, выбираем collation utf8_general_ci, то мультиязычный сайт уже не создаётся, а CMS ругается, что база имеет кодировку windows-1251, посему мультиязычность не поддерживается.

Юникод - хорошая штука, но надо, чтобы хостер её поддерживал. Мне так пришлось свой сайт перевести в 1251, потому что сервер юникод не поддерживал, и мои аккуратные юникодовые странички выглядели на нём крякозябрами. Пришлось пожертвовать идеей в пользу реальности...

СКОРПИОН, аналогичная ситуация. С 2006 года только в UTF-8 работаем. +1

Где-то слышал, что юникод требует бОльших ресурсов. Возможно, речь идет именно о мультиязычном сайте, по крайней мере в документации к CMS eZ Publish написано:

То есть, мультиязычные сайты с кодировкой UTF-8 нуждаются как минимум в 64 MB PHP memory limit для нормальной установки eZ. Как бы - в отличие от других: там это сказано в таком контексте, что вот в некоторых других случаях можно и 16-ю обойтись, но уж в этом случае - только 64 и более.

Как Вы думаете, Господа, что именно "утяжеляет" требования: тут вся соль именно в Юникоде, или виновата мультиязычность?

Конечно имеет. Так символ - 1 байт, а в юникоде 2 и более байт. Так что любые данные строкового типа как минимум в 2 раза больше памяти потребуют.

Можно ли, говоря упрощенно, понимать это так, что даже одноязычный сайт с посещаемостью, например, 3.000 хостов в сутки будет требовать значитаельно бОльших серверных мощностей при использовании Юникода, чем абсолютно идентичный по контенту сайт на windows-1251?

Места под БД - больше, памяти под скрпт - тоже больше. На процесорное время не думаю, что это ощутимо повлияет. Но диски и память нинче дешевые, так что особых проблем не вижу. Я пока windows-1251 использую С юникоом пока проблем больше. Вот когда все проблемы исчезгут - тогда посмотрим.

Собственно, если верить нашему Админу, как я уже говорил, начиная с MySQL 5 контент так или иначе хранится в Юникоде. Просто в зависимости от настроек скрипт может получать контент в том числе и в другой кодировке. Таким образом, вроде как вопрос диска снимается, так как в обоих случаях на диске будет Юникод. А вот память под скрипт, как Вы полагаете, будет ли требоваться больше в одном случае, чем в другом:

Случай 1)База в Юникоде, collation utf8_unicode_ci, на выходе базы - Юникод.

Случай 2)База в Юникоде, collation utf8_general_ci, на выходе базы - windows-1251.

P.S. Лично моё ощущение, что память всё же намного критичней, чем диск.

Я бы сказал, если правильно верстать страницы, то даже жестко прописывать кодировку не надо, браузер всё сам поймёт.

Извините за назойливость, Господа, всё же не мог бы кто-либо, разбирающийся в данном вопросе, прокомментировать еще немного данный аспект: действительно ли использование Юникода при прочих равных подразумевает бОльшую нагрузку на сервер, и насколько серьезно это влияние (немного, или в разы...)?