日本語及び英語混在

JIS(G1) Kanji code system

漢字符号方式の紹介

The code extension technique applied in the document is based on ISO/IEC 2022.

This is same JIS X 0202(Code extension technique for information interchange).

1. Announcer assumed;
   ESC 02/0 04/4

2. ASCII characters(ISO/IEC 646) is designated into G0 set and the G0 set is invoked into the left side(column 2 to 7) of the code system,

   The following escape sequence is assumed;
   ESC 02/5 04/0
   where 04/0 : identifier of ISO/IEC 646.

3. JIS Kanji code(JIS X 0208-1997) is designated into G1 set and the G1 set is invoked into the right side (column 10 to 15) of the code system.

   The following escape sequences are assumed;
   ESC 02/6 04/0 ESC 02/4 02/9 04/2
   where ESC 02/06 04/0 : identifier for 1997 version of JIS 0208 code table,
   ESC 02/4 02/9 04/2 : designate the multibyte(02/4) code JIS X 0208(04/2) into G1 set(02/9).

ここでは，符号構成として，JIS(G1)漢字方式を採用しています。
これは，ISO/IEC 2022符号拡張方法に適合した方式で,符号表の
左側にASCII,右側に情報交換用漢字符号を呼び出したものです。
SGMLの構文によっても一意に解釈できます（JIS X 4151 文書記述
言語SGMLの表9参照)

Note: This code can be presented by Extended Unix Code(EUC) as a part of this code system. The difference among three coding techniques is as shown in the following table.

備考：この符号構成は,EUCで表示できます。
JIS(G1),JIS(G0),EUCの間の違いは，次のとおりです。

================================================================
    Type of code      JIS(G1)technique     ISO-2022-JP   EUC
----------------------------------------------------------------
     ASCII               G0 set            G0 set      G0 set
     JIS Kanji           G1 set            G0 set      G1 set
     JIS katanaka        none              none        G2 set
     JIS Hojyo-Kanji     (G3 set)if req    none        none
     User defined         none             none        G3 set
=================================================================

• ISO/IEC 646(IRV), but not JIS X 0201.
• JIS Kanji : JIS X 0208-1997 which was registered to ISO number 87.
• JIS Hojyo-Kanji : JIS X 0212(Escape final character=04/4).
• JIS katakana : JIS X 0201 table 3 (final character=04/9).
• User defined : character defined by user and/or systems.
• ISO-2022-JP : An international code system which conforms to
  ISO/IEC 2022 and JIS X 0208.
  A sample conversion from "Shiftjis" to "JIS code" is shown.

ここで，

• JIS Kanji : ISOに登録（登録番号：87)された情報
  交換用漢字符号(JIS X 0208-1997)
  
• JIS Hojyo-Kanji : JIS X 0212 情報交換用補助漢字
  
• JIS katakana : JIS X 0201 表3(エスケ－プ最終文字
  04/9)
• User defined : システム定義文字及び利用者定義文字
  
• ISO-2022-JP : インタ－ネットで使われる7単位系の漢字符号構成
  参考までに，シフトジスからISO-2022-JPに変換する見本を示す。

参考：ISO/IEC 2022による符号拡張方法がHTML及びその母体となったSGMLで使えないことを解説しておきます。

1. ISO 8879 SGML制定の直前でのISO/IEC JTC1/SC18/WG8との交渉

   　SGMLのSGML宣言が符号値を宣言して使うことになっており，符号
   種別がCHARSETの値として文字列によって記述されることに気づいた
   SGMLのJIS原案作成委員会主査若鳥らは,SC18/WG8のCharles Goldfarb
   らに，ISO/IEC 2022によって宣言すればDESCSETでUNUSEDをわざわざ
   宣言しなくてもよいように交渉した。

   しかし，この交渉は失敗に終わり，その結果，JIS X 4151では表9
   を追加して符号の値及び不使用領域を日本国内に周知させた。

2. ISO/IEC 2022の符号宣言及び呼び出しとSGMLとの不一致性

   SGMLは，人の目に見える図形文字を主体にして，可搬性を出す記述
   言語である。したがって，エスケ－プシケンスが文面に混入しては，
   意図に反するという性質を持つ。よって，ISO/IEC 2022とは,折り
   合いが悪い。

   SGMLでは，もし通信途上だけの符号指定であれば，ISO/IEC 9069
   (SDIF)に従って変換して，転送できるように準備してある。しかし，
   ISO/IEC 9069(SDIF)の転送構文は，ビット透過様相でなければなら
   ないので,当面のInternetでは使いずらいという事情もある。

3. 当初，SC18/WG8には，ISO/IEC 2022を駆使できる人はいなかった。

   それどころか，ISO/IEC 2022は難しくて分からないと主張する人の
   方が多かった。これは，主要委員が米国でASCIIだけしか見ていない
   状態にあったことに起因する。

4. 場当たり的な日本人達の対応

   更に悪いことには，日本人（ほんとの国籍は知らない）に個人計算
   機(PC)で使われていたシフトジス符号による取扱いを主眼にする人達
   がいたため，PCもUNIXも共通文書にするのだという理想形になって
   こなかった。

5. 共通文書の符号

   文書の符号は，本来，処理，通信及び格納の段階で共通であるのが
   理想である。ASCIIでの処理をみると，これらの間で共通になって
   いることに気付く。日本国でも共通でなければならないものなの
   である。

6. 文字符号に関するNCALS規格

   NCALS/WG3/SWG31 & SWG32では, このような点を将来改善するために,
   NCALS規格案を作成し,処理対象の文書（文面,絵,写真,設計図など）
   の日本語文字符号を,機械,操作系, 応用系などに統一することを提案
   している。