Inhoud
In dit hoofdstuk bekijken we hoe HTML documenten gerepresenteerd worden op een computer en over het Internet.
De sectie over de document karakter set behandelt welke abstracte karakters een onderdeel kunnen zijn van een HTML document. Karakters die de latijnse letter "A" bevatten, de Cyrillische letter "I", het Chinese karakter voor "water", enz.
De sectie over karakter encoderingen behandelt hoe deze karakters gerepresenteerd kunnen worden in een bestand of wanneer verzonden over het Internet. Omdat sommige karakter encoderingen niet direct alle karakters kunnen representeren die een auteur wilt opnemen in een document, biedt HTML andere mechanismen, karakter referenties genoemd, voor verwijzing naar welk karakter dan ook.
Omdat er een groot aantal karakters in de menselijke taal mogelijk is en omdat deze karakters op verschillende manieren weergegeven kunnen worden, is het nodig dat er afspraken gemaakt worden opdat de documenten begrepen kunnen worden door User Agents over de hele wereld.
Om interoperabiliteit te verhogen vereist SGML dat elke toepassing (dus ook HTML) zijn document karakter set definieert. Een document karakter set bestaat uit:
Elk SGML document (dus ook elk HTML document) is een opeenvolging van karakters van het repertoire. Computer systemen identificeren elk karakter door zijn code positie; bijvoorbeeld in de ASCII karakter set verwijzen de code posities 65, 66, en 67 respectievelijk naar de karakters 'A', 'B' en 'C'.
De ASCII karakter set is niet voldoende voor een wereldwijd informatie systeem zoals het Web, zodat HTML de meer complete karakter set Universal Character Set (UCS) of Universele Karakter Set gebruikt die gedefinieerd wordt in [ISO10646]. Deze standaard definieert een repertoire van duizenden karakters gebruikt door gemeenschappen over de hele wereld.
De karakter set gedefinieerd in [ISO10646] is karakter-per-karakter equivalent aan Unicode 2.1 ([UNICODE]). Beide van deze standaarden worden van tijd tot tijd ge-update met nieuwe karakters en de verbeteringen zouden geraadpleegd moeten worden op de respectievelijke websites. In de huidige specificatie wordt "[ISO10646]" gebruikt om te verwijzen naar de document karakter set terwijl "[UNICODE]" gereserveerd is voor verwijzingen naar het Unicode bidirectionele tekst algoritme.
De document karakter set is echter niet voldoende om User Agents toe te staan om HTML documenten correct te interpreteren wanneer ze uitgewisseld worden -- geëncodeerd als een opeenvolging van bytes in een bestand of tijdens een netwerk verzending. User Agents moeten ook de specifieke karakter encodering kennen die gebruikt werd om de document karakter stream in een byte stream om te zetten.
Hetgeen door deze specificatie een karakter encodering genoemd wordt is onder andere namen bekend in andere specificaties (dit kan voor verwarring zorgen). Het concept is echter algemeen hetzelfde over het Internet. Ook protocol koppen, attributen en parameters die verwijzen naar karakter encoderingen delen dezelfde naam -- "charset" -- en gebruiken dezelfde waarden van de [IANA] registry (bekijk [CHARSETS] voor een volledige lijst).
De "charset" parameter identificeert een karakter encodering welke een methode is om een sequentie van bytes in een sequentie van karakters te converteren. Deze conversie past op een natuurlijke wijze in het schema van de Web activiteit: servers zenden HTML documenten naar User Agents als een stream van bytes; User Agents interpreteren deze als een sequentie van karakters. De conversie methode kan gaan van een eenvoudige "one-to-one" overzetting tot complexere "switching schemes" of algorithmen.
Een eenvoudige één-byte-per-karakter encoderingstechniek is niet voldoende voor tekst strings van een karakter repertoire zo groot als [ISO10646]. Er zijn verscheidene verschillende encoderingen van stukken van [ISO10646] als aanvulling op encoderingen van de volledige karakterset (zoals UCS-4).
Auteurs tools (bijvoorbeeld tekst editors) kunnen HTML documenten encoderen in de karakter encodering van hun keuze en de keuze hangt grotendeels af van de conventies gebruikt door de systeem software. Deze tools kunnen elk gemakkelijke encodering aanwenden die de meeste karakters in het document aankan op voorwaarde dat de encodering correct gelabeled is. Af en toe voorkomende karakters die buiten deze encodering vallen kunnen nog steeds voorgesteld worden door karakter referenties. Deze verwijzen altijd naar de document karakter set, niet naar de karakter encodering.
Servers en proxies kunnen de karakter encodering "on the fly" (bij het opvragen) wijzigen (dit wordt transcoding genoemd) om aan de aanvragen van de User Agents te voldoen (bekijk sectie 14.2 van [RFC2616], de "Accept-Charset" HTTP request header). Servers en proxies hoeven een document niet te presenteren in een karakter encodering die de karakter set van het hele document bestrijkt.
Algemeen gebruikte karakter encoderingen op het Web bevatten ISO-8859-1 (ook als "Latin-1" aangegeven; bruikbaar voor de meeste West Europese talen), ISO-8859-5 (Cyrillische tekens), SHIFT_JIS (een Japanse encodering ), EUC-JP (andere Japanse encodering) en UTF-8 (een encodering van ISO 10646 die een verschillend aantal bytes voor verschillende karakters gebruikt). Namen voor karakter encoderingen zijn hoofdletterongevoelig zodat bijvoorbeeld "SHIFT_JIS", "Shift_JIS" en "shift_jis" equivalent zijn.
Deze specificatie bepaalt niet welke karakter encoderingen een User Agent moet ondersteunen.
Geschikte User Agents moeten in alle karakter encoderingen die ze herkennen (of waarvan ze zich gedragen alsof ze dat doen) alle karakters transfereren naar ISO 10646.
Wanneer HTML tekst verzonden wordt in UTF-16 (charset=UTF-16), dan zou tekst data verzonden moeten worden in network byte volgorde ("big-endian", hoogste-orde byte eerst) om overeen te komen met [ISO10646], Sectie 6.3 en [UNICODE], clausule C3, pagina 3-1.
Verder wordt het, om de kansen op juiste interpretatie te maximaliseren, aangeraden dat documenten verzonden als UTF-16 altijd beginnen met een "ZERO-WIDTH NON-BREAKING SPACE karakter" (hexadecimaal FEFF, ook "Byte Order Mark" genoemd (BOM)) welk, wanneer de byte omgekeerd is, hexadecimaal FFFE wordt, een karakter dat zeker nooit toegewezen wordt. Zo kan een User Agent, die een hexadecimaal FFFE ontvangt als de eerste bytes van een tekst, weten dat de bytes omgekeerd moeten worden voor de rest van de tekst.
Het UTF-1 transformatie formaat van [ISO10646] (geregistreerd door IANA als ISO-10646-UTF-1), zou niet gebruikt moeten worden. Voor informatie over ISO 8859-8 en het bidirectionele algoritme raadpleeg het deel over bidirectionaliteit en karakter encodering.
Hoe bepaalt een server welke karakter encodering geldt voor een document dat hij serveert? Sommige servers onderzoeken de eerste paar bytes van het document of controleren ten opzichte van een database van gekende bestanden en encoderingen. Veel moderne servers geven Web masters meer controle over karakterset configuratie dan oude servers. Web masters zouden deze mechanismen moeten gebruiken om "charset" parameters te verzenden wanneer dat mogelijk is, maar moeten opletten om een document niet met de verkeerde "charset" parameterwaarde te identificeren.
Hoe weet een agent welke karakter encodering gebruikt werd? De server zou deze informatie ter beschikking moeten stellen. De meest ongecompliceerde manier om voor een server om de User Agent te informeren over de karakter encodering van het document is het gebruik van de "charset" parameter van het "Content-Type" header veld van het HTTP protocol ([RFC2616], secties 3.4 en 14.17) De volgende HTTP header kondigt bijvoorbeeld aan dat de karakter encodering EUC-JP is:
Content-Type: text/html; charset=EUC-JP
Raadpleeg het deel over Comformiteit voor de definitie van text/html.
Het HTTP protocol ([RFC2616], sectie 3.7.1) vermeldt ISO-8859-1 als een standaard karakter encodering wanneer de "charset" parameter afwezig is in het "Content-Type" header veld. In praktijk is gebleken dat deze aanbeveling onbruikbaar is omdat sommige servers niet toelaten om een "charset" parameter te verzenden en anderen kunnen niet geconfigureerd worden om de parameter te verzenden. Daarom moeten User Agents geen standaard waarde voor de "charset" parameter aannemen.
Om server- of configuratiebeperkingen te omzeilen mogen HTML documenten expliciete informatie over de karakter encodering van het document bevatten; het META element kan gebruikt worden om User Agents deze informatie te bezorgen.
Om bijvoorbeeld te specifiëren dat de karakter encodering van het huidige document "EUC-JP" is, zou een document de volgende META declaratie moeten bevatten:
<META http-equiv="Content-Type" content="text/html; charset=EUC-JP">
De META declaratie moet enkel gebruikt worden wanneer de karakter encodering zo georganiseerd is dat ASCII-waarde-bytes voor zichzelf staan (ten minste totdat de META element doorgegeven is). META declaraties zouden zo vroeg mogelijk in het HEAD element moeten verschijnen..
Voor gevallen waar noch het HTTP protocol noch het META element informatie beiden over de karakter encodering van een document biedt HTML het charset attribuut op verscheidene elementen. Door het combineren van deze mechanismen kan een auteur de kansen verhogen dat, wanneer de gebruiker een bron opvraagt, de User Agent de karakter encodering zal herkennen..
Samengevat, geschikte User Agents moeten de volgende prioriteiten volgen wanneer een karakter encodering van een document wordt bepaald (van hoogste naar laagste prioriteit):
Als aanvulling aan deze lijst van prioriteiten mag de User Agent heuristische en gebruikersinstellingen gebruiken. Veel User Agents gebruiken bijvoorbeeld een heuristiek om de verschillende encoderingen gebruikt voor Japanse tekst te onderscheiden. User Agents hebben typisch een gebruikers-definieerbare, lokale standaard karakter encodering welke gebruikt wordt wanneer er geen andere indicatoren zijn.
User Agents kunnen een mechanisme voorzien dat de gebruikers toelaat om incorrecte "charset" informatie te negeren. Wanneer een User Agent echter zo een mechanisme voorziet, dan zou dat enkel geboden mogen worden voor het bladeren en niet voor het bewerken, om zo te vermijden dat Web pagina's gemaakt kunnen worden die een incorrecte "charset" parameter hebben.
Nota. Als het, voor een specifieke toepassing, nog is om te verwijzen naar karakters buiten [ISO10646], dan zouden deze karakters moeten toegewezen worden in een private zone om conflicten met huidige of toekomstige versies van de standaard te vermijden. Dit wordt echter sterk afgeraden voor redenen van overdraagbaarheid.
Een gegeven karakter encodering kan onvoldoende blijken om alle karakters van de document karakter set uit te drukken. Voor zulke encoderingen, of wanneer hardware of software configuraties gebruikers niet toestaan om een aantal document karakters direct in te voegen, kunnen auteurs SGML karakter referenties gebruiken. Karakter referenties zijn een karakter encodering-onafhankelijk mechanisme voor het ingeven van welk karakter dan ook van de document karakter set.
Karakter referenties in HTML kunnen verschijnen in twee vormen:
Karakter referenties binnen opmerkingen hebben geen speciale betekenis; ze vormen enkel commentaar-data.
Nota. HTML biedt andere manieren om karakter data te presenteren zoals inline figuren.
Nota. In SGML is het mogelijk om de afsluitende ";" na een karakter referentie in sommige gevallen te elimineren (bijvoorbeeld bij een lijnafbreking of onmiddelijk voor een tag). In andere omstandigheden mag het niet geëlimineerd worden (bijvoorbeeld in het midden van een woord) We raden te stelligste aan om het ";"-teken in alle gevallen te gebruiken om problemen te vermijden met User Agents die dit karakter vereisen.
Numerieke karakter referenties specificeren de code positie van een karakter in de document karakter set. Numerieke karakter referenties kunnen in twee vormen voorkomen:
Hier zijn een paar voorbeelden van numerische karakter referenties:
Nota. Alhoewel de hexadecimale representatie niet gedefinieerd is in [ISO8879], wordt het verwacht in de herziening, zoals omschreven in [WEBSGML]. Deze conventie is gedeeltelijk bruikbaar daar karakter standaarden algemeen gebruik maken van hexadecimale representaties.
Om auteurs een meer intuïtieve manier van verwijzing naar karakters te geven in de document karakter set, biedt HTML een set van karakter entiteitsreferenties. Karakter entiteitsreferenties gebruiken symbolische namen zodat auteurs code posities niet meer moeten kennen. Bijvoorbeeld, de karakter entiteitsreferentie å verwijst naar het "a" karakter met een ring erop; "å" is gemakkelijker te onthouden dan å.
HTML 4 definieert niet een karakter entiteitsreferentie voor elk karakter in de document karakter set. Er is bijvoorbeeld geen karakter entiteitsreferentie voor de Cyrillische hoofdletter "I". Raadpleeg de volledige lijst van karakter referenties gedefinieerd in HTML 4.
Karakter entiteitsreferenties zijn hoofdlettergevoelig. Zo verwijst Å naar een ander karakter (hoofdletter A, ring) dan å (kleine letter a, ring).
Vier karakter entiteitsreferenties verdienen speciale vermelding daar ze regelmatig gebruikt worden om speciale karakters weer te geven:
Auteurs die het "<" karakter in een tekst willen gebruiken zouden "<" (ASCII decimaal 60) moeten gebruiken om te mogelijke verwarring te vermijden met het begin van een tag (start tag openende afgrenzer). Gelijkaardig zouden auteurs ">" (ASCII decimaal 62) moeten gebruiken in tekst in plaats van ">" om problemen te vermijden met oudere User Agents die dit onjuist zien als het einde van een tag (tag sluitende afgrenzer) wanneer het verschijnt in aanhalingstekens in attribuutwaarden.
Auteurs zouden het "&" (ASCII decimaal 38) moeten gebruiken in plaats van "&" om verwarring te vermijden met het begin van een karakter referentie (entiteitsreferentie openende afgrenzer). Auteurs zouden ook "&" moeten gebruiken in attribuutwaarden daar karakter referenties toegestaan zijn binnen CDATA attribuutwaarden.
Sommige auteurs gebruiken de karakter entiteitsreferentie """ om delen van het dubbele aanhalingsteken (") te coderen daar dat karakter gebruikt kan worden om attribuutwaarden af te bakenen.
Het kan ook voorkomen dat een User Agent niet alle karakters in een document kan weergeven. Bijvoorbeeld omdat de User Agent niet het gepaste lettertype heeft, omdat een karakter een waarde heeft die niet uitgedrukt kan worden in de interne karakter encodering van de User Agent, enz.
Omdat er veel verschillende dingen gedaan kunnen worden in zulke gevallen, zal dit document geen specifiek gedrag voorschrijven. Afhankelijk van de implementatie kunnen niet-weergeefbare karakters ook afgehandeld worden door het onderliggende weergavesysteem en niet door de toepassing zelf. Bij afwezigheid van meer gecompliceerd gedrag, bijvoorbeeld aangepast voor de nood van een bepaald script of een bepaalde taal, bevelen we het volgende gedrag voor User Agents aan: