トップQs
タイムライン
チャット
視点

ISO/IEC 2022

国際標準規格のうち、文字符号化方式および文字集合の拡張方式を規定したもの ウィキペディアから

Remove ads

ISO/IEC 2022（旧称 ISO 2022）は、

  • 文字集合を7ビット符号または8ビット符号で表現するための技術、および
  • 複数の文字集合を単一の文字符号化方式に含める技術

を規定するISO規格である。JISの対応規格はJIS X 0202 「情報技術-文字符号の構造及び拡張法」[1]。Ecma Internationalの対応規格はECMA-35。

ISO/IEC 2022 の符号化方式は、一般に、1文字に1バイトか2バイト以上を使う可変長の文字符号化方式である。いくつかの符号化表現がISO/IEC 2022の機構を使っている。たとえば、ISO-2022-JPは日本語で広く使われている符号化表現であり、いわゆる「JISコード」というのもこれを指すことが一般的である。

歴史

要約
視点

コンピュータによる文字情報処理が可能になって以来、さまざまな言語のために、コンピュータ上で文字データを表現したいという要求を満たすため、多くの符号化文字集合が作られてきた。複数の文字集合の存在は、文字集合があらかじめ当事者間で合意されていなければ情報交換に支障をきたす。また、情報交換中に複数の文字集合を利用することも困難である。ISO/IEC 2022は、複数の文字集合を単一の文字符号化方式の下で利用できるようにするための技術として開発された。

ASCIIは7ビットのラテンアルファベット文字集合であり、最大94文字の図形文字 (空白文字を除く) しか収容できない。ISO/IEC 646 (1967年初版)[2]では、図形文字の収容領域を ASCII に倣いつつ、12個の符号位置を各国の国内使用目的のために置き換えてよいこととし、さらにレパートリとして国別の文字集合を定義するという方法をとった。

ISO/IEC 2022 (1973年初版)[3] は、ISO/IEC 646 に準拠した複数の符号表を切り替えて多言語の処理を実現することを目的に制定された。しかし、ISO/IEC 646 の方式では、ラテンアルファベットの範囲に限ってさえも、多数のダイアクリティカルマーク付き文字や、言語ごとに必要とされる記号類などを十分に収容することができなかった。このため、ISO/IEC 646 と互換性を保ちつつ8ビット符号 を採用した ISO/IEC 4873 (1979年初版)[4] が制定された。特にヨーロッパでは1980年代に入って多言語のテキストデータを共通の仕様の下に処理できるようにしたいという要求が高まっており[5]、1987年からは ISO/IEC 4873 に対応した ISO/IEC 8859シリーズが制定されはじめた。ISO/IEC 8859シリーズでは、新たに96文字の図形文字を収容可能にし、さらにレパートリとして言語別の文字集合を定義するという方法をとった。

また、ギリシア語、ロシア語、アラビア語、もしくはヘブライ語のような、ラテンアルファベットに基づかない多くの言語の文字も、歴史的に ISO/IEC 4873 に準拠した俗に言う「拡張ASCII」を用いてコンピュータ上で表現されてきたものが多い (一部は後に ISO/IEC 8859 シリーズにも規定されたほか、多くの国・地域の符号化文字集合の規格が ISO/IEC 4873 に準拠している)。さらに、東アジア言語、とくに中国語、日本語、および韓国語の表記は、8ビットの1バイトで表現可能な範囲をはるかに超えた数の文字を使い、言語別の2バイト文字集合によって初めてコンピュータ上で表現された。ISO/IEC 2022 は、これら複数の文字集合を単一の符号化方式の下に扱うことを可能にしている。

ISO/IEC 2022に基づく符号化表現は現在も広く使われている。たとえば日本語電子メール用のISO-2022-JPや、UNIX環境で使われるEUC-JP、中国のGB 2312ことEUC-CN、韓国のEUC-KRなどがそうである。ISO/IEC 8859シリーズもISO/IEC 2022の構造にしたがっている。一方で、この規格に則らない符号化方式、たとえばShift_JISや台湾のBig5などもまた広く使われている。

第2次規格以降の主な改正点

第2次規格以降の主な改正点には次のようなものがある。なお、用語については当項目でこの後解説する。

第2次規格
  • 8ビット符号に対応した。
  • バッファG2およびG3を新設した。
  • マルチバイト文字集合に対応した。
第3次規格
  • 96文字集合および96n文字集合に対応した。
  • （JISのみ）この版からJIS X 0201を拡張する規格からISO/IEC 646を拡張する規格になったため、国際一致規格になった。
第4次規格
  • 7ビット符号中心の記述から8ビット符号中心の記述に改められた。

#表1に、各版ごとの規格番号、制定日などを示す。

さらに見る 版, JIS番号 ...
※ 1987年3月1日部門X（情報処理）の新設に伴いJIS X 0202:1984 と改称された。
Remove ads

詳細

要約
視点

符号表の構造

ISO/IEC 2022は当初ISO/IEC 646に基づいた7ビット符号であったので、多くのISO/IEC 646の特性を持ち合わせている。7ビット符号では、各バイトの最上位桁ビットは使われない。これにより、7ビットの伝送路を通してISO/IEC 2022を伝送することは(ISO/IEC 646と同様)容易である。8ビット符号では、最上位桁ビットを GL領域とGR領域 (後述) の区別に用いるが、文字集合中の文字を区別するのには用いない。この特性はEUC符号化の基本原理にも利用されている。

ISO/IEC 2022の符号表は、表示や印字される文字 (図形文字) の領域と、制御機能に使う文字 (制御文字) の領域に分けられている。7ビット符号は、32個の制御文字基本集合の領域 (C0) と、94個または96個の図形文字集合の領域 (GL領域) を持つ。8ビット符号は、これに加えて32個の制御文字補助集合の領域 (C1) と、94個または96個の図形文字集合の領域 (GR領域) を持つ。#図1に、7ビットと8ビットの符号表の構造を示す。符号表上の文字の位置は、表の行および列で表す。たとえばASCIIの「Z」という文字は行列で 05/10 にあたり、符号のバイトの値としては16進数で 5A (10進数で 90) となる。

複数バイトの文字集合では、複数のバイトで1文字を符号化する。たとえば94n文字集合では、2バイトを使って8836個(94×94)までの文字を表現できる。そして、3バイトを使って830584個(94×94×94)までの文字を表現できる。2バイト文字集合では、各文字の符号位置は区点 (3バイト文字集合の場合は面区点) で(面および)区および区内の位置を指定する。つまり、94×94文字集合の場合、区および点のそれぞれが 1 から 94 の範囲をとるので、それぞれを1バイトずつGL領域の 02/01 から 07/14 (GR領域ならば 10/01 から 15/14) に対応させて2バイトとする。たとえば、JIS X 0208 の「字」は 27区90点 (27-90) なので、GL領域では 03/11 07/10、GR領域では 11/11 15/10 と表現される。

さらに見る 行＼ 列 ...

制御機能

さらに見る 制御文字またはエスケープシーケンス, 説明 ...

複数の文字集合を表現するために、ISO/IEC 2022の文字符号化方式は、符号の性質や扱う文字集合を指定するための制御機能を含んでいる。制御機能の表現には、7ビット符号ではC0制御文字のほか、ESCAPE制御文字(01/11。十六進数の1B、十進数の27)で始まる2バイトないし4バイトからなるエスケープシーケンスを用いる[6]。8ビット符号ではさらに、C1 制御文字も用いる。この文字符号化方式では、データの正しい解釈が最後に出現した制御機能に依存するため、データを先頭から順番に処理する必要がある。#表2に、ISO/IEC 2022 の制御機能の一部を示す。

文字集合の選択

ある文字集合を符号表上で使うには、一般に指示 (英: designate) と呼び出し (英: invoke) という2段階の手続きを必要とする。

ISO/IEC 2022 は、符号表上の4つの領域C0、GL、C1、GRとは別に、仮想的なバッファをもっている。G0、G1、G2、G3という4つのバッファがある。

まず、指示のエスケープシーケンスによって、使おうとしている文字集合を、4つのバッファのいずれかに対応付ける。

指示のエスケープシーケンスは、どの文字集合を使おうとしているか宣言するのみならず、これらの文字集合の特性をも知らせる。扱おうとしている文字集合が94文字、96文字、8836(94×94)文字、830584(94×94×94)文字、もしくは他のサイズのいずれであるかを伝える。指示していない文字集合を使うことはできない。また、5つ以上の文字集合を一度に指示しておくこともできない。

つぎに、呼び出し (シフト) の制御機能によって、G0、G1、G2、G3のいずれかを、符号表上のGL領域かGR領域に対応付ける。指示した文字集合を呼び出ししてはじめて、その文字集合を符号として使うことができるようになる。7ビット符号では2つ以上、8ビット符号では3つ以上のバッファを一度に呼び出しておくことはできない。

呼び出しには、ロッキングシフトとシングルシフトがある。ロッキングシフトでは、いったん呼び出しされたものは、別の呼び出しがあるまで使いつづけることができる[7]。シングルシフトでは、呼び出しされたものは直後の1文字 (シングルバイトの文字集合であれば1バイト、マルチバイトの文字集合であればそれぞれのバイト数分) だけ使え、そのあとは呼び出し前の状態に戻る[8]。

実際には、文脈や規約が特定の文字集合を使うよう指定していれば、符号化の仕様を指定する制御機能 (アナウンス機能) や初期の文字集合を指示する制御機能は省略することができる。ISO-2022-CNを定義しているRFC 1922を例に取ると、呼び出しにSIとSOの制御文字を使用するが、この仕様を宣言するアナウンス機能のエスケープシーケンスを省略している。また、初期状態ではG0にUS-ASCII、G1にGB2312-80を指示し、G0をGL領域に呼び出しているが、指示のエスケープシーケンスも省略している。

ISO国際登録簿

ISO/IEC 2022は具体的な符号化文字集合とは切り離して規定されているため、実際にこの規格を適用するにあたってはエスケープシーケンスの終端文字と符号化文字集合などとの具体的な対応関係を定める必要があり、そのために符号化文字集合のISO国際登録簿が存在する。これはエスケープシーケンスの終端文字についてそれぞれどの文字がどの符号化文字集合などに対応しているのかを定めたものである。符号化文字集合のISO国際登録簿と登録方法はISO/IEC 2375 Data Processing - Procedure for Registration of Escape Sequences (情報技術－エスケープシーケンス及び符号化文字集合の登録手順) に規定されている。

ISO国際登録簿への登録申請を行うことが出来るのは次の者に限定される。

  • ISO/IEC（ISO/IEC JTC 1結成以前はISO）の技術委員会（TC）または小委員会（SC）
    ISO TC 46/SC 4、ISO TC 97/SC 2、ISO TC 97/SC 21など
  • 符号拡張またはエスケープシーケンスの使用法を検討するISO/IEC JTC/SC2（ISO/IEC JTC 1結成以前はISO TC 97/SC 2）内の作業グループ（WG）
    ISO/IEC JTC 1/SC 2/WG 2、ISO/IEC JTC 1/SC 2/WG 3、ISO TC 97/SC 2/WG 4、ISO TC 97/SC 2/WG 7など。
  • ISO/IEC（ISO/IEC JTC 1結成以前はISO）の会員団体（各国で1団体ずつと決められている。）
    米国規格協会（ANSI）、日本工業標準調査会（JISC）、英国規格協会（BSI）、ドイツ規格協会（DIN）など。
  • ISO/IECの技術委員会または小委員会と関連のある国際機関
    ヨーロッパ電子計算機工業会（ECMA）、国際電気通信連合 電気通信標準化部門（ITU-T：旧CCITT）など。

登録の手続きと国際登録簿の維持管理は登録事務局（Registration Authority）がおこなうことになっている。現在、その事務局は日本の情報処理学会情報規格調査会 (IPSJ/ITSCJ) が引き受けている（符号化文字集合の国際登録簿）。かつてはECMA（欧州計算機製造業者協会、現Ecma International）が登録事務局を引き受けていた[9]。

終端文字は登録順に16進数の「4/0」から順に割り振っていくことになっている。終端文字の割り振りは区分ごとに行われることになっている。（そのため同じ終端文字でも、どの区分の終端文字であるのかによって指し示す符号系は異なり、そのエスケープシーケンスがどの区分の符号系を指し示すのかは中間文字が何であるのかによって識別できる。）

登録数の最も多い94文字集合については、当初の規格で用意されていた利用可能な終端文字を使い切ってしまったため、第三次規格において94文字集合を指し示す新たな中間文字を設けてより多くの94文字集合が登録出来るように規定が改正された。

なお、一つの規格で定められた符号系であっても、文字の追加変更を含む改正が行われたときには異なる符号系として扱われることになっており、そのために改めて登録が行われ、新たな登録番号と終端符号が付与されることになる。例えばJIS X 0208は1978年版、1983年版、1990年版のそれぞれが、JIS X 0213は2000年版と2004年版がそれぞれ異なる符号系として登録されている。

Remove ads

応用例

要約
視点

7ビット符号によるマルチバイト用のキャラクタセット

ISO/IEC 2022の機構を使う7ビット符号のキャラクタセットには以下のものが含まれる。次のような特徴を持つ。

  1. アナウンス機能のエスケープシーケンスは省略する。
  2. 7ビット符号なので、GR領域は使わず、C1制御文字はエスケープシーケンスで表す。
  3. 最初は、G0にASCIIを指示し、G0をGL領域に呼び出した状態で始まる (このための制御機能は省略する)。つまり、最初はUS-ASCIIで始まる。
  4. 行の終わりではASCIIに戻さなければならない[10]。

#表3に、これらのキャラクタセットで用いる符号化文字集合と、その選択のための制御機能を示す。

ISO-2022-JPでの「日本語版Wikipedia」という文字列の符号化を例に説明する (#表3も参照)。

さらに見る 文字, 機能区点 行列 ...

上図で、上段が符号化したい文字列である。「日本語版」は JIS X 0208 に含まれる文字の列、「Wikipedia」はASCIIに含まれる文字の列である。また、最初はASCIIで始まる。したがって、「日本語版」の直前と「Wikipedia」の直前に文字集合を指示するエスケープシーケンスが必要になる (ISO-2022-JP では指示が呼び出しを兼ねるので、呼び出しの制御機能は必要ない)。マルチバイト文字は区点で、シングルバイト文字は行列で表すと、中段のようになる。区点を2バイトずつで表し、全体を7ビット符号で表すと、下段のように符号化される。

さらに見る キャラクタセット, 対象言語 ...

ISO-2022-JP

→「ISO-2022-JP」も参照

ISO-2022-JPは、日本語の電子メールなどのための符号化表現として広く使われている。このキャラクタセットは、1986年後半ころに、当時のJUNETで、ネットニューズや電子メールで日本語を利用するための符号化の共通仕様として成立し、のちにその仕様は RFC 1468 でInformationalとして発行された。当初は「JISコード」、「JUNETコード」(junet-code) などと呼ばれたが、最終的には同RFCにおいて、MIMEのためのキャラクタセット名としてISO-2022-JPの名称が規定され[11]、後のIANA Character Setsにも収録されている。

ISO/IEC 2022 に準拠した7ビットの符号化表現だが、次のような特徴を持つ。

  • JIS X 0208が指示(かつ呼び出し)されている状態では、SPACE (空白) や制御文字を使ってはならない。
  • 行末では指示(かつ呼び出し)をASCIIにもどさなければならない。つまり、行末の前に漢字の文字集合が指示されていたら、ASCIIを指示してから改行しなければならない[10]。
  • JIS X 0208を指示するとき、改訂番号識別のエスケープシーケンスを用いずに1983年版と1990年版のどちらを使ってもよい。

JUNETコードの成立当時、日本語対応端末などの機器には「漢字イン/漢字アウト」理解[7]に基づく動作をするものが複数存在し、JIS X 0208の文字要素並びの途中にSPACE (空白 02/00) や制御文字が現れると正しく処理できなかった。改行の処理についても、行末の制御文字の処理でASCIIにもどってしまうものがあった。こういった機器は、ハードウェアの組込みソフトウェアによって実現されている例も多く、その挙動を修正することはしばしば困難だった。そのため、情報交換当事者間の合意として上記の条件のもと符号化する。

また、ISO/IEC 2022 では、改訂後の文字集合を指示する場合には、指示のエスケープシーケンスの前に改訂番号を識別するエスケープシーケンス (IRR。#表2参照) を置くと定めている。たとえば、JIS X 0208:1990 (JIS X 0208 の1990年版) は JIS C 6226-1983 (同じく1983年版。後に JIS X 0208-1983に改称) の改訂である (漢字2文字が追加されている) ため、1990年版を指示する場合は、指示のエスケープシーケンスの直前に 01/11 02/06 04/00 (ESC & @) を付加する。実際にIRRを使用するかどうかは情報交換の仕様の中で定められる。RFC 1468 では、1990年版を使う場合も IRR の付加をしないことを提案している。

JIS X 0208:1997では、附属書2「RFC1468符号化表現」として ISO-2022-JP をJISの規定としたが、この符号化表現が「ISO/IEC 2022に適合するものではない」[12]と付記している。

ISO-2022-JP は、マルチバイト文字集合を扱うものとしては初のMIME用キャラクタセットであった。これ以降、中国語、朝鮮語、あるいは多言語での利用を想定したマルチバイトのキャラクタセットが、ISO-2022-○○という名称でいくつか提案され、一部はRFC にもなった。これらは、ISO-2022-JP で採用された ISO/IEC 2022 の7ビット符号による符号化方式を踏襲していた。しかしその後、日本語以外の言語では、電子メールなどのキャラクタセットはEUC符号化によるものなどが事実上の標準となっていった。今日、マルチバイトで7ビットのキャラクタセットとして一般的に使われているものは、事実上、日本語用の ISO-2022-JP のみである。

Extended Unix Code (EUC)

Extended Unix Code (EUC) は、ISO/IEC 2022の機構に準じた8ビット符号の文字コード[13]である。これには以下のものが含まれる。次のような特徴を持つ。

  • アナウンス機能のエスケープシーケンスは省略する。
  • 8ビット符号なので、GR領域も使う。エスケープシーケンスは使わない。
  • G0にASCIIを、G1にマルチバイト文字集合を、G2やG3に補助的な文字集合を (あれば) 指示し、G0をGL領域に、G1をGR領域に呼び出した状態で始まる (このための制御機能は省略する)。つまり、最初は7ビット符号がASCII、8ビット符号がマルチバイト文字集合で始まる。
  • 指示の状態は固定的に決まっており、変更は行わない。
  • 呼び出しはシングルシフトのみで、G2かG3 (あれば) からGR領域へのみ。

この結果、ASCIIの文字は常に7ビット、それ以外の文字集合の文字は常に8ビットで符号化され、しかも、同じ文字集合の文字は常に同じバイト数で表現されることになる。

#表4に、これらの文字コードで用いる符号化文字集合と、その選択のための制御機能を示す。

EUC-JPでの「日本語版Wikipedia」という文字列の符号化を例に説明する (#表4も参照)。

さらに見る 文字, 区点 行列 ...

上図で、上段が符号化したい文字列である。「日本語版」は JIS X 0208 に含まれる文字の列、「Wikipedia」はASCIIに含まれる文字の列である。ASCIIはGL領域に、JIS X 0208はGR領域に呼び出されている。したがって、「日本語版」を8ビットで、「Wikipedia」を7ビットで符号化すればよい。マルチバイト文字は区点で、シングルバイト文字は行列で表すと、中段のようになる。区点を2バイトずつで表し、全体を8ビット符号か7ビット符号で表すと、下段のように符号化される。

さらに見る 文字コード, 対象言語 ...

変異

EUCは業界標準であるため、ベンダごとの独自の実装も包含するものとなっている。そのため、厳密に言えばISO/IEC 2022に準拠しているとは言えないものもある。

EUC-JP では、G1に指示する文字集合に JIS X 0208 のさまざまな版を使うものがある。1978年版 (JIS C 6226-1978)、1983年版 (JIS X 0208-1983)、1990年版 (JIS X 0208:1990) は、ISO/IEC 2022に基づく符号化文字集合としてはそれぞれ異なるものだが、いずれの文字集合を使っているかはベンダによって異なる。また、G2 のJIS X 0201片仮名文字集合や、G3 のJIS X 0212については、ベンダによっては実装していないことがある。

EUC-TW では、CNS 11643の2面以降の文字を、シングルシフト (SS2) の後に面1バイト(10/02 A2 から11/00 B0 で2面から16面を表す)と区点2バイトの合計4バイトで呼び出す。つまり、CNS 11643の2面以降をまとめてひとつの文字集合として扱っていることになる。ISO/IEC 2022に基づく符号化文字集合としては、各面はそれぞれ異なる文字集合である。

拡張ASCII

「拡張ASCII」は俗称である。8ビット符号を使うシングルバイト文字集合で、ASCIIに対して上位互換となっているものを指す。#歴史で見たように、ISO/IEC 4873 に準拠した符号表を持てばその文字集合は ISO/IEC 2022 に準拠していると言える。しかしここでは、ISO/IEC 2022 の側から見て解説する。

一般に、拡張ASCIIとはISO/IEC 2022準拠の符号表を使う文字集合の、つぎのような符号化表現であると考えることができる。

  • アナウンス機能のエスケープシーケンスは省略する。
  • G0に ISO/IEC 646 の各国版またはASCIIを、G1にその他のシングルバイト文字集合を指示し、G0をGL領域に、G1をGR領域に呼び出した状態で始まる (このための制御機能は省略する)。
  • 指示の状態も呼び出しの状態も固定的に決まっており、変更は行わない。

この結果、8ビット符号で最大188個ないし190個の図形文字を利用することができ、しかもすべての文字が1バイトの固定長で表現されることになる。なお、これらの多くは、IANAがキャラクタセットとして登録している。

拡張ASCIIの例としては次のようなものがある。詳細は各項目の解説を参照。

ARMSCII
アルメニア文字。
ASMO 449+
アラビア語用のアラビア文字。ISO/IEC 8859-6と互換性がある。
ISCII
インドの諸言語の文字。用字系の切り替えや、結合文字の表現のための特殊な図形文字を持つ。
ISO/IEC 8859 シリーズ
ヨーロッパの諸言語 (トルコ語およびエスペラントを含む) のラテン文字集合を含み、さらにアラビア文字、ギリシア文字、キリル文字、タイ文字、ヘブライ文字の文字集合をも含む。
JIS X 0201
日本語用の片仮名。
PASCII
アラビア文字 (ウルドゥ語、シンド語、カシミール語、アラビア語)。ISO/IEC 8859-6とは互換性がない。
TIS 620
タイ文字。ISO/IEC 8859-11と互換性がある。
TSCII
タミル文字。ISCIIのタミル文字とは互換性がない。

はみ出し

拡張ASCIIの方法では、ラテン文字以外の文字は最大96文字までしか収録できない。またたとえラテン文字であっても、極めて多数のダイアクリティカルマーク付き文字を使う言語では、ISO/IEC 2022の8ビット符号でも文字数が不足する。かといって、マルチバイト文字集合を採用するほど多いわけでもない、という場合、図形文字をGR領域やGL領域の外にまで配置することもある。

VISCII
ベトナム語用電子メールなどで広く使われているキャラクタセットである。GL領域はASCIIであるが、ダイアクリティカルマーク付き文字のうち96文字をGR領域に収容し、残りを、C1の32文字すべて、さらにはC0のうち6文字にまで割り当てている。
KOI8 系文字集合
キリル文字。ロシア語用およびブルガリア語用に使われるKOI8-R、ウクライナ語用に使われるKOI8-U、ウクライナ語、ベラルーシ語、ロシア語共通のKOI8-RUが代表的である。ほかにも、キリル文字を使う多くの言語用にKOI8の変種が用いられており、タジク語用 (KOI8-T)、チェコ語およびスロバキア語用 (KOI8-CS)、モンゴル語用などがある。C1領域にも記号や罫線素などを収容している。
MS-DOS、Windows、その他パソコンに組み込みのコードページ
これらのうち、シングルバイトのものの多く。C1領域にも記号や罫線素などを収容している。

Compound Text Encoding (CTEXT)

さらに見る 制御機能, 説明 ...

Compound Text Encoding (CTEXT) は、ISO/IEC 2022およびISO/IEC 6429の機構に準じつつそれを拡張した8ビット符号の符号化方式である。X Window Systemにおいて、クライアント間のテキスト情報の伝達や、リソース中のテキスト情報の表現に用いる。次のような特徴を持つ。

  • アナウンス機能のエスケープシーケンスは省略する。
  • 8ビット符号なので、GR領域も使う。
  • G0にASCIIを、G1にISO/IEC 8859-1の右半分を指示し、G0をGL領域に、G1をGR領域に呼び出した状態で始まる (このための制御機能は省略する)。つまり、最初はISO/IEC 8859-1で始まる。
  • G0およびG1への指示がGL領域およびGR領域への呼び出しを兼ねる。呼び出しの制御機能は使わない。つまり、文字集合の選択は指示のエスケープシーケンスだけで行う。
  • ISO/IEC 2022のDOCS (#表2参照) と私用終端バイトにより、利用者独自の文字集合や、UTF-8 のようにISO/IEC 2022に準拠した構造の符号表を持たない符号化システムを指示する (#表5参照)。
  • ISO/IEC 6429のSDSにより書字方向を指定する (#表5参照)。

また、つぎの点で ISO/IEC 2022 に対する拡張となっている。

  • 指示のエスケープシーケンスでは、中間バイト02/08の省略 (#表2 注参照) をしない。

この結果、複数の符号化システムや文字集合が混在する場合でも、文字コード変換による情報の劣化を起こさず、またクライアントが対応していない符号化システムや文字集合の情報も伝達することが可能になっている。なお、これは異なるアプリケーションの間でのテキスト情報の交換のための符号化方式を定めたものであり、個々のアプリケーション内部でのテキスト処理の際は、適当な内部形式に変換してから処理することが想定されている。

Remove ads

注

参考文献

関連項目

外部リンク

Loading related searches...

Wikiwand - on

Seamless Wikipedia browsing. On steroids.

Remove ads
Remove ads