Какая кодировка лучше UTF-8 или cp1251?

Следующая статья: CSS и Cache (Кэш) + Javascript

Содержание

• Введение
• Страхи перед UTF-8
• Неоспоримые плюсы UTF-8
• Ответы на частые вопросы и заблуждения по кодировкам
• Вывод

Введение

Читая на просторах интернета споры про кодировки UTF-8 и cp1251 решил подытожить и всю муть изложить коротко.

Сразу и смело можно перефразировать вопрос и знающие люди поймут. UTF или не UTF? То есть, я за UTF-8 - однозначно!

Страхи перед UTF-8

• Не поддержка старых (рабочих) проектов кодировки UTF-8. (Давайте еще ДОС вспомним). Ориентироваться на старые продукты, считаю полностью утопично.
• Один символ кириллицы в cp1251 занимает 1 байт, а в utf-8 - 2 байта. Как ни странно данный факт сильно отталкивает, и отталкивал меня долгое время от начало использования данной кодировки. Как показала практика в среднем UTF страница на русском языке больше, чем стандартная cp1251 всего на 20-30 процентов. Если текст на английском, то страница одинакового размера. Чаще всего - основной вес страницы составляет html-код, javascript, flash, картинки, css и так далее. Тем, кто заботится о «весе», следовало бы в первую очередь выкинуть из кода подстановки для тех символов, которым они не нужны, например, « - » для длинного тире или для неразрывного пробела (ой, как часто я вижу это в страницах новичков). Видим, что вместо 1 знака длинного тире мы пишем 6, вместо 1 знака неразрывного пробела мы пишем 5 знаков. И где же экономия? Действительно, иногда доходит до маразма - некто упирается: «Не буду делать страницы в UTF-8, потому что они от этого увеличиваются» - а сам при этом ваяет код с жуткими атрибутами и подстановками, который без них мог бы быть в пять раз короче. Также у 90 процентов web программистов html страницы просто не оптимизированы, даже пробелы не убраны из кода. А пробел это тоже байтик!
• отображения крокозябликов в любимых стареньких программах, таких как Far. Не знаю почему, но far так не сумел приучить читать корректно данную кодировку даже в последнем beta релизе Far 2.0.

Неоспоримые плюсы UTF-8

• старые кодировки, таких как cp1251 или KOI8R, предоставляли не более 256 символов, а в Unicode есть свыше 100 000 символов, среди них - типографские знаки (тире, кавычки, многоточие, апостроф, неразрывный пробел неразрывный дефис и прочие прикольные символы);
• специальные символы №, §, ©, ‰, « », …, × и прочее. Например, это очень актуально на сайтах с кулинарной тематикой, где употребляются различные дробные меры такие как ½, ⅓, ¼, ⅔, ¾ и так далее. А как же быть с финансовой тематикой? Сейчас сложно представить нормальный сайт, где бы не указывался значки валют в ценниках, например, ȼ ¥ £ €. Повторите тоже самое на cp1251 или будете целые картинки подгружать вместо одного символа?
• буквы с диакритическими знаками и лигатуры (é, è, Ü, Æ, ø, fi и прочее);
• символы почти всех существующих в мире алфавитов (α, Ω, א, ת, , 伲, 儻 и прочее);
• пиктограммы и значки (→, ■, ♥, ☺ и прочее);
• множество других полезных символов.

Самое классное в этом всём это то, что все эти символы можно вставлять непосредственно в редакторе (из таблицы символов или с помощью горячих клавиш), что делает код куда более читабельным, нежели использование кракозяб вроде µ - или π (альтернативы в cp1251).

• Универсальность! Благодаря utf-8 можно создавать сайты без каких-либо переделок как для американцев, так и для немцев (с их буквочками вроде Ü), так и для арабов, так и для китайцев! И все равно, какая кодировка у них установлена, а какая нет, ибо Юникод у них установлен 100 процентов. Например, если у вас сайт публикует новости сразу на русском и немецком языке, то эту UTF с этим легко справляется, а вот уже на cp1251 это сделать невозможно.
• Юникод является стандартом для работы таких часто используемых ныне функций php, как json_encode/json_decode, а так же используемого в Ajax XHttpRequest. Причем, начиная с 6й версии PHP Юникод станет стандартом для всех строковых функций. Поэтому на много быстрее и удобнее скармливать данные уже в utf кодировке а не конвертировать постоянно, потому как все равно функции PHP и JavaScript будут это требовать. То есть, если вы хотите работать с такими технологиями как XML, JSON, AJAX и прочие современные технологии, то вам придется переходить на UTF-8, ибо со времен своего основания они работают только в этой кодировке.
• Поисковые системы значительно лучше относятся к сайтам на UTF-8 кодировке, чем на какой либо другой. Многие скажут, что это спорный момент, однако проводился эксперимент, на 10 сайтах. Один и тот же контент, тот же дизайн, тот же хостер, разные были только кодировки. Не поверите, но сайт на UTF кодировке стоял выше в поисковых позициях. Вот такой вот фокус.
• Для быстрой индексации сайта в поисковых системах Yandex и Google используется файлик sitemap.xml, как ни странно, но работает он только если сделан в UTF, иначе поисковые системы ругаются.
• И напоследок, многие ссылаются на то, что люди постепенно переходят на utf-8 потому, что «кто-то умный сказал, что это хорошо». Соглашусь, кто-то умный это сказал уже давно, а именно - Консорциум W3C (кому-то эти 3 буквы что-то говорят? И рекомендует он использовать для создания web страниц ни что иное, как utf-8. Для тех, кто знает английский (а есть программисты, кто его не знает? Можете почитать.

Ответы на частые вопросы и заблуждения по кодировкам

У меня сайт только на русском языке и на всякие китайские языки я переходить не намерен

Очень интересное заблуждение. Если у Вас один проект, то тут соглашусь, что особо не стоит заморачиваться на эту тему. Если проектов много то уже очень скоро столкнетесь с проблемами. Ведь UTF это не только разные языки, но и как я уже говорил, это довольно сложные математические функции и многое другое :) А математика есть в любом языке, в том числе и на русском.

Терминалы не поддерживают utf-8 (ssh, ssl, terminal)

Какой бред. Я вам ответсвенно заявляю, как программист, что все терминалы не испытывают никаких проблем с utf, да им это особо и не требуется, так как в основном они пишут все на английском языке.

Постоянная проблемы с BOM заголовком

Никаких проблем вообще не возникает. Напомню, что BOM заголовок в текстовых документах был придумал как дополнение, чтобы по быстрому определяться и в дальнейшем определять в какой кодировке записан текстовой документ. BOM заголовок это принятый стандарт, если вы программист, то научитесь обрабатывать грамотно всего три байта. Если вы профи, то я думаю вы справитесь с этой «мега» задачей в три байта. Если Вы обычный пользователь, то не заморачивайтесь на счет этого заголовка, просто его не прописывайте.

Постоянный геморрой в PHP с использованием функций mb_

1. Если у вас вызывает неприятность функции в добавлением всего 2 буковок, может программирование не ваш конек?

2. В PHP 5.0 обычные функции strpos и подобные легко и прекрасно работают с кодировкой UTF. Смотрите подробнее init_charset в PHP. Есть ряд переключателей которые легко переключают весь php движок на работу с нужной кодировкой по умолчанию.

3. В PHP 6.0, как я уже говорил (смотрите официальный сайт PHP) UTF-8 будет кодировкой по умолчанию. Вам нужен лишний геморрой в дальнейшем при переносе проектов? В свое время тоже все считали, что PHP 3.0 удовлетворяет всем потребностям, но не заметили как уже докатились до PHP 5.0.

4. Javascript с самого момента своего создания работал только с кодировкой UTF. Все, что вы видите на JS в cp1251 это метаморфозы на уровне ядра. Об этом можете легко прочитать на официальном сайте javascript на Sun Мастерс.

5. Основная в базах данных также по умолчанию теперь только UTF-8. Смотрите и читайте соответствующие спецификации.

Если у меня старый проект на cp1251 работает стабильно, нужно ли переносить на UTF?

Если рассуждать рационально, то нет. Но если вы в дальнейшем планируете свой старый проект еще перерабатывать и дополнять новыми функциями, то стоит обдумать, но перед этим 1000 раз все взвешать.

UTF это бред, так как мой редактор его не поддерживает

Ваш редактор не пуп земли. И если у вас есть такой редактор, который не поддерживает данной кодировки, то это уже бездарность. Напомню, что начиная с выпуска Windows XP даже пресловутый Windows блокнот знает и корректно открывает текстовые документы в UTF кодировке. А также начиная с системы Windows Vista кодировка UTF считается кодировкой по умолчанию. Не питайте иллюзий, что Windows до сих пор сидит на своей родной кодировке cp1251. Это было сделано только для поддержки старых программ не более. Рекомендую по чаще заходить на сайт microsoft и интересоваться ихними направлениями развития и технологиями. Откроете для себя много интересного, а главное, ваши знания будут уже не на уровне только слухов.

Все браузеры по умолчанию настроены на cp1251

Мда, как тут все запущено. В любом браузере есть галочка, авто определение кодировки. Какой тег на странице у вас будет прописан такую кодировку и будет браузер применять по умолчанию. Напоминаю код который управляет кодировкой на странице:

<!-- страницу отображать в кодировке utf8 -->
<meta http-equiv="content-type" content="text/html; charset=utf-8" />

<!-- страница отображать в кодировке windows-1251 -->
<meta http-equiv="content-type" content="text/html; charset=cp1251" />

<!-- в HTML5 стало еще просче -->
<meta charset="utf-8" />

В cp1251 одна буква, так одна буква, а в юникоде это xAB и uABCD

Ребята, не нужно путать теплое с мягким. А именно не нужно путать отображение и фактическим состоянием. То есть, utf он как шифровался в 1-2 байт так и шифруется (UTF-16 не беру в данном случае в расчет), а отображается может хоть как. Как говорится на заборе тоже написано «…», но за забором то картошка. Не плохо было бы иногда все таки заглядывать за забор.

Это все к тому, что та же единица (1) может отображаться как:

• 00000001 - двоичная система
• 01 - шестнадцатеричная система счисления
• 1 - десятичная

и так далее. Здесь тоже самое.

Написал charset utf-8 сайт все равно открывается в cp1251

Вариантов может быть много, но есть частые ошибки.

1. Неправильно прописан meta http-equiv. Нужно писать charset=utf-8, у многих charset=utf8. Как ни странно, но тире играет большу роль почему то.

2. Прописав charset=utf-8 в мета, требуется еще и саму страницу конвертировать в эту кодировку, но многие считают, что типа этого делать не нужно.

3. Проблема при выводе информации из базы данных MySQL при помощи PHP. Более детально эта, ошибка расписана в статье «Как вывести данные в PHP из таблицы MySQL?»

Вот коротко ответил на самые частые утверждения, вопросы и заблуждения. По мере поступления буду дополнять и отвечать здесь.

Вывод

Люди утверждающие, что cp1251 лучше, чем UTF-8, это как те аборигены, которые в свое время считали, что земля плоская и человек есть пуп земли. А именно у таких людей преобладает лень к стремлению к новым вершинам, или тяжело ломать старые стереотипы, или тупо, боязнь того что, как это у других может быть лучше, чем у меня, нет уж если я в дерьме, то и новички тоже пускай в дерьме сидят, а то одному то скучно ;) Ээх человечество.

Видео: «Отношения заказчик-исполнитель в виде бытовых сценок»

Видео бытовых сценок об отношениях заказчик - исполнитель