アナウンサー

符号構造機能の告知

0F型エスケープシーケンス

[1] 0Fエスケープ・シーケンスは、 告知 (ANNOUNCE CODE STRUCTURE) に使われます。

[2] 仕様書:

[3] 構文:

告知 (ISO/IEC 2022)

[4] 告知 = 符号構造機能の告知

名前
ANNOUNCE CODE STRUCTURE
日本語通用名称
符号構造アナウンス
略号
ACS
符号化表現
ESC 02/00 F

[5] ISO/IEC 2022 の announce(r) を、 JIS X 0202:1998 はそのまま アナウンス (アナウンサー)としているが、ここでは告知と訳す。

仕様書

構文

[11] 構文 >>6

[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] 先頭で使う想定なのに情報交換の中途で出現したときや、 使う想定がないのに出現したときや、 想定外の告知シーケンスが出現したときに、 どう扱うべきかは不明です。 ISO/IEC 2022 のエラー処理の項

[20] 実際の情報交換ではなく、 符号化文字集合を規定する仕様書において符号構造の説明のために使うことがあります。

[21] 例えば ISO-2022-JP を規定する RFC 1468Background Information の項に記述されています。

[41] ctext の仕様書にもあります。

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

[60] GB 8565.2告知シーケンス7ビット符号8ビット符号を区別するとしています。

[61] ISO-2022-ESC B

意味

構造番号F使用する符号要素シフト機能
104/01GL == G0なし
204/02GL = G0, G1 SI/LS0, SO/LS1
304/03(8ビット) GL == G0, GR == G1なし
404/04(7ビット) 2と同じ / (8ビット) 3と同じ
504/057ビット・8ビット間変換で完全に保持
604/06C1 == ESC FeESC Fe
704/07(7ビット) C1 == ESC Fe / (8ビット) C1 == CR
804/08図形文字集合は全て94集合
904/09G1〜G3 は94集合または96集合
1004/107ビット
1104/118ビット
1204/12ISO/IEC 4873 実装水準1
1304/13ISO/IEC 4873 実装水準2
1404/14ISO/IEC 4873 実装水準3
1605/00+G0SI/LS0
1805/02+G1SO/LS1
1905/03+G1SO/LS1R
2005/04+G2LS2
2105/05+G2LS2/LS2R
2205/06+G3LS3
2305/07+G3LS3/LS3R
2605/10+G2SS2
2705/11+G3SS3
2805/12SS2/SS3 の後 GR を使用

1,3,4と16,18〜23は併用不能, 12〜14は他と併用不能

[14] 複数の組合せ: 告知機能は複数回続けて使用できます JIS X 0202:1998 15.1。 しかし、幾つかの機能は同時に使用できないと規定されています >>10 15.2.2

[15]

機能番号終端バイト機能 (7ビット)機能 (8ビット)同時使用禁止
104/01G0 = GL, ×固定シフトG0 = GL, ×固定シフト, ×GR12, 13, 14, 16, 18〜23
204/02G0, G1, SI, SO >>8G0, G1, LS0, LS1R >>712, 13, 14
304/03×G0, ×G1, ×固定シフトG0 = GL, G1 = GR, ×固定シフト12, 13, 14, 16, 18〜23
404/04G0, G1, SI, SO >>8G0 = GL, G1 = GR, ×固定シフト12, 13, 14, 16, 18〜23
504/057ビット・8ビットデータ変換。すべてのシフト機能を維持。12, 13, 14
604/06C1 = ESC Fe12, 13, 14
704/07C1 = ESC FeC1 = CR12, 13, 14
804/08図形文字集合は94文字12, 13, 14
904/09図形文字集合は94文字及び/又は96文字12, 13, 14
1004/107ビット符号だけを使用12, 13, 14
1104/118ビット符号を使用12, 13, 14
1204/12ISO/IEC 4873 実装水準113, 14
1304/13ISO/IEC 4873 実装水準212, 14
1404/14ISO/IEC 4873 実装水準312, 13
1504/15(予約)12, 13, 14
1605/00G0, SIG0, LS01, 3, 4, 12, 13, 14
1705/01(予約)12, 13, 14
1805/02G1, SOG1, LS11, 3, 4, 12, 13, 14
1905/03G1, SOG1, LS1R1, 3, 4, 12, 13, 14
2005/04G2, LS2G2, LS21, 3, 4, 12, 13, 14
2105/05G2, LS2G2, LS2R1, 3, 4, 12, 13, 14
2205/06G3, LS3G3, LS31, 3, 4, 12, 13, 14
2305/07G3, LS3G3, LS3R1, 3, 4, 12, 13, 14
2405/08(予約)12, 13, 14
2505/09(予約)12, 13, 14
2605/10G2, SS212, 13, 14
2705/11G3, SS312, 13, 14
2805/11単独シフト領域GR
29〜6205/1207/14(予約)12, 13, 14

[16] 2番は JIS X 0202:1998 で LS1G1GR に呼び出す と書かれており、図も LS1 になっていますが、呼出(図もそうなっています。) なら LS1R だと思われます。

[7] 2番と4番は7ビット符号では同じですが、 変換前の8ビット符号の構造の情報を保存するために用意されています。 >>10 15.2.2

[53] ISO/IEC 2022 では私用終端バイトは認められているようには読めませんが Fp VT で 3/6, 3/7 の利用例があります。 VT

[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

DECTC1 = 3/6FeC1 とする & CRC0 とする

DECAC1 = 3/7CR & FeC1 とする

処理

[22] 告知シーケンスを受信した時、それをどう解釈することが期待されているのかは、 ISO/IEC 2022 仕様書上不明瞭です。

[23] 情報交換の先頭で符号構造を明示することで、 装置が正しく処理できない符号化文字データ要素の出現が予想されるとき、 そのようなデータの受信を拒絶するような使い方が想定されているのでしょうか。 ISO/IEC 2022 のエラー処理の項

[25] 告知シーケンスの後に、それと矛盾する符号化文字データ要素が出現したとき、 装置が何をどうするべきなのかも不明です。 例えば G2 を使用しないと定められているにも関わらず、 G2指示シーケンスが出現したり、 SS2 が使われたりするとき、 何がなされるべきかは不明です。

[27] 矛盾する複数の告知シーケンスを使用することは禁止されていますが、 それが出現したときの処理方法も不明です。

[26] 符号構造を通知するだけで規定するものではないのですから、 矛盾しても通常通りに処理するのが穏当でしょうか。

[31] いくつかの告知は、固定シフト等を使用しない符号構造を決定するものとなっています。 ISO/IEC 2022 を受信する実装が初期状態から符号の解釈が可能な状態に遷移する必要があると考えると、 次のような処理が必要となります。

[55] ISO/IEC 2022 の標準の告知および VT3/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}

[58] 副作用で指示するのは ISO/IEC 4873 にない独自仕様。 現行 ISO/IEC 4873 では G0US-ASCII だが以前の版では制限が緩かった (ISO/IEC 646の版相当)。 G1 は現行版でも制限なし。 ISO/IEC 4873告知のあとすべて指示シーケンスを明示することを求めている。
[149] Very old fj.kanji discussion 13/622, , https://ie.u-ryukyu.ac.jp/~kono/fj/fj.kanji/13.html

以上のように、使いたい図形文字セットをバッファに指示し、コード表へ呼 び出して使うのが正式なのだが、それは面倒という場合には、あるバッファは あるコード表に直結していて、指示しただけで即使えるという方法もある。そ れには使う前にアナウンサというのを送る。例えばESC 2/0 4/1を 送ると、これは「バッファはG0しか使わない、そのかわり、G0へ指示した ものは7単位環境ではすぐコード表へ呼び出す。8単位ではG0へ指示したも のを左のコード表へ呼び出す」という約束をする。アナウンサにはまだ沢山あ るがそれはJIS C6228の8章を見てほしい。しかし上には上があって、 情報交換当事者間の合意があればアナウンサも省略してよいことになっている。

[62] この著者は当時この分野一線の専門家だった和田英一

メモ