За технічними подробицями можна звернутися до RFC 3629 (STD 63) і стандарту Unicode (п. 3.9). А тут піде мова про практичну сторону використання UTF-8.
Загляньте в «Таблицю символів» на своєму комп'ютері. У кодуванні UTF-8 ви можете взяти прямо з цієї таблиці будь-який символ і вставити його безпосередньо в свій документ. Якщо вам потрібен знак копірайту, градуси або інтеграла - не потрібно шукати особливий шрифт, представляти цей знак в графічному форматі або відмовити ще якісь хитрощі. У кодуванні UTF-8 будь-який символ, будь то дріб ⅓ або китайський ієрогліф, можна використовувати в документі точно так же, як латинську букву «A», російську «И» або знак «+».
Колись давно розробники веб-сторінок були змушені користуватися такими громіздкими підстановками, тому що кодування UTF-8 ще не існувало. Але тепер можна забути як про підстановки, так і про старі кодування.
Обговоривши переваги UTF-8, варто було б поговорити і про недоліки цієї кодування. А недоліків, уявіть собі, у неї немає. Є тільки міфи і легенди, а також чутки і домисли, які поширюють замшілі консерватори і махрові ретрогради. Багато років тому деякі недоліки дійсно мали місце, але зараз вони канули в Лету.
Браузери погано підтримують UTF-8?
Кажуть, що у деяких користувачів все ще встановлені старі браузери, які не здатні відображати сторінки в UTF-8. Це повна нісенітниця. Навіть Internet Explorer 4 і Netscape 4, якими вже давно ніхто не користується, прекрасно розуміють UTF-8. А більш сучасні браузери - і поготів.
UTF-8 - зовсім не «новомодна» або «молода» кодування, вона успішно застосовується більш десяти років. Якщо якийсь розробник дізнався про неї недавно або не знає досі - це недолік його кваліфікації, а не кодування.
З UTF-8 виникають проблеми на веб-сервері?
«Я помістив на сервер сторінку в UTF-8, а вона відображається кракозябрами», - так іноді скаржаться початківці розробники. Насправді, така проблема трапляється з різними кодуваннями і не пов'язана ні з якими специфічними особливостями UTF-8. Тут неприємність в тому, що сторінка зроблена в одному кодуванні, а сервер в заголовках HTTP повідомляє іншу. Треба привести настройки сервера у відповідність з дійсною кодуванням веб-сторінок. Повторю, що це треба зробити при будь-якому кодуванні.
Файли в UTF-8 займають багато місця?
Кажуть, що документи в UTF-8 стають в два рази більше, ніж в старих кодуваннях. Це міф з розряду «чув дзвін, та не знаю, де він». Насправді - раз на раз не доводиться. Наприклад, якщо документ складається тільки з символів ASCII (латинські літери, цифри, знаки пунктуації і т. Д.) - то в кодуванні UTF-8 він буде займати рівно стільки ж байтів, скільки в будь-який інший. Якщо документ містить лише літери російського алфавіту і ніяких інших символів (що, погодьтеся, буває досить рідко) - то в UTF-8 він дійсно стане в два рази більше. А якщо в ньому, наприклад, порівну російських і арабських букв - в UTF-8 він буде в два рази менше, ніж, наприклад, в Windows-1251 або Asmo-708.
Та сама сторінка, яку ви зараз читаєте, в кодуванні UTF-8 займає 35 кілобайт. А якщо перевести її, наприклад, в Windows-1251, вона буде займати 26 кілобайт (переконайтеся самі). До речі, порівнюючи сторінки, подивіться, наскільки легше читається код в UTF-8.
Тим, хто піклується про «вазі», слід було б в першу чергу викинути з коду застарілі атрибути HTML (на кшталт cellpadding або valign) і підстановки для тих символів, яким вони не потрібні (наприклад, — для довгого тире або для нерозривного пробілу). Дійсно, іноді доходить до маразму - хтось впирається: «Не буду робити сторінки в UTF-8, тому що вони від цього збільшуються» - а сам при цьому ліпить код з моторошними атрибутами і підстановками, який без них міг би бути в п'ять разів коротше .
Серверні мови програмування і бази даних погано підтримують UTF-8?
Хтось скаже: «Все це добре, поки ми маємо справу зі статичними веб-сторінками. Але якщо ми користуємося PHP і MySQL, про UTF-8 краще забути ». Це теж неправда. У давнину, дійсно, деякі мови програмування і системи управління базами даних не вміли працювати з UTF-8. Але зараз всі сучасні мови програмування і бази даних знаходяться в чудових стосунках з цією кодуванням. А несучасними мовами і базами користуватися не стóит: чим давніший ваші системи, тим простіше їх зламати.
На моєму персональному сайті можна бачити результати роботи програми на PHP 4, яка розставляє переноси в словах. Вона отримує на вхід текст в UTF-8 і видає той же текст в UTF-8, але з переносами. Між іншим, вихідний код самóй програми також представлений в UTF-8.
Можу ще продемонструвати аматорський сценарій на Perl, який рахує кількість вертикальних штрихів в буквах тексту. Запускаючи цей сценарій, йому як параметр треба передати текстовий файл в кодуванні UTF-8, наприклад: palki.pl file.txt. Знову ж, сам сценарій теж представлений в UTF-8.
Єдина складність з серверними програмами - в тому, що багато хто з них за замовчуванням налаштовані не на UTF-8, а на інші кодування. Ну так перенастройте; ми ж з вами не діти малі, щоб по всіх усюдах використовувати тільки стандартні параметри.
Пошукові системи погано працюють з UTF-8?
Ще доводиться чути, ніби пошукові системи «спотикаються» про UTF-8. Ці відомості, знову ж таки, застаріли років на вісім. Ось вам, наприклад, пошукова система «Яндекс»:
Переконайтеся, що вона прекрасно знаходить все, що завгодно, на моєму персональному сайті, де, між іншим, її роботу «ускладнює» не тільки UTF-8, а й перенесення в словах.
Таким чином, не існує ніяких протипоказань до широкого застосування UTF-8. Ті, хто вважає по-іншому, просто відстали від життя.
Коли UTF-8 не треба використовувати
Звичайно, бувають випадки, коли найкращу кодування UTF-8 використовувати все-таки небажано. Хоча це зовсім не ті ситуації, якими лякають адепти вишеразвенчанних міфів.
По-перше, іноді нам потрібно не створювати новий документ, а внести зміни в уже існуючий. Зазвичай в таких випадках немає сенсу перетворювати наявний документ в кодування UTF-8, тому доводиться редагувати його в тій кодуванні, в якій він представлений.
По-друге, іноді роботу сайту забезпечує програмне ядро (так званий «движок»), яке не вміє працювати з UTF-8. У такій ситуації, звичайно, слід задуматися, чи немає можливості підправити «движок» або замінити його на інший. Але це не завжди вдається. Деякі програмні ядра забезпечують функціональні переваги, заради яких можна змиритися із застарілою кодуванням.
Сподіваюся, що подальші рекомендації будуть вам корисні при роботі з UTF-8.
Byte Order Mark (BOM) - це три службових байта, які автоматично записуються в початок документа і позначають, що він збережений в кодуванні UTF. Подробиці можна прочитати в довіднику, а практична сторона полягає в тому, що ці службові байти в UTF-8 не є необхідними, зате, навпаки, можуть ввести в оману деякі старі браузери та інші програми.
Налаштуйте прості поєднання клавіш для спеціальних символів
Звичайно, коли мені потрібно рідко використовуваний символ - буква «юс», пика або ієрогліф, - я звертаюся до «Таблиці символів».
Вказуйте кодування скрізь, де потрібно
Переконайтеся, що веб-сервер повідомляє правильний метод кодування сторінок. Якщо це не так - зверніться до адміністратора сервера або прочитайте довідкові матеріали про те, як налаштувати кодування.
Зустрічаються служби розміщення сайтів (хостинги), які «намертво прив'язані» до якої-небудь однієї кодуванні і не дозволяють господарям сайтів користуватися іншими кодуваннями. З такими хостингами зв'язуватися ні стóит. У якому кодуванні робити сторінки - повинен вирішувати розробник сайту, а не служба його розміщення.
У коді HTML часто має сенс використовувати елемент meta:
Існують різні думки про використання meta для вказівки кодування. Колись я вважав, що цей елемент швидше шкідливий, ніж корисний. Однак ряд досліджень і власний досвід змусили мене переглянути свою точку зору. Застосовувати чи не застосовувати meta - слід вирішувати окремо для кожного конкретного сайту.
Який би кодуванням ви не користувалися, треба пам'ятати, що браузери відображають тільки ті символи, які є в встановлених на комп'ютері шрифтах. «Таблиця символів» показує саме їх. Перелік стандартних шрифтів Windows розміщений в розділі «Довідники».
В Unicode можна знайти чимало інших символів - наприклад, руни, літери глаголиці, різноманітні значки і піктограми. Але вставити їх в документ не вийде: у переважної більшості користувачів немає шрифтів, в яких були б присутні ці знаки. Тут навіть UTF-8, при всіх її достоїнствах, допомогти не в силах. Доводиться розміщувати такі символи у вигляді растрових зображень (як зроблено тут) або шукати інші обхідні шляхи.
Багато інших «екзотичні» символи зазвичай доступні на комп'ютерах користувачів, але браузеру доводиться допомагати знайти потрібний шрифт. Наприклад, щоб відобразити старослов'янські букви або математичні знаки (∀ та ін.) - я вказую в CSS шрифт «Lucida Sans Unicode».
Один з рідкісних міфів на користь UTF-8 говорить, що це кодування змушує комп'ютер відображати такі символи, які недосяжні ні в одній старій кодуванні. Однак чудес не буває: якщо у вас на комп'ютері немає шрифту, в якому присутня скрипковий ключ, - то ви не побачите цього символу в UTF-8 з таким же успіхом, як в будь-якій іншій кодуванні.
Головна перевага UTF-8 - не в чарівному розширенні набору символів, а в простому способі їх включення в документ.
Якщо ви знайомі з Unicode, то, можливо, поцікавитеся, чому я раджу саме UTF-8, а не інші сучасні кодування - скажімо, UTF-16 або UTF-32. Відповідаю: вони забезпечують той же головна перевага, що і UTF-8, але мають і низку недоліків. По-перше, вони, на відміну від UTF-8, дійсно помітно збільшують «вага» файлів. По-друге, з ними в деяких використовуваних нині браузерах ще виникають проблеми.
До речі, Консорціум W3C рекомендує використовувати для веб-сторінок саме UTF-8.
Однак не забувайте про те, що світ постійно змінюється. Можливо, в майбутньому виникнуть причини, які змусять нас відмовитися від UTF-8 і перейти на якусь ще більш досконалу систему кодування. Коли це трапиться, я обов'язково вам повідомлю.