У цьому розділі ми обговоримо, як документи HTML відображаються на комп'ютері і в Internet.
У розділі кодова сторінка документа обговорюється питання про те, як абстрактні символи можуть бути частиною документа HTML. Символи включають букви латиниці, кирилиці, китайські символи "водяні знаки", і т.д.
Оскільки існує величезна кількість символів в мовах різних народів і велика різноманітність способів представлення цих символів, потрібен особливий підхід для того, щоб документи були доступні для читання в будь-якому браузері в будь-якій точці земної кулі.
5.1 Кодова сторінка документа
З метою поліпшення взаємодії, SGML вимагає, щоб кожен додаток (додаток HTML - в тому числі) специфіковані свій набір символів. Набір символів (кодова сторінка) складається з:
- "Репертуару". набору абстрактних символів, таких як латинська буква "A", російська буква "І", китайські "водяні знаки" і т.д.
- Позиції символу. набору цифрових посилань на символи в "репертуарі".
Кожен документ SGML (включаючи кожний документ HTML) - це послідовність символів з "репертуару". Операційна система комп'ютера ідентифікує кожен символ по його кодової позиції. Наприклад, в наборі символів ASCII кодові позиції 65, 66 і 67 посилаються на символи 'A', 'B' і 'C' відповідно.
Набір символів ASCII недостатній для глобальних інформаційних систем, таких як Web, тому HTML використовує більш повний набір символів, званий Universal Character Set (UCS) / Універсальний набір символів, визначений у документі [ISO10646]. Цей стандарт визначає репертуари тисяч наборів символів, використовуваних у всьому світі.
Набір символів, певний в [ISO10646]. це символ-символ еквівалент Юникода ([UNICODE]). Обидва цих стандарту час від часу доповнюються новими символами, і по цих поправках потрібно постійно консультуватися на відповідних Web-сайтах. У поточній специфікації ISO10646 використаний для визначення набору символів, в той час як UNICODE зарезервований для посилань на двонаправлений текстовий алгоритм.
Одного набору символів, однак, недостатньо для того, щоб браузери користувача могли коректно інтерпретувати документи HTML, так як вони зазвичай кодуються як послідовність байтів у файлі під час передачі по мережі. Браузер користувача повинен також "знати" специфічну кодування. використовувану для трансформації документа в потік байтів.
5.2 Кодові сторінки
Те, що в цій специфікації називається кодуванням символів. відоме під різними назвами в інших специфікаціях (що може іноді бентежити). Однак загальне розуміння - одне в усій мережі Internet.
Заголовки протоколів (protocol headers), атрибути і параметри, які стосуються кодуванні символів, використовують один термін - "charset" і одні і ті ж значення з реєстрації [IANA] (дивись повний список в [CHARSETS]).
Параметр "charset" ідентифікує кодування символів, яка представляє собою метод конвертації послідовності байтів в послідовність символів. Ця конвертація відповідає, за своєю природою, схемою діяльності Web: сервери посилають документи HTML браузерам користувачів як потік байтів, браузери користувачів інтерпретують його в послідовність символів.
Методи конвертації варіюються від простих один-за-одним до складних схем перемикання і алгоритмів.
Проста техніка кодування, один-байт-один-символ, недостатня для використання символів, що не входять в "репертуар" [ISO10646]. Є кілька різних кодувань, починаючи з часткових кодувань з використанням [ISO10646]. і до кодувань повного набору символів (як UCS-4).
Сервери і proxy-сервери можуть змінювати кодування символів (це називається transcoding) "на ходу", щоб прийняти запит користувача браузера (дивись розділ 14.2 в [RFC2616]. Заголовок запиту "Accept-Charset" HTTP). Сервери та проксі-сервери не повинні обов'язково обслуговувати документ в тій кодуванні, яка покриває весь набір символів цього документа.
Зазвичай в Web використовуються кодування: ISO-8859-1 (також відома як "Latin-1", використовується для більшості західноєвропейських мов), ISO-8859-5 (підтримуюча кирилицю), SHIFT_JIS (японська кодування), EUC-JP (інша японська кодування) і UTF-8 (кодування ISO 10646, що використовує різне число байтів для різних символів). Назви кодувань нечутливі до регістру. Таким чином, "SHIFT_JIS", "Shift_JIS" і "shift_jis" еквівалентні.
Ця специфікація не наказує, які кодування браузер повинен підтримувати.
Відповідність браузерів. Браузери повинні відповідати відображенню, по ISO 10646, всіх символів в будь-якому кодуванні, які ними розпізнаються (або вони повинні діяти, як якщо б вони розпізнавали їх).
Зауваження за спеціальною кодиров ке
Якщо текст HTML передається в кодуванні UTF-16 (charset = UTF-16), дані тексту повинні передаватися в мережевому порядку байтів ( "big-endian", старший байт - перший) відповідно до [ISO10646]. розділ 6.3 і [UNICODE]. пункт C3, сторінка 3-1.
Крім того, для того, щоб збільшити шанси правильної інтерпретації документа, рекомендується, щоб документ, який передається як UTF-16, завжди починався символом ZERO-WIDTH NON-BREAKING SPACE (шістнадцяткова FEFF, звана також Byte Order Mark (BOM)), яка при перестановці байтів стає FFFE, символом, що гарантує, що він ніколи не буде встановлено. Таким чином, браузер користувача, отримавши FFFE як перший байт тексту, зможе визначити, що цей байт зарезервований для нагадування про кодування UTF-16.
UTF-1 формат трансформації [ISO10646] (зареєстрований IANA як ISO10646-UTF-1), не повинен використовуватися.
Про ISO 8859-8 і двунаправленном алгоритмі см. Розділ двунаправленность і кодування символів.
Як сервер визначає кодування документа? Деякі сервери перевіряють кілька перших байтів документа або перевіряють інформацію в базі даних про відомих файлах і кодуваннях. Багато сучасні сервери дають Web-майстру більше можливостей для контролю за зміною наборів символів. Web-майстра повинні використовувати ці механізми для передачі відомостей "charset" завжди, коли це можливо, і не позначати документ неправильним значенням параметра "charset".
Як браузер користувача розпізнає кодування документа?
Цю інформацію повинен надавати сервер. Прямий шлях для цього - використання параметра "charset" заголовки поля "Content-Type" протоколу HTTP ([RFC2616]. Розділи 3.4 і 14.17). Наприклад, наступний заголовок HTTP оголошує кодування EUC-JP:
Протокол HTTP ([RFC2616]. Розділ 3.7.1) згадує ISO-8859-1 як кодування за замовчуванням в разі відсутності параметра "charset" в поле заголовка "Content-Type". На практиці ця рекомендація не буде корисною, оскільки деякі сервери не пересилають параметр "charset", а інші можуть бути не сконфігуровані для пересилання параметра. Таким чином, браузер може не отримати значення параметра "charset" за замовчуванням.
Підсумовуючи вищесказане: браузери відповідають вимогам, повинні дотримуватися наступні пріоритети при визначенні кодування документа (від вищого пріоритету до нижчого):
На додаток до цього списку пріоритетів, браузер може використовувати heuristics і призначені для користувача установки. Наприклад, багато браузери використовують heuristics для розрізнення кодувань японського тексту. Також браузери зазвичай використовують локальні кодування за замовчуванням, визначені користувачем, які застосовуються при відсутності інших покажчиків.
Примітка. Якщо в певному додатку потрібно звернутися до набору символів поза [ISO10646]. символи повинні бути виділені в окремий простір (private zone), щоб виключити конфлікти з майбутніми версіями стандарту. Однак, це вкрай не рекомендується з міркувань переносимості.
5.3 Мнемоніки (символи по посиланню, за псевдонімом)
Посилання на символ (мнемоніки) можуть бути двох видів:
- Цифрові мнемоніки (десятеричная або шістнадцяткові).
- Мнемоніки з символьних елементів.
Примітка. HTML надає можливість вибрати для подання символьних даних, особливо - вбудовані зображення \ inline images.
5.3.1 Цифрові мнемоніки
Цифрові посилання-мнемоніки на символи визначають кодову позицію символу в символьному наборі документа. Цифрові мнемоніки бувають двох видів:
- "#D;", де D. десятеричная число, посилається на десятеричная значення D символу ISO 10646.
- "#xH;" або "#XH;", де H. шістнадцяткове число, посилається на шістнадцяткове значення H символу ISO 10646. Шістнадцяткові числа в цифрових мнемоніку нечутливі до регістру.
Ось кілька прикладів цифрових мнемонік:
- # 229; (10-ва) представляє букву "a" з маленьким кружком зверху (використовується, напр. В Норвегії);
- # XE5; (16-ва) та ж сама буква;
- # Xe5; (16-ва) те ж саме;
- # 1048; (10-ва) російська "І" заголовна;
- # X6C34; (16-ва) китайський "водяний" символ.
Примітка. Хоча 16-ве уявлення не визначене в [ISO8879]. це очікується при перегляді, як описано в [WEBSGML]. Ця угода особливо актуально, поки стандарти символів використовують 16-ні уявлення.
5.3.2 Символьні посилання-мнемоніки (за псевдонімом)
Символьні мнемоніки чутливі до регістру. так, Å посилається на іншу букву (A з гуртком у верхньому регістрі), а не на å (А з гуртком в нижньому регістрі).
Чотири символьні мнемоніки повинні бути згадані окремо, так як вони часто використовуються в певних escape-послідовності:
Браузер може не відображати коректно все символи в документі. Наприклад, якщо у користувача немає відповідного шрифту, символ має значення, якого бракує у внутрішній кодуванні браузера, і т.д.
- Створити ясний, але ненав'язливий механізм повідомлення користувачу про відсутній ресурсі.
- Якщо відсутні символи представлені цифрами, використовуйте 16-ні (НЕ десятеричная) форми, поки ці форми є в стандартах.