Кодировка

Jackyk, думаю что большей частью будет заметно только то, что строки будут длинее (в БД, на диске), ну и выдаваемый html будет тоже больше (хотя если прикрутить GZIP к выводу, то это не критично). Нагрузка врядли будет в разы больше. От силы - единицы процентов.

Ну, казалось бы, что (опять же, если верить нашему Админу) если в MySQL 5 контент независимо от выдаваемой кодировки хранится в юникоде, то диск, вроде как, должен быть занят одинаково.

Пойду-ка я, да сделаю эксперимент. Создам 2 идентичных сайта, один в юникоде, второй в windows-1251. Уж как минимум по размеру базы и по весу загружаемых страниц ответ, надеюсь, получим.

Ну если только учитывать соответствие символа каждой кодировки количеству байт.

Значится, так. Повозился я с этим некоторое время, и вот что увидел.

1)На размер базы выбор кодировки в MySQL 5 никак не влияет. Похоже, что Админ оказался прав, и всё равно всё хранится в одних символах, в Юникоде. Правда, судил я по размеру дампов. Надеюсь, это корректно.

2)В используемой мной CMS есть возможность посмотреть времена выполнения скрипта и генерации страницы. В целом юникодовая страница генерилась дольше примерно на 30-50% (например, 0.6сек и 0.9 сек). Вместе с тем:

3)Замер секундомером времени полной загрузки страницы в IE дал после усреднения следующие значения: Юникод 2.91 сек, Windows-1251 2.85 секунды. Иными словами - особо превосходство одного над другим не ощущается.

4)Размер загружаемой страницы отличался примерно на 10% (105Кб Windows-1251 и 114Кб Юникод).

Пока не решил, какие выводы из этого всего можно сделать. Опасения в том, что увеличение времени генерации страницы при нулевой посещаемости могут сильно аукнуться при многотысячной. Как Вы думаете?

И еще, хочу немного поправить сам себя.

Всё верно, кроме того, что с utf8_general_ci не создаётся мультиязычный сайт. Это утверждение ошибочно. Разница между utf8_general_ci и utf8_unicode_ci, как выяснилось, в том, что utf8_unicode_ci поддерживает expansions, то есть сопоставление одного символа нескольким (например - в Германии ß = ss )

вполне может быть погрешность... связанная с различной загрузкой операционной системы в разные моменты времени... сколько раз повторяли эксперимент?

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

Проверяю я бэклинк роботом, а он текст ссылки не понимает. Потом что бот - не броузер :) Я понимаю, что надо делать правильных роботов, но тем не менее, как пример, думаю, интересно.

То-то и оно, что немало. Сотни раз. Могу в личку скинуть 2 url, с абсолютно идентичным контентом, снизу будут таблицы показаний debug CMS.

Если можно, 2 вопроса.

1.Чем конкретно плохим чревато использование windows-1251 в сравнении с Юникодом?

2.Как на практике может сказаться различие во времени выполнения скрипта при генерации страницы на 50% на посещаемом проекте? На что влияет, будет ли время 0.8 сек или 1.2 сек? Сильно ли влияет? Повышает на 50% нагрузку на сервер? Или больше? Или наоборот, это некритичный параметр?

Спасибо заранее.

А я бы сказал, что если правильно верстать страницы, то прописывать кодировку надо, ибо этого требуют стандарты.

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

Ну и be1 выдает иероглифы в title/keywords при проверке сайтов в UTF-8. Периодически возникают панические топики на этом форуме. :)

Ну и что? Нынче еще KOI8 иногда встречается. А иначе этот робот - не законченный продукт, а полуфабрикат (кстати, be1.ru/stat/ касается тоже).