rfc2070.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,611 行 · 第 1/5 页

   specification and its accompanying DESCSET declaration, replacing
   them with the following declaration:












Yergeau, et. al.            Standards Track                     [Page 6]

RFC 2070               HTML Internationalization            January 1997


     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



Yergeau, et. al.            Standards Track                     [Page 7]

RFC 2070               HTML Internationalization            January 1997


   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:

   -  A clearly visible, but unobtrusive behaviour should be preferred.
      Some documents may contain many characters that cannot be
      rendered, and so showing an alert for each of them is not the
      right thing to do.

   -  In case a numeric representation of the missing character is
      given, its hexadecimal (not decimal) form is to be preferred,
      because this form is used in character set standards [ERCS].

3. The LANG attribute

   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.






Yergeau, et. al.            Standards Track                     [Page 8]

RFC 2070               HTML Internationalization            January 1997


   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-US" to 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.

4. Additional entities, attributes and elements

4.1. Full Latin-1 entity set

   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.



Yergeau, et. al.            Standards Track                     [Page 9]

RFC 2070               HTML Internationalization            January 1997


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:

   -  Markup of bidirectional text, i.e. text where left-to-right and
      right-to-left scripts are mixed.

   -  Control of cursive joining behaviour in contexts where the
      default behaviour is not appropriate.

   -  Language-dependent rendering of short (in-line) quotations.

   -  Better justification control for languages where this is
      important.

   -  Superscripts and subscripts for languages where they appear as
      part of general text.

   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.












Yergeau, et. al.            Standards Track                    [Page 10]

RFC 2070               HTML Internationalization            January 1997


   A set of named character entities is added for use with bidirectional
   rendering and cursive joining control:

   <!ENTITY zwnj CDATA "&#8204;"--=zero width non-joiner-->
   <!ENTITY zwj  CDATA "&#8205;"--=zero width joiner-->
   <!ENTITY lrm  CDATA "&#8206;"--=left-to-right mark-->
   <!ENTITY rlm  CDATA "&#8207;"--=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), 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 (rather poorly, because of
   the character set restriction of Internet specifications), the
   quotation marks surrounding the quotation are particularly 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, which 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.









Yergeau, et. al.            Standards Track                    [Page 11]

RFC 2070               HTML Internationalization            January 1997


      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