BBS水木清华站∶精华区
发信人: yanglc (魂归燕园), 信区: Linux
标 题: Li18nux国际化草案(最初稿, 4-)
发信站: BBS 水木清华站 (Wed May 17 22:42:56 2000)
www.linuxforum.net
Subject
Li18nux国际化草案(最初稿, 4-)
Posted by
yumj
Posted on
5/17/2000 11:47 AM
Hello Li18nux members,
Here is the draft specification of LI18NUX2000 which
we, Li18nux-sa subgroup members, has worked on for these several months.
Please review and send your comments to li18nux-sa subgroup by 4/17.
Mail address: li18nux-sa@sun.com
Format: free
It is nice to have the following information
with your comments.
- section number, section title, paragraph number
- comment type (technical/editorial/clarification request)
Comment due: 4/17 10:00 a.m. PST
The draft will be discussed at the coming LI18NUX meeting on 4/19-20.
Note to li18nux-sa subgroup members:
Numata-san (technical editor) made several editorial changes (spell,
correction, etc.) to the draft after it was posted to
the li18nux-sa mailing list.
Thank you, Numata-san.
best regards,
Yoichi Suehiro
(as the leader of Li18nux-sa subgroup)
===
LI18NUX2000 Globalization Specification (Draft 2000-04-10)
1. Foreword
1.1 Scope
This document specifies interfaces and functionalities that must be supported
by operating systems to run internationalized application software.
This document also includes recommendations for internationalized execution
environments.
This specification only lists internationalization aspects of each
functionality provided by the conforming operating systems.
The standards required to conform to are listed in the beginning of each
chapter.
1.2 Normative References
[POSIX.1]
ISO/IEC 9945-1:1996 Information technology -- Portable Operating
System Interface (POSIX) -- Part 1: System Application Program
Interface (API) [C Language]
[POSIX.2]
ISO/IEC 9945-2:1993 Information technology -- Portable Operating
System Interface (POSIX) -- Part 2: Shell and Utilities
[ISO C]
ISO/IEC 9899:1999 Programming languages -- C
[XCU5]
The Single UNIX Specification, Version 2
- Commands and Utilities, Issue 5
The Open Group CAE Specification C604
[XBD5]
The Single UNIX Specification, Version 2
- System Interface Definitions, Issue 5
The Open Group CAE Specification C605
[XSH5]
The Single UNIX Specification, Version 2
- System Interfaces and Headers, Issue 5 (2 volumes)
The Open Group CAE Specification C606
[XNS5.2]
The Single UNIX Specification, Version 2
- Networking Services, Issue 5.2
The Open Group CAE Specification C808
[XCURSES4.2]
The Single UNIX Specification, Version 2
- X/Open Curses (XCurses), Issue 4 Version 2
The Open Group CAE Specification C610
[ISO C++]
ISO/IEC 14882:1998 Programming Languages -- C++
[ICU]
International Component for Unicode 1.4.0
http://oss.software.ibm.com/icu/icuhtml/index.html
[Perl 5.6]
Perl 5.6 (March 23, 2000)
- http://www.perl.com/pub/n/Perl_5.6.0_is_out!
[Tcl/Tk 8.3]
Tcl/Tk 8.3 (February 10, 2000)
- http://dev.scriptics.com/software/tcltk/8.3.tml
[*** Editor's note: pointer to Java Language Specification is needed. ***]
[X11R6]
The Definitive Guides to the X Window System, O'Reilly & Associates, Inc.
Volume 0: X Protocol Reference Manual, 4th Edition (X11R6)
Volume 2: Xlib Reference Manual, 3rd Edition (X11R5)
Volume 5: X Toolkit Intrinsics Reference Manual, 3rd Edition (X11R5)
Programmer's Supplement for Release 6
[Unicode 3.0]
The Unicode Standard, Version 3.0
[Unicode Normalization]
Unicode Technical Report #15: Unicode Normalization Forms,
Revision 18.0
http://www.unicode.org/unicode/reports/tr15/
(included in "The Unicode Standard, Version 3.0")
[UTF-32]
Draft Unicode Technical Report #19: UTF-32, Revision 5.0
http://www.unicode.org/unicode/reports/tr19/
[ISO 10646-1]
ISO/IEC 10646-1:1993 Information technology -- Universal
Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture
and Basic Multilingual Plane
ISO/IEC 10646-1:1993/Cor 1:1996
ISO/IEC 10646-1:1993/Cor 2:1998
ISO/IEC 10646-1:1993/Amd 1:1996 Transformation Format for 16
planes of group 00 (UTF-16)
ISO/IEC 10646-1:1993/Amd 2:1996 UCS Transformation Format 8
(UTF-8)
ISO/IEC 10646-1:1993/Amd 3:1996
ISO/IEC 10646-1:1993/Amd 4:1996
ISO/IEC 10646-1:1993/Amd 5:1998 Hangul syllables
ISO/IEC 10646-1:1993/Amd 6:1997 Tibetan
ISO/IEC 10646-1:1993/Amd 7:1997 33 additional characters
ISO/IEC 10646-1:1993/Amd 8:1997
ISO/IEC 10646-1:1993/Amd 9:1997 Identifiers for characters
ISO/IEC 10646-1:1993/Amd 10:1998 Ethiopic
ISO/IEC 10646-1:1993/Amd 11:1998 Unified Canadian Aboriginal
Syllabics
ISO/IEC 10646-1:1993/Amd 12:1998 Cherokee
ISO/IEC 10646-1:1993/Amd 13:1998 CJK unified ideographs with
supplementary sources
ISO/IEC 10646-1:1993/Amd 16:1998 Braille patterns
ISO/IEC 10646-1:1993/Amd 17:1999 CJK Unified Ideographs
Extension A
ISO/IEC 10646-1:1993/Amd 18:1999 Symbols and others characters
ISO/IEC 10646-1:1993/Amd 19:1998 Runic
ISO/IEC 10646-1:1993/Amd 20:1998 Ogham
ISO/IEC 10646-1:1993/Amd 21:1999 Sinhala
ISO/IEC 10646-1:1993/Amd 23:1999 Bopomofo Extended and others
characters
[ISO 639]
ISO 639:1988 Code for the representation of names of languages
[ISO 639-2]
ISO 639-2:1998 Codes for the representation of names of languages
-- Part 2: Alpha-3 code
[ISO 3166-1]
ISO 3166-1:1997 Codes for the representation of names of countries
and their subdivisions -- Part 1: Country codes
[ISO 3166-2]
ISO 3166-2:1998 Codes for the representation of names of countries
and their subdivisions -- Part 2: Country subdivision code
[ISO 3166-3]
ISO 3166-3:1999 Codes for the representation of names of countries
and their subdivisions -- Part 3: Code for formerly used names of
countries
1.3 Conformance
1.3.1 Conforming Environments
For conformance purposes the following environments are defined:
(1) Application Execution Environment
Application Execution Environment is a minimum operating system
environment which can run internationalized application software.
The facilities defined in this environment are mandatory and shall be
present on all conforming implementations.
The following sections are applied to Application Execution Environment:
3. Base Libraries
5. Shells and Utilities
(2) End User Environment
End User Environment is an operating system environment with user
interface. It is assumed that End User Environment has a set of
utilities for user interaction.
This environment includes all the interfaces and functionalities provided
by Application Execution Environment. Additional interfaces and
utilities are defined for the following sub-environments:
(a) Server Environment
Server environment is an operating system environment suitable for
backend server purposes. Graphical user interfaces are not required
in this environment.
The following sections are applied to Server Environment:
3. Base Libraries
4. Graphic Libraries
5. Shells and Utilities
6. Programming Languages (with Software Development Option)
7. Graphic Toolkit
10. Network Servers
(b) Desktop Environment
Desktop environment is an operating system environment suitable for
end user interaction. Graphical user interface is required in this
environment.
The following sections are applied to Desktop Environment:
3. Base Libraries
4. Graphic Libraries
5. Shells and Utilities
6. Programming Languages (with Software Development Option)
7. Graphic Toolkit
8. Input Methods
9. Output Methods
11. Internet Tools
12. X Clients
If an interface or utility is defined as "supported in End User
Environment", that interface or utility shall be available in both
Server and Desktop environments.
[*** Editor's Note: More restricted environment, such as "embedded"
systems, may be defined in the future version of this document. ***]
The following option can be supported in each environment:
(3) Software Development Option
If this option is supported, utilities, libraries and associated modules
to develop internationalized software (such as compilers or interpreters)
shall be provided.
1.3.2 Conformance Levels
Several levels are defined for conformance for each environment. These levels
are defined as follows:
(1) Level 1
The level 1 is the bottom-line level of conformance. All conforming
implementations shall provide this level of interfaces and utilities to
conform to this specification. If level is not specified in the specification,
that specification shall be considered as Level 1.
(2) Level 2
The level 2 is more advanced or extended level of conformance. Conforming
implementations are encouraged to provide this level of interfaces and
utilities to conform to this specification, but it is not mandatory.
2. Terminology
2.1 Definition of Terms
The following terms are used in this specification:
Implementation-defined
A value or behavior is implementation-defined when it is left to
the implementation to define [and document] the corresponding
requirements for correct application behavior.
May
With respect to implementations, the word "may" is to be interpreted as
an optional feature that is not required in this
specification but can be provided. With respect to application, the word
"may" means that the feature is optional. The term "optional" has
the same definition as "may".
Shall
In this specification, the word "shall" is to be interpreted as a
mandatory requirement on the implementation or on application, depending
upon the context. The term "must" has the same definition as "shall".
Should
With respect to implementations, the word "should" is to be interpreted
as an implementation recommendation, but not a requirement. With respect
to application, the word "should" is to be interpreted as recommended
programming practice.
Supported
Certain facilities in this specification are optional. If a facility is
supported, it behaves as specified by this specification.
If a facility is "supported" by an implementation, the implementation
must document how to obtain and install the facility, or the facility is
installed by installer of the implementation by explicitly selected by
the user or implicitly installed with other system components. If an
implementation "supports" a facility, the distributor of the
implementation shall commit that the facility can run on the
implementation.
Unspecified
When a value or behavior is unspecified, the specification defines no
portability requirements for a facility on an implementation even when
faced with an application that uses the facility. An application that
requires specific behavior in such an instance, rather than tolerating
any behavior when using that facility, is not a portable application.
Provided
Certain facilities in this specification are mandatory and implemented
in all conforming implementations.
2.2 General Terms
character
A sequence of one or more bytes representing a single graphic symbol or
control code.
This term corresponds to the ISO C standard term multibyte character
(multi-byte character), where a single-byte character is a special case
of a multi-byte character. Unlike the usage in the ISO C standard,
character here has no necessary relationship with storage space, and
byte is used when storage space is discussed.
[Single UNIX Specification, Version 2 (derived from ISO/IEC 9945-2:1993)]
byte
An individually addressable unit of data storage that is equal to or
larger than an octet, used to store a character or a portion of a
character; see character.
A byte is composed of a contiguous sequence of bits, the number of which
is implementation-dependent. The least significant bit is called the
low-order bit; the most significant is called the high-order bit.
Note that this definition of byte deviates intentionally from the usage
of byte in some international standards, where it is used as a synonym
for octet (always eight bits). On a system based on the ISO/IEC
9945-2:1993 standard, a byte may be larger than eight bits so that it
can be an integral portion of larger data objects that are not evenly
divisible by eight bits (such as a 36-bit word that contains four 9-bit
bytes).
[Single UNIX Specification, Version 2 (derived from ISO/IEC 9945-2:1993)]
repertoire
A specified set of characters that are represented in a coded character
set.
[ISO/IEC 10646-1:2000]
character boundary
Within a stream of octets the demarcation between the last octet of the
coded representation of a character and the first octet of that of the
next coded character.
[ISO/IEC 10646-1:2000]
control function
An action that affects the recording, processing, transmission, or
interpretation of data, and that has coded representation consisting of
one or more octets.
[ISO/IEC 10646-1:2000]
graphic character
A character, other than a control function, that has a visual
representation normally handwritten, printed, or displayed.
[ISO/IEC 10646-1:2000]
graphic symbol
The visual representation of a graphic character or of a composite
sequence.
[ISO/IEC 10646-1:2000]
coded character set [CCS]
A Coded Character Set (CCS) is a mapping from a set of abstract
characters to a set of integers. Examples of coded character sets
are ISO 10646, US-ASCII, and ISO-8859 series.
[RFC 2130]
character encoding scheme [CES]
A Character Encoding Scheme (CES) is a mapping from a Coded Character
Set or several coded character sets to a set of octets. Examples of
Character Encoding Schemes are ISO 2022 and UTF-8.
A given CES is typically associated with a single CCS; for example,
UTF-8 applies only to ISO 10646.
[RFC 2130]
transfer encoding syntax [TES]
It is frequently necessary to transform encoded text into a format
which is transmissible by specific protocols. The Transfer Encoding
Syntax (TES) is a transformation applied to character data encoded
using a CCS and possibly a CES to allow it to be transmitted.
Examples of Transfer Encoding Syntaxes are Base64 Encoding,
gzip encoding, and so forth.
[RFC 2130]
internationalization
The process of designing and developing an implementation with a set of
features, functions, and options intended to facilitate the adaptation
of the implementation to satisfy a variety of cultural environments.
[P1003.0/D16]
localization
The process of utilizing the internationalization features to create a
version of the product for a specific culture.
[P1003.0/D16]
local adaptation
The process of modifying a product that is specific to one culture to
make it specific to another culture.
[P1003.0/D16]
locale
A description of a cultural environment.
[P1003.0/D16]
3. Base Libraries
(1) Scope
This chapter defines runtime library interfaces required to conform to this
specification. Conforming implementations shall provide the C language
APIs defined by [ISO C] and [POSIX.1]. In addition to the C language
interface, conforming level 2 implementations shall provide interfaces for
other programming languages.
(2) Requirements
Conforming implementations shall provide the internationalization
functions listed in the Table 3-1 and the headers listed in the Table 3-2.
The specifications of the functions and the definitions of the headers
shall conform to [POSIX.1] and [ISO C].
In addition to the functions in the Table 3-1, conforming implementations
shall provide the wide character and wide string I/O functionality
through printf/scanf family of functions as specified in [ISO C].
Table 3-1 C Language internationalization functions
btowc() fgetwc() fgetws() fputwc() fputws()
fwide() fwprintf() fwscanf() getwc() getwchar()
iswalnum() iswalpha() iswcntrl() iswctype() iswdigit()
iswgraph() iswlower() iswprint() iswpunct() iswspace()
iswupper() iswxdigit() localeconv() mblen() mbrlen()
mbrtowc() mbsinit() mbsrtowcs() mbstowcs() mbtowc()
putwc() putwchar() setlocale() strftime() swprintf()
swscanf() towctrans() towlower() towupper() ungetwc()
vfwprintf() vswprintf() vwprintf() wcrtomb() wcscat()
wcschr() wcscmp() wcscoll() wcscpy() wcscspn()
wcsftime() wcslen() wcsncat() wcsncmp() wcsncpy()
wcspbrk() wcsrchr() wcsrtombs() wcsspn() wcsstr()
wcstod() wcstok() wcstol() wcstombs() wcstoul()
wcsxfrm() wctob() wctomb() wctrans() wctype()
wmemchr() wmemcmp() wmemcpy() wmemmove() wmemset()
wprintf() wscanf()
Table 3-2 C language headers
Conforming implementations shall provide the internationalization
functions listed in the Table 3-3 and headers listed in the Table 3-4.
The specifications of the functions and the definitions of the headers
shall conform to [XSH5].
Table 3-3 Additional C Language internationalization functions
catclose() catgets() catopen()
iconv() iconv_close() iconv_open()
nl_langinfo() strfmon() strptime()
wcswidth() wcwidth()
Table 3-4 Additional C language headers
Conforming implementations may provide the gettext message handling
function which is specified in Annex C: Publicly Available Specifications.
Conforming level 1 implementations should support
the POSIX regular expression functions listed in the Table 3-5
and the header .
The specifications of the functions and the definitions of the header
should conform to [XSH5].
Table 3-5 POSIX regular expression functions
regcomp() regexec() regerror() regfree()
Conforming implementations shall provide the application execution
environment in which the internationalized applications (written
by using the internationalization functions above) can behave
appropriately depending on the value of Environment Variables,
without requiring any change of the applications.
See Annex A: Environment Variables for the environment variables
to which internationalization functions will refer.
Conforming implementations shall support the application execution
environments specified in Annex B.
Conforming level 2 implementations shall define
_XOPEN_CURSES version test macro and provide the internationalized
curses library functions which are specified in [XCURSES4.2].
Conforming level 2 implementations shall support Java Runtime
environment ([TBD]), Internationalization Component for Unicode
[ICU], and Perl execution environment [Perl 5.6] including Perl
interpreter and modules.
Note. The following Perl modules are related with Globalization.
(see http://www.perl.com/CPAN-local/modules/
00modlist.long.html#Part2-ThePerl5Mo)
Name Description
------------ --------------------------------------------
I18N::
∶:Charset Character set names and aliases
∶:Collate Locale based comparisons
∶:LangTags compare & extract language tags (RFC1766)
∶:WideMulti Wide and multibyte character string
Locale::
∶:Country ISO 3166 two letter country codes
∶:Date Month/weekday names in various languages
∶:Langinfo The API
∶:Language ISO 639 two letter language codes
∶:Msgcat Access to XPG4 message catalog functions
∶:PGetText What GNU gettext does, written in pure perl
∶:gettext Multilanguage messages
Unicode::
∶:String String manipulation for Unicode strings
∶:Map8 Convert between most 8bit encodings
(3) Implementation Examples
GNU C library version 2.2
[TBD]
(4) Future Direction
In the next version of this specification,
conforming implementations may be required to provide
POSIX regular expression functions and internationalized curses
library functions.
4. Graphic Libraries
(1) Scope
This chapter defines runtime library interfaces for graphical user interface
(GUI). Conforming implementations shall provide graphical user interface
defined by the X Window System Version 11 Release 6 [X11R6].
(2) Requirements
The confirming implementation shall provide the API for
following functions:
- Locale
setlocale()
XSupportsLocale()
XSetLocaleModifiers()
- Internationalized Text Drawing
XCreateFontSet() -- not recommended (use XOpenOM/XCreateOC)
XFreeFontSet()
XFontsOfFontSet()
XBaseFontNameListOfFontSet()
XLocaleOfFontSet()
XContextDependentDrawing()
XExtentsOfFontSet()
XmbTextEscapement()
XwcTextEscapement()
XmbTextExtents()
XwcTextExtents()
XmbTextPerCharExtents()
XwcTextPerCharExtents()
XmbDrawString()
XwcDrawString()
XmbDrawImageString()
XwcDrawImageString()
XmbDrawText()
XwcDrawText()
- X Output Methods -- X11R6 Extension
XOpenOM()
XCloseOM()
XDisplayOfOM()
XLocaleOfOM()
XSetOMValues()
XGetOMValues()
XCreateOC()
XDestroyOC()
XOMOfOC()
XSetOCValues()
XGetOCValues()
- Resource Management
XrmInitialize()
XrmLocaleOfDatabase()
XrmParseCommand()
XResourceManagerString()
XScreenResourceString()
XrmGetFileDatabase()
XrmGetStringDatabase()
XrmMergeDatabases()
XrmCombineDatabase()
XrmCombineFileDatabase()
XrmGetDatabase()
XrmSetDatabase()
XrmGetResource()
XrmEnumerateDatabase()
XrmPutResource()
XrmPutStringResource()
XrmPutLineResource()
XrmPutFileDatabase()
XrmDestroyDatabase()
XrmPermStringToQuark()
XrmQGetResource()
XrmQGetSearchList()
XrmQGetSearchResource()
XrmQPutResource()
XrmQPutStringResource()
XrmQuarkToString()
XrmStringToBindingQuarkList()
XrmStringToQuark()
XrmStringToQuarkList()
XrmUniqueQuark()
- Inter-Client Communication
XmbTextListToTextProperty()
XwcTextListToTextProperty()
XmbTextPropertyToTextList()
XwcTextPropertyToTextList()
XFreeStringList()
XwcFreeStringList()
XmbSetWMProperties()
XSetWMProperties()
XSetWMName()
XSetWMIconName()
- X Input Methods -- Internationalized Text Input
XOpenIM()
XCloseIM()
XDisplayOfIM()
XLocaleOfIM()
XSetIMValues()
XGetIMValues()
XCreateIC()
XVaCreateNestedList()
XDestroyIC()
XIMOfIC()
XSetICValues()
XGetICValues()
XSetICFocus()
XUnsetICFocus()
XmbResetIC()
XwcResetIC()
XFilterEvent()
XmbLookupString()
XwcLookupString()
XRegisterIMInstantiateCallback()
XUnregisterIMInstantiateCallback()
Conforming level 2 implementations shall support languages listed in
Annex B. Conforming level 1 implementations need not to support
languages that require complex text layout (ar_*, he_IL, iw_IL, th_TH,
and *_IN).
(3) Implementation Examples
The following implementation examples are available
for this category.
[#1] X11R6.3 or later
http://www.x.org
[#2] XFree86 3.3 or later
http://www.xfree86.org
(4) Future Direction
In the next version of this specification, Unicode, BiDi
(bidirectional text), and vertical writing will become requirement.
5. Shells and Utilities
(1) Scope
This chapter defines runtime environment required to support traditional
UNIX command interpreter called "shell" and other basic utilities defined
by [POSIX.2].
(2) Requirements
- Shell implementation
Conforming level 2 implementations shall be able to use at least,
UTF-8 encoding as filename.
The globbing functionality of the shell shall be internationalized as
defined in [POSIX.2].
Conforming implementations shall provide a shell that supports the
functionalities of "Bourne shell", with internationalization
capabilities defined above.
- The utilities implementation
Conforming level 1 implementations shall determine the message
catalogue, printing date format and sorting order according to the
environment variables listed in Annex A.
(a) Locale
Conforming implementations shall provide the following utilities
to generate and refer locale definitions as specified in [XCU5]:
gencat locale localedef
(b) Text Editor
Conforming implementations shall provide the following utilities
to edit text files encoded in the supported locale as specified in [XCU5].
ed ex vi
(c) Date and Time formatting
Conforming implementations shall provide the following utilities
to display locale-specific date and time formats as specified in [XCU5]:
at cal cpio date lp lpstat ls patch ps tar
time uucp uustat
(d) Text Processing
Conforming implementations shall provide the following utilities
to process text as specified in [XCU5].
comm cxref diff egrep expand fgrep fold
getopts grep iconv join less mailx man
nm (symbol sorting order) od (floating point) pr
printf sed sort tr unexpand uniq wc
(e) Regular Expressions
On conforming level 2 implementations, utilities that process
regular expressions shall support Basic Regular Expression
(BRE) and Extended Regular Expression (ERE) as specified in
[POSIX.2].
On conforming level 1 implementations, utilities that process
regular expressions should support BRE and ERE as specified in
[POSIX.2]. If an implementation is not able to support BRE
and ERE, it may support the regular expression syntax defined in
re_comp() of [XSH5] instead of BRE and the regular expression
syntax defined in regcmp() of [XSH5] instead of ERE.
The following utilities are relevant:
egrep fgrep grep perl sed awk
(f) Filename Handling
Conforming implementations shall provide the following utilities
to correctly handle filenames beyond those in Portable Filename
Character Set.
cpio find tar
(g) General Text Editor
Conforming implementations shall support at least one text editor
that can handle text which is encoded in UTF-8.
(h) Terminal Emulator
Conforming implementations shall support terminal emulator that
can handle character encoding schemes for supporting locales.
Conforming implementations should support terminal emulator
that works every supporting locale, but the implementation
may support different terminal emulator per locale.
[*** Editor's note: msgfmt(1), xgettext(1) will be added. ***]
(3) Implementation Examples
Examples of level 1 implementation
GNU bash
GNU textutils
GNU shellutils
GNU fileutils
GNU emacs
kterm, kon, etc.
(4) Future Direction
none
6. Programming Languages
(1) Scope
This chapter defines the requirements for various programming languages.
Note that the specifications defined by this chapter shall be provided
by conforming implementations if Software Development Option is supported.
(2) Requirements
Conforming level 2 implementations shall support the
compiler or interpreter for the following languages:
- C/C++
- Perl
- Java
Each programming language shall be internationalized as specified in
the following specifications:
- C language as specified in [ISO C]
- C++ language as specified in [ISO C++]
- Perl language as specified in [Perl 5.6]
- Java language as specified in [Java]
Note: See 3. Base Libraries about runtime environment
of Perl and Java languages.
(3) Implementation Examples
The following implementation examples are available for these
languages:
[#1] C/C++: GNU Compiler Collection
- http://www.gnu.org/software/gcc/gcc.html
[#2] C/C++: Fortran & C Package (Linux)
C++ Package (Linux)
Fujitsu Kyushu System Engineering Limited (in Japan)
http://www.fqs.co.jp/fort-c/
Fujitsu C/C++ Express (Linux)
Fujitsu Fortran Express (Linux)
Fujitsu America Inc. (in US)
http://www.tools.fujitsu.com/
[#3] Perl:
- http://www.perl.com/pub/n/Perl_5.6.0_is_out!
[#4] Java: Java env.(from Hiura-san)
(4) Future Directions
None
7. Graphic Toolkit and X Window Server
(1) Scope
This chapter defines the requirements for graphic toolkit supported on
top of the X Window System and the X Window System server.
(2) Requirements
Graphic Toolkit
There are no requirements on the Graphic Toolkit
in terms of internationalization.
X Window Server
Conforming implementations shall support X11R6-based X server
and font server which support TrueType fonts.
(3) Implementation Examples
The following implementation examples are available
for this category.
[Graphic Toolkit]
GTK+
http://www.gtk.org
Qt
http://www.troll.no/products/qt.html
[X Window Server]
X TrueType Server(X-TT)
http://X-TT.dsl.gr.jp/index.html
XFree86 3.3.6
(4) Future Directions
None
8. Input Method
(1) Scope
This chapter defines the requirements for text input used by the X Window
System and other environments. Such mechanism is needed to support
non-Western languages (for example, Chinese, Japanese and Korean).
(2) Requirements
Conforming implementations shall provide means, i.e., Input
Method(s) for user to input characters specified in the
Annex B: Supported locales and character encoding schemes.
Conforming implementations shall provide X Input Method
Server(s) which can connect with Input Method Engines of
the supporting locales.
Conforming implementations shall support Input Method
Engines for the supporting locales, that can be connected
with the above Input Method Server(s). The conforming
implementations shall document which Input Method Engines
are supported by the above X Input Method Server(s) and
how user can get and install the Engines into the conforming
implementations.
The X Input Method Server(s) should have a
capability to switch Input Method Engines dynamically,
but a conforming implementation may provide multiple
Input Method Servers per locale.
Conforming level 1 implementations should provide
an X Input Method Server which supports UTF-8 encoding
and allows user to input whole repertoire of Unicode 3.0.
Conforming level 2 implementations shall provide
an X Input Method Server which supports UTF-8 encoding
and allows user to input whole repertoire of Unicode 3.0.
Conforming implementations may provide X Input
Method Server(s) which supports locale specific
character repertoire and locale specific
character encodings.
Every application that has X Windows system based GUI and
has a capability to accept character input from users
shall have the interface with the above X Input Method
Server(s).
Conforming implementations should provide means
for user to input characters specified in the supporting
locale through Console and TTY device interfaces.
(3) Implementation Examples
X Input Method Servers: IIIMF, kinput2, Xwnmo etc.
(4) Future Direction
In the next version of this specification,
the recommendation of single X Input Method Server
which can switch Input Method Engines dynamically
will become mandatory requirement.
In the next version of this specification,
the recommendation for conforming level 1 implementations
regarding the X Input Method Server(s) which support
UTF-8 encoding will become mandatory requirement.
9. Output Method
(1) Scope
This chapter defines the requirements for text output used by the X Window
System. Such mechanism is needed to support languages that require
complex text rendering.
(2) Requirements
Conforming implementations shall provide means, i.e., Output
Method(s), for user to output characters specified in the
Annex B: Supported locales and character encoding schemes.
Conforming implementations shall provide X Output Method
interface defined in X11R6 Xlib specification chapter 13 as a
displaying primitive for X Window System.
Conforming implementations shall provide multibyte and
wide character interface which cover Unicode 3.0 repertoire.
Conforming implementations should provide
an X Output Method which supports the encoding schemes
listed in Annex B and UTF-32.
Conforming implementations shall provide a terminal
emulator on X Window System that output characters in the
supported locale.
Conforming implementations should provide console or
tty device interface that output characters in the supported
locale.
(3) Implementation Examples
X11R6.4 Xlib, IIIMXCF
(4) Future Direction
None
10. Network Servers
(1) Scope
This chapter defines the requirements for various network servers, such as
file sharing servers, WWW servers, etc.
The requirements on the following kinds of servers will be
discussed in this section.
- NetBios over TCP/IP
- AppleTalk
- Network File System
- HTTP Server
(2) Requirements
This version of this standard has no requirements for the Network
Servers.
(3) Implementation Examples
None
(4) Future Directions
In the next version of this specification, the requirements on the handling
of names, e.g., filename, domain name, resource name, and user name, will be
specified in this section.
11. Internet Tools
(1) Scope
This chapter defines the requirements for Internet client tools, such as
WWW browsers and Mail User Agents (MUAs).
(2) Requirements
Conforming implementations shall make at least one character encoding scheme
available per locale specified in Annex B.
The supported character encoding scheme should be in IANA registry
and dominant in the supported locales.
Conforming level 2 implementations of Web browsers and mail user agents
shall be able to input and output whole repertoire of Unicode 3.0.
(3) Implementation Examples
The following implementation examples are available
for this category.
Mozilla
http://www.mozilla.org
(4) Future Direction
None
12. X Clients
(1) Scope
This chapter defines the requirements for the X Window System clients,
including window managers.
(2) Requirements
Conforming level 2 implementations shall support a text editor that
can handle full repertoire of UTF-8. Conforming level 1 implementations
need not support languages that require complex text layout.
Conforming implementations shall provide a terminal emulator on the
X Window System that output characters specified in the supported locale.
(3) Implementation Examples
kterm, rxvt-ml, etc.
(window managers: twm, vtwm, fvwm2, mwm, etc.)
(4) Future Direction
None
Annex A (Normative): Environment Variables
Conforming implementations shall provide the following environment
variables that are relevant to the operation of internationalized
interfaces or internationalized commands and utilities.
LANG
LC_ALL
LC_COLLATE
LC_CTYPE
LC_MESSAGES
LC_MONETARY
LC_NUMERIC
LC_TIME
NLSPATH
The usage and the semantics of these environment variables shall
be the same as the description in "6.2 Internationalisation
Variables" in [XBD5].
Annex B (Normative): Support locales and character encoding schemes
Conforming implementations shall provide the following locales.
C
POSIX
Conforming implementations shall support the following locales.
Note 1. The language names come from ISO/IEC 639-1.
Note 2. The region/country names come from ISO/IEC 3166-1.
ar_AE Arabic UNITED ARAB EMIRATES
ar_BH BAHRAIN
ar_DZ ALGERIA
ar_EG EGYPT
ar_IQ IRAQ
ar_JO JORDAN
ar_KW KUWAIT
ar_LB LEBANON
ar_LY LIBYAN ARAB JAMAHIRIYA
ar_MA MOROCCO
ar_OM OMAN
ar_QA QATAR
ar_SA SAUDI ARABIA
ar_SD SUDAN
ar_SY SYRIAN ARAB REPUBLIC
ar_TN TUNISIA
ar_YE YEMEN
be_BY Byelorussian BELARUS
bg_BG Bulgarian BULGARIA
ca_ES Catalan SPAIN
cs_CZ Czech CZECH REPUBLIC
da_DK Danish DENMARK
de_AT German AUSTRIA
de_CH SWITZERLAND
de_DE GERMANY
de_LU LUXEMBOURG
el_GR Greek GREECE
en_AU English GREECE
en_BE BELGIUM
en_CA CANADA
en_GB UNITED KINGDOM
en_IE IRELAND
en_NZ NEW ZEALAND
en_US UNITED STATES
en_ZA SOUTH AFRICA
es_AR Spanish ARGENTINA
es_BO BOLIVIA
es_CL CHILE
es_CO COLOMBIA
es_CR COSTA RICA
es_DO DOMINICAN REPUBLIC
es_EC ECUADOR
es_ES SPAIN
es_GT GUATEMALA
es_HN HONDURAS
es_MX MEXICO
es_NI NICARAGUA
es_PA PANAMA
es_PE PERU
es_PR PUERTO RICO
es_PY PARAGUAY
es_SV SYRIAN ARAB REPUBLIC
es_UY URUGUAY
es_VE VENEZUELA
et_EE Estonian ESTONIA
fi_FI Finnish FINLAND
fr_BE French BELGIUM
fr_CA CANADA
fr_CH SWITZERLAND
fr_FR FRANCE
fr_LU LUXEMBOURG
he_IL Hebrew ISRAEL
hr_HR Croatian CROATIA
hu_HU Hungarian HUNGARY
is_IS Icelandic ICELAND
it_CH Italian SWITZERLAND
it_IT ITALY
iw_IL Hebrew ISRAEL ** An alias of he_IL **
ja_JP Japanese JAPAN
ko_KR Korean KOREA, REPUBLIC OF
lt_LT Lithuanian LITHUANIA
lv_LV Lativian, Lettish LATVIA
mk_MK Macedonian MACEDONIA, THE FORMER YUGOSLAV REPUBLIC OF
nl_BE Dutch BELGIUM
nl_NL NETHERLANDS
no_NO Norwegian NORWAY
pl_PL Polish POLAND
pt_BR Portuguese BRAZIL
pt_PT PORTUGAL
ro_RO Romanian ROMANIA
ru_RU Russian RUSSIAN FEDERATION
sh_YU Serbo-Croatian YUGOSLAVIA
sk_SK Slovak SLOVAKIA
sl_SI Slovenian SLOVENIA
sq_AL Albanian ALBANIA
sr_YU Serbian YUGOSLAVIA
sv_SE Swedish SWEDEN
th_TH Thai THAILAND
tr_TR Turkish TURKEY
uk_UA Ukrainian UKRAINE
vi_VN Vietnamese VIETNAM
zh_CN Chinese CHINA
zh_HK HONG KONG
zh_TW TAIWAN, PROVINCE OF CHINA
ar_IN Arabic INDIA
as_IN Assamese INDIA
bn_IN Bengali INDIA
fa_IN Persian INDIA
gu_IN Gujarati INDIA
hi_IN Hindi INDIA
kn_IN Kannada INDIA
ks_IN Kashmiri INDIA
ml_IN Malayalam INDIA
or_IN Oriya INDIA
pa_IN Punjabi INDIA
sd_IN Sindhi INDIA
ps_IN Pashto, Pushto INDIA
ta_IN Tamil INDIA
te_IN Telugu INDIA
ur_IN Uldu INDIA
Conforming implementations shall make at least UTF-8 coded
character set usable under the above locale environments.
Conforming implementations also may make the following
character encoding schemes usable under some of the above
locale environments.
ISO/IEC 8859-1
ISO/IEC 8859-2
ISO/IEC 8859-5
ISO/IEC 8859-7
ISO/IEC 8859-9
ISO/IEC 8859-13
ISO/IEC 8859-15
Korean EUC
Japanese EUC
Simplified Chinese EUC
Traditional Chinese EUC
Annex C (Normative): Publicly Available Specification
C.1 gettext message handling functions
[Editor's Note:
The following is the reference page for SunOS's gettext.
This will be modified appropriately later.]
-----------------------------------------------------------------------
C Library Functions gettext(3C)
NAME
gettext, dgettext, dcgettext, textdomain, bindtextdomain -
message handling functions
SYNOPSIS
#include
char *gettext(const char *msgid);
char *dgettext(const char *domainname, const char *msgid);
char *textdomain(const char *domainname);
char *bindtextdomain(const char *domainname, const char
*dirname);
#include
#include
char *dcgettext(const char *domainname, const char *msgid,
int category);
DESCRIPTION
The gettext(), dgettext(), and dcgettext() functions attempt
to retrieve a target string based on the specified msgid
argument within the context of a specific domain and the
current locale. The length of strings returned by gettext(),
dgettext(), and dcgettext() is undetermined until the func-
tion is called. The msgid argument is a null-terminated
string.
The NLSPATH environment variable (see environ(5)) is
searched first for the location of the LC_MESSAGES catalo-
gue. The setting of the LC_MESSAGES category of the current
locale determines the locale used by gettext() and dget-
text() for string retrieval. The category argument deter-
mines the locale used by dcgettext(). If NLSPATH is not
defined and the current locale is "C", gettext(), dget-
text(), and dcgettext() simply return the message string
that was passed. In a locale other than "C", if NLSPATH is
not defined or if a message catalogue is not found in any of
the components specified by NLSPATH, the routines search for
the message catalogue dirname/locale/category/domainname.mo,
after querying bindtextdomain() for dirname.
For gettext(), the domain used is set by the last valid
call to textdomain(). If a valid call to textdomain() has
not been made, the default domain (called messages) is
used.
For dgettext() and dcgettext(), the domain used is specified
by the domainname argument. The domainname argument is
equivalent in syntax and meaning to the domainname argument
to textdomain(), except that the selection of the domain is
valid only for the duration of the dgettext() or dcgettext()
function call.
The textdomain() function sets or queries the name of the
current domain of the active LC_MESSAGES locale category.
The domainname argument is a null-terminated string that can
contain only the characters allowed in legal filenames.
The domainname argument is the unique name of a domain on
the system. If there are multiple versions of the same
domain on one system, namespace collisions can be avoided by
using bindtextdomain(). If textdomain() is not called, a
default domain is selected. The setting of domain made by
the last valid call to textdomain() remains valid across
subsequent calls to setlocale(3C), and gettext().
The domainname argument is applied to the currently active
LC_MESSAGES locale.
The current setting of the domain can be queried without
affecting the current state of the domain by calling
textdomain() with domainname set to the null pointer. Cal-
ling textdomain() with a domainname argument of a null
string sets the domain to the default domain (messages).
The bindtextdomain() function binds the path predicate for a
message domain domainname to the value contained in dirname.
For gettext(), the domain used is set by the last valid
call to textdomain(). If a valid call to textdomain() has
not been made, the default domain (called messages) is
used.
For dgettext() and dcgettext(), the domain used is specified
by the domainname argument. The domainname argument is
equivalent in syntax and meaning to the domainname argument
to textdomain(), except that the selection of the domain is
valid only for the duration of the dgettext() or dcgettext()
function call.
The textdomain() function sets or queries the name of the
current domain of the active LC_MESSAGES locale category.
The domainname argument is a null-terminated string that can
contain only the characters allowed in legal filenames.
The domainname argument is the unique name of a domain on
the system. If there are multiple versions of the same
domain on one system, namespace collisions can be avoided by
using bindtextdomain(). If textdomain() is not called, a
default domain is selected. The setting of domain made by
the last valid call to textdomain() remains valid across
subsequent calls to setlocale(3C), and gettext().
The domainname argument is applied to the currently active
LC_MESSAGES locale.
The current setting of the domain can be queried without
affecting the current state of the domain by calling
textdomain() with domainname set to the null pointer. Cal-
ling textdomain() with a domainname argument of a null
string sets the domain to the default domain (messages).
The bindtextdomain() function binds the path predicate for a
message domain domainname to the value contained in dirname.
If domainname is a non-empty string and has not been bound
previously, bindtextdomain() binds domainname with dir-
name.
If domainname is a non-empty string and has been bound pre-
viously, bindtextdomain() replaces the old binding with
dirname. The dirname argument can be an absolute or relative
pathname being resolved when gettext(), dgettext(), or
dcgettext() are called. If domainname is a null pointer or
an empty string, bindtextdomain() returns NULL. User
defined domain names cannot begin with the string SYS_.
Domain names beginning with this string are reserved for
system use.
RETURN VALUES
The individual bytes of the string returned by gettext(),
dgettext(), or dcgettext() can contain any value other than
null. If msgid is a null pointer, the return value is unde-
fined. The string returned must not be modified by the pro-
gram, and can be invalidated by a subsequent call to get-
text(), dgettext(), dcgettext() , or setlocale(3C). If the
domainname argument to dgettext() or dcgettext() is a null
pointer, the results are undefined.
If the target string cannot be found in the current locale
and selected domain, gettext(), dgettext(), and dcgettext()
return msgid.
The normal return value from textdomain() is a pointer to a
string containing the current setting of the domain. If
domainname is a null pointer, textdomain() returns a pointer
to the string containing the current domain. If textdomain()
was not previously called and domainname is a null string,
the name of the default domain is returned. The name of the
default domain is messages.
The return value from bindtextdomain() is a null-terminated
string containing dirname or the directory binding associ-
ated with domainname if dirname is NULL. If no binding is
found, the default return value is /usr/lib/locale. If
domainname is a null pointer or an empty string,
bindtextdomain() takes no action and returns a null pointer.
The string returned must not be modified by the caller.
USAGE
These routines impose no limit on message length. However, a
text domainname is limited to TEXTDOMAINMAX (256) bytes.
The gettext(), dgettext(), dcgettext(), textdomain(), and
bindtextdomain() can be used safely in multithreaded appli-
cations, as long as setlocale(3C) is not being called to
change the locale.
FILES
/usr/lib/locale
The default path predicate for message domain
files.
/usr/lib/locale/locale/LC_MESSAGES/domainname.mo
system default location for file containing mes-
sages for language locale and domainname
/usr/lib/locale/locale/LC_XXX/domainname.mo
system default location for file containing mes-
sages for language locale and domainname for
dcgettext() calls where LC_XXX is LC_CTYPE,
LC_NUMERIC, LC_TIME, LC_COLLATE, LC_MONETARY, or
LC_MESSAGES.
dirname/locale/LC_MESSAGES/domainname.mo
location for file containing messages for domain
domainname and path predicate dirname after a suc-
cessful call to bindtextdomain()
dirname/locale/LC_XXX/domainname.mo
location for files containing messages for domain
domainname, language locale, and path predicate
dirname after a successful call to
bindtextdomain() for dcgettext() calls where
LC_XXX is one of LC_CTYPE, LC_NUMERIC, LC_TIME,
LC_COLLATE, LC_MONETARY, or LC_MESSAGES.
** Editor's note ** specification of msgfmt(1), xgettext(1) will be added.
------------------------------------------------------------
Annex D (Informative): Base Components
A) Conforming implementations shall provide the following interfaces
and commands besides internationalized interfaces and commands in
chapter 3-11.
** System Interfaces:
Conforming implementations shall provide the C functions and headers
which are defined in POSIX.1 [ISO/IEC 9945-1:1990], see document #1.
** Commands and Utilities:
[A] ar, at, arch[*], arp[*]
basename, batch, bzip2[*], bunzip2[*], bzip2recover[*]
[C] cat, cd, chgrp, chmod, chown, cmp, col, comm, compress, cp,
cpio, csplit, cu, cut, chroot[*]
[D] date, dd, delta, df, diff, dirname, du, diff3[*], domainname[*],
dircmp
[E] echo, expand, expr
[F] false, file, fuser, ftp[BSD]
[G] getopts, gzip[*], gunizip[*], getconf
[H] head, hostname[*], hash
id, ipcrm, ipcs, ifconfig[*], imake
[J] join
[K] kill, killall[*]
[L] ln, logger, logname, ls, ldd[*]
[M] make, mkdir, mkfifo, mv, mount[*], m4, mailx, mkswap[*],
mkfs[*],
[N] nice, nl, nohup, netstat[*], nslookup[*], newgrp, nm
[O] od
[P] paste, patch, pathchk, printf, ps, pwd, ping[*],
[R] read, renice, rm, rmdir, reboot[*]
[S] sleep, spell, split, strings, strip, sum,
shar[BSD], su[BSD], shutdown[*]
[T] tabs, tail, tar, tee, test, time, touch, tr, true, tty, type,
telnet[*], talk, tput, tsort
[U] umask, uname, uncompress, unexpand, uniq, unlink,
unpack, uudecode, uuencode, umount[*]
[V] val
[W] wait, wc, who
[X] xargs
[Z] zcat
The usage and the semantics of these commands without [*] be the
same as the description in the document #2, ones with [BSD] be in #4
and ones with [*] be in ...
B) Furthermore, conforming implementations should support the
following commands and protocols.
** Commands and Utilities:
[A] alias, admin (SCCS), asa
bc, bg
[C] cal, crontab, clear[*], calendar, cancel, cflow, cksum, command,
ctags, cxref
[D] dis, fc
[E] env
[F] fg, fort77
[G] get(SCCS)
[J] jobs
[L] lex, lpr[BSD], lpq[BSD], lprm[BSD], lpc[BSD], less[*], line,
link, lint, lp, lpstat
[M] more, mesg
[P] passwd[BSD], pack, pcat, pax, pg, pr, prs(SCCS)
[R] rmdel(SCCS)
[S] stty, sact(SCCS), sccs(SCCS)
[T] tclsh[#3]
[U] unalias, uumerge[*], ulimit, unget(SCCS), uucp, uulog, uuname,
uupick, uustat, uuto, uux
[W] wish[#3], write, what(SCCS)
[Y] yacc
The usage and the semantics of commands without [*] be the same as
the description in the document #2, ones with [#3] be in the
document #3, ones with [BSD] be in #4, and ones with [*] be in ...
** Protocols:
Conforming implementations should support the protocols which are
defined in the following RFC
specifications(http://www.rfc-editor.org/):
- ICMP (Internet Control Message Protocol): RFCs 792 and 950
- SMTP (Simple Mail Transfer Protocol): RFCs 821, 822, 1123 and 2045-2049
- FTP (File Transfer Protocol): RFCs 959, 2228 and 2640
- TELNET: RFCs 854, 855, 856, 857, 858, 859, 860 and 861
- DNS (Domain Naming System): RFCs 974, 1034, 1035, 1101, 1183, 1706,
1982, 1995, 1996, 2136, 2137, 2181, 2308 and 2535
- LPD (Line Printer Daemon Protocol): RFC 1179
- POP3 (Post Office Protocol - Version 3): RFCs 1939, 1957 and 2449
C) Furthermore, conforming implementations may support the following
commands.
** Commands and Utilities:
[D] depmod[*]
ipchains[*], ipmasqadm[*], insmod[*]
[K] kerneld[*], ksyms[*]
[L] lilo[*], loadkeys[*], lsmod[*]
[M] modprobe[*]
[R] rmmod[*], rdev[*]
[T] tac[*]
The usage and the semantics of these commands be the same as the
description in ...
[#1] ISO/IEC 9945-1:1990 Information Technology -- Portable
Operating System Interface (POSIX) -- Part 1: System
Application Program Interface (API) [C Language]
[#2] The Single UNIX Specification, Version 2:
- System Interface Definitions, Issue 5
- Commands & Utilities Issue 5
[#3] Tcl/Tk 8.3 (February 10, 2000)
- http://dev.scriptics.com/software/tcltk/8.3.tml
[#4] 4.4BSD User's Reference Manual
[#5] ...
Annex E (Informative): Informative References
[ISO 2022]
ISO/IEC 2022:1994 Information technology -- Character code
structure and extension techniques
ISO/IEC 2022:1994/Cor 1:1999
[ISO 6429]
ISO/IEC 6429:1992 Information technology -- Control functions
for coded character sets
[ISO 646]
ISO/IEC 646:1991 Information technology -- ISO 7-bit coded
character set for information interchange
[ISO 6937]
ISO/IEC 6937:1994 Information technology -- Coded graphic
character set for text communication -- Latin alphabet
[ISO 8859-1]
ISO/IEC 8859-1:1998 Information technology -- 8-bit single-byte
coded graphic character sets -- Part 1: Latin alphabet No. 1
[ISO 8859-2]
ISO/IEC 8859-2:1999 Information technology -- 8-bit single-byte
coded graphic character sets -- Part 2: Latin alphabet No. 2
[ISO 8859-3]
ISO/IEC 8859-3:1999 Information technology -- 8-bit single-byte
coded graphic character sets -- Part 3: Latin alphabet No. 3
[ISO 8859-4]
ISO/IEC 8859-4:1998 Information technology -- 8-bit single-byte
coded graphic character sets -- Part 4: Latin alphabet No. 4
[ISO 8859-5]
ISO/IEC 8859-5:1999 Information technology -- 8-bit single-byte
coded graphic character sets
[ISO 8859-6]
ISO/IEC 8859-6:1999 Information technology -- 8-bit single-byte
coded graphic character sets -- Part 6: Latin/Arabic alphabet
[ISO 8859-7]
ISO 8859-7:1987 Information processing -- 8-bit single-byte coded
graphic character sets -- Part 7: Latin/Greek alphabet
[ISO 8859-8]
ISO/IEC 8859-8:1999 Information technology -- 8-bit single-byte
coded graphic character sets -- Part 8: Latin/Hebrew alphabet
[ISO 8859-9]
ISO/IEC 8859-9:1999 Information technology -- 8-bit single-byte
coded graphic character sets -- Part 9: Latin alphabet No. 5
[ISO 8859-10]
ISO/IEC 8859-10:1998 Information technology -- 8-bit single-byte
coded graphic character sets -- Part 10: Latin alphabet No. 6
[ISO 8859-13]
ISO/IEC 8859-13:1998 Information technology -- 8-bit single-byte
coded graphic character sets -- Part 13: Latin alphabet No. 7
[ISO 8859-14]
ISO/IEC 8859-14:1998 Information technology -- 8-bit single-byte
coded graphic character sets -- Part 14: Latin alphabet No. 8 (Celtic)
[ISO 8859-15]
ISO/IEC 8859-15:1999 Information technology -- 8-bit single-byte coded
graphic character sets -- Part 15: Latin alphabet No. 9
[PPP-I18N]
RFC 2484 PPP LCP Internationalization Configuration Option. G. Zorn.
January 1999. (Format: TXT=8330 bytes) (Updates RFC2284, RFC1994,
RFC1570) (Status: PROPOSED STANDARD)
[IETF-Charset]
RFC 2277 IETF Policy on Character Sets and Languages. H. Alvestrand.
January 1998. (Format: TXT=16622 bytes) (Also BCP0018) (Status: BEST
CURRENT PRACTICE)
[IANA-Charset]
RFC 2278 IANA Charset Registration Procedures. N. Freed, J. Postel.
January 1998. (Format: TXT=18881 bytes) (Also BCP0019) (Status: BEST
CURRENT PRACTICE)
[MIME-Parameter]
RFC 2231 MIME Parameter Value and Encoded Word Extensions: Character Sets,
Languages, and Continuations. N. Freed, K. Moore. November 1997.
(Format: TXT=19280 bytes) (Obsoletes RFC2184) (Updates RFC2045,
RFC2047 RFC2183) (Status: PROPOSED STANDARD)
[RFC 2130]
RFC 2130 The Report of the IAB Character Set Workshop held 29 February - 1
March, 1996. C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R.
Atkinson, M. Crispin, P. Svanberg. April 1997. (Format: TXT=63443
bytes) (Status: INFORMATIONAL)
[HTML-I18N]
RFC 2070 Internationalization of the Hypertext Markup Language. F.
Yergeau, G. Nicol, G. Adams, M. Duerst. January 1997. (Format:
TXT=91887 bytes) (Status: PROPOSED STANDARD)
[MIME]
RFC 2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of
Internet Message Bodies. N. Freed & N. Borenstein. November 1996.
(Format: TXT=72932 bytes) (Obsoletes RFC1521, RFC1522, RFC1590)
(Updated by RFC2184, RFC2231) (Status: DRAFT STANDARD)
RFC 2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media
Types. N. Freed & N. Borenstein. November 1996. (Format: TXT=105854
bytes) (Obsoletes RFC1521, RFC1522, RFC1590) (Updated by RFC2646)
(Status: DRAFT STANDARD)
RFC 2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message
Header Extensions for Non-ASCII Text. K. Moore. November 1996.
(Format: TXT=33262 bytes) (Obsoletes RFC1521, RFC1522, RFC1590)
(Updated by RFC2184, RFC2231) (Status: DRAFT STANDARD)
RFC 2048 Multipurpose Internet Mail Extensions (MIME) Part Four:
Registration Procedures. N. Freed, J. Klensin & J. Postel. November
1996. (Format: TXT=45033 bytes) (Obsoletes RFC1521, RFC1522, RFC1590)
(Also BCP0013) (Status: BEST CURRENT PRACTICE)
RFC 2049 Multipurpose Internet Mail Extensions (MIME) Part Five:
Conformance Criteria and Examples. N. Freed & N. Borenstein. November
1996. (Format: TXT=51207 bytes) (Obsoletes RFC1521, RFC1522, RFC1590)
(Status: DRAFT STANDARD)
[LANG-TAG]
RFC 1766 Tags for the Identification of Languages. H. Alvestrand. March
1995. (Format: TXT=16966 bytes) (Status: PROPOSED STANDARD)
[MIME-BIDI]
RFC 1556 Handling of Bi-directional Texts in MIME. H. Nussbacher. December
1993. (Format: TXT=5602 bytes) (Status: INFORMATIONAL)
[Unicode-Language-tag]
RFC 2482 Language Tagging in Unicode Plain Text. K. Whistler, G. Adams.
January 1999. (Format: TXT=27800 bytes) (Status: INFORMATIONAL)
[UTF-16]
RFC 2781 UTF-16, an encoding of ISO 10646. P. Hoffman, F. Yergeau.
February 2000
※ 来源:·BBS 水木清华站 smth.org·[FROM: 166.111.214.121]
BBS水木清华站∶精华区