[32]
DOCS
(DESIGNATE OTHER CODING SYSTEM)
は、
ISO/IEC 2022 や
ISO/IEC 2022 以外の文字コード体系を相互に切り替えるエスケープシーケンスです。
[37]
DOCS は ISO/IEC 2022
以外の符号化システムを指示し、同時に呼出すことができます。
他の符号化システムは文字符号以外のものも構いません。
JIS X 0202:1998 15.4.1
[36] 仕様書:
[39] 終端バイト: 符号化システムは (必要なら中間バイトと) 終端バイトで識別されます。 終端バイト Ft は ISO-IR に登録されます。
[34] ISO/IEC2022 1994 15.4
ISO/IEC 2022 に適合しない符号化体系 Coding System を指示・呼び出ししたり、 ISO/IEC 2022 に戻ってきたりします。
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] 仕様書:
エスケープ・シーケンス /= 5F 型エスケープ・シーケンス5F 型エスケープ・シーケンス := DOCS / 5F 型予約エスケープ・シーケンスDOCS := 標準 DOCS / 私用 DOCS ;; DESIGNATE OTHER CODING SYSTEM標準 DOCS := ESC %x25 [%x2F] [%x21-23 *I] Ft私用 DOCS := ESC %x25 *I Fp5F 型予約エスケープ・シーケンス := ESC %x21 (%x20 / %x24-2E / %x2F (%x20 / %x24-2F)) *I FtI := %x20-2F ;; 中間バイトFp := %x30-3F ;; 私用終端バイトFt := %x40-7E ;; 標準終端バイト[44]
ESC 2/5 F
は標準復帰で
ISO/IEC 2022
に切り替えられるものとされます。
| ESC 02/05 | 2 | 3 | 4 | 5 | 6 | 7 |
|---|---|---|---|---|---|---|
| 0 | I | return | ISO 2022 | |||
| 1 | moe | 108 | ||||
| 2 | 178 | |||||
| 3 | 131 | |||||
| 4 | NAPLPS | 145 | ||||
| 5 | 160 | |||||
| 6 | 161 | |||||
| 7 | 196 | |||||
| 8 | ※ | 188 | ||||
| 9 | ||||||
| 10 | ||||||
| 11 | ||||||
| 12 | ||||||
| 13 | Proprinter | |||||
| 14 | ||||||
| 15 | n/s | --- |
| ISO-IR | エスケープシーケンス | 符号化システム |
|---|---|---|
| --- | ESC 02/05 04/00 | ISO/IEC 2022 |
| 108 | ESC 02/05 04/01 | NAPLPS |
| 178 | ESC 02/05 04/02 | UTF-1 |
| 131 | ESC 02/05 04/03 | Data Syntax I of CCITT Rec. T.101. |
| 145 | ESC 02/05 04/04 | Data Syntax II of CCITT Rec. T.101. |
| 160 | ESC 02/05 04/05 | Photo-Videotex Data Syntax of CCITT Recommendation T.101. |
| 161 | ESC 02/05 04/06 | Audio Data Syntax of CCITT Recommendation T.101. |
| 196 | ESC 02/05 04/07 | UTF-8 with standard return (実装水準指定なし) |
| 186 | ESC 02/05 04/08 | VEMMI Data Syntax of (draft) ITU-T Recommendation |
| ESC 02/05 05/hh | T.100 >>113 |
[45]
ESC 2/5 2/15 F
は標準復帰で
ISO/IEC 2022
に切り替えられないものとされます。
| ESC 02/05 02/15 | 3 | 4 | 5 | 6 | 7 |
|---|---|---|---|---|---|
| 0 | xseg | 162 | |||
| 1 | xseg | 163 | |||
| 2 | xseg | 125 | |||
| 3 | xseg | 174 | |||
| 4 | xseg | 175 | |||
| 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 復帰 |
|---|---|---|---|
| 162 | ESC 02/05 02/15 04/00 | ISO/IEC 10646:1993, UCS-2, Level1 | ESC U+0025 U+0040 |
| 163 | ESC 02/05 02/15 04/01 | ISO/IEC 10646:1993, UCS-4, Level1 | ESC U+0025 U+0040 |
| 125 | ESC 02/05 02/15 04/02 | Virtual Terminal Service Transparent Set | 復帰なし |
| 174 | ESC 02/05 02/15 04/03 | ISO/IEC 10646:1993, UCS-2, Level2 | ESC U+0025 U+0040 |
| 175 | ESC 02/05 02/15 04/04 | ISO/IEC 10646:1993, UCS-4, Level2 | ESC U+0025 U+0040 |
| 176 | ESC 02/05 02/15 04/05 | ISO/IEC 10646:1993, UCS-2, Level3 | ESC U+0025 U+0040 |
| 177 | ESC 02/05 02/15 04/06 | ISO/IEC 10646:1993, UCS-4, Level3 | ESC U+0025 U+0040 |
| 190 | ESC 02/05 02/15 04/07 | UTF-8 level 1, without standard return | ESC U+0025 U+0040 |
| 191 | ESC 02/05 02/15 04/08 | UTF-8 level 2, without standard return | ESC U+0025 U+0040 |
| 192 | ESC 02/05 02/15 04/09 | UTF-8 level 3, without standard return | ESC U+0025 U+0040 |
| 193 | ESC 02/05 02/15 04/10 | UTF-16 level 1, without standard return | ESC U+0025 U+0040 |
| 194 | ESC 02/05 02/15 04/11 | UTF-16 level 2, without standard return | ESC U+0025 U+0040 |
| 195 | ESC 02/05 02/15 04/12 | UTF-16 level 3, without standard return | ESC U+0025 U+0040 |
[2] 終端バイト 7/14 については空集合 (ISO/IEC 2022)参照。
[117] Unicode になる前の DIS 10646 は、本来4オクテットの符号を符号短縮法により2オクテットに縮小することを表す、
というエスケープシーケンスがあったそうです。
F2 は未定の終端バイト。
HOP は 8/1。
G, 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 に送付されたものの、 なぜか登録されなかった模様。
[10] 初期の ISO 2022 では終端バイトが指示・呼び出しする符号のビット数によって割り当てることになっていました。 すなわち、 >>9
[11] ビット長の異なるデータをどのように混在させる想定だったのかは不明です。
[12] 当時の ISO 2022 には ISO 2022 への復帰のシーケンスが規定されていませんでした。 ISO 2022 自身の7ビット符号と8ビット符号の切り替えの方法も用意されていませんでした。
[16]
JIS X 4151
が
ESC 2/5 4/0 を未登録の128文字の文字集合と説明するのは、
この時代の仕様に基づく説明っぽいです。
[20] 実際にはこの規定に基づき ISO-IR に登録された終端バイトは1つもありません。
[40]
ISO/IEC 2022 の終端バイト:
中間バイトなし、終端バイト 04/00
(つまり ESC 02/05 04/00ACS)
により設定した状態と符号化図形文字集合と符号化制御機能集合の指示・呼出しの状態を指します。
現在位置などがどうなるかは 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/15 な DOCS
を使う他の符号化システムは、 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 系、 Videotex、 libmoe と約半数の符号化系が 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
が使われていますが、
私用終端バイトの利用例として示されているだけで、
特に意味はなさげです。
[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
[111]
Videotex は ISO/IEC 2022 ベースの符号と独自の符号の混在でした。
各種符号を
DOCS (標準復帰あり)
で切り替えられるとされていました (少なくても仕様書の上では)。
[113]
他に T.100 が
ESC 2/5 5/h
と規定していました。
該当する終端バイトは登録されておらず、
仕様策定が頓挫したものと思われます。
これは実質的には
alphageometric coding scheme
という96集合 (図形文字集合ではない)
の指示として機能するものでした。
標準復帰すら待たずに G1 への指示で終了します。
[114]
他にも NAPLPS で独自のエスケープシーケンスが用いられたとする説があります。
[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)
[58]
ESC 2/5 3/13 :
IBM Proprinter Emulation mode
>>15
[60] DEC PPL で使われます。標準復帰とほか2種類以外の DEC PPL エスケープシーケンスは認識しなくなります。 (利用可能な CSI も CR でなく 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
ESC 2/5 3/0 - DECTCS (Exit NAPLPS)ESC 2/5 3/4 - DECSCCS (Enter NAPLPS)ESC 2/5 3/8 -
DECHPPCL (Enter HP PCL emulation mode)[124] Control functions - akinomyoga/contra, , https://akinomyoga.github.io/contra/escseq.html#dfn.DOCS
[64]
X の Compound Text では
extended segment
に
DOCS が使われます。
他で表せない文字に使います。
>>3
[68] M と L は長さを表す各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 は仕様全体がドラコニアンエラー処理を採用しており >>3、
DOCS やそれ以後が指定された構文に合わない時の処理は規定されていません。
[70] encoding name はISO 8859-1 で記述します。 >>3
[101] encoding name は登録簿のものであるべきです。 >>3 次のものが登録されています。 >>83
| encoding name | 登録簿の説明 | メモ |
|---|---|---|
DEC.CNS11643.1986-2 | CNS11643 2-plane using the recommended internal representation scheme | DEC Hanyu CNS 第2面 |
DEC.DTSCS.1990-2 | DEC Taiwan Supplemental Character Set | DTSCS |
fujitsu.u90x03 | U90 CS3 | |
ILA | registry prefix | |
IPSYS | registry prefix | |
omron_UDC | omron User Defined Charset | |
omron_UDC_ja | omron User Defined Charset for Japanese | |
omron_UDC_zh | omron User Defined Charset for Chinese(Main land) | |
omron_UDC_tw | omron User Defined Charset for Chinese(Taiwan) |
[75] 「registry prefix」は DEC. のように名前の接頭辞に使うもののようです。
2つ登録されていますが、それを接頭辞とする実際の値があるのかは不明です。
[102]
現在オープンソースで公開されている X の実装中で発見できるのはこのうち
fujitsu.u90x03
だけです。それ以外は非公開の商用製品などで使われていたのでしょうか。
[103] 現在オープンソースで公開されている X の実装中には次のものがあります。
iso8859-14iso8859-15big5hkscs-0georgian-academygeorgian-psibm-cp1133isiri-3342iso8859-9efujitsu.u90x03microsoft-cp1251microsoft-cp1255microsoft-cp1256viscii1.1-1[104] 現在オープンソースで公開されている X の実装ではソースコード中にハードコードされているものと、 ロケールを定義するテキストファイルから読み込んで定められるものがあります。 X を利用する製品や実際の運用によっては、 後者の仕組みを通じてこれら以外を使ったり、 これらの定義を修正したりすることもあるのかもしれません。
[105] 現在オープンソースで公開されている X の実装では encoding name は定義の読み込み時点で ASCII小文字に変換したものが利用されます。 ctext の仕様には大文字と小文字の違いに言及がなく、 登録簿 (>>101) には大文字混じりのものも含まれるのですが、 X の実装によっては大文字も使えるのかもしれません。
[106]
encoding name
として
HP-UX で HP-BIG5 (バイト長可変)、
Digital UNIX BIG5-0 (バイト長2)
が使われました。
>>100
後者は >>103 にもありますが、こちらでは大文字です。
[109] 過去にはここに挙げた以外にも実装例のある encoding name が存在したかもしれません。
[110] Compound Text 仕様書にはバイト長4まで定められていますが、 3バイト、4バイトの encoding name は確認されていません。
[107]
なお、 >>83, >>99
は
942集合の GL を ESC 2/5 2/8 3/2,
GR を ESC 2/5 2/15 3/2
と書いて区別しています。
前者は何らかの誤りなのか、あるいは過去にそう実装していたものがあったのか不明です。
/* Registered encodings with a varying number of bytes per character */
{ "ISO10646-1", /* UTF-8 196 */ "\033%G" },
/* Encodings without ISO-IR assigned escape sequence must be
defined in XLC_LOCALE files, using "\033%/1" or "\033%/2". */
/* Backward compatibility with XFree86 3.x */
#if 1
{ "ISO8859-14:GR", "\033%/1" },
{ "ISO8859-15:GR", "\033%/1" },
#endif
/* For use by utf8 -> ctext */
{ "BIG5-0:GLGR", "\033%/2"},
{ "BIG5HKSCS-0:GLGR", "\033%/2"},
{ "GBK-0:GLGR", "\033%/2"},
/* used by Emacs, but not backed by ISO-IR */
{ "BIG5-E0:GL", "\033$(0" },
{ "BIG5-E0:GR", "\033$)0" },
{ "BIG5-E1:GL", "\033$(1" },
{ "BIG5-E1:GR", "\033$)1" },
};
/* We represent UTF-8 as an XlcGLGR charset, not in extended segments. */
#define UTF8_IN_EXTSEQ 0XLC_CHARSET_DEFINE
csd0 {
charset_name ARMSCII-8
side GR
length 1
string_encoding False
sequence \x1b%/1
}
END XLC_CHARSET_DEFINEXLC_CHARSET_DEFINE
csd0 {
charset_name GEORGIAN-ACADEMY
side GR
length 1
string_encoding False
sequence \x1b%/1
}
END XLC_CHARSET_DEFINEXLC_CHARSET_DEFINE
csd0 {
charset_name GEORGIAN-PS
side GR
length 1
string_encoding False
sequence \x1b%/1
}
END XLC_CHARSET_DEFINEXLC_CHARSET_DEFINE
csd0 {
charset_name IBM-CP1133
side GR
length 1
string_encoding False
sequence \x1b%/1
}
END XLC_CHARSET_DEFINEXLC_CHARSET_DEFINE
csd0 {
charset_name ISCII-DEV
side GR
length 1
string_encoding False
sequence \x1b%/1
}
END XLC_CHARSET_DEFINEXLC_CHARSET_DEFINE
csd0 {
charset_name ISIRI-3342
side GR
length 1
string_encoding False
sequence \x1b%/1
}
END XLC_CHARSET_DEFINEXLC_CHARSET_DEFINE
csd0 {
charset_name ISO8859-9E
side GR
length 1
string_encoding False
sequence \x1b%/1
}
END XLC_CHARSET_DEFINEXLC_CHARSET_DEFINE
csd0 {
charset_name u90x03.1991-0
side GL
length 2
gc_number 94
string_encoding False
sequence \x1b\x25\x28\x32
encoding_name fujitsu.U90X03
}
csd1 {
charset_name u90x03.1991-0
side GR
length 2
gc_number 94
string_encoding False
sequence \x1b\x25\x2f\x32
encoding_name fujitsu.U90X03
}
END XLC_CHARSET_DEFINEXLC_CHARSET_DEFINE
csd0 {
charset_name KOI8-C
side GR
length 1
string_encoding False
sequence \x1b%/1
}
END XLC_CHARSET_DEFINEXLC_CHARSET_DEFINE
csd0 {
charset_name KOI8-R
side GR
length 1
string_encoding False
sequence \x1b%/1
}
END XLC_CHARSET_DEFINEXLC_CHARSET_DEFINE
csd0 {
charset_name KOI8-U
side GR
length 1
string_encoding False
sequence \x1b%/1
}
END XLC_CHARSET_DEFINEXLC_CHARSET_DEFINE
csd0 {
charset_name MICROSOFT-CP1251
side GR
length 1
string_encoding False
sequence \x1b%/1
}
END XLC_CHARSET_DEFINEXLC_CHARSET_DEFINE
csd0 {
charset_name MICROSOFT-CP1255
side GR
length 1
string_encoding False
sequence \x1b%/1
}
END XLC_CHARSET_DEFINEXLC_CHARSET_DEFINE
csd0 {
charset_name MICROSOFT-CP1256
side GR
length 1
string_encoding False
sequence \x1b%/1
}
END XLC_CHARSET_DEFINEXLC_CHARSET_DEFINE
csd0 {
charset_name MULELAO-1
side GR
length 1
string_encoding False
sequence \x1b%/1
}
END XLC_CHARSET_DEFINEXLC_CHARSET_DEFINE
csd0 {
charset_name NOKHCHI-1
side GR
length 1
string_encoding False
sequence \x1b%/1
}
END XLC_CHARSET_DEFINEXLC_CHARSET_DEFINE
csd0 {
charset_name TATAR-CYR
side GR
length 1
string_encoding False
sequence \x1b%/1
}
END XLC_CHARSET_DEFINEXLC_CHARSET_DEFINE
csd0 {
charset_name TSCII-0
side GR
length 1
string_encoding False
sequence \x1b%/1
}
END XLC_CHARSET_DEFINEXLC_CHARSET_DEFINE
csd0 {
charset_name TCVN-5712
side GR
length 1
string_encoding False
sequence \x1b%/1
}
END XLC_CHARSET_DEFINEXLC_CHARSET_DEFINE
csd0 {
charset_name VISCII1.1-1
side GR
length 1
string_encoding False
sequence \x1b%/1
}
END XLC_CHARSET_DEFINEBecause there is no standard encoding in Traditional Chinese environments, Exceed can support only one encoding name at a time. By default, Exceed supports the HP-BIG5 (HP Traditional Chinese Environment) encoding. If you want to use the BIG5-0 (Digital Traditional Chinese Environment) encoding, you need to make changes to the Exceed initialization file and the
xlc_localefile.• # used for HP-UX
• # ct_encoding HP-BIG5:GLGR:\x1b\x25\x2f\x30\x80\x8aHP-BIG5\x02
• # used for Digital UNIX
• ct_encoding BIG5-0:GLGR:\x1b\x25\x2f\x32\x80\89BIG5-0\x02
[26]
文字コード変換ライブラリー libmoe は ISO/IEC 2022
と他のいくつかの文字コード体系に対応しており、
DOCS の独自構文 (私用終端バイト)
で相互に切り替えられます。
>>5
[27] ISO/IEC 2022, UTF-8, UTF-16 以外は独自の構文:
... を使います。 >>5
x-moe-internal[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-TW と x-euc-jisx0213-packed
は ISO/IEC 2022 の符号構造から逸脱していないので、
本来 DOCS にしなければならない理由はありません。
ここで DOCS が用いられたのは、
これらが正規の終端バイトを用いた指示シーケンスで記述できない符号化文字集合を使っているからでしょう。
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
[38]
ISO/IEC 2022 を使用する場面によっては、
使用する符号化システムを指定する方法が別途用意されているかもしれません。
また、 ISO/IEC 2022 にも ISO/IEC 2022
符号化データ要素列の終わりを示す
CMD という制御機能があります。
このようなものを使用して ISO/IEC 2022
とそれ以外を区別できる環境では、それを使って構いません。
特別そのような方法が用意されていない場合は、
DOCS を使って符号化システムを切換えることにしても構いません。