Імасайтерінформаційне моделювання та аналіз сайтів
інформаційне моделювання та аналіз сайтів
Не існує найкращого браузера, найкращого текстового редактора, найкращої операційної системи. А найкраще кодування існує. Це Utf-8.
За технічними подробицями можна звернутися до RFC 3629 (STD 63) і стандарту Unicode (п. 3.9). А тут піде мова про практичну сторону використання UTF‑8.
У кодуванні Utf-8 ви можете безпосередньо вводити в документ будь-які символи зі всього набору Unicode. Старовинні кодування (наприклад, Windows-1251 чи Koi8-r) надавали не більше 256 символів, а в Unicode є понад 100 000 символів. Серед них - друкарські знаки (тире, лапки, три крапки, апостроф, нерозривний пробіл, нерозривний дефіс та ін.), спеціальні символи (№, §, ©, ‰, та ін.), букви з діакритичними знаками та лігатури (é, è, Ü, Æ, ø, fi та ін.), символи майже всіх алфавітів, що існують в світі (α, Ω, א, ת, ѣ, 伲, 儻 та ін.), піктограми та значки (→, ■, ♥, ☺ та ін.) та безліч інших символів.
Подивіться «Таблицю символів» на своєму комп'ютері. У кодуванні Utf-8 ви можете взяти прямо з цієї таблиці будь-який символ і вставити його безпосередньо в свій документ. Якщо вам потрібен знак копірайта, градуса чи інтеграла - не потрібно шукати особливий шрифт, представляти цей знак в графічному форматі чи вигадувати ще якісь хитрощі. У кодуванні Utf-8 будь-який символ, будь то дріб чи китайський ієрогліф, можна використовувати в документі так само, як і латинську букву «A», російську «Ы» чи знак «+».
У старих кодуваннях можна було вставити в документ особливі символи за допомогою підстановок (references). Наприклад, довгому тире відповідала підстановка — (а також — або —), а грецькій букві «пі» - підстановка π (а також π чи π). Для більшості символів існували лише числові підстановки: наприклад, для дробу ⅓ - ⅓ чи ⅓, для музичного знаку «бемоль» - ♭ чи ♭, для нерозривного дефісу - ‑ чи ‑. Звичайно, це дуже незручно. По-перше, дуже довго: наприклад, замість одного символу «♭» доводиться вставляти сім: ♭. По-друге, документ з підстановками неприємно переглядати і редагувати. Набагато зручніше, коли ви бачите в документі безпосередньо ті символи, які там мають бути, а не коди, такі як — чи π.
Колись давно розробники веб-сторінок були вимушені користуватися такими громіздкими підстановками, тому що кодування Utf-8 ще не існувало. Але зараз можна забути як про підстановки, так і про старі кодування.
Обговоривши переваги Utf-8, варто було б поговорити і про недоліки цього кодування. А недоліків, уявіть собі, у нього немає. Є лише міфи та легенди, а також чутки та домисли, які поширюють старі консерватори та махрові ретрогради. Багато років тому деякі недоліки дійсно мали місце, але зараз їх немає.
Кажуть, що у деяких користувачів все ще встановлені старі браузери, які не здатні відображувати сторінки в Utf-8. Це повна нісенітниця. Навіть Internet Explorer 4 і Netscape 4, якими вже давно ніхто не користується, чудово розуміють Utf-8. А сучасніші браузери - тим паче.
Utf-8 - зовсім не «новомодне» або «молоде» кодування, воно успішно застосовується більше десяти років. Якщо якийсь розробник дізнався про нього досить недавно чи не знає до цих пір - це недолік його кваліфікації, а не кодування.
«Я розмістив на сервері сторінку в Utf-8, а вона відображується кракозябрами», - так інколи скаржаться розробники-початковці. Насправді, така проблема трапляється з самими різними кодуваннями і не пов'язана ні з якими специфічними особливостями Utf-8. Тут справа в тому, що сторінка зроблена в одному кодуванні, а сервер в заголовках HTTP повідомляє інше. Треба привести налаштування серверу у відповідність з дійсним кодуванням веб-сторінок. Ще раз скажу, що це треба зробити при будь-якому кодуванні.
Кажуть, що документи в Utf-8 стають в два рази більше, ніж в старих кодуваннях. Це міф з розряду «чув дзвін, та не знаю, де він». Насправді - по-різному. Наприклад, якщо документ складається лише з символів ASCII (латинські букви, цифри, розділовий і т. д знаки.) - то в кодуванні Utf-8 він займатиме рівно стільки ж байтів, скільки і в будь-якому іншому. Якщо документ містить лише букви російського алфавіту і ніяких інших символів (що, погодьтеся, буває досить рідко) - то в Utf-8 він дійсно стане в два рази більше. А якщо в ньому, наприклад, порівну російських і арабських букв - в Utf-8 він буде в два рази менше, ніж, наприклад, в Windows-1251 чи Asmo-708.
Та сама сторінка, яку ви зараз читаєте, в кодуванні Utf-8 займає 35 кілобайт. А якщо перевести її, наприклад, в Windows-1251, вона займатиме 26 кілобайт. До речі, порівнюючи сторінки, подивіться, наскільки легше читається код в Utf-8.
Розмовляючи про «вагу» веб-сторінок, слід зазначити, що більшу частину цієї ваги зазвичай складає не код HTML, а зображення. (А також, можливо, інші об'єкти: ролики Flash, файли Javascript і т. д.) В результаті навіть в тих випадках, коли документ в Utf-8 збільшується - це практично непомітно в загальному об'ємі даних. Здається, «розбухання» коду на декілька відсотків - невисока ціна за головну перевагу Utf-8, з якої ми почали.
Тим, хто піклується про «вагу», слід було б насамперед викинути з коду застарілі атрибути HTML (такі як cellpadding чи valign) і підстановки для тих символів, яким вони не потрібні (наприклад — для довгого тире чи для нерозривного пробілу). Дійсно, інколи доходить до маразму - хтось впирається: «Не робитиму сторінки в 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 розуміють всі сучасні редактори - від стандартного «Блокноту» в Windows до Dreamweaver'а. (Сам я, до речі, користуюся EmEditor'ом, і цей сайт зроблений саме його засобами.)
Сподіваюся, що подальші рекомендації будуть вам корисні при роботі з Utf-8.
При збереженні файлу багато текстових редакторів пропонують прапорець «Include Unicode Signature (BOM)», «Add Byte Order Mark» тощо. Перш за все переконаєтеся, що у вашому редакторі це є. Якщо схожого налаштування не виявлено (як, наприклад, в «Блокноті») - користуватися таким редактором для серйозних завдань не варто. Знайшовши цей прапорець - вимкніть його.
Byte Order Mark (BOM) - це три службові байти, які автоматично записуються на початку документу і означають, що він збережений в кодуванні UTF. Подробиці можна прочитати в довіднику , а практична сторона полягає в тому, що ці службові байти в Utf-8 не є необхідними, та, навпаки, можуть ввести в оману деякі старі браузери та інші програми.
Якщо за кожною лапкою, тире чи нерозривним пробілом лізти в «Таблицю символів» - можна дуже довго провозитися з одним документом. Для найбільш поширених спеціальних символів рекомендується налаштувати поєднання клавіш, що забезпечить будь-який гарний редактор. Наприклад, я налагодив Emeditor так, що по натисненню Ctrl -↓ ↑↑ в документі з'являється довге тире, а при натисненні Ctrl↓ пробіл ↓ ↑↑ - нерозривний пробіл. Таких поєднань клавіш у мене близько 20, і вони дозволяють вводити найбільш корисні спеціальні символи так само просто, як звичайні букви та розділові знаки.
Звичайно, коли мені потрібен рідко використовуваний символ - буква «юс» чи ієрогліф, - я звертаюся до «Таблиці символів».
Переконаєтеся, що веб-сервер повідомляє правильне кодування сторінок. Якщо це не так - зверніться до адміністратора серверу чи прочитайте довідкові матеріали про те, як налаштувати кодування.
Зустрічаються служби розміщення сайтів (хостінги), які «прив'язані» до якогось одного кодування і не дозволяють господарям сайтів користуватися іншими кодуваннями. З такими хостінгамі не варто зв'язуватися. У якому кодуванні робити сторінки - повинен вирішувати розробник сайту, а не служба його розміщення.
У коді HTML часто має сенс використання елементу meta:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
Існують різні думки з приводу використання 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 та перейти на якесь більш досконале кодування. Коли це трапиться, я обов'язково вам повідомлю.