Обычно ресурсы создаются с рассчётом на кодировку cp_1251, это привычно и никаких сложностей не вызывает. Но вот нужно создать ресурс в юникоде... ибо требуется доступ к большему числу символов, чем в упомянутой таблице. Собственно и вопрос: какие сложности могут возникнуть, что нужно учесть? Ведь данные в БД должны храниться в иной кодировке, иная кодировка должна указываться в заголовках страницы... что ещё нужно учесть, как это правильно сделать, что об этом стоит прочесть?
главное, чтобы у юзверя проблем не было. Кто-то ещё на старых виндах сидит со старыми браузерами, эти перед каждым выходом в интернет справочник по криптографии перечитывают...
Подобного рода экземпляры брать в рассмотрение смысла нет. Что ж теперь, может и странички верстать соответствующие HTML 3.2 спецификации? Это же бред. Совместимость - это не игры и уловки, а соответствие адекватным и актуальным стандартам. Вот "никаких проблем" - это мне уже нравится... Теперь разберёмся с тем, правильно ли я понял. Базу - т.е. кодировку таблиц для бызы UTF-8 Данные... на каком этапе я могу повлиять на то, в какой они кодировке? Скрипты - что имеется в виду? Те, которые выполняются на стороне клиента? Может быть, это не сложные вопросы, но мне крайне необходимо разобраться. Ряд функций? Можно увидеть пример такой проблемы?
eduha Классная статья. Еще раз убедила меня, что без крайней нужды в дебри "поддержки" UTF в PHP лучше не соваться. Жаль что разработчики PHP не хотят взять пример с разработчиков Джавы...
Dagdamor В PHP 6 обещают нормальную поддержку юникода А пока что спасает mbstring с его перезагрузкой некоторых функций. В принципе, для комфортной работы хватает // Правда, вместо wordwrap приходится использовать еще один костыль