[Mirrored from: http://www.alis.com:8085/ietf/html/rfc2070.html]
Network Working Group F. Yergeau
Request for Comments: 2070 Alis Technologies
Category: Standards Track G. Nicol
Electronic Book Technologies
G. Adams
Spyglass
M. Dürst
University of Zurich
January 1997
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
The Hypertext Markup Language (HTML) is a markup language used to create hypertext documents that are platform independent. Initially, the application of HTML on the World Wide Web was seriously restricted by its reliance on the ISO-8859-1 coded character set, which is appropriate only for Western European languages. Despite this restriction, HTML has been widely used with other languages, using other coded character sets or character encodings, at the expense of interoperability.
This document is meant to address the issue of the internationalization (i18n, i followed by 18 letters followed by n) of HTML by extending the specification of HTML and giving additional recommendations for proper internationalization support. A foremost consideration is to make sure that HTML remains a valid application of SGML, while enabling its use with all languages of the world.
The Hypertext Markup Language (HTML) is a markup language used to create hypertext documents that are platform independent. Initially, the application of HTML on the World Wide Web was seriously restricted by its reliance on the ISO-8859-1 coded character set, which is appropriate only for Western European languages. Despite this restriction, HTML has been widely used with other languages, using other coded character sets or character encodings, through various ad hoc extensions to the language [TAKADA].
This document is meant to address the issue of the internationalization of HTML by extending the specification of HTML and giving additional recommendations for proper internationalization support. It is in good part based on a paper by one of the authors on multilingualism on the WWW [NICOL]. A foremost consideration is to make sure that HTML remains a valid application of SGML, while enabling its use with all languages of the world.
The specific issues addressed are the SGML document character set to
be used for HTML, the proper treatment of the charset parameter
associated with the text/html
content type and the specification of
some additional elements and entities.
1.1 Scope
HTML has been in use by the World-Wide Web (WWW) global information initiative since 1990. This specification extends the capabilities of HTML 2.0 (RFC 1866), primarily by removing the restriction to the ISO-8859-1 coded character set [ISO-8859].
HTML is an application of ISO Standard 8879:1986, Information Processing Text and Office Systems — Standard Generalized Markup Language (SGML) [ISO-8879]. The HTML Document Type Definition (DTD) is a formal definition of the HTML syntax in terms of SGML. This specification amends the DTD of HTML 2.0 in order to make it applicable to documents encompassing a character repertoire much larger than that of ISO-8859-1, while still remaining SGML conformant.
Both formal and actual development of HTML are advancing very fast.
The features described in this document are designed so that they
can (and should) be added to other forms of HTML besides that described
in RFC 1866. Where indicated, attributes introduced here should
be extended to the appropriate elements.
1.2 Conformance
This specification changes slightly the conformance requirements of HTML documents and HTML user agents.
All HTML 2.0 conforming documents remain conforming with this specification. However, the extensions introduced here make valid certains documents that would not be HTML 2.0 conforming, in particular those containing characters or character references outside of the repertoire of ISO 8859-1, and those containing markup introduced herein.
In addition to the requirements of RFC 1866, the following requirements are placed on HTML user agents.
This overview explains a reference processing model used for HTML, and in particular the SGML concept of a document character set. An actual implementation may widely differ in its internal workings from the model given below, but should behave as described to an outside observer.
Because there are various widely differing encodings of text, SGML does not directly address how the sequence of characters that constitutes an SGML document in the abstract sense are encoded by means of a sequence of octets (or occasionally bit groups of another length than 8) in a concrete realization of the document such as a computer file. This encoding is called the external character encoding of the concrete SGML document, and it should be carefully distinguished from the document character set of the abstract HTML document. SGML views the characters as a single set (called a character repertoire
), and a code set
that assigns an integer number (known as character number
) to each character in the repertoire. The document character set declaration defines what each of the character numbers represents [GOLD90, p. 451]. In most cases, an SGML DTD and all documents that refer to it have a single document character set, and all markup and data characters are part of this set.
HTML, as an application of SGML, does not directly address the question the external character encoding. This is deferred to mechanisms external to HTML, such as MIME as used by the HTTP protocol or by electronic mail.
For the HTTP protocol [RFC1945], the external character encoding is defined by the charset
parameter of the Content-Type
field of the header of an HTTP response. For example, to indicate that the transmitted document is encoded in the JUNET
encoding of Japanese [RFC1468], the header will contain the following line:
Content-Type: text/html; charset=ISO-2022-JPThe term
charsetin MIME is used to designate a character encoding, rather than merely a coded character set as the term may suggest. A character encoding is a mapping (possibly many-to-one) of sequences of octets to sequences of characters taken from one or more character repertoires.
The HTTP protocol also defines a mechanism for the client to specify the character encodings it can accept. Clients and servers are strongly requested to use these mechanisms to assure correct transmission and interpretation of any document. Provisions that can be taken to help correct interpretation, even in cases where a server or client do not yet use these mechanisms, are described in section 6.
Similarly, if HTML documents are transferred by electronic mail, the external character
encoding is defined by the charset
parameter of the Content-Type
MIME header line [RFC1521], and
defaults to US-ASCII in its absence.
No mechanisms are currently standardized for indicating the external character encoding of HTML documents transferred by FTP or accessed in distributed file systems.
In the case any other way of transferring and storing HTML documents are defined or become popular, it is advised that similar provisions be made to clearly identify the character encoding used and/or to use a single/default encoding capable of representing the widest range of characters used in an international context.
Whatever the external character encoding may be, the reference processing model translates it to the document character set specified in Section 2.2 before processing specific to SGML/HTML. The reference processing model can be depicted as follows:
[resource]->[decoder]->[entity ]->[ SGML ]->[application]->[display]
[manager] [parser]
^ |
| |
+----------+
The decoder is responsible for decoding the external representation of the resource to the document character set. The entity manager, the parser, and the application deal only with
characters of the document character set. A display-oriented part of
the application or the display machinery itself may again convert
characters represented in the document character set to some other
representation more suitable for their purpose. In any case, the
entity manager, the parser, and the application, as far as character
semantics are concerned, are using the HTML document character set
only.
An actual implementation may choose, or not, to translate the document into some encoding of the document character set as described above; the behaviour described by this reference processing model can be achieved otherwise. This subject is well out of the scope of this specification, however, and the reader is invited to consult the SGML standard [ISO-8879] or an SGML handbook [BRYAN88] [GOLD90] [VANH90] [SQ91] for further information.
The most important consequence of this reference processing model is
that numeric character references are always resolved with respect to
the fixed document character set, and thus to the same characters,
whatever the external encoding actually used. For an example, see
Section 2.2.
2.2. The document character set
The document character set, in the SGML sense, is the Universal Character Set (UCS) of ISO 10646:1993 [ISO-10646], as amended. Currently, this is code-by-code identical with the Unicode standard, version 1.1 [UNICODE].
NOTE — implementers should be aware that ISO 10646 is amended from time to time; 4 amendments have been adopted since the initial 1993 publication, none of which significantly affects this specification. A fifth amendment, now under consideration, will introduce incompatible changes to the standard: 6556 Korean Hangul syllables allocated between code positions 3400 and 4DFF (hexadecimal) will be moved to new positions (and 4516 new syllables added), thus making references to the old positions invalid. Since the Unicode consortium has already adopted a corresponding amendment for inclusion in the forthcoming Unicode 2.0, adoption of DAM 5 is considered likely and implementers should probably consider the old code positions as already invalid. Despite this one-time change, the relevant standard bodies appear to remain committed not to change any allocated code position in the future. To encode Korean Hangul irrespective of these changes, the combining Hangul Jamo in the range 1110-11F9 can be used.The adoption of this document character set implies a change in the SGML declaration specified in the HTML 2.0 specification (section 9.5 of [RFC1866]). The change amounts to removing the first BASESET specification and its accompanying DESCSET declaration, replacing them with the following declaration:
BASESET "ISO Registration Number 177//CHARSET
ISO/IEC 10646-1:1993 UCS-4 with implementation level 3
//ESC 2/5 2/15 4/6"
DESCSET 0 9 UNUSED
9 2 9
11 2 UNUSED
13 1 13
14 18 UNUSED
32 95 32
127 1 UNUSED
128 32 UNUSED
160 2147483486 160
Making the UCS the document character set does not create
non-conformance of any expression, construct or document that is
conforming to HTML 2.0. It does make conforming certain constructs
that are not admissible in HTML 2.0. One consequence is that data
characters outside the repertoire of ISO-8859-1, but within that of
UCS-4 become valid SGML characters. Another is that the upper limit
of the range of numeric character references is extended from 255 to
2147483645;
thus, И is a valid reference to a CYRILLIC CAPITAL LETTER I(И). [ERCS] is a good source of information on Unicode and SGML, although its scope and technical content differ greatly from this specification.
NOTE — the above SGML declaration, like that of HTML 2.0, specifies the character numbers 128 to 159 (80 to 9F hex) as UNUSED. This means that numeric character references within that range (e.g. ’) are illegal in HTML. Neither ISO 8859-1 nor ISO 10646 contain characters in that range, which is reserved for control characters.Another change was made from the HTML 2.0 SGML declaration, in the belief that the latter did not express its authors' true intent. The syntax character set declaration was changed from ISO 646.IRV:1983 to the newer ISO 646.IRV:1991, the latter, but not the former, being identical with US-ASCII. In principle, this introduces an incompatibility with HTML 2.0, but in practice it should increase interoperability by i) having the SGML declaration say what everyone thinks and ii) making the syntax character set a proper subset of the document character set. The characters that differ between the two versions of ISO 646.IRV are not actually used to express HTML syntax.
ISO 10646-1:1993 is the most encompassing character set currently existing, and there is no other character set that could take its place as the document character set for HTML. If nevertheless for a
specific application there is a need to use characters outside this standard, this should be done by
avoiding any conflicts with present or future versions of ISO 10646, i.e. by assigning these characters to a private zone of the UCS-4 coding space [ISO-10646 section 11]. Also, it should be borne in mind that such a use will be highly unportable; in many
cases, it may be better to use inline bitmaps.
2.3. Undisplayable characters
With the document character set being the full ISO 10646, the possibility that a character cannot be displayed due to lack of appropriate resources (fonts) cannot be avoided. Because there are many different things that can be done in such a case, this document does not prescribe any specific behaviour. Depending on the implementation, this may also be handled by the underlaying display system and not the application itself. The following considerations, however, may be of help:
Language tags can be used to control rendering of a marked up document in various ways: glyph disambiguation, in cases where the character encoding is not sufficient to resolve to a specific glyph; quotation marks; hyphenation; ligatures; spacing; voice synthesis; etc. Independently of rendering issues, language markup is useful as content markup for purposes such as classification and searching.
Since any text can logically be assigned a language, almost all HTML elements admit the LANG attribute. The DTD reflects this; the only elements in this version of HTML without the LANG attribute are BR, HR, BASE, NEXTID, and META. It is also intended that any new element introduced in later versions of HTML will admit the LANG attribute, unless there is a good reason not to do so.
The language attribute, LANG, takes as its value a language tag that identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information to other human beings. Computer languages are explicitly excluded.
The syntax and registry of HTML language tags is the same as that defined by RFC 1766 [RFC1766]. In summary, a language tag is composed of one or more parts: A primary language tag and a possibly empty series of subtags:
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
Whitespace is not allowed within the tag and all tags are case-
insensitive. The namespace of language tags is administered by the
IANA. Example tags include:
en, en-US, en-cockney, i-cherokee, x-pig-latin
In the context of HTML, a language tag is not to be interpreted as a
single token, as per RFC 1766, but as a hierarchy. For example, a user
agent that adjusts rendering according to language should consider
that it has a match when a language tag in a style sheet entry matches
the initial portion of the language tag of an element. An exact match
should be preferred. This interpretation allows an element marked up
as, for instance, en-USto trigger styles corresponding to, in order of preference, US-English (
en-US) or 'plain' or 'international' English (
en).
NOTE — using the language tag as a hierarchy does not imply that all languages with a common prefix will be understood by those fluent in one or more of those languages; it simply allows the user to request this commonality when it is true for that user.The rendering of elements may be affected by the LANG attribute. For any element, the value of the LANG attribute overrides the value specified by the LANG attribute of any enclosing element and the value (if any) of the HTTP Content-Language header. If none of these are set, a suitable default, perhaps controlled by user preferences, by automatic context analysis or by the user's locale, should be used to control rendering.
According to the suggestion of section 14 of
[RFC1866], the set of
Latin-1 entities is extended to cover the whole right part of
ISO-8859-1 (all code positions with the high-order bit set), including
the already commonly used , © (©) and ® (®). The
names of the entities are taken from the appendices of SGML
[ISO-8879]. A list is provided
in section 7.3 of this specification.
4.2. Markup for language-dependent presentation
4.2.1. Overview
For the correct presentation of text in certain languages (irrespective of formatting issues), some support in the form of additional entities and elements is needed.
In particular, the following features are dealt with:
Some of the above features need very little additional support;
others need more. The additional features are introduced below
with brief comments only. Explanations on
cursive joining behaviour and bidirectional text follow later.
For cursive joining behaviour and bidirectional text,
this document follows [UNICODE]
in that: i) character semantics,
where applicable, are identical to [UNICODE],
and ii) where
functionality is moved to HTML as a higher level protocol,
this is done in a way that allows straightforward conversion
to the lower-level mechanisms defined in [UNICODE].
4.2.2. List of entities, elements, and attributes
First, a generic container is needed to carry the LANG and DIR (see below) attributes in cases where no other element is appropriate; the SPAN element is introduced for that purpose.
A set of named character entities is added for use with bidirectional rendering and cursive joining control:
<!ENTITY zwnj CDATA "‌"--=zero width non-joiner--> <!ENTITY zwj CDATA "‍"--=zero width joiner--> <!ENTITY lrm CDATA "‎"--=left-to-right mark--> <!ENTITY rlm CDATA "‏"--=right-to-left mark-->These entities can be used in place of the corresponding formatting characters whenever convenient, for example to ease keyboard entry or when a formatting character is not available in the character encoding of the document.
Next, an attribute called DIR is introduced, restricted to the values LTR (left-to-right) and RTL (right-to-left) and admitted by most elements, for the indication of directionality in the context of bidirectional text (see 4.2.4 below for details). Since any text and many other elements (e.g. tables) can logically be assigned a directionality, all elements except BR, HR, BASE, NEXTID, and META admit this attribute. The DTD reflects this. It is also intended that any new element introduced in later versions of HTML will admit the DIR attribute, unless there is a good reason not to do so.
A new phrase-level element called BDO (BIDI Override) is introduced, which requires the DIR attribute to specify whether the override is left-to-right or right-to-left. This element is required for bidirectional text control; for detailed explanations, see section 4.2.4.
The phrase-level element Q is introduced to allow language-dependent rendering of short quotations depending on language and platform capability. As the following examples show, in particular the quotation marks surrounding the quotation are affected: "a quotation in English", `another, slightly better one', ,,a quotation in German'', « a quotation in French ». The contents of the Q element does not include quotation marks, they have to be added by the rendering process.
NOTE — Q elements can be nested. Many languages use different quotation styles for outer and inner quotations, and this should be respected by user-agents implementing this element.
NOTE — minimal support for the Q element is to surround the contents with some kind of quotes, like the plain ASCII double quotes. As this is rather easy to implement, and as the lack of any visible quotes may affect the perceived meaning of the text, user-agent implementors are strongly requested to provide at least this minimal level of support.
Many languages require superscript text for proper rendering: as an example, the French Mlle Dupont
should have lle
in superscript. The SUP element, and its sibling SUB for subscript text, are introduced to allow proper markup of such text. SUP and SUB contents are restricted to PCDATA to avoid nesting problems.
Finally, in many languages text justification is much more important than it is in Western languages, and justifies markup. The ALIGN attribute, admitting values of LEFT, RIGHT, CENTER and JUSTIFY, is added to a selection of elements where it makes sense (the block-like P, HR, H1 to H6, OL, UL, DIR, MENU, LI, BLOCKQUOTE and ADDRESS). If a user-agent chooses to have LEFT as a default for blocks of left-to-right directionality, it should use RIGHT for blocks of right-to-left directionality.
NOTE — RFC 1866 section 4.2.2 specifies that an HTML user agent should treat an end of line as a word space, except in preformatted text. This should be interpreted in the context of the script being processed, as the way words are separated in writing is script-dependent. For some scripts (e.g. Latin), a word space is just a space, but in other scripts (e.g. Thai) it is a zero-width word separator, whereas in yet other scripts (e.g. Japanese) it is nothing at all, i.e. totally ignored.
NOTE — the SOFT HYPHEN character (U+00AD) needs special attention from user-agent implementers. It is present in many character sets (including the whole ISO 8859 series and, of course, ISO 10646), and can always be included by means of the reference ­. Its semantics are different from the plain HYPHEN: it indicates a point in a word where a line break is allowed. If the line is indeed broken there, a hyphen must be displayed at the end of the first line. If not, the character is not dispalyed at all. In operations like searching and sorting, it must always be ignored.In the DTD, the LANG and DIR attributes are grouped together in a parameter entity called attrs. To parallel RFC 1942 [RFC1942], the ID and CLASS attributes are also included in attrs. The ID and CLASS attributes are required for use with style sheets, and RFC 1942 defines them as follows:
Markup is needed in some cases to force cursive joining behavior in contexts in which it would not normally occur, or to block it when it would normally occur.
The zero-width joiner and non-joiner (‍ and ‌) are used to
control cursive joining behaviour. For example, ARABIC LETTER HEH is
used in isolation to abbreviate Hijri
(the Islamic calendrical
system);
however, the initial form of the letter is desired, because the
isolated form of HEH looks like the digit five as employed in Arabic
script. This is obtained by following the HEH with a zero-width
joiner whose only effect is to provide context. In Persian texts,
there are cases where a letter that normally would join a subsequent
letter in a cursive connection does not. Here a zero-width non-joiner
is used.
4.2.4. Bidirectional text
Many languages are written in horizontal lines from left to right, while others are written from right to left. When both writing directions are present, one talks of bidirectional text (BIDI for short). BIDI text requires markup in special circumstances where ambiguities as to the directionality of some characters have to be resolved. This markup affects the ability to render BIDI text in a semantically legible fashion. That is, without this special BIDI markup, cases arise which would prevent any rendering whatsoever that reflected the basic meaning of the text. Plain text may contain BIDI markup in the form of special-purpose formatting characters. This is also possible in HTML, which includes the five BIDI-related formatting characters (202A - 202E) of ISO 10646. As an alternative, HTML provides equivalent SGML markup.
BIDI is a complex issue, and conversion of logical text sequences to display sequences has to be done according to the algorithm and character properties specified in [UNICODE]. Here, explanations are given only as far as they are needed to understand the necessity of the features introduced and to define their exact semantics.
The Unicode BIDI algorithm is based on the individual characters of a text being stored in logical order, that is the order in which they are normally input and in which the corresponding sounds are normally spoken. To make rendering of logical order text possible, the algorithm assigns a directionality property to each character, e.g. Latin letters are specified to have a left-to-right direction, Arabic and Hebrew characters have a right-to-left direction.
The left-to-right and right-to-left marks (‎ and ‏) are used to disambiguate directionality of neutral characters. For example, when a double quote sits between an Arabic and a Latin letter, its direction is ambiguous; if a directional mark is added on one side such that the quotation mark is surrounded by characters of only one directionality, the ambiguity is removed. These characters are like zero width spaces which have a directional property (but no word/line break property).
Nested embeddings of contra-directional text runs, due to nested quotations or to the pasting of text from one BIDI context to another, is also a case where the implicit directionality of characters is not sufficient, requiring markup. Also, it is frequently desirable to specify the basic directionality of a block of text. For these purposes, the DIR attribute is used.
On block-type elements, the DIR attribute indicates the base directionality of the text in the block; if omitted it is inherited from the parent element. The default directionality of the overall HTML document is left-to-right.
On inline elements, it makes the element start a new embedding level (to be explained below); if omitted the inline element does not start a new embedding level.
NOTE — the PRE, XMP and LISTING elements admit the DIR attribute. Their contents should not be considered as preformatted with respect to bidirectional layout, but the BIDI algorithm should be applied to each line of text.Following is an example of a case where embedding is needed, showing its effect:
Given the following latin (upper case) and arabic (lower case) letters in backing store with the specified embeddings:
<SPAN DIR=LTR> AB <SPAN DIR=RTL> xy <SPAN DIR=LTR> CD </SPAN> zw </SPAN> EF </SPAN>
One gets the following rendering (with [] showing the directional transitions):
[ AB [ wz [ CD ] yx ] EF ]
On the other hand, without this markup and with a base direction of LTR one gets the following rendering:
[ AB [ yx ] CD [ wz ] EF ]
Notice that yx is on the left and wz on the right unlike the above case where the embedding levels are used. Without the embedding markup one has at most two levels: a base directional level and a single counterflow directional level.
The DIR attribute on inline elements is equivalent to the formatting characters LEFT-TO-RIGHT EMBEDDING (202A) and RIGHT-TO-LEFT EMBEDDING (202B) of ISO 10646. The end tag of the element is equivalent to the POP DIRECTIONAL FORMATTING (202C) character.
Directional override, as provided by the BDO element, is needed to deal with unusual short pieces of text in which directionality cannot be resolved from context in an unambiguous fashion. For example, it can be used to force left-to-right (or right-to-left) display of part numbers composed of Latin letters, digits and Hebrew letters.
The effect of BDO is to force the directionality of all characters within it to the value of DIR, irrespective of their intrinsic directional properties. It is equivalent to using the LEFT-TO-RIGHT OVERRIDE (202D) or RIGHT-TO-LEFT OVERRIDE (202E) characters of ISO 10646, the end tag again being equivalent to the POP DIRECTIONAL FORMATTING (202C) character.
NOTE — authors and authoring software writers should be aware that conflicts can arise if the DIR attribute is used on inline elements (including BDO) concurrently with the use of the corresponding ISO 10646 formatting characters. Preferably one or the other should be used exclusively; the markup method is better able to guarantee document structural integrity, and alleviates some problems when editing bidirectional HTML text with a simple text editor, but some software may be more apt at using the 10646 characters. If both methods are used, great care should be exercised to insure proper nesting of markup and directional embedding or override; otherwise, rendering results are undefined.
It is natural to expect input in any language in forms, as they provide one of the only ways of obtaining user input. While this is primarily a UI issue, there are some things that should be specified at the HTML level to guide behavior and promote interoperability.
To ensure full interoperability, it is necessary for the user agent (and the user) to have an indication of the character encoding(s) that the server providing a form will be able to handle upon submission of the filled-in form. Such an indication is provided by the ACCEPT-CHARSET attribute of the INPUT and TEXTAREA elements, modeled on the HTTP Accept-Charset header (see [HTTP-1.1]), which contains a space and/or comma delimited list of character sets acceptable to the server. A user agent may want to somehow advise the user of the contents of this attribute, or to restrict his possibility to enter characters outside the repertoires of the listed character sets.
NOTE — The list of character sets is to be interpreted as an EXCLUSIVE-OR list; the server announces that it is ready to accept any ONE of these character encoding schemes for each part of a multipart entity. The client may perform character encoding translation to satisfy the server if necessary.
NOTE — The default value for the ACCEPT-CHARSET attribute of an INPUT or TEXTAREA element is the reserved valueUNKNOWN. A user agent may interpret that value as the character encoding scheme that was used to transmit the document containing that element.
The HTML 2.0 form submission mechanism, based on the
application/x-www-form-urlencoded
media type, is ill-equipped
with regard to internationalization. In fact, since URLs are
restricted to ASCII characters, the mechanism is akward even for
ISO-8859-1 text. Section 2.2 of
[RFC1738] specifies that octets may
be encoded using the %HH
notation, but text submitted from a
form is composed of characters, not octets. Lacking a specification
of a character encoding scheme, the %HH
notation has no
well-defined meaning.
The best solution is to use the multipart/form-data
media type
described in [RFC1867]
with the POST method of form submission.
This mechanism encapsulates the value part of each name-value pair in
a body-part of a multipart MIME body that is sent as the HTTP entity;
each body part can be labeled with an appropriate Content-Type,
including if necessary a charset parameter that specifies the
character encoding scheme. The changes to the DTD necessary to
support this method of form submission have been incorporated in the
DTD included in this specification.
A less satisfactory solution is to add a MIME charset parameter to the
application/x-www-form-urlencoded
media type specifier sent
along with a POST method form submission, with the understanding that
the URL encoding of [RFC1738]
is applied on top of the specified
character encoding, as a kind of implicit Content-Transfer-Encoding.
One problem with both solutions above is that current browsers do not generally allow for bookmarks to specify the POST method; this should be improved. Conversely, the GET method could be used with the form data transmitted in the body instead of in the URL. Nothing in the protocol seems to prevent it, but no implementations appear to exist at present.
How the user agent determines the encoding of the text entered by the user is outside the scope of this specification.
NOTE — Designers of forms and their handling scripts should be aware of an important caveat: when the default value of a field (the VALUE attribute) is returned upon form submission (i.e. the user did not modify this value), it cannot be guaranteed to be transmitted as a sequence of octets identical to that in the source document — only as a possibly different but valid encoding of the same sequence of text elements. This may be true even if the encoding of the document containing the form and that used for submission are the same.
Differences can occur when a sequence of characters can be represented by various sequences of octets, and also when a composite sequence (a base character plus one or more combining diacritics) can be represented by either a different but equivalent composite sequence or by a fully precomposed character. For instance, the UCS-2 sequence 00EA+0323 (LATIN SMALL LETTER E WITH CIRCUMFLEX ACCENT + COMBINING DOT BELOW) may be transformed into 1EC7 (LATIN SMALL LETTER E WITH CIRCUMFLEX ACCENT AND DOT BELOW), into 0065+0302+0323 (LATIN SMALL LETTER E + COMBINING CIRCUMFLEX ACCENT + COMBINING DOT BELOW), as well as into other equivalent composite sequences.
Proper interpretation of a text document requires that the character encoding scheme be known. Current HTTP servers, however, do not generally include an appropriate charset parameter with the Content-Type header. This is bad behaviour, which is even encouraged by the continued existence of browsers that declare an unrecognized media type when they receive a charset parameter. User agent implementators are strongly encouraged to make their software tolerant of this parameter, even if they cannot take advantage of it. Proper labelling is highly desirable, but some preventive measures can be taken to mini mize the detrimental effects of its absence:
In the case where a document is accessed from a hyperlink in an origin HTML document, a CHARSET attribute is added to the attribute list of elements with link semantics (A and LINK), specifically by adding it to the linkExtraAttributes entity. The value of that attribute is to be considered a hint to the User Agent as to the character encoding scheme used by the resource pointed to by the hyperlink; it should be the appropriate value of the MIME charset parameter for that resource.
In any document, it is possible to include an indication of the encoding scheme like the following, as early as possible within the HEAD of the document:
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-2022-JP">This is not foolproof, but will work if the encoding scheme is such that ASCII-valued octets stand for ASCII characters only at least until the META element is parsed. Note that there are better ways for a server to obtain character encoding information, instead of the unreliable META above; see [NICOL2] for some details and a proposal.
For definiteness, the charset
parameter received from the source
of the document should be considered the most authoritative, followed
in order of preference by the contents of a META element such as the
above, and finally the CHARSET parameter of the anchor that was
followed (if any).
When HTML text is transmitted directly in UCS-2 or UCS-4 form, the question of byte order arises: does the high-order byte of each multi-byte character come first or last? For definiteness, this specification recommends that UCS-2 and UCS-4 be transmitted in big-endian byte order (high order byte first), which corresponds to the established network byte order for two- and four-byte quantities, to the ISO 10646 requirement and Unicode recommendation for serialized text data and to RFC 1641. Furthermore, to maximize chances of proper interpretation, it is recommended that documents transmitted as UCS-2 or UCS-4 always begin with a ZERO-WIDTH NON-BREAKING SPACE character (hexadecimal FEFF or 0000FEFF) which, when byte-reversed becomes number FFFE or FFFE0000, a character guaranteed to be never assigned. Thus, a user-agent receiving an FFFE as the first octets of a text would know that bytes have to be reversed for the remainder of the text.
There exist so-called UCS Transformation Formats than can be used to transmit UCS data, in addition to UCS-2 and UCS-4. UTF-7 [RFC1642] and UTF-8 [UTF-8] have favorable properties (no byte-ordering problem, different flavours of ASCII compatibility) that make them worthy of consideration, especially for transmission of multilingual text. Another encoding scheme, MNEM [RFC1345], also has interesting properties and the capability to transmit the full UCS. The UTF-1 transformation format of ISO 10646:1993 (registered by IANA as ISO-10646-UTF-1), has been removed from ISO 10646 by amendment 4, and should not be used.
This section contains a DTD for HTML based on the HTML 2.0 DTD of RFC 1866, incorporating the changes for file upload as specified in RFC 1867, and the changes deriving from this document.
<!-- html.dtd
Document Type Definition for the HyperText Markup Language,
extended for internationalisation (HTML DTD)
Last revised: 96/08/07
Authors: Daniel W. Connolly <connolly@w3.org>
Francois Yergeau <yergeau@alis.com>
See Also:
http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html
-->
<!ENTITY % HTML.Version
"-//IETF//DTD HTML i18n//EN"
-- Typical usage:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML i18n//EN">
<html>
...
</html>
--
>
<!--============ Feature Test Entities ========================-->
<!ENTITY % HTML.Recommended "IGNORE"
-- Certain features of the language are necessary for
compatibility with widespread usage, but they may
compromise the structural integrity of a document.
This feature test entity enables a more prescriptive
document type definition that eliminates
those features.
-->
<![ %HTML.Recommended [
<!ENTITY % HTML.Deprecated "IGNORE">
]]>
<!ENTITY % HTML.Deprecated "INCLUDE"
-- Certain features of the language are necessary for
compatibility with earlier versions of the specification,
but they tend to be used and implemented inconsistently,
and their use is deprecated. This feature test entity
enables a document type definition that eliminates
these features.
-->
<!ENTITY % HTML.Highlighting "INCLUDE"
-- Use this feature test entity to validate that a
document uses no highlighting tags, which may be
ignored on minimal implementations.
-->
<!ENTITY % HTML.Forms "INCLUDE"
-- Use this feature test entity to validate that a document
contains no forms, which may not be supported in minimal
implementations
-->
<!--============== Imported Names ==============================-->
<!ENTITY % Content-Type "CDATA"
-- meaning an internet media type
(aka MIME content type, as per RFC1521)
-->
<!ENTITY % HTTP-Method "GET | POST"
-- as per HTTP specification, RFC1945
-->
<!--========= DTD "Macros" =====================-->
<!ENTITY % heading "H1|H2|H3|H4|H5|H6">
<!ENTITY % list " UL | OL | DIR | MENU " >
<!ENTITY % attrs -- common attributes for elements --
"LANG NAME #IMPLIED -- RFC 1766 language tag --
DIR (ltr|rtl) #IMPLIED -- text directionnality --
ID ID #IMPLIED -- element identifier (from RFC1942) --
CLASS NAMES #IMPLIED -- for subclassing elements (from RFC1942) --">
<!ENTITY % just -- an attribute for text justification --
"ALIGN (left|right|center|justify) #IMPLIED"
-- default is left for ltr paragraphs, right for rtl -- >
<!--======= Character mnemonic entities =================-->
<!ENTITY % ISOlat1 PUBLIC
"ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML">
%ISOlat1;
<!ENTITY amp CDATA "&" -- ampersand -->
<!ENTITY gt CDATA ">" -- greater than -->
<!ENTITY lt CDATA "<" -- less than -->
<!ENTITY quot CDATA """ -- double quote -->
<!--Entities for language-dependent presentation (BIDI and contextual analysis) -->
<!ENTITY zwnj CDATA ""-- zero width non-joiner-->
<!ENTITY zwj CDATA ""-- zero width joiner-->
<!ENTITY lrm CDATA ""-- left-to-right mark-->
<!ENTITY rlm CDATA ""-- right-to-left mark-->
<!--========= SGML Document Access (SDA) Parameter Entities =====-->
<!-- HTML contains SGML Document Access (SDA) fixed attributes
in support of easy transformation to the International Committee
for Accessible Document Design (ICADD) DTD
"-//EC-USA-CDA/ICADD//DTD ICADD22//EN".
ICADD applications are designed to support usable access to
structured information by print-impaired individuals through
Braille, large print and voice synthesis. For more information on
SDA & ICADD:
- ISO 12083:1993, Annex A.8, Facilities for Braille,
large print and computer voice
- ICADD ListServ
<ICADD%ASUACAD.BITNET@ARIZVM1.ccit.arizona.edu>
- Usenet news group bit.listserv.easi
- Recording for the Blind, +1 800 221 4792
-->
<!ENTITY % SDAFORM "SDAFORM CDATA #FIXED"
-- one to one mapping -->
<!ENTITY % SDARULE "SDARULE CDATA #FIXED"
-- context-sensitive mapping -->
<!ENTITY % SDAPREF "SDAPREF CDATA #FIXED"
-- generated text prefix -->
<!ENTITY % SDASUFF "SDASUFF CDATA #FIXED"
-- generated text suffix -->
<!ENTITY % SDASUSP "SDASUSP NAME #FIXED"
-- suspend transform process -->
<!--========== Text Markup =====================-->
<![ %HTML.Highlighting [
<!ENTITY % font " TT | B | I ">
<!ENTITY % phrase "EM | STRONG | CODE | SAMP | KBD | VAR | CITE ">
<!ENTITY % text "#PCDATA|A|IMG|BR|%phrase|%font|SPAN|Q|BDO|SUP|SUB">
<!ELEMENT (%font;|%phrase) - - (%text)*>
<!ATTLIST ( TT | CODE | SAMP | KBD | VAR )
%attrs;
%SDAFORM; "Lit"
>
<!ATTLIST ( B | STRONG )
%attrs;
%SDAFORM; "B"
>
<!ATTLIST ( I | EM | CITE )
%attrs;
%SDAFORM; "It"
>
<!-- <TT> Typewriter text -->
<!-- <B> Bold text -->
<!-- <I> Italic text -->
<!-- <EM> Emphasized phrase -->
<!-- <STRONG> Strong emphasis -->
<!-- <CODE> Source code phrase -->
<!-- <SAMP> Sample text or characters -->
<!-- <KBD> Keyboard phrase, e.g. user input -->
<!-- <VAR> Variable phrase or substitutable -->
<!-- <CITE> Name or title of cited work -->
<!ENTITY % pre.content "#PCDATA|A|HR|BR|%font|%phrase|SPAN|BDO">
]]>
<!ENTITY % text "#PCDATA|A|IMG|BR|SPAN|Q|BDO|SUP|SUB">
<!ELEMENT BR - O EMPTY>
<!ATTLIST BR
%SDAPREF; "&#RE;"
>
<!-- <BR> Line break -->
<!ELEMENT SPAN - - (%text)*>
<!ATTLIST SPAN
%attrs;
%SDAFORM; "other #Attlist"
>
<!-- <SPAN> Generic inline container -->
<!-- <SPAN DIR=...> New counterflow embedding -->
<!-- <SPAN LANG="..."> Language of contents -->
<!ELEMENT Q - - (%text)*>
<!ATTLIST Q
%attrs;
%SDAPREF; '"'
%SDASUFF; '"'
>
<!-- <Q> Short quotation -->
<!-- <Q LANG=xx> Language of quotation is xx -->
<!-- <Q DIR=...> New conterflow embedding -->
<!ELEMENT BDO - - (%text)+>
<!ATTLIST BDO
LANG NAME #IMPLIED
DIR (ltr|rtl) #REQUIRED
ID ID #IMPLIED
CLASS NAMES #IMPLIED
%SDAPREF "Bidi Override #Attval(DIR): "
%SDASUFF "End Bidi"
>
<!-- <BDO DIR=...> Override directionality of text to value of DIR -->
<!-- <BDO LANG=...> Language of contents -->
<!ELEMENT (SUP|SUB) - - (#PCDATA)>
<!ATTLIST (SUP)
%attrs;
%SDAPREF "Superscript(#content)"
>
<!ATTLIST (SUB)
%attrs;
%SDAPREF "Subscript(#content)"
>
<!-- <SUP> Superscript -->
<!-- <SUB> Subscript -->
<!--========= Link Markup ======================-->
<!ENTITY % linkType "NAMES">
<!ENTITY % linkExtraAttributes
"REL %linkType #IMPLIED
REV %linkType #IMPLIED
URN CDATA #IMPLIED
TITLE CDATA #IMPLIED
METHODS NAMES #IMPLIED
CHARSET NAME #IMPLIED
">
<![ %HTML.Recommended [
<!ENTITY % A.content "(%text)*"
-- <H1><a name="xxx">Heading</a></H1>
is preferred to
<a name="xxx"><H1>Heading</H1></a>
-->
]]>
<!ENTITY % A.content "(%heading|%text)*">
<!ELEMENT A - - %A.content -(A)>
<!ATTLIST A
%attrs;
HREF CDATA #IMPLIED
NAME CDATA #IMPLIED
%linkExtraAttributes;
%SDAPREF; "<Anchor: #AttList>"
>
<!-- <A> Anchor; source/destination of link -->
<!-- <A NAME="..."> Name of this anchor -->
<!-- <A HREF="..."> Address of link destination -->
<!-- <A URN="..."> Permanent address of destination -->
<!-- <A REL=...> Relationship to destination -->
<!-- <A REV=...> Relationship of destination to this -->
<!-- <A TITLE="..."> Title of destination (advisory) -->
<!-- <A METHODS="..."> Operations on destination (advisory) -->
<!-- <A CHARSET="..."> Charset of destination (advisory) -->
<!-- <A LANG="..."> Language of contents btw <A> and </A> -->
<!-- <A DIR=...> Contents is a new counterflow embedding -->
<!--========== Images ==========================-->
<!ELEMENT IMG - O EMPTY>
<!ATTLIST IMG
%attrs;
SRC CDATA #REQUIRED
ALT CDATA #IMPLIED
ALIGN (top|middle|bottom) #IMPLIED
ISMAP (ISMAP) #IMPLIED
%SDAPREF; "<Fig><?SDATrans Img: #AttList>#AttVal(Alt)</Fig>"
>
<!-- <IMG> Image; icon, glyph or illustration -->
<!-- <IMG SRC="..."> Address of image object -->
<!-- <IMG ALT="..."> Textual alternative -->
<!-- <IMG ALIGN=...> Position relative to text -->
<!-- <IMG LANG=...> Image contains "text" in that language -->
<!-- <IMG DIR=...> Inline image acts as a RTL or LTR
embedding w/r to BIDI algorithm -->
<!-- <IMG ISMAP> Each pixel can be a link -->
<!--========== Paragraphs=======================-->
<!ELEMENT P - O (%text)*>
<!ATTLIST P
%attrs;
%just;
%SDAFORM; "Para"
>
<!-- <P> Paragraph -->
<!-- <P LANG="..."> Language of paragraph text -->
<!-- <P DIR=...> Base directionality of paragraph -->
<!-- <P ALIGN=...> Paragraph alignment (justification) -->
<!--========== Headings, Titles, Sections ===============-->
<!ELEMENT HR - O EMPTY>
<!ATTLIST HR
%just;
%SDAPREF; "&#RE;&#RE;"
>
<!-- <HR> Horizontal rule -->
<!ELEMENT ( %heading ) - - (%text;)*>
<!ATTLIST H1
%attrs;
%just;
%SDAFORM; "H1"
>
<!ATTLIST H2
%attrs;
%just;
%SDAFORM; "H2"
>
<!ATTLIST H3
%attrs;
%just;
%SDAFORM; "H3"
>
<!ATTLIST H4
%attrs;
%just;
%SDAFORM; "H4"
>
<!ATTLIST H5
%attrs;
%just;
%SDAFORM; "H5"
>
<!ATTLIST H6
%attrs;
%just;
%SDAFORM; "H6"
>
<!-- <H1> Heading, level 1 -->
<!-- <H2> Heading, level 2 -->
<!-- <H3> Heading, level 3 -->
<!-- <H4> Heading, level 4 -->
<!-- <H5> Heading, level 5 -->
<!-- <H6> Heading, level 6 -->
<!--========== Text Flows ======================-->
<![ %HTML.Forms [
<!ENTITY % block.forms "BLOCKQUOTE | FORM | ISINDEX">
]]>
<!ENTITY % block.forms "BLOCKQUOTE">
<![ %HTML.Deprecated [
<!ENTITY % preformatted "PRE | XMP | LISTING">
]]>
<!ENTITY % preformatted "PRE">
<!ENTITY % block "P | %list | DL
| %preformatted
| %block.forms">
<!ENTITY % flow "(%text|%block)*">
<!ENTITY % pre.content "#PCDATA | A | HR | BR | SPAN | BDO">
<!ELEMENT PRE - - (%pre.content)*>
<!ATTLIST PRE
%attrs;
WIDTH NUMBER #implied
%SDAFORM; "Lit"
>
<!-- <PRE> Preformatted text -->
<!-- <PRE WIDTH=...> Maximum characters per line -->
<!-- <PRE DIR=...> Base direction of preformatted block -->
<!-- <PRE LANG=...> Language of contents -->
<![ %HTML.Deprecated [
<!ENTITY % literal "CDATA"
-- historical, non-conforming parsing mode where
the only markup signal is the end tag
in full
-->
<!ELEMENT (XMP|LISTING) - - %literal>
<!ATTLIST XMP
%attrs;
%SDAFORM; "Lit"
%SDAPREF; "Example:&#RE;"
>
<!ATTLIST LISTING
%attrs;
%SDAFORM; "Lit"
%SDAPREF; "Listing:&#RE;"
>
<!-- <XMP> Example section -->
<!-- <LISTING> Computer listing -->
<!ELEMENT PLAINTEXT - O %literal>
<!-- <PLAINTEXT> Plain text passage -->
<!ATTLIST PLAINTEXT
%attrs;
%SDAFORM; "Lit"
>
]]>
<!--========== Lists ==================-->
<!ELEMENT DL - - (DT | DD)+>
<!ATTLIST DL
%attrs;
COMPACT (COMPACT) #IMPLIED
%SDAFORM; "List"
%SDAPREF; "Definition List:"
>
<!ELEMENT DT - O (%text)*>
<!ATTLIST DT
%attrs;
%SDAFORM; "Term"
>
<!ELEMENT DD - O %flow>
<!ATTLIST DD
%attrs;
%SDAFORM; "LItem"
>
<!-- <DL> Definition list, or glossary -->
<!-- <DL COMPACT> Compact style list -->
<!-- <DT> Term in definition list -->
<!-- <DD> Definition of term -->
<!ELEMENT (OL|UL) - - (LI)+>
<!ATTLIST OL
%attrs;
%just;
COMPACT (COMPACT) #IMPLIED
%SDAFORM; "List"
>
<!ATTLIST UL
%attrs;
%just;
COMPACT (COMPACT) #IMPLIED
%SDAFORM; "List"
>
<!-- <UL> Unordered list -->
<!-- <UL COMPACT> Compact list style -->
<!-- <OL> Ordered, or numbered list -->
<!-- <OL COMPACT> Compact list style -->
<!ELEMENT (DIR|MENU) - - (LI)+ -(%block)>
<!ATTLIST DIR
%attrs;
%just;
COMPACT (COMPACT) #IMPLIED
%SDAFORM; "List"
%SDAPREF; "<LHead>Directory</LHead>"
>
<!ATTLIST MENU
%attrs;
%just;
COMPACT (COMPACT) #IMPLIED
%SDAFORM; "List"
%SDAPREF; "<LHead>Menu</LHead>"
>
<!-- <DIR> Directory list -->
<!-- <DIR COMPACT> Compact list style -->
<!-- <MENU> Menu list -->
<!-- <MENU COMPACT> Compact list style -->
<!ELEMENT LI - O %flow>
<!ATTLIST LI
%attrs;
%just;
%SDAFORM; "LItem"
>
<!-- <LI> List item -->
<!--========== Document Body ===================-->
<![ %HTML.Recommended [
<!ENTITY % body.content "(%heading|%block|HR|ADDRESS|IMG)*"
-- <h1>Heading</h1>
<p>Text ...
is preferred to
<h1>Heading</h1>
Text ...
-->
]]>
<!ENTITY % body.content "(%heading | %text | %block |
HR | ADDRESS)*">
<!ELEMENT BODY O O %body.content>
<!ATTLIST BODY
%attrs;
>
<!-- <BODY> Document body -->
<!-- <BODY DIR=...> Base direction of whole body -->
<!-- <BODY LANG=...> Language of contents -->
<!ELEMENT BLOCKQUOTE - - %body.content>
<!ATTLIST BLOCKQUOTE
%attrs;
%just;
%SDAFORM; "BQ"
>
<!-- <BLOCKQUOTE> Quoted passage -->
<!ELEMENT ADDRESS - - (%text|P)*>
<!ATTLIST ADDRESS
%attrs;
%just;
%SDAFORM; "Lit"
%SDAPREF; "Address:&#RE;"
>
<!-- <ADDRESS> Address, signature, or byline -->
<!--======= Forms ====================-->
<![ %HTML.Forms [
<!ELEMENT FORM - - %body.content -(FORM) +(INPUT|SELECT|TEXTAREA)>
<!ATTLIST FORM
%attrs;
ACTION CDATA #IMPLIED
METHOD (%HTTP-Method) GET
ENCTYPE %Content-Type; "application/x-www-form-urlencoded"
%SDAPREF; "<Para>Form:</Para>"
%SDASUFF; "<Para>Form End.</Para>"
>
<!-- <FORM> Fill-out or data-entry form -->
<!-- <FORM ACTION="..."> Address for completed form -->
<!-- <FORM METHOD=...> Method of submitting form -->
<!-- <FORM ENCTYPE="..."> Representation of form data -->
<!-- <FORM DIR=...> Base direction of form -->
<!-- <FORM LANG=...> Language of contents -->
<!ENTITY % InputType "(TEXT | PASSWORD | CHECKBOX |
RADIO | SUBMIT | RESET |
IMAGE | HIDDEN | FILE )">
<!ELEMENT INPUT - O EMPTY>
<!ATTLIST INPUT
%attrs;
TYPE %InputType TEXT
NAME CDATA #IMPLIED
VALUE CDATA #IMPLIED
SRC CDATA #IMPLIED
CHECKED (CHECKED) #IMPLIED
SIZE CDATA #IMPLIED
MAXLENGTH NUMBER #IMPLIED
ALIGN (top|middle|bottom) #IMPLIED
ACCEPT CDATA #IMPLIED --list of content types --
ACCEPT-CHARSET CDATA #IMPLIED --list of charsets accepted by server --
%SDAPREF; "Input: "
>
<!-- <INPUT> Form input datum -->
<!-- <INPUT TYPE=...> Type of input interaction -->
<!-- <INPUT NAME=...> Name of form datum -->
<!-- <INPUT VALUE="..."> Default/initial/selected value -->
<!-- <INPUT SRC="..."> Address of image -->
<!-- <INPUT CHECKED> Initial state is "on" -->
<!-- <INPUT SIZE=...> Field size hint -->
<!-- <INPUT MAXLENGTH=...> Data length maximum -->
<!-- <INPUT ALIGN=...> Image alignment -->
<!-- <INPUT ACCEPT="..."> List of desired media types -->
<!-- <INPUT ACCEPT-CHARSET="..."> List of acceptable charsets -->
<!ELEMENT SELECT - - (OPTION+) -(INPUT|SELECT|TEXTAREA)>
<!ATTLIST SELECT
%attrs;
NAME CDATA #REQUIRED
SIZE NUMBER #IMPLIED
MULTIPLE (MULTIPLE) #IMPLIED
%SDAFORM; "List"
%SDAPREF;
"<LHead>Select #AttVal(Multiple)</LHead>"
>
<!-- <SELECT> Selection of option(s) -->
<!-- <SELECT NAME=...> Name of form datum -->
<!-- <SELECT SIZE=...> Options displayed at a time -->
<!-- <SELECT MULTIPLE> Multiple selections allowed -->
<!ELEMENT OPTION - O (#PCDATA)*>
<!ATTLIST OPTION
%attrs;
SELECTED (SELECTED) #IMPLIED
VALUE CDATA #IMPLIED
%SDAFORM; "LItem"
%SDAPREF;
"Option: #AttVal(Value) #AttVal(Selected)"
>
<!-- <OPTION> A selection option -->
<!-- <OPTION SELECTED> Initial state -->
<!-- <OPTION VALUE="..."> Form datum value for this option-->
<!ELEMENT TEXTAREA - - (#PCDATA)* -(INPUT|SELECT|TEXTAREA)>
<!ATTLIST TEXTAREA
%attrs;
NAME CDATA #REQUIRED
ROWS NUMBER #REQUIRED
COLS NUMBER #REQUIRED
ACCEPT-CHARSET CDATA #IMPLIED -- list of charsets accepted by server --
%SDAFORM; "Para"
%SDAPREF; "Input Text -- #AttVal(Name): "
>
<!-- <TEXTAREA> An area for text input -->
<!-- <TEXTAREA NAME=...> Name of form datum -->
<!-- <TEXTAREA ROWS=...> Height of area -->
<!-- <TEXTAREA COLS=...> Width of area -->
]]>
<!--======= Document Head ======================-->
<![ %HTML.Recommended [
<!ENTITY % head.extra "">
]]>
<!ENTITY % head.extra "& NEXTID?">
<!ENTITY % head.content "TITLE & ISINDEX? & BASE? %head.extra">
<!ELEMENT HEAD O O (%head.content) +(META|LINK)>
<!ATTLIST HEAD
%attrs; >
<!-- <HEAD> Document head -->
<!ELEMENT TITLE - - (#PCDATA)* -(META|LINK)>
<!ATTLIST TITLE
%attrs;
%SDAFORM; "Ti" >
<!-- <TITLE> Title of document -->
<!ELEMENT LINK - O EMPTY>
<!ATTLIST LINK
%attrs;
HREF CDATA #REQUIRED
%linkExtraAttributes;
%SDAPREF; "Linked to : #AttVal (TITLE) (URN) (HREF)>" >
<!-- <LINK> Link from this document -->
<!-- <LINK HREF="..."> Address of link destination -->
<!-- <LINK URN="..."> Lasting name of destination -->
<!-- <LINK REL=...> Relationship to destination -->
<!-- <LINK REV=...> Relationship of destination to this -->
<!-- <LINK TITLE="..."> Title of destination (advisory) -->
<!-- <LINK CHARSET="..."> Charset of destination (advisory) -->
<!-- <LINK METHODS="..."> Operations allowed (advisory) -->
<!ELEMENT ISINDEX - O EMPTY>
<!ATTLIST ISINDEX
%attrs;
%SDAPREF;
"<Para>[Document is indexed/searchable.]</Para>">
<!-- <ISINDEX> Document is a searchable index -->
<!ELEMENT BASE - O EMPTY>
<!ATTLIST BASE
HREF CDATA #REQUIRED >
<!-- <BASE> Base context document -->
<!-- <BASE HREF="..."> Address for this document -->
<!ELEMENT NEXTID - O EMPTY>
<!ATTLIST NEXTID
N CDATA #REQUIRED >
<!-- <NEXTID> Next ID to use for link name -->
<!-- <NEXTID N=...> Next ID to use for link name -->
<!ELEMENT META - O EMPTY>
<!ATTLIST META
HTTP-EQUIV NAME #IMPLIED
NAME NAME #IMPLIED
CONTENT CDATA #REQUIRED >
<!-- <META> Generic Meta-information -->
<!-- <META HTTP-EQUIV=...> HTTP response header name -->
<!-- <META NAME=...> Meta-information name -->
<!-- <META CONTENT="..."> Associated information -->
<!--======= Document Structure =================-->
<![ %HTML.Deprecated [
<!ENTITY % html.content "HEAD, BODY, PLAINTEXT?">
]]>
<!ENTITY % html.content "HEAD, BODY">
<!ELEMENT HTML O O (%html.content)>
<!ENTITY % version.attr "VERSION CDATA #FIXED '%HTML.Version;'">
<!ATTLIST HTML
%attrs;
%version.attr;
%SDAFORM; "Book"
>
<!-- <HTML> HTML Document -->
<!SGML "ISO 8879:1986"
--
SGML Declaration for HyperText Markup Language version 2.x
(HTML 2.x = HTML 2.0 + i18n).
--
CHARSET
BASESET "ISO Registration Number 177//CHARSET
ISO/IEC 10646-1:1993 UCS-4 with
implementation level 3//ESC 2/5 2/15 4/6"
DESCSET 0 9 UNUSED
9 2 9
11 2 UNUSED
13 1 13
14 18 UNUSED
32 95 32
127 1 UNUSED
128 32 UNUSED
160 2147483486 160
--
In ISO 10646, the positions with hexadecimal
values 0000D800 - 0000DFFF, used in the UTF-16
encoding of UCS-4, are reserved, as well as the last
two code values in each plane of UCS-4, i.e. all
values of the hexadecimal form xxxxFFFE or xxxxFFFF.
These code values or the corresponding numeric
character references must not be included when
generating a new HTML document, and they should be
ignored if encountered when processing a HTML
document.
--
CAPACITY SGMLREF
TOTALCAP 150000
GRPCAP 150000
ENTCAP 150000
SCOPE DOCUMENT
SYNTAX
SHUNCHAR CONTROLS 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 127
BASESET "ISO 646IRV:1991//CHARSET
International Reference Version
(IRV)//ESC 2/8 4/2"
DESCSET 0 128 0
FUNCTION
RE 13
RS 10
SPACE 32
TAB SEPCHAR 9
NAMING LCNMSTRT ""
UCNMSTRT ""
LCNMCHAR ".-"
UCNMCHAR ".-"
NAMECASE GENERAL YES
ENTITY NO
DELIM GENERAL SGMLREF
SHORTREF SGMLREF
NAMES SGMLREF
QUANTITY SGMLREF
ATTSPLEN 2100
LITLEN 1024
NAMELEN 72 -- somewhat arbitrary; taken from
internet line length conventions --
PILEN 1024
TAGLVL 100
TAGLEN 2100
GRPGTCNT 150
GRPCNT 64
FEATURES
MINIMIZE
DATATAG NO
OMITTAG YES
RANK NO
SHORTTAG YES
LINK
SIMPLE NO
IMPLICIT NO
EXPLICIT NO
OTHER
CONCUR NO
SUBDOC NO
FORMAL YES
APPINFO "SDA" -- conforming SGML Document Access application --
>
The following public text lists each of the characters specified in the Added Latin 1 entity set, along with its name, syntax for use, and description. This list is derived from ISO Standard 8879:1986//ENTITIES Added Latin 1//EN. HTML includes the entire entity set, and adds entities for all missing characters in the right part of ISO-8859-1.
<!-- (C) International Organization for Standardization 1986
Permission to copy in any form is granted for use with
conforming SGML systems and applications as defined in
ISO 8879, provided this notice is included in all copies.
-->
<!-- Character entity set. Typical invocation:
<!ENTITY % ISOlat1 PUBLIC
"ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML">
%ISOlat1;
-->
<!ENTITY nbsp CDATA " " -- no-break space -->
<!ENTITY iexcl CDATA "¡" -- inverted exclamation mark -->
<!ENTITY cent CDATA "¢" -- cent sign -->
<!ENTITY pound CDATA "£" -- pound sterling sign -->
<!ENTITY curren CDATA "¤" -- general currency sign -->
<!ENTITY yen CDATA "¥" -- yen sign -->
<!ENTITY brvbar CDATA "¦" -- broken (vertical) bar -->
<!ENTITY sect CDATA "§" -- section sign -->
<!ENTITY uml CDATA "¨" -- umlaut (dieresis) -->
<!ENTITY copy CDATA "©" -- copyright sign -->
<!ENTITY ordf CDATA "ª" -- ordinal indicator, feminine -->
<!ENTITY laquo CDATA "«" -- angle quotation mark, left -->
<!ENTITY not CDATA "¬" -- not sign -->
<!ENTITY shy CDATA "­" -- soft hyphen -->
<!ENTITY reg CDATA "®" -- registered sign -->
<!ENTITY macr CDATA "¯" -- macron -->
<!ENTITY deg CDATA "°" -- degree sign -->
<!ENTITY plusmn CDATA "±" -- plus-or-minus sign -->
<!ENTITY sup2 CDATA "²" -- superscript two -->
<!ENTITY sup3 CDATA "³" -- superscript three -->
<!ENTITY acute CDATA "´" -- acute accent -->
<!ENTITY micro CDATA "µ" -- micro sign -->
<!ENTITY para CDATA "¶" -- pilcrow (paragraph sign) -->
<!ENTITY middot CDATA "·" -- middle dot -->
<!ENTITY cedil CDATA "¸" -- cedilla -->
<!ENTITY sup1 CDATA "¹" -- superscript one -->
<!ENTITY ordm CDATA "º" -- ordinal indicator, masculine -->
<!ENTITY raquo CDATA "»" -- angle quotation mark, right -->
<!ENTITY frac14 CDATA "¼" -- fraction one-quarter -->
<!ENTITY frac12 CDATA "½" -- fraction one-half -->
<!ENTITY frac34 CDATA "¾" -- fraction three-quarters -->
<!ENTITY iquest CDATA "¿" -- inverted question mark -->
<!ENTITY Agrave CDATA "À" -- capital A, grave accent -->
<!ENTITY Aacute CDATA "Á" -- capital A, acute accent -->
<!ENTITY Acirc CDATA "Â" -- capital A, circumflex accent -->
<!ENTITY Atilde CDATA "Ã" -- capital A, tilde -->
<!ENTITY Auml CDATA "Ä" -- capital A, dieresis or umlaut mark -->
<!ENTITY Aring CDATA "Å" -- capital A, ring -->
<!ENTITY AElig CDATA "Æ" -- capital AE diphthong (ligature) -->
<!ENTITY Ccedil CDATA "Ç" -- capital C, cedilla -->
<!ENTITY Egrave CDATA "È" -- capital E, grave accent -->
<!ENTITY Eacute CDATA "É" -- capital E, acute accent -->
<!ENTITY Ecirc CDATA "Ê" -- capital E, circumflex accent -->
<!ENTITY Euml CDATA "Ë" -- capital E, dieresis or umlaut mark -->
<!ENTITY Igrave CDATA "Ì" -- capital I, grave accent -->
<!ENTITY Iacute CDATA "Í" -- capital I, acute accent -->
<!ENTITY Icirc CDATA "Î" -- capital I, circumflex accent -->
<!ENTITY Iuml CDATA "Ï" -- capital I, dieresis or umlaut mark -->
<!ENTITY ETH CDATA "Ð" -- capital Eth, Icelandic -->
<!ENTITY Ntilde CDATA "Ñ" -- capital N, tilde -->
<!ENTITY Ograve CDATA "Ò" -- capital O, grave accent -->
<!ENTITY Oacute CDATA "Ó" -- capital O, acute accent -->
<!ENTITY Ocirc CDATA "Ô" -- capital O, circumflex accent -->
<!ENTITY Otilde CDATA "Õ" -- capital O, tilde -->
<!ENTITY Ouml CDATA "Ö" -- capital O, dieresis or umlaut mark -->
<!ENTITY times CDATA "×" -- multiply sign -->
<!ENTITY Oslash CDATA "Ø" -- capital O, slash -->
<!ENTITY Ugrave CDATA "Ù" -- capital U, grave accent -->
<!ENTITY Uacute CDATA "Ú" -- capital U, acute accent -->
<!ENTITY Ucirc CDATA "Û" -- capital U, circumflex accent -->
<!ENTITY Uuml CDATA "Ü" -- capital U, dieresis or umlaut mark -->
<!ENTITY Yacute CDATA "Ý" -- capital Y, acute accent -->
<!ENTITY THORN CDATA "Þ" -- capital Thorn, Icelandic -->
<!ENTITY szlig CDATA "ß" -- small sharp s, German (sz ligature) -->
<!ENTITY agrave CDATA "à" -- small a, grave accent -->
<!ENTITY aacute CDATA "á" -- small a, acute accent -->
<!ENTITY acirc CDATA "â" -- small a, circumflex accent -->
<!ENTITY atilde CDATA "ã" -- small a, tilde -->
<!ENTITY auml CDATA "ä" -- small a, dieresis or umlaut mark -->
<!ENTITY aring CDATA "å" -- small a, ring -->
<!ENTITY aelig CDATA "æ" -- small ae diphthong (ligature) -->
<!ENTITY ccedil CDATA "ç" -- small c, cedilla -->
<!ENTITY egrave CDATA "è" -- small e, grave accent -->
<!ENTITY eacute CDATA "é" -- small e, acute accent -->
<!ENTITY ecirc CDATA "ê" -- small e, circumflex accent -->
<!ENTITY euml CDATA "ë" -- small e, dieresis or umlaut mark -->
<!ENTITY igrave CDATA "ì" -- small i, grave accent -->
<!ENTITY iacute CDATA "í" -- small i, acute accent -->
<!ENTITY icirc CDATA "î" -- small i, circumflex accent -->
<!ENTITY iuml CDATA "ï" -- small i, dieresis or umlaut mark -->
<!ENTITY eth CDATA "ð" -- small eth, Icelandic -->
<!ENTITY ntilde CDATA "ñ" -- small n, tilde -->
<!ENTITY ograve CDATA "ò" -- small o, grave accent -->
<!ENTITY oacute CDATA "ó" -- small o, acute accent -->
<!ENTITY ocirc CDATA "ô" -- small o, circumflex accent -->
<!ENTITY otilde CDATA "õ" -- small o, tilde -->
<!ENTITY ouml CDATA "ö" -- small o, dieresis or umlaut mark -->
<!ENTITY divide CDATA "÷" -- divide sign -->
<!ENTITY oslash CDATA "ø" -- small o, slash -->
<!ENTITY ugrave CDATA "ù" -- small u, grave accent -->
<!ENTITY uacute CDATA "ú" -- small u, acute accent -->
<!ENTITY ucirc CDATA "û" -- small u, circumflex accent -->
<!ENTITY uuml CDATA "ü" -- small u, dieresis or umlaut mark -->
<!ENTITY yacute CDATA "ý" -- small y, acute accent -->
<!ENTITY thorn CDATA "þ" -- small thorn, Icelandic -->
<!ENTITY yuml CDATA "ÿ" -- small y, dieresis or umlaut mark -->
Anchors, embedded images, and all other elements which contain URIs as parameters may cause the URI to be dereferenced in response to user input. In this case, the security considerations of [RFC1738] apply.
The widely deployed methods for submitting form requests — HTTP and SMTP — provide little assurance of confidentiality. Information providers who request sensitive information via forms — especially by way of the 'PASSWORD' type input field (see section 8.1.2 in [RFC1866]) — should be aware and make their users aware of the lack of confidentiality.
SGML — An Author's Guide to the Standard Generalized Markup Language, Addison-Wesley, Reading, 1988.
The SGML Handbook, Y. Rubinsky, Ed., Oxford University Press, 1990.
Hypertext Transfer Protocol — HTTP/1.1, Work in progress (draft-ietf-http-v11-spec-03.txt), MIT/LCS, May 1996.
The Multilingual World Wide Web, Electronic Book Technologies, 1995, <http://www.ebt.com/docs/multling.html>
MIME Header Supplemented File Type, Work in progress, <draft-nicol-mime-header-type-00.txt>, EBT, October 1995.
Character Mnemonics & Character Sets, RFC 1345, Rationel Almen Planlaegning, June 1992.
Japanese Character Encoding for Internet Messages, RFC 1468, Keio University, Panda Programming, June 1993.
MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies, RFC 1521, Bellcore, Innosoft, September 1993.
Using Unicode with MIME, RFC 1641, Taligent inc., July 1994.
UTF-7: A Mail-safe Transformation Format of Unicode, RFC 1642, Taligent inc., July 1994.
Uniform Resource Locators (URL), RFC 1738, CERN, Xerox PARC, University of Minnesota, October 1994.
Tags for the Identification of Languages, RFC 1766, UNINETT, March 1995.
Hypertext Markup Language - 2.0, RFC 1866, MIT/W3C, November 1995.
Form-based File Upload in HTML, RFC 1867, Xerox Corporation, November 1995.
HTML Tables, RFC 1942, W3C, May 1996.
Hypertext Transfer Protocol — HTTP/1.0, RFC 1945, MIT/LCS, UC Irvine, May 1996.
The SGML Primer, 3rd ed., SoftQuad Inc., 1991.
Multilingual Information Exchange through the World-Wide Web, Computer Networks and ISDN Systems, Vol. 27, No. 2, Nov. 1994 , p. 235-241.
The Unicode Standard — Worldwide Character Encoding — Version 1.0, Addison-Wesley, Volume 1, 1991, Volume 2, 1992, and Technical Report #4, 1993. The BIDI algorithm is in appendix A of volume 1, with corrections in appendix D of volume 2.
Practical SGML, Kluwer Academicq Publishers Group, Norwell and Dordrecht, 1990.