Буквально на днях начал работу над перекодировкой своего преокта
RooCMS на UTF-8 и сумел на личном опыте убедиться во всех плюсах и минусах этих двух кодировок. Ниже я их описываю, без излешне технических описания, а лишь сам факт, потому что техническую сторону вопроса по большей части уже обмусолили на всех возможных ресурсах.
Буквально перед этим я так же как и вы искал информация в интернете о сравнении этих кодировок. На удивление вся информация была крайне однообразной и явно копипастной. То есть из 50 ссылок, которые мне выдали Гугл и Яндекс, везде смысл статей был один и тот же. Если вы их читали, то уже знаете, что cp1251 весьма закостнелая кодировку, которой в скором времени предстоит кануть в летах, как и многим кодировкам, названия которых мы сейчас вспоминаем с трудом.
Во всех статьях, что я нашел в поиске люди сравнивали побайтовость кодировк и угражающе говорили, что символы в utf8 занимают ровно в два раза больше места, чем в cp1251. Факт неоспоримый, потому что БД после кодировки немного увеличилась, как и шаблоны в которых были кирилические символы. А вот те файлы и ячейки таблицы, в которых кирилицы не было, остались такими же. То есть все таки не все символы в Unicode Text Format (о! абревиатурка оказывается) занимают места в два раза больше.
Потом в тех же статьях все говорили о закостенелости программистов, которые привыкли работать в windows-1251. Я же лично думаю что проблема не в закостенелости, а отчасти в OS семейства Windows, которая всегда учит нас дурному, и отчасти в нежелание работать с мультибайтовыми символами. Да, да, да. Почти ни в одной статье я не нашел упоминаний о том, что есть такой маленький подводный булыжник как нежелание кирилического текста корректно обрабатываться в PHP при вызове строковых функций. А это что называется был сюрприз. Даже простейшие команды типа strtolower или strtoupper сжевывают текст превращая его в непереводимый набор символов. Все это потому, что строковые функции php не привыкли работать с мультибайтовыми строками. Они привыкли что один символ равен одному байту и все. Но в UTF это не так, вот они и обрезают лишний байт, тоесть обрабатывают лишь половину символа, отчего на выходе и получается ерунда какая то.
Данная проблема несмертельна. Выход из неё простой, нужно установить для php расширение mbstring (опять абревиатура - multi bite string). И соответсвенно обрабатывать строки командами расширения - mb_strtolower или mb_strtoupper. Стоит так же заметить, что в расширении есть аналоги не для всех строковых функций. И для отсутсвующих функций придется самим писать функции перекодировщики с помошью расширение iconv (conv от слова convert, а вот i не знаю от чего). Но так что бы обойтись без расширений не получиться.
Вот именно по этим причинам, многие программисты, наверное не работают с utf, а предпочитают виндосовскую кодировку. Все таки в России живем, а с ней отказоустойчивость будет выше и ненужно проверять есть ли расширения на хостинге или нет. Но на практике, фактически каждая хостинг площака в интернете по умолчанию ставит расширения mbstring и iconv. Так что вероятность того, что скрипт откажеться работать крайне низкая. И если все же откажеться, рекомендую обратить в службу поддержки хостера и попросить включить данные расширения (например на nic.ru все расширения по умолчанию выключены, и администратор сам их включает). Если же хостер невнятно пытается объяснить вам, что по каким то причинам не может включить данные расширения, то стоит задумать о смене хостера.
На деле же премуществ у unicode гораздо больше. Например в отличии от виндовой кодировки, русские буквы и на китайских компьютерах выгледять русскими, а не непонятными символами. Поисковые системы с большей симпатией относятся к сайтам на unicode кодировке (ну оно и понятно, ведь такими сайтами сможет пользоваться весь мир, а не только отдельная страна). Ну и самое главное, по заявлению разработчиков php 6 версия, по умолчанию будет использовать ЮТФ. Опять же работать с таблицей символов из 10000 знаков, гораздо приятней чем с таблицей из 500 знаков.
