standard return

DOCS (ISO/IEC 2022)

[32] DOCS (DESIGNATE OTHER CODING SYSTEM) は、 ISO/IEC 2022ISO/IEC 2022 以外の文字コード体系を相互に切り替えるエスケープシーケンスです。

意味

[37] DOCSISO/IEC 2022 以外の符号化システム指示し、同時に呼出すことができます。 他の符号化システム文字符号以外のものも構いません。 JIS X 0202:1998 15.4.1

構文

[35]

名前
DESIGNATE OTHER CODING SYSTEM
日本語通用名称
他の符号化システムの指示
略号
DOCS
符号化表現
ESC 02/05 *I F

[36] 仕様書:

[39] 終端バイト: 符号化システムは (必要なら中間バイトと) 終端バイトで識別されます。 終端バイト FtISO-IR に登録されます。

[34] ISO/IEC2022 1994 15.4

  1. DOCS = ESC %x25 [I] F ;; DESIGNATE OTHER CODING SYSTEM
  2. I = I-foreign / %x20-2E
  3. I-foreign = %x2F
  4. F = %x40-%x7E

ISO/IEC 2022 に適合しない符号化体系 Coding System を指示・呼び出ししたり、 ISO/IEC 2022 に戻ってきたりします。

  1. return-to-ISO2022 = ESC %x25 %x40

ESC 02/05 04/00 で戻ってきたときには、告知, 指示, 呼び出しの状態は元に戻ります。現在位置など他の状態が 戻るかは未定義です。

中間バイトが 02/15 の時は、呼び出された符号化体系は ISO/IEC 2022 に復帰するのに return-to-ISO2022 を使いません。 他の方法で戻ってきたとしても上述の状態も戻るかは未定義ですし、 そもそも戻る方法が無いかもしれません。

他の中間バイトを使うか、または中間バイト無しの時は、 return-to-ISO2022 を使って ISO/IEC 2022 に復帰できます。

[17] 5Fエスケープ・シーケンスは、 符号化システム指示 (DESIGNATE OTHER CODING SYSTEM) に使われます。

[18] 仕様書:

[19]

標準復帰あり DOCS (ESC 02/05 Ft)

[44] ESC 2/5 F標準復帰ISO/IEC 2022 に切り替えられるものとされます。

ESC 02/05234567
0IreturnISO 2022
1moe108
2178
3131
4NAPLPS145
5160
6161
7196
8188
9
10
11
12
13Proprinter
14
15n/s---
ISO-IRエスケープシーケンス符号化システム
---ESC 02/05 04/00ISO/IEC 2022
108ESC 02/05 04/01NAPLPS
178ESC 02/05 04/02UTF-1
131ESC 02/05 04/03Data Syntax I of CCITT Rec. T.101.
145ESC 02/05 04/04Data Syntax II of CCITT Rec. T.101.
160ESC 02/05 04/05Photo-Videotex Data Syntax of CCITT Recommendation T.101.
161ESC 02/05 04/06Audio Data Syntax of CCITT Recommendation T.101.
196ESC 02/05 04/07UTF-8 with standard return (実装水準指定なし)
186ESC 02/05 04/08VEMMI Data Syntax of (draft) ITU-T Recommendation
ESC 02/05 05/hhT.100 >>113

標準復帰なしのDOCS (ESC 02/05 02/15 Ft)

[45] ESC 2/5 2/15 F標準復帰ISO/IEC 2022 に切り替えられないものとされます。

ESC 02/05 02/1534567
0xseg162
1xseg163
2xseg125
3xseg174
4xseg175
5(xseg)176
6(xseg)177
7(xseg)190
8(xseg)191
9(xseg)192
10(xseg)193
11(xseg)194
12(xseg)195
13(xseg)
14(xseg)
15(xseg)---
ISO-IRエスケープシーケンス符号化システムISO/IEC 2022 復帰
162ESC 02/05 02/15 04/00ISO/IEC 10646:1993, UCS-2, Level1ESC U+0025 U+0040
163ESC 02/05 02/15 04/01ISO/IEC 10646:1993, UCS-4, Level1ESC U+0025 U+0040
125ESC 02/05 02/15 04/02Virtual Terminal Service Transparent Set復帰なし
174ESC 02/05 02/15 04/03ISO/IEC 10646:1993, UCS-2, Level2ESC U+0025 U+0040
175ESC 02/05 02/15 04/04ISO/IEC 10646:1993, UCS-4, Level2ESC U+0025 U+0040
176ESC 02/05 02/15 04/05ISO/IEC 10646:1993, UCS-2, Level3ESC U+0025 U+0040
177ESC 02/05 02/15 04/06ISO/IEC 10646:1993, UCS-4, Level3ESC U+0025 U+0040
190ESC 02/05 02/15 04/07UTF-8 level 1, without standard returnESC U+0025 U+0040
191ESC 02/05 02/15 04/08UTF-8 level 2, without standard returnESC U+0025 U+0040
192ESC 02/05 02/15 04/09UTF-8 level 3, without standard returnESC U+0025 U+0040
193ESC 02/05 02/15 04/10UTF-16 level 1, without standard returnESC U+0025 U+0040
194ESC 02/05 02/15 04/11UTF-16 level 2, without standard returnESC U+0025 U+0040
195ESC 02/05 02/15 04/12UTF-16 level 3, without standard returnESC U+0025 U+0040

[2] 終端バイト 7/14 については空集合 (ISO/IEC 2022)参照。

[117] Unicode になる前の DIS 10646 は、本来4オクテットの符号を符号短縮法により2オクテットに縮小することを表す、

ESC 2/5 2/15 F2 HOP HOP G P

というエスケープシーケンスがあったそうです。 F2 は未定の終端バイトHOP8/1G, P。 (このエスケープシーケンスは7ビットまたは8ビットの8オクテット列でいいのか、 4オクテット符号の合計32オクテット列になるのかわかりません。)

他にも符号短縮法があったそうで、それぞれ終端バイトが予定されていたと思われます。

[125] 02N3140 で ISO-IR 210 (案) Sami complete 8-bit graphic character set no. 1., 02N3141 で ISO-IR 211 (案) Sami complete 8-bit graphic character set no. 2. として CR にも図形文字を定義した8ビット符号SC2 に送付されたものの、 なぜか登録されなかった模様。

旧仕様の DOCS (終端バイトと符号のビット数)

[10] 初期の ISO 2022 では終端バイト指示呼び出しする符号ビット数によって割り当てることになっていました。 すなわち、 >>9

[11] ビット長の異なるデータをどのように混在させる想定だったのかは不明です。

[12] 当時の ISO 2022 には ISO 2022 への復帰のシーケンスが規定されていませんでした。 ISO 2022 自身の7ビット符号8ビット符号の切り替えの方法も用意されていませんでした。

[33] 標準復帰あり・なしの概念もありませんでした。

[16] JIS X 4151ESC 2/5 4/0 を未登録の128文字の文字集合と説明するのは、 この時代の仕様に基づく説明っぽいです。 公開テキスト指示シーケンス

[20] 実際にはこの規定に基づき ISO-IR に登録された終端バイトは1つもありません。

ISO/IEC 2022 の DOCS

[40] ISO/IEC 2022 の終端バイト: 中間バイトなし、終端バイト 04/00 (つまり ESC 02/05 04/00) は ISO/IEC 2022符号化システム指示します。 他の符号化システムを使用中にこのエスケープ・シーケンスを使うと、 ISO/IEC 2022指示され、前に ISO/IEC 2022 から他の符号化システム呼出した時点の状態に復帰します。 前の状態とは、告知機能 (ACS) により設定した状態と符号化図形文字集合符号化制御機能集合指示呼出しの状態を指します。 現在位置などがどうなるかは ISO/IEC 2022 の範囲外とされています。 JIS X 0202:1998 15.4.2

このエスケープ・シーケンスISO-IR の登録の範囲外になっているようです。

[41] 標準復帰: 第2中間バイト02/15 かどうかにより、 >>40 が使用できるか区別されます。

02/15 でない DOCS で他の符号化システム呼出すと、 ISO/IEC 2022 に復帰するために >>40 を使用できます。

02/15DOCS を使う他の符号化システムは、 ISO/IEC 2022 に復帰するために >>40 を使用しません。 (別の方法で復帰できるかもしれませんし、できないかもしれません。) 復帰できたとしても ISO/IEC 2022 の状態 (告知指示呼出し) は不定とされています。

JIS X 0202:1998 15.4.2

[42] ISO/IEC 2022 符号化システムに復帰するためには >>40 を使うことが望ましいとされています。 JIS X 0202:1998 15.4.1

[43] ISO/IEC 2022 は復帰したときに DOCS で移行したときの状態に戻るとしていますが、 他の符号化システム内でエスケープシーケンスやそれと同等の仕組みが利用可能なときに、 そこで変更した状態も復帰時に破棄して元の状態が復元されるべきなのかどうか、 よくわかりません。 ISO/IEC 2022 が復帰時に復元すると明記しているのだからそれに戻るべきという解釈もあり得ますし、 ISO/IEC 10646におけるエスケープシーケンスのように ISO/IEC 2022のエスケープシーケンスを利用すると規定しているものは ISO/IEC 2022 の状態を参照・編集しているのだから復帰してもそれが破棄されるのはおかしいという解釈もあり得ます。 なぜか標準復帰あり・なしの2種類ある UTF-8 がその違いを踏まえているという解釈もあり得ますが、 UTF-1, UCS-2, UTF-16, UCS-4 は各1種類しかないのがネックです。

[47] 実際の所 (少なくても) Unicode 系、 Videotexlibmoe と約半数の符号化系が ISO/IEC 2022エスケープシーケンスを使っています。 それらは ISO/IEC 2022 と (少なくても) 一部の状態を共有しているようです。

[112] 標準復帰は特定のビット組合せ列が ISO/IEC 2022 の復帰に使われるというものですが、 そのビット組合せが必ず標準復帰を意味しているわけではありません。 現に Videotex 系の符号化環境は PCD を使いますが、 そこでは指定したバイト長の任意のバイト列を含めることができます。 そのバイト列は ISO/IEC 2022エスケープシーケンスとして解釈されないので、 標準復帰を意味しません。 それゆえ、 標準復帰を使っているからといって、 構文の知識のない符号化系が指定されたとき、 その部分を読み飛ばすわけにはいかないのです。

[116] KS X 2502:2003 (CGM) の p.66 には ESC 2/5 2/0 3/0 という例が示されています。 中間バイト 2/0 が使われていますが、 私用終端バイトの利用例として示されているだけで、 特に意味はなさげです。

Unicode の DOCS

[31] UTF-1, UTF-8, UCS-2, UTF-16, UCS-4終端バイトが登録されています。

[7] UCS 系符号化体系では ISO/IEC 2022 への復帰に ESC(U+001B) U+0025 U+0040 を使います。 UCS-2, UTF-16 では 0x001B 0x0025 0x0040 に、 UCS-4 では 0x0000001B 0x00000025 0x00000040 になります。 UTF-8 では 0x1B 0x24 0x40 になります。

[6] ISO/IEC 10646におけるエスケープシーケンスも参照。

[21] いくつかの実装が UTF-8 に対応しています。 >>5, >>8, >>23 それを利用したWeb頁もあります >>22

[8] Man page of CONSOLE_CODES, , https://linuxjm.osdn.jp/html/LDP_man-pages/man4/console_codes.4.html

VT

Videotex の DOCS

[111] VideotexISO/IEC 2022 ベースの符号と独自の符号の混在でした。 各種符号を DOCS (標準復帰あり) で切り替えられるとされていました (少なくても仕様書の上では)。

[53] 私用終端バイトも使われていました。 VT

[113] 他に T.100ESC 2/5 5/h と規定していました。 該当する終端バイトは登録されておらず、 仕様策定が頓挫したものと思われます。 これは実質的には alphageometric coding scheme という96集合 (図形文字集合ではない) の指示として機能するものでした。 標準復帰すら待たずに G1 への指示で終了します。

[115] 標準復帰のない旧 ISO 2022 時代に規定されたのでしょう。

[114] 他にも NAPLPS で独自のエスケープシーケンスが用いられたとする説があります。 NAPLPS

VTS の DOCS

[4] ISO-IR 125 ESC 02/05 02/15 04/02 Virtual Terminal Service Transparent Set は、 8ビットの1バイト符号化文字集合で、 ISO OSI 仮想端末規格で利用します。 仮想端末サービス (VTS) の利用者が VTS の適用範囲外たる意味を 一部又は全部の値に割り当てます。 VTS はその意味や解釈の責任を有しません。 ISO/IEC 2022 符号化体系に復帰する手段はありません。 (ISO 9040, ISO 9041)

印刷プロトコルの DOCS

[58] ESC 2/5 3/13 : IBM Proprinter Emulation mode >>15

[60] DEC PPL で使われます。標準復帰とほか2種類以外の DEC PPL エスケープシーケンスは認識しなくなります。 (利用可能な CSICR でなく ESC Fe でなければなりません。) >>15

[61] ESC 2/5 3/13 >>15標準復帰 ESC 2/5 4/0 >>14 は、 DEC PPL のプロトコルとしての挙動変化という (符号化システムとしてみたときの) 副作用を持ちます。


[62] DEC PPL において ESC 2/5 2/0 3/0 は bar code の始まり、 標準復帰 ESC 2/5 4/0 は終わりを表します。 >>13

[63] バーコード (と付随する文字列) の記述方法は制御シーケンスで指定できます。 >>13

VT の DOCS

[57] VT

[123] >>8

[124] Control functions - akinomyoga/contra, , https://akinomyoga.github.io/contra/escseq.html#dfn.DOCS

ctext の DOCS

[64] XCompound Text では extended segmentDOCS が使われます。 他で表せない文字に使います。 >>3

[67] 構文: >>3

[66] F は次のいずれかです。 >>3

[68] ML は長さを表す各1バイト (最上位ビット 1) です。 ((M - 128) × 128) + (L - 128) で bytes の長さを表します。 >>3

[69] F が [ 3/0, 3/4 ] のとき、 bytes

... という構造になります。 encoding name文字符号化の名前、 text がそれによって符号化されたバイト列です。 >>3

[71] 復帰は明示せず、指定された長さで自動的に ISO/IEC 2022 に戻るようです。

[72] ctext は仕様全体がドラコニアンエラー処理を採用しており >>3DOCS やそれ以後が指定された構文に合わない時の処理は規定されていません。


[70] encoding nameISO 8859-1 で記述します。 >>3

[101] encoding name は登録簿のものであるべきです。 >>3 次のものが登録されています。 >>83

encoding name 登録簿の説明 メモ
DEC.CNS11643.1986-2CNS11643 2-plane using the recommended internal representation schemeDEC Hanyu CNS 第2面
DEC.DTSCS.1990-2DEC Taiwan Supplemental Character SetDTSCS
fujitsu.u90x03U90 CS3
ILAregistry prefix
IPSYSregistry prefix
omron_UDComron User Defined Charset omron_UDC
omron_UDC_jaomron User Defined Charset for Japanese omron_UDC
omron_UDC_zhomron User Defined Charset for Chinese(Main land) omron_UDC
omron_UDC_twomron User Defined Charset for Chinese(Taiwan) omron_UDC

[75] 「registry prefix」は DEC. のように名前の接頭辞に使うもののようです。 2つ登録されていますが、それを接頭辞とする実際の値があるのかは不明です。

[102] 現在オープンソースで公開されている X の実装中で発見できるのはこのうち fujitsu.u90x03 だけです。それ以外は非公開の商用製品などで使われていたのでしょうか。

[103] 現在オープンソースで公開されている X の実装中には次のものがあります。

n
encoding name
f
バイト長
size
集合大
side
左右
note
メモ
n
iso8859-14
f
1
side
note
後方互換性のため
n
iso8859-15
f
1
side
note
後方互換性のため
n
big5-0
f
2
side
n
big5hkscs-0
f
2
side
n
gbk-0
f
2
side
n
armscii-8
side
f
1
n
georgian-academy
side
f
1
n
georgian-ps
side
f
1
n
ibm-cp1133
side
f
1
n
iscii-dev
side
f
1
n
isiri-3342
side
f
1
n
iso8859-9e
side
f
1
n
fujitsu.u90x03
side
左/右
size
94
f
2
n
koi8-c
side
f
1
n
koi8-r
side
f
1
n
koi8-u
side
f
1
n
microsoft-cp1251
side
f
1
n
microsoft-cp1255
side
f
1
n
microsoft-cp1256
side
f
1
n
mulelao-1
side
f
1
n
nokhchi-1
side
f
1
n
tatar-cyr
side
f
1
n
tscii-0
side
f
1
n
tcvn-5712
side
f
1
n
viscii1.1-1
side
f
1

[104] 現在オープンソースで公開されている X の実装ではソースコード中にハードコードされているものと、 ロケールを定義するテキストファイルから読み込んで定められるものがあります。 X を利用する製品や実際の運用によっては、 後者の仕組みを通じてこれら以外を使ったり、 これらの定義を修正したりすることもあるのかもしれません。

[105] 現在オープンソースで公開されている X の実装では encoding name は定義の読み込み時点で ASCII小文字に変換したものが利用されます。 ctext の仕様には大文字小文字の違いに言及がなく、 登録簿 (>>101) には大文字混じりのものも含まれるのですが、 X の実装によっては大文字も使えるのかもしれません。

[106] encoding name として HP-UXHP-BIG5 (バイト長可変)、 Digital UNIX BIG5-0 (バイト長2) が使われました。 >>100 後者は >>103 にもありますが、こちらでは大文字です。

[109] 過去にはここに挙げた以外にも実装例のある encoding name が存在したかもしれません。

[110] Compound Text 仕様書にはバイト長4まで定められていますが、 3バイト、4バイトの encoding name は確認されていません。

[107] なお、 >>83, >>99942集合GLESC 2/5 2/8 3/2, GRESC 2/5 2/15 3/2 と書いて区別しています。 前者は何らかの誤りなのか、あるいは過去にそう実装していたものがあったのか不明です。

libmoe の DOCS

[26] 文字コード変換ライブラリー libmoeISO/IEC 2022 と他のいくつかの文字コード体系に対応しており、 DOCS の独自構文 (私用終端バイト) で相互に切り替えられます。 >>5

[29] mbconv という変換プログラムが付属する他、 w3m を機能拡張した w3mmee という Webブラウザーでも利用されています。
[30] 更新が停止して久しいですが、公式サイトのソースコードの他、 現在でも Ubuntu のパッケージが提供されていてすぐに利用できます。

[27] ISO/IEC 2022, UTF-8, UTF-16 以外は独自の構文:

ESC 2/5 2/1 I Fp

... を使います。 >>5

[24] >>5

[28] エスケープシーケンスISO/IEC 2022 以外でも利用できます。 DOCS を超えて状態が持続します。 左側ISO/IEC 2022 以外でも指示シーケンス固定シフトが解釈されます。 右側は不可解でよくわかりません。

[25] 出力の符号化 (ISO/IEC 2022 系のもの以外を含む。) で表現できないとき、 ESC 2/5 2/1 2/0 3/0 が使われます。適宜 ESC 2/5 4/0 が入ることもあれば、入らないまま ISO/IEC 2022 指示シーケンスが現れることもあります (この辺は若干挙動が怪しい)。

[108] なお、このうち EUC-TWx-euc-jisx0213-packedISO/IEC 2022 の符号構造から逸脱していないので、 本来 DOCS にしなければならない理由はありません。 ここで DOCS が用いられたのは、 これらが正規の終端バイトを用いた指示シーケンスで記述できない符号化文字集合を使っているからでしょう。

ecma35lib の DOCS

[119] ecma35lib は次の DOCS Fp に対応しているようです。 >>118

[120] ここで "Plain extended ASCII" は ISO/IEC 2022 エスケープシーケンスによる文字集合の切り替えの他に、 DECSPPCS (の独自の拡張) と CSI )p による文字集合の切り替えが使えます。 それによって各コードページに切り替えられます。 >>118

文脈

[1] SGML公式公開識別子公開文指示シーケンスにおける DOCS の用法についての話は CHARSET を参照。

[59] ISO/IEC 2022 character transfer syntax では使えません。 ISO/IEC 2022 A.3.2

処理

ISO/IEC 2022 decoder

関連

[38] ISO/IEC 2022 を使用する場面によっては、 使用する符号化システムを指定する方法が別途用意されているかもしれません。 また、 ISO/IEC 2022 にも ISO/IEC 2022 符号化データ要素列の終わりを示す CMD という制御機能があります。 このようなものを使用して ISO/IEC 2022 とそれ以外を区別できる環境では、それを使って構いません。 特別そのような方法が用意されていない場合は、 DOCS を使って符号化システムを切換えることにしても構いません。

メモ