[1] 0F
型エスケープ・シーケンスは、
告知 (ANNOUNCE CODE STRUCTURE
)
に使われます。
[2] 仕様書:
[3] 構文:
エスケープ・シーケンス /= 0F 型エスケープ・シーケンス
0F 型エスケープ・シーケンス := ACS / 0F 型予約エスケープ・シーケンス
ACS := 標準 ACS / 私用 ACS ;; ANNOUNCE CODE STRUCTURE
標準 ACS := ESC
%x20 Ft
私用 ACS := ESC
%x20 *I Fp
0F 型予約エスケープ・シーケンス := ESC
%x20 1*I Ft
I := %x20-2F ;; 中間バイト
Fp := %x30-3F ;; 私用終端バイト
Ft := %x40-7E ;; 標準終端バイト
[5] ISO/IEC 2022 の announce(r) を、 JIS X 0202:1998 はそのまま
アナウンス (アナウンサー)
としているが、ここでは告知
と訳す。
[13]
終端バイト:
終端バイト F
は
1〜62 の番号が付けられており、 1 が
04/01
に、 62 が 07/14
によって表現されます。各番号の意味は ISO/IEC 2022
で規定されており、将来追加の機能が必要になったときは
ISO/IEC 2022 が改訂されることが示唆されています。
登録制度はありません。
>>10 15.2.2
[12] 符号識別機能は、情報交換の開始時に文字符号化情報に埋込んで、 後続のデータで使用される符号構造機能を告知します。 >>10 15.1
[17] 現実にはほとんど利用されている例は無いようです。
[18] 通常情報交換の先頭で使うことが想定されますが、 使わなければならないものでもありません。 いつどう使うかは応用依存と思われます。
[19]
先頭で使う想定なのに情報交換の中途で出現したときや、
使う想定がないのに出現したときや、
想定外の告知シーケンスが出現したときに、
どう扱うべきかは不明です。
[20] 実際の情報交換ではなく、 符号化文字集合を規定する仕様書において符号構造の説明のために使うことがあります。
[21] 例えば ISO-2022-JP を規定する RFC 1468 の Background Information の項に記述されています。
[59] ISO/IEC 2022 character transfer syntax では使えません。 ISO/IEC 2022 A.3.2
構造番号 | F | 使用する符号要素 | シフト機能 |
1 | 04/01 | GL == G0 | なし |
2 | 04/02 | GL = G0, G1 | SI /LS0 , SO /LS1 |
3 | 04/03 | (8ビット) GL == G0, GR == G1 | なし |
4 | 04/04 | (7ビット) 2と同じ / (8ビット) 3と同じ | |
5 | 04/05 | 7ビット・8ビット間変換で完全に保持 | |
6 | 04/06 | C1 == ESC Fe | ESC Fe |
7 | 04/07 | (7ビット) C1 == ESC Fe / (8ビット) C1 == CR | |
8 | 04/08 | 図形文字集合は全て94集合 | |
9 | 04/09 | G1〜G3 は94集合または96集合 | |
10 | 04/10 | 7ビット | |
11 | 04/11 | 8ビット | |
12 | 04/12 | ISO/IEC 4873 実装水準1 | |
13 | 04/13 | ISO/IEC 4873 実装水準2 | |
14 | 04/14 | ISO/IEC 4873 実装水準3 | |
16 | 05/00 | +G0 | SI /LS0 |
18 | 05/02 | +G1 | SO /LS1 |
19 | 05/03 | +G1 | SO /LS1R |
20 | 05/04 | +G2 | LS2 |
21 | 05/05 | +G2 | LS2 /LS2R |
22 | 05/06 | +G3 | LS3 |
23 | 05/07 | +G3 | LS3 /LS3R |
26 | 05/10 | +G2 | SS2 |
27 | 05/11 | +G3 | SS3 |
28 | 05/12 | SS2 /SS3 の後 GR を使用 |
1,3,4と16,18〜23は併用不能, 12〜14は他と併用不能
[14] 複数の組合せ: 告知機能は複数回続けて使用できます JIS X 0202:1998 15.1。 しかし、幾つかの機能は同時に使用できないと規定されています >>10 15.2.2。
機能番号 | 終端バイト | 機能 (7ビット) | 機能 (8ビット) | 同時使用禁止 |
1 | 04/01 | G0 = GL, ×固定シフト | G0 = GL, ×固定シフト, ×GR | 12, 13, 14, 16, 18〜23 |
2 | 04/02 | G0, G1, SI , SO >>8 | G0, G1, LS0 , LS1R >>7 | 12, 13, 14 |
3 | 04/03 | ×G0, ×G1, ×固定シフト | G0 = GL, G1 = GR, ×固定シフト | 12, 13, 14, 16, 18〜23 |
4 | 04/04 | G0, G1, SI , SO >>8 | G0 = GL, G1 = GR, ×固定シフト | 12, 13, 14, 16, 18〜23 |
5 | 04/05 | 7ビット・8ビットデータ変換。すべてのシフト機能を維持。 | 12, 13, 14 | |
6 | 04/06 | C1 =
| 12, 13, 14 | |
7 | 04/07 | C1 =
| C1 = CR | 12, 13, 14 |
8 | 04/08 | 図形文字集合は94文字 | 12, 13, 14 | |
9 | 04/09 | 図形文字集合は94文字及び/又は96文字 | 12, 13, 14 | |
10 | 04/10 | 7ビット符号だけを使用 | 12, 13, 14 | |
11 | 04/11 | 8ビット符号を使用 | 12, 13, 14 | |
12 | 04/12 | ISO/IEC 4873 実装水準1 | 13, 14 | |
13 | 04/13 | ISO/IEC 4873 実装水準2 | 12, 14 | |
14 | 04/14 | ISO/IEC 4873 実装水準3 | 12, 13 | |
15 | 04/15 | (予約) | 12, 13, 14 | |
16 | 05/00 | G0, SI | G0, LS0 | 1, 3, 4, 12, 13, 14 |
17 | 05/01 | (予約) | 12, 13, 14 | |
18 | 05/02 | G1, SO | G1, LS1 | 1, 3, 4, 12, 13, 14 |
19 | 05/03 | G1, SO | G1, LS1R | 1, 3, 4, 12, 13, 14 |
20 | 05/04 | G2, LS2 | G2, LS2 | 1, 3, 4, 12, 13, 14 |
21 | 05/05 | G2, LS2 | G2, LS2R | 1, 3, 4, 12, 13, 14 |
22 | 05/06 | G3, LS3 | G3, LS3 | 1, 3, 4, 12, 13, 14 |
23 | 05/07 | G3, LS3 | G3, LS3R | 1, 3, 4, 12, 13, 14 |
24 | 05/08 | (予約) | 12, 13, 14 | |
25 | 05/09 | (予約) | 12, 13, 14 | |
26 | 05/10 | G2, SS2 | 12, 13, 14 | |
27 | 05/11 | G3, SS3 | 12, 13, 14 | |
28 | 05/11 | 単独シフト領域は GR | ||
29〜62 | 05/12 〜07/14 | (予約) | 12, 13, 14 |
[16]
2番は JIS X 0202:1998 で
と書かれており、図も LS1
が G1 を GR に呼び出すLS1
になっていますが、右に呼出す
(図もそうなっています。) なら
LS1R
だと思われます。
[7] 2番と4番は7ビット符号では同じですが、 変換前の8ビット符号の構造の情報を保存するために用意されています。 >>10 15.2.2
[53]
ISO/IEC 2022
では私用終端バイトは認められているようには読めませんが
[57] Digital Ansi-Compliant Print Protocol Lev 2 Program. Ref. Man. - PPLV2PMB.PDF, , http://sup.xenya.si/sup/info/digital/MDS/jun99/Cd3/PRINTER/PPLV2PMB.PDF#page=103
[22] 告知シーケンスを受信した時、それをどう解釈することが期待されているのかは、 ISO/IEC 2022 仕様書上不明瞭です。
[23]
情報交換の先頭で符号構造を明示することで、
装置が正しく処理できない符号化文字データ要素の出現が予想されるとき、
そのようなデータの受信を拒絶するような使い方が想定されているのでしょうか。
[25]
告知シーケンスの後に、それと矛盾する符号化文字データ要素が出現したとき、
装置が何をどうするべきなのかも不明です。
例えば G2 を使用しないと定められているにも関わらず、
G2 の指示シーケンスが出現したり、
SS2
が使われたりするとき、
何がなされるべきかは不明です。
[27] 矛盾する複数の告知シーケンスを使用することは禁止されていますが、 それが出現したときの処理方法も不明です。
[26] 符号構造を通知するだけで規定するものではないのですから、 矛盾しても通常通りに処理するのが穏当でしょうか。
[31] いくつかの告知は、固定シフト等を使用しない符号構造を決定するものとなっています。 ISO/IEC 2022 を受信する実装が初期状態から符号の解釈が可能な状態に遷移する必要があると考えると、 次のような処理が必要となります。
SPACE
, DELETE
を使用するとされているもの[55] ISO/IEC 2022 の標準の告知および VT の 3/6, 3/7 は、いずれも ISO/IEC 2022 の符号構造に関係する記述です。 ISO/IEC 2022 の符号化文字データ要素の列を解釈して他の形式に変換する場合には、 完全に除去してしまっても構わないと考えられます。
[54] Xterm Control Sequences, , https://www.xfree86.org/current/ctlseqs.html
F, G, L, M, N に対応。
[56] Digital Ansi-Compliant Print Protocol Lev 2 Program. Ref. Man. - PPLV2PMB.PDF, , http://sup.xenya.si/sup/info/digital/MDS/jun99/Cd3/PRINTER/PPLV2PMB.PDF#page=92
4/12, 4/13, 4/14 に対応: {GL = G0 = ASCII; GR = G1 = Latin-1}