RFC 1815

Character Sets ISO-10646 and ISO-10646-J-1

📅 published July 1995, from ietf

RFC 1815: Character Sets ISO-10646 and ISO-10646-J-1 🎀

okay bestie, so RFC 1815 is from the Network Working Group 💖 It was written by Masataka Ohta of the Tokyo Institute of Technology, it's an Informational doc, and it's dated July 1995 ✨ The title block doesn't list anything it obsoletes or updates, so it's a standalone vibe 🦋

Status of this Memo 🌸

This memo gives info to the Internet community 💅 It does not specify an Internet standard of any kind, and distribution of it is unlimited 🫶

Abstract 💜

ISO 10646 is specified pretty well when it comes to European characters, but it's not so useful in a fully internationalized environment 🌍

To actually use ISO 10646 in practice, you need a lot of external profiling: restricting which characters are allowed, restricting how characters can combine, and adding language info 🧁

This memo covers that profiling and gives a charset name to each profiled version 📚

ngl, the results aren't that great even though everyone tried their hardest to make them as useful as possible 😭 So the charsets in here are only for reference, and using them for practical stuff is strongly discouraged 🚫

Introduction 🧚

This memo describes two text encoding schemes based on ISO 10646 [10646] ✨

ISO 10646 says too little about how text gets visualized, so to use it in practice you have to restrict the standard minimally and then add some profiling info 💅

For ISO 2022 [ISO2022] based national standards, the national standardization bodies provide enough profiling info. For ISO 10646, that profiling just isn't provided yet 🫠

Profiling ISO 10646 seriously changes which characters (or combinations of characters) can be displayed properly. So changing the profiling is as significant as adding new character sets to ISO 2022 🔥

It's impractical to support the entirety of ISO 10646, because new restrictions or profiling can always be added 🙃 So a client needs to know whether some restriction or profiling is being used before it can decide whether to display the body part. That's why you need to provide multiple charset names, one for each variation of ISO 10646 💖

For example, in Japan with Japanese Windows NT, only the Han characters already supported by MS Kanji code (mostly equivalent to JIS X 0208 [JISX0208]) can be displayed, because no other font pattern is commonly provided 🇯🇵

Another problem with Han characters in ISO 10646 is that, to display them at the quality needed for daily plain text processing in China/Japan/Korea, you need profiling info on which one of Chinese/Japanese/Korean the text is using. It should be noted that this makes multilingual mixed Chinese/Japanese/Korean text with ISO 10646 impractical 🙈

Also, [RFC1521] was unclear about how bi-directionality should be supported with "ISO-8859-6" and "ISO-8859-8". That got corrected by [RFC1556] 🔄 But it's still unclear how bi-directionality could be supported with ISO 10646, and there are too many ways to do it. So until some bi-directionality mechanism(s) becomes widely supported, you need to exclude characters for languages that require bi-directionality support from the minimal variation. It should be noted that, although ISO 10646 is meant to be free from long term states (apart from some profiling info), introducing bi-directionality with ISO 10646 does require long term states 😵‍💫

Combining characters cause problems too 🧩 In many countries where combining characters based on [ISO2022] are used, there are restrictions on how they're ordered [TIS]. Without that restriction, the result of combining is completely meaningless, and that's the current state of ISO 10646. So if one implementation allows some combination and another doesn't support it, communication between them is hard unless ISO 10646 is profiled to be the least common set of widely supported combinations. Again, until combination restrictions get developed for each language, you need to exclude characters for those languages from the minimal variation 💀

Conjoining characters may or may not be supported too, which requires another profiling 🫧

With all that in mind, this memo defines two variations of ISO 10646: "ISO-10646", the minimal basic variation, and "ISO-10646-J-1", the variation that could be useful in Japan 🎌

Finally, this memo by no means promotes using ISO 10646 on the Internet 🙅 Its use is strongly discouraged when other charsets can encode the same information. Families of ISO 10646 based charsets, like ISO 2022 based charsets, only form sets of mutually incompatible encoding systems. Unlike ISO 2022 based charsets [2022INT], they can't be merged together into a single worldwide charset 💔

Description of "ISO-10646" 📖

ISO-10646 is profiled to be the most basic part of the family of encodings based on ISO 10646. It contains the following minimal graphic characters 🧸

      collection number and name      positions      further restriction
      ------------------------------------------------------------------
      1 BASIC LATIN                   0020-007E
      2 LATIN-1 SUPPLEMENT            00A0-00FF

C0 and C1 control characters may also be used as specified in section 16 of ISO 10646 🎈

The text with "ISO-10646" encodes text in 16 bit big endian form 💫

Since no combining characters are included, "ISO-10646" can be used with applications at implementation level 1 🍓

Left-to-right directionality should be used ➡️

The encoding is implemented by Windows/NT 🪟

For practical communication, use of "ISO-10646" is discouraged. "ISO-8859-1" [RFC1345] should be used instead 🫶

Description of "ISO-10646-J-1" 🇯🇵

ISO-10646-J-1 is profiled to be useful for Japanese PC users who run the Japanese version of Windows/NT. It contains the following graphic characters 🎀

      collection number and name         positions  further restrictions
      ------------------------------------------------------------------
      1 BASIC LATIN                      0020-007E
      2 LATIN-1 SUPPLEMENT               00A0-00FF
      8 BASIC GREEK                      0370-03CF
      10 CYRILLIC                        0400-04FF
      32 GENERAL PUNCTUATION             2000-206F  See note 1, below.
      39 MATHEMATICAL OPERATORS          2200-22FF  See note 1, below.
      44 BOX DRAWING                     2500-257F
      49 CJK SYMBOLS AND PUNCTUATION     3000-303F  See note 1, below.
      50 HIRAGANA                        3040-309F
      51 KATAKANA                        30A0-30FF
      60 CJK UNIFIED IDEOGRAPHS          4E00-9FFF  See note 1, below.
      62 CJK COMPATIBILITY IDEOGRAPHS    F900-FAFF  See note 1, below.
      66 CJK COMPATIBILITY FORMS         FE30-FE4F
      69 HALFWIDTH AND FULLWIDTH FORMS   FF00-FFEF
Note 1: Most of the characters are excluded. Only the characters of JIS X 0208 [JISX0208] are included. The reason is that the Japanese version of Windows/NT only has fonts for those, and most users can't read messages containing other characters 🥺

C0 and C1 control characters may also be used as specified in section 16 of ISO 10646 🎈

The text with "ISO-10646-J-1" encodes text in 16 bit big endian form 💫

Shapes of Han characters should be of Japanese Han, meaning those in column "J" in section 26 of ISO 10646 🀄

Since no combining characters are included, "ISO-10646-J-1" can be used with applications at implementation level 1 🍓

Characters in "HALFWIDTH AND FULLWIDTH FORMS" are treated as different characters from the normal width characters 👀

When text is displayed horizontally, left-to-right directionality should be used ➡️

For practical communication, use of "ISO-10646-J-1" is discouraged. "ISO-2022-JP" [2022JP] should be used instead 🫶

MIME Considerations 📬

The names for the character encoding methods in this memo are, respectively, "ISO-10646" and "ISO-10646-J-1" 🏷️ This name is meant to be used in MIME messages like this:

                Content-Type: text/plain; charset=iso-10646

The ISO-10646 and ISO-10646-J-1 encodings are in 16-bit form, so it's often necessary to use a Content-Transfer-Encoding header. Base64 should be useful 🧪

The ISO-10646 and ISO-10646-J-1 may also be used in MIME Part 2 headers [RFC1522]. The "B" encoding should be used with them 💅

References 📚

  • [10646] International Organization for Standardization (ISO), "Universal Multiple-Octet Coded Character Set (UCS)", International Standard, Ref. No. ISO/IEC 10646-1:1993 (E).
  • [2022INT] (An Internet Draft "draft-ohta-text-encoding-*.txt" may be available).
  • [2022JP] Murai, J., Crispin, M., and E. van der Poel, "Japanese Character Encoding for Internet Messages", RFC 1468, June 1993.
  • [ISO2022] International Organization for Standardization (ISO), "Information processing -- ISO 7-bit and 8-bit coded character sets -- Code extension techniques", International Standard, Ref. No. ISO 2022-1986 (E).
  • [JISX0208] Japanese Standards Association, "Code of the Japanese graphic character set for information interchange", JIS X 0208-1990.
  • [RFC1345] Simonsen, K., "Character Mnemonics & Character Sets", RFC-1345, Rationel Almen Planlaegning, June 1992.
  • [RFC1521] Borenstein, N., and Freed, N., "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, September 1993.
  • [RFC1522] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522, September 1993.
  • [RFC1556] Nussbacher, H., "Handling of Bi-directional Texts in MIME" RFC 1556, Israeli Inter-University Computer Center, December 1993.
  • [TIS] Thai Industrial Standard for Thai Character Code for Computer, TIS 620-2533:1990.

Security Considerations 😱

Security issues are not discussed in this memo. Yes, you read that right. Nothing about security in here at all 🔐

Author's Address 🏠

   Masataka Ohta
   Tokyo Institute of Technology
   2-12-1, O-okayama, Meguro-ku,
   Tokyo 152, JAPAN

   Phone: +81-3-5499-7084
   Fax: +81-3-3729-1940
   EMail: mohta@cc.titech.ac.jp

That's the whole RFC, bestie! 🌈💖

📦 where this page comes from