Использовать ли UTF-8?

[Jackyk]

Использовать ли UTF-8?

Приветствую Уважаемое Сообщество.

Воспользовался поиском, прочел, как мне кажется, все сообщения на форуме, связанные с юникодом, искал в FAQ, облазил Яндекс, но так и не составил впечатления. Буду благодарен всем, кто выскажет мнение, в какой кодировке предпочтительнее делать русскоязычный сайт, нацеленный на РФ - utf-8 или windows-1251. Озадачен этим вопросом уже не первую неделю, имею ряд аргументов как в пользу одного, так и другого решения, но, к сожалению, не хватает информации для его принятия.
Уточню, что сайт будет использовать западные движки (CMS eZ Publish и форум vBulletin).
Заранее благодарен за любые комментарии.
С уважением, Евгений.

 

[Gorynych]

Уточню, что сайт будет использовать западные движки (CMS eZ Publish и форум vBulletin).

использовать то, поддержка чего, что предлагается в движках изначально.

 

[Jackyk]

Вы имеете в виду, что использовать надо ту кодировку, которая стоит по умолчанию в движке? В форуме по умолчанию, например, латиница. Выбрать можно что угодно. CMS же по умолчанию устанавливает кодировку в соответствии с кодировкой базы при инсталляции. Правильно ли я понял, что в основе Вашего совета лежит предположение, что рано или поздно западные движки могут перестать поддерживать windows-1251?
Если можно, вопрос ко всем - как Вы полагаете, возможно ли, что такие общие вещи, как PHP, MySQL перестанут в обозримом будущем поддерживать windows-1251, полностью перейдя на Unicode?

 

[Gorynych]

Jackyk
на конференции в мае Андрей Змиевский как раз рассказывал о внедрении встроенной поддержки Unicode в PHP-6.

и я действительно думаю, что пора переориентироваться на Unicode (может быть потому, что наличие в отдельно взятой стране кодировок Windows-1251, KOI8-R, ISO-8859-5 (UNIX Cyrillic) периодически просто действительно ###### создает некоторое количество проблем

 

[Jackyk]

Gorynych, благодарю. Простите за тупой ламерский вопрос, а сейчас в php есть встроенная поддержка какой-либо кодировки (той же Windows-1251), или нет никакой? Вопрос к тому, что, конечно, если нет никакой, а будет поддержка Unicode, то это повод переориентироваться на Unicode. Если же сейчас есть поддержка однобайтных, а будет еще и Unicode, то ... в-общем, мысль понятна.

 

[Gorynych]

Jackyk
а что в вашем понимании поддержка какой-либо кодировки? В PHP или в движке? В движке это связано (чаще всего) с: кодировкой служебных сообщений, надписях на ссылках и кнопках, формированием заголовка HTML-страницы.

что касается поддержки той или оной кодировки в PHP, то чаще под этим подразумевается набор функция для преобразования из одной кодировки в другую. Таких наборов / вариантов / способов довольно много. Они описаны в руководстве, много информации по этому есть в "Вопросах и Ответах" ( http://phpclub.ru/faq/ )

давайте вы почитаете доклад http://www.gravitonic.com/do_download.php?download_file=talks/phpconf-ru-2006/php-6-and-unicode_phpconfru2006.pdf PDF (1.3 MB). Кстати, там на странице 36 есть очень хорошая диаграмма потоков данных. Это к вопросу о том, а что собствено называть поддержкой кодировок

 

[Jackyk]

Gorynych
спасибо за ссылку, доклад сейчас почитаю обязательно. Под поддержкой же кодировок я понимаю ровно то, что понимают, говоря о внедрении встроенной поддержки Unicode в PHP-6. То есть, сейчас нет встроенной поддержки Unicode в PHP, но с выходом оф. релиза PHP-6 будет встроенная поддержка Unicode в PHP-6.
Вот ровно в этом же ключе я и спросил: сейчас нет встроенной поддержки Unicode в PHP, но есть ли сейчас встроенная поддержка windows-1251 в PHP? Доклад я обязательно изучу, спасибо еще раз, но если всё же на мой вопрос можно ответить весьма коротко (типа - "да, сейчас в PHP есть встроенная поддержка windows-1251, а в PHP-6 будет ЕЩЕ И Unicode" или "Нет, сейчас в PHP нет встроенной поддержки windows-1251"), и если это не затруднит, буду признателен за этот ответ.

 

[SelenIT]

Jackyk
Принципиальное отличие юникодовских кодировок от "обычных" (однобайтных) - то, что один символ может кодироваться разным количеством байт. Поэтому, например, чтобы просто посчитать символы в строке, уже недостаточно знать ее размер в байтах. Как следствие - для строк в таких кодировках не подходят стандартные строковые функции (типа substr), приходится использовать их мультибайтные аналоги mb_* (расширение PHP).

C любыми однобайтными кодировками (включая windows-1251) подобных проблем нет. Но бывают другие проблемы, особенно если нужно отобразить на одной странице текст с символами из разных кодировок.

Более точная и подробная информация по кодировкам - в этих ссылках.

 

[Jackyk]

SelenIT, благодарю за ответ. Отдельно - за ссылки. То есть, как я понял, говоря о будущей поддержке в PHP-6 Unicode, мы говорим о некой особенности, которую можно назвать полезной ТОЛЬКО в том случае, если нам изначально (по иным причинам) нужен Юникод. Например, как в LiveJournal, где его использование более чем оправдано, так как один пишет по-китайски, другой по-русски. Если же Юникод не нужен, то вроде как получается, что от этой особенности в PHP-6 ни жарко, ни холодно.
Я всё хочу понять простую вещь: есть ли в мире тенденция к прекращению поддержки windows-1251? То есть, всё же Юникод активно ДОБАВЛЯЕТСЯ к существующим кодировкам, либо он активно ВЫТЕСНЯЕТ существующие кодировки? С одной стороны, совершенно не хочется, чтобы через пару лет мы встали перед необходимостью перекодировки базы из-за того, что vBulletin отныне работает ТОЛЬКО с Юникодом. С другой стороны - если предпосылок к прекращению поддержки windows-1251 не наблюдается, то все остальные преимущества Юникода, о которых я читал, сводятся к мультиязычности (которая русскозычному проекту не нужна) и к абстрактным рассуждениям о Вавилонской башне. Именно абстрактным. Посему, если кто-нибудь может указать вполне конкретные преимущества Unicode и недостатки либо опасности использования windows-1251, буду ему очень благодарен.
С уважением, Евгений

 

[Romantik]

поопробовав UTF-8 я понял что пока это нужно где используются разные кодировки к примеру русский и немецкий на одной странице
в других случаях стараюсь не использовать UTF-8

 

[Gorynych]

Romantik еще XML, XML чтоб ему было не ладно!

P.S. если Вы что не так подумали - неправда! На самом деле я его очень люблю и актично использую, но, временами хочется говорить о нем на арго

 

[Jackyk]

Насчет использования разных кодировок на одной странице. На своём форуме, где кодировка windows-1251, я с успехом разместил некириллические символы. Подозреваю, что сейчас это же удастся и здесь.
דקהדקהדקהדקהדקהדקהדקה

Точно. Удалось. Этот сайт также не в Юникоде. Тогда можно поинтересоваться, чем в Юникоде это удобнее?

 

[SelenIT]

Jackyk
Посмотри теперь исходный код страницы в блокноте - во что эти символы превратились. Поисковики их так и увидят. А с UTF-8 символы остались бы сами собой.

 

[Frol]

вопрос можно сократить до "уговорите меня использовать юникод".

 

[Денч]

Frol
Ну не стоит так косо смотреть на мир. Человек просто спрашивает мнение более опытных людей насчет юникода, чтобы определиться в конце концов самостоятельно, что ему нужно...

 

[Jackyk]

Уважаемый Frol, не совсем так. Говоря коротко - я сейчас работаю над собственным проектом автомобильной тематики, и РЕАЛЬНО хочу принять верное решение, чтобы потом не кусать локти. Я не первый день в сети, и перед тем, как что-то спрашивать, я предпочту спросить у Яндекса, и за некоторое время (от часов до дней) всё становится ясно. Обычно становится. А тут я бьюсь над этим вопросом уже недели две, прочитана вся выдача Яндекса, выпита цистерна пива со знакомыми программистами, подняты темы на трех форумах плюс на англ. форуме подержки CMS, и вот только сейчас начинает что-то проясняться. За что спасибо и этому форуму, и всем, кто дал ответы.
Наибольшее удивление моё вызывает в данной проблеме то, что даже в разговорах с вменяемыми и толковыми людьми, кроме единственного конкретного аргумента - мультиязычности - все остальные аргументы были примерно на уровне "Юникод - это будущее".
Вот тут уважаемый Gorynych сказал про XML. Если не затруднит, приведите кто-нибудь, пожалуйста, конкретный пример, чего нельзя сделать в данном аспекте на сайте, сделанном в кодировке windows-1251, но можно сделать на сайте в Unicode. Для чего именно требуется Unicode при работе с XML?
Реально очень бы хотелось понять конкретику не в виде "В России правильно говорить по-русски, а не по-китайски", а так: "Если в России ты будешь говорить по-китайски, тебя тут никто не поймет".
Применительно к теме - в таком виде: "Если сайт сделан в кодировке windows-1251, то ты не сможешь сделать вот это и это". В частности, как уважаемый SelenIT дал исчерпывающий ответ про то, что при написании символов иных кодировок они будут нечитаемы в коде страницы и их не увидят поисковики (спасибо!).

Заранее благодарю за конкретные ответы.

 

[Krishna]

Лично я для себя принял решение по возможности во всех новых проектах использовать UTF-8, а так-же XHTML вместо HTML. Имхо лучше быть в авангарде тенденций, когда это не затрудняет, чтобы потом не пришлось быстро и вынужденно перестраиваться.

Преимущество Юникода имхо прежде всего в том, что не нужно мучиться на мультиязычных сайтах с кодировками + для работы с файлами в этой кодировке есть средства в Win, nix и других системах.

 

[Scud]

Хм, а как насчёт кодировки строк в скриптах или ресурсах, тоже utf-8?

Просто я недавно тоже задался вопросом, а не начать ли использовать UTF-8 у себя в i18n, тоже полез фильтровать тему, и на сайте WACT обнаружил довольно подробную статью, описывающую, какие выгоды можно получить и какие проблемы можно огребсти при использовании UTF-8 в скриптах. И эта статья меня несколько охладила....

 

[Jackyk]

Автор оригинала: Scud
на сайте WACT обнаружил довольно подробную статью, описывающую, какие выгоды можно получить и какие проблемы можно огребсти при использовании UTF-8 в скриптах.

Простите, а ссылку не могли бы дать если и не на статью, то хоть на "сайт WACT"? Прежде, чем спросить, Яндексом я воспользовался и в браузере в стандартных доменных зонах набрал.

 

[SelenIT]

Скорее всего, речь об этом. По сути там подробно раскрыта проблема мультибайтных строк, о которой я говорил вскользь чуть выше (собственно, вот это и есть "отсутствие встроенной поддержки юникода").