Edit

Page

Page title:

Page body:

[7] [DFN[[RUBYB[[[エスケープシーケンス]]]@en[escape sequence]]]]は、
[CODE(charname)@en[[[ESCAPE]]]] から始まり、0個[[以上]]の[[中間バイト]]と1つの[[終端バイト]]によって構成される[[バイト列]]です。
[[ISO/IEC 2022]] [[符号拡張法]]に従う[[文字集合]]の指定や、
[[制御機能]]の[[呼び出し]]などに用います。

* 仕様書

[REFS[
- [19] [[ISO/IEC 10646]]
-- [53] 旧版: [[GB 13000.1-93]] 附录G
-- [18] 旧版: [[JIS X 0221:2007]] 16
-- [38] 旧版: [[JIS X 0221:2007]] C.5
-- [42] 旧版: [[JIS X 0221:2007]] D.6
-- [55] 旧版: [[ISO/IEC 10646:2011]] 12

]REFS]

* 意味

[15]
>
:エスケープシーケンス (escape sequence):
[[符号拡張手順]]において[[制御]]のために[[使用]]する一つ以上の[[ビット組合せ]]。
先頭の[[ビット組合せ]]は、[[制御文字]] [CODE(charname)[[[ESCAPE]]]]
([CODE(jcharname)[[[エスケープ]]]]) を[[表現]]する。
- 参考 この規格では、 [CODE(charname)[[[ESCAPE]]]] は、
常に[[制御文字]]として[[引用]]される。
[SRC[[[JIS X 0202]]:1998 4.13]]

[1] 
>
:3.1 エスケープシーケンス (escape sequence):
[[符号拡張手順]]において[[制御]]のために使用する一つ以上の[[ビット組合せ]]。
先頭の[[ビット組合せ]]は、
[[制御文字]] [CODE(charname)@en[[[ESCAPE]]]] 
([CODE(jcharname)@en[[[エスケープ]]]]) 
を[[表現]]する。
[SRC[[[JIS X 0201]]:1997 3.1]]

* 構文

[10]
[SRC[[[JIS X 0202]]:1998 13.1]]:
- [CODE(ABNF)[[DFN[エスケープ・シーケンス]] := [CODE(charname)[[[ESCAPE]]]] *I F]]
-- [[バイト列]]。[[8ビット符号]]では8ビット、[[7ビット符号]]では7ビットの列。
- [CODE(ABNF)[[DFN[I]] := %x20-2F [CODE(comment)[;; [[中間バイト]]]]]]
- [CODE(ABNF)[[DFN[F]] := %x30-7E [CODE(comment)[;; [[終端バイト]]]]]]

[11]
[[エスケープ・シーケンス]]を構成する各[[ビット組合せ]]は、
それ単独で出現した時の意味とは無関係で、
[[エスケープ・シーケンス]]全体だけで意味が決まります。
[SRC[[[JIS X 0202]]:1998 13.1]]

[12]
>>10 に当てはまらない[[バイト]]が[[エスケープ・シーケンス]] (のようなもの)
に含まれるかもしれません。
[[応用]]は[[誤り]]を識別して回復する手段を提供する必要があるかもしれませんが、
それは [[ISO/IEC 2022]] の適用範囲外とされています。
[SRC[[[JIS X 0202]]:1998 13.1]]

[3] '''エスケープ・シーケンスの種類''':
エスケープ・シーケンスは、 [CODE(charname)@en[[[ESC]]]]
の直後の[[ビット組合せ]]により次の通り分類されます
[SRC[[[JIS X 0202]]:1998 13.2.1, 13.2.2]]。
,種類,[CODE(charname)@en[[[ESC]]]] の次のビット組合せ,機能
,[CODE@en[[[0F]]]],[CODE(char)[02/00]],[[告知]] ([CODE(charname)@en[[[ANNOUNCE CODE STRUCTURE]]]])
,[CODE@en[[[1F]]]],[CODE(char)[02/01]],[[C0]] [[指示]] ([CODE(charname)@en[[[C0-DESIGNATE]]]])
,[CODE@en[[[2F]]]],[CODE(char)[02/02]],[[C1]] [[指示]] ([CODE(charname)@en[[[C1-DESIGNATE]]]])
,[CODE@en[[[3F]]]],[CODE(char)[02/03]],[[単独制御機能]]
,[CODE@en[[[4F]]]],[CODE(char)[02/04]],[[複数バイト図形文字集合]][[指示]]
,[CODE@en[[[5F]]]],[CODE(char)[02/05]],[CODE(charname)@en[[[DESIGNATE OTHER CODING SYSTEM]]]]
,[CODE@en[[[6F]]]],[CODE(char)[02/06]],[CODE(charname)@en[[[IDENTIFY REVISED REGISTRATION]]]]
,[CODE@en[[[7F]]]],[CODE(char)[02/07]],(予約)
,[CODE@en[[[8F]]]],[CODE(char)[02/08]],[[G0]] [[指示]] ([CODE(charname)@en[[[G0-DESIGNATE 94-SET]]]])
,[CODE@en[[[9F]]]],[CODE(char)[02/09]],[[G1]] [[指示]] ([CODE(charname)@en[[[G0-DESIGNATE 94-SET]]]])
,[CODE@en[[[10F]]]],[CODE(char)[02/10]],[[G2]] [[指示]] ([CODE(charname)@en[[[G0-DESIGNATE 94-SET]]]])
,[CODE@en[[[11F]]]],[CODE(char)[02/11]],[[G3]] [[指示]] ([CODE(charname)@en[[[G0-DESIGNATE 94-SET]]]])
,[CODE@en[[[12F]]]],[CODE(char)[02/12]],[[G0]] [[指示]] ([CODE(charname)@en[[[G0-DESIGNATE 96-SET]]]])
,[CODE@en[[[13F]]]],[CODE(char)[02/13]],[[G1]] [[指示]] ([CODE(charname)@en[[[G0-DESIGNATE 96-SET]]]])
,[CODE@en[[[14F]]]],[CODE(char)[02/14]],[[G2]] [[指示]] ([CODE(charname)@en[[[G0-DESIGNATE 96-SET]]]])
,[CODE@en[[[15F]]]],[CODE(char)[02/15]],[[G3]] [[指示]] ([CODE(charname)@en[[[G0-DESIGNATE 96-SET]]]])
,[CODE@en[[[Fp]]]],[CODE(char)[03/00]]〜[CODE(char)[03/15]],[[私用制御機能]]
,[CODE@en[[[Fe]]]],[CODE(char)[04/00]]〜[CODE(char)[05/15]],[[C1]] [[制御機能]]
,[CODE@en[[[Fs]]]],[CODE(char)[06/00]]〜[CODE(char)[07/14]],[[標準単独制御機能]]

([CODE@en[[[12F]]]] は [[ISO/IEC 2022]] では予約)

[62] 長さ上限については[[中間バイト]]参照。

*誤り処理

[SEE[ [[ISO/IEC 2022]] のエラー処理の項も参照 ]]

[8] 00/00〜01/15, 07/15〜15/15 が誤って含まれた場合
[[応用]]は誤り状態の識別手段及び誤り状態からの回復手段を
提供する必要があるかもしれませんが、その様な要件は
ISO/IEC 2022 の範囲外とするとされています。 ([[JISX0202]]:1998 13.1 備考参照。)

[1] >>8 エスケープ・シーケンスに出現し得ないバイトが出てきた場合だけでなく、未知のエスケープ・シーケンスが出てきた場合の回復はどうですかね? 
これも実装依存ですかね?

* ISO/IEC 2022 エスケープシーケンスを用いた符号

[72] 
[[ISO/IEC 2022]] の符号構造に基づく[[符号]]は無数に存在し、
その形態も様々ですが、その中には
[[ISO/IEC 2022エスケープシーケンス]]や[[固定シフト]]を使って状態を切り替える特徴を有する一連の[[符号]]群が存在しています。

[73] 
歴史的に各社の [[Unix]] の多くはこの種の[[符号]]を使っていました。
[[ロケール]]により、また[[ソフトウェア]]により、
切り替えに使う[[エスケープシーケンス]]や[[固定シフト]]は少しずつ違いがあります。
また利用可能な[[符号化文字集合]]にも違いが大きいです。

[74] 
[[Emacs]] は
[DFN[[CODE[iso-2022-7bit]]]],
[DFN[[CODE[iso-2022-7bit-lock]]]],
[DFN[[CODE[iso-2022-7bit-lock-ss2]]]],
[DFN[[CODE[iso-2022-7bit-ss2]]]],
[DFN[[CODE[iso-2022-8bit-ss2]]]],
[DFN[[CODE[iso-2022-cjk]]]]
を実装しています。
また、
[CODE[junet]],
[CODE[iso-2022-cn]],
[CODE[iso-2022-cn-ext]],
[CODE[iso-2022-int-1]],
[CODE[iso-2022-jp]],
[CODE[iso-2022-jp-1978-irv]],
[CODE[iso-2022-jp-2]],
[CODE[iso-2022-jp-2004]],
[CODE[iso-2022-jp-3]],
[CODE[iso-2022-jp]],
[CODE[iso-2022-kr]]
を実装しています。

[75] [[DECの文字コード]]にも各種あります。

[76] [[符号化文字集合]]がある程度限定されたものに、
[[ISO-2022-JP]] の一族、
[[ISO-2022-CN]] の一族、
[[ISO-2022-KR]]、
[[ISO-2022-INT]]、
[[Compound Text]]、
[[ISO/IEC 4873]]、
[[VideotexString]]、
[[ARIB STD-B5]]、
[[T.61]]、
[[MARC-8]]
などがあります。

[89] 
[CITE[Mosaic-L10N: User's Guide]], [TIME[2017-09-14T23:08:44.000Z]], [TIME[2024-08-16T07:51:37.848Z]] <http://takadat.com/i/Mosaic-l10n/users.html#detection>

[90] [CITE@ja-JP[公衆漢字端末検討会報告書 その1]], [[国立国会図書館]], [TIME[1979.12][1979]], [TIME[2025-07-30T10:21:15.000Z]], [TIME[2025-09-24T15:35:51.144Z]] <https://dl.ndl.go.jp/pid/12629081/1/19> (要登録)

- [[C0]] : [[JIS X 0201]] [[C0]]
- [CN[SI]], [CN[SO]]
- [[指示シーケンス]]
- [[G0]] : [[JIS X 0201]] [[ラテン文字用図形文字集合]], [[JIS X 0208:1978]]
- [[G1]] : [[JIS X 0201]] [[片仮名用図形文字集合]]

** irori

[125] [CITE[irori]], [TIME[2023-07-31T06:14:37.000Z]], [TIME[2000-05-26T20:50:43.171Z]] <https://web.archive.org/web/20000526204917/http://irori.topica.ne.jp/>

>
-PC/AT 互換機上の Linux で動作する、文字列処理のライブラリです。
-ISO-2022 に準拠した形式の、多国語混在テキストを扱います。
-各文字コード(日本語/JISX0208・中国語/GB2312 等)は、PlugIn です。PlugIn を追加する事で、アプリケーションが対応する言語を増やせます。

[126] 残念ながら [[Internet Archive]] には[[ウェブサイト]]のトップページしか現存しません。

[86] 
[[e漢字]]プラグインの配布ファイル [CODE[eKanji.src.0.0p1.tar.gz]] 内のサンプルファイル 
[CODE[eKanji.txt]] 
によると、
少なくても [CODE(charname)[ESC]] 2/4 4/0, [CODE(charname)[ESC]] 2/4 4/2,
[CODE(charname)@en[ESC]] 2/8 4/2
が使えました。また、 [[KS X 1001]] と思われるものが [CODE(charname)[SO]] /
[CODE(charname)@en[SI]] と共に ([[エスケープシーケンス]]なく)
使われました。

[87] 
同ファイルおよびソースコードによると、
[CODE(charname)[ESC]] [CODE[eKanji]] から[[改行]]までは[[e漢字]]として解釈されました。
その部分だけ抜粋:

>
[PRE[
eKanji/Unicode :eKanji<u4e00><u4e01><u4e02><u4e03><u4e04><u4e05><u4e06><u4e07>
eKanji/ekan0020:eKanji<k49179><k49180><k49181><k49182><k49183><k49184><k49185><k49186>
eKanji/eKan0030:eKanji<m50468><m50469><m50470><m50471><m50472><m50473><m50474><m50475>
]PRE]

[88] 
[DFN[[CODE(charname)@en[ESC]] [CODE[eKanji]]]] は独自仕様。
[[ISO/IEC 2022]] では
[CODE(charname)@en[ESC]] [N[5/5]] は[[C1制御文字]]なので、
そのような[[制御機能]]を含む[[C1集合]]が[[指示]]された状態、
と解釈すれば一応は [[ISO/IEC 2022]] の枠内。

** ISO-2022-ESC B

[81] 
[CITE[[[Aprotool TM Editor]]]] が対応していた
[SRC[>>80, >>81]]
[DFN[ISO-2022-ESC B]]
は次のようなものと付属ドキュメントで説明されています。

>
[PRE[
  1. すべて 7bitで構成されている。
  2. G0, G1 集合のみ使用する。
  3. 94領域文字集合は必ず G0, 96領域文字集合は必ず G1 にする。
  4. 図形集合の切り替えにすべてロッキングシフトを使用する。
  5. ESC$@, ESC$A, ESC$B 等の慣用表現は用いない。

ESC B : アナウンサ, G0 を SI で GL に、G1 を S0 で GL に指定する。
]PRE]

[84] 名前にある 「ESC B」は、
ファイルの先頭に書く [SRC[>>82]]
[[告知列]] [CODE(charname)@en[ESC]] [N[2/0]] [N[4/2]]
に由来するようです。

[83] すべてに[[固定シフト]]を使うというのは、
[[G0]], [[G1]] とも ([[ASCII]] も) 例外なくということのようです。 
[SRC[>>82]]

[85] なお「慣用表現」不使用は [[ISO/IEC 2022]] 違反。
[[指示シーケンス]]参照。

[REFS[
- [80] 
[CITE@ja[Aprotool TM tips collection]], [TIME[2006-11-13T17:59:52.000Z]], [TIME[2022-10-11T05:11:54.593Z]] <http://hp.vector.co.jp/authors/VA002891/APROTIPS.HTM#tip2>
- [82] 
[CITE[Japanese Windows and hangul]], [TIME[2006-10-05T11:14:54.000Z]], [TIME[2022-10-11T05:12:28.624Z]] <https://ha1.seikyou.ne.jp/home/akairingosaita/hangul/hangul01.htm#toolman>
]REFS]

* 文脈

[13] [[ISO/IEC 2022]] による[[文字列]]の[[符号化]]の他にも、
次の場面で[[エスケープシーケンス]]が用いられます。

[FIG(short list)[ [14] その他の[[エスケープシーケンス]]の用法
- [[公式公開識別子]] ([CODE[CHARSET]])
- [[ISO 9660]]
]FIG]

[79] 
[[KS X 6001:1990]]
のファイル内で使う[[エスケープシーケンス]]:
[[ISO/IEC 6429]] や [[VT][VT100]]
のものと似ているが少し違う

* ISO/IEC 10646 におけるエスケープシーケンス

[16] 
[[ISO/IEC 10646]]
は[[エスケープシーケンス]]の用法を規定しています。
([[Unicode]] には相当する規定がありません。)
[SEE[ 構文については[[制御文字]] ]]

[17] 
[[ISO/IEC 2022]] の[[符号拡張制御機能]] 
([[指示シーケンス]]、[[単独シフト]]、[[固定シフト]])
の 
[[ISO/IEC 10646]]
における利用は禁止されています。
この規定は曖昧ですが、
[[図形文字集合]]の[[指示]]と[[呼び出し]]による
[[ISO/IEC 10646]]
の[[図形文字]]の[[符号位置]]の解釈の変更が禁止されているものとみられます。
[SEE[ [[制御文字]] ]]

;; [35] 禁止されたものが使われた時の挙動は不明です。

[30] 
[[ISO/IEC 10646]]
は[[エスケープシーケンス]]の用法について4通りを自身で特に定めています。
これらは、
「ISO/IEC 2022 のエスケープシーケンスを使う場合」、
「ISO/IEC 6429 のエスケープシーケンスを使う場合」
といった限定がついていて、
使う、使わないは判断が委ねられているようです (利用者に? 実装者に?)。

[31] 
現実問題としてこれらや、その他の[[エスケープシーケンス]]、
[[制御シーケンス]]が使われるのは極めて稀です。
いわゆる[[ANSIエスケープシーケンス]]が[[端末エミュレーター]]の類で使われる程度でしょうか。

-*-*-

[33] 
[[ISO/IEC 10646]]
は、
[CODE(charname)@en[DOCS]]
の用法を2通り定めていました。

[2] 
[[ISO/IEC 10646]]
は、
[[エスケープシーケンス]]によって[[符号化表現]]と[[実装水準]]を識別できるとしていました。
[[ISO/IEC 2022]] [[符号化文字データ要素]]中でも
[[ISO/IEC 10646]] [[符号化文字データ要素]]中でも利用できるとしていました。
[SRC[>>53, >>18, >>38, >>42]]

- [4] [CODE(charname)@en[ESC]] 2/5 2/15 4/0 - [[UCS-2]] [[実装水準1]]
- [5] [CODE(charname)@en[ESC]] 2/5 2/15 4/1 - [[UCS-4]] [[実装水準1]]
- [CODE[4/2]] は他に割り当てられているので注意
- [9] [CODE(charname)@en[ESC]] 2/5 2/15 4/3 - [[UCS-2]] [[実装水準2]]
- [20] [CODE(charname)@en[ESC]] 2/5 2/15 4/4 - [[UCS-4]] [[実装水準2]]
- [21] [CODE(charname)@en[ESC]] 2/5 2/15 4/5 - [[UCS-2]] [[実装水準3]]
- [22] [CODE(charname)@en[ESC]] 2/5 2/15 4/6 - [[UCS-4]] [[実装水準3]]
- [43] [CODE(charname)@en[ESC]] 2/5 2/15 4/7 - [[UTF-8]] [[実装水準1]]
- [44] [CODE(charname)@en[ESC]] 2/5 2/15 4/8 - [[UTF-8]] [[実装水準2]]
- [45] [CODE(charname)@en[ESC]] 2/5 2/15 4/8 - [[UTF-8]] [[実装水準3]]
- [39] [CODE(charname)@en[ESC]] 2/5 2/15 4/10 - [[UTF-16]] [[実装水準1]]
- [40] [CODE(charname)@en[ESC]] 2/5 2/15 4/11 - [[UTF-16]] [[実装水準2]]
- [41] [CODE(charname)@en[ESC]] 2/5 2/15 4/12 - [[UTF-16]] [[実装水準3]]
- [54] [CODE(charname)@en[ESC]] 2/5 4/2 - [[UTF-1]]
- [41] [CODE(charname)@en[ESC]] 2/5 4/7 - [[UTF-8]] [[実装水準]]指定なし

[46] 
なぜか [[UTF-8]] (と [[UTF-1]] [SRC[>>53]])
だけ[[実装水準]]の指定がないものも用意されていました [SRC[>>42 注記]]。
[[実装水準]]の存在意義が問われそうですが、
実際不要だったのでしょう。

[56] [[実装水準]]が廃止され、
[[Unicode]] の[[符号化形式]]が侵略してからは、
次のような規定に変わっています。
[SRC[>>55]]
([[ISO/IEC 10646]] の本文の規定だけで、 [[ISO-IR]] の登録は前のまま放置されています。)

- [57] [CODE(charname)@en[ESC]] 2/5 2/15 4/9 - [[UTF-8]]
- [58] [CODE(charname)@en[ESC]] 2/5 2/15 4/12 - [[UTF-16BE]]
- [59] [CODE(charname)@en[ESC]] 2/5 2/15 4/6 - [[UTF-32BE]]
- [61] [CODE(charname)@en[ESC]] 2/5 4/7 - [[UTF-8]]
- [60] [CODE(charname)@en[ESC]] 2/5 2/15 4/0,
[CODE(charname)@en[ESC]] 2/5 2/15 4/1,
[CODE(charname)@en[ESC]] 2/5 2/15 4/3,
[CODE(charname)@en[ESC]] 2/5 2/15 4/4,
[CODE(charname)@en[ESC]] 2/5 2/15 4/7,
[CODE(charname)@en[ESC]] 2/5 2/15 4/8,
[CODE(charname)@en[ESC]] 2/5 2/15 4/10,
[CODE(charname)@en[ESC]] 2/5 2/15 4/11 - [RUBYB[[[非推奨]]][deprecated]]

[64] 
なお、古くからの実装で、
[CODE(charname)@en[ESC]] 2/5 3/8 
で [[UTF-8]]
を表すものもあります。
[SEE[ [[DOCS]] ]]

[32] 
[[ISO/IEC 10646]]
は、
[[ISO/IEC 10646]]
から
[[ISO/IEC 2022]]
への切り替えに
[CODE(charname)@en[ESC]] 2/5 4/0
を使うとしていました。
[[ISO/IEC 2022]] [[符号化文字データ要素]]中でも
[[ISO/IEC 10646]] [[符号化文字データ要素]]中でも利用できるとしていました。
[SRC[>>18]]

;; [34] 
[[ISO/IEC 2022]] [[符号化文字データ要素]]中での利用が想定された理由は謎です。

[36] 
[CODE(charname)@en[DOCS]]
は、
標準的な復帰のエスケープシーケンスである
[CODE(charname)@en[ESC]] 2/5 4/0
で
[[ISO/IEC 2022]]
に復元できる場合とできない場合を区別し、
できないシステムへの切り替えの
[CODE(charname)@en[DOCS]]
の[[中間バイト]]に
[CODE[2/15]]
を含めるとしていました。
[[ISO/IEC 10646]]
は標準的な[[エスケープシーケンス]]で
[[ISO/IEC 2022]]
に復帰しますが、
詰め込みオクテットがある [SEE[ [[制御文字]]. [[同型符号化]] ]]
ために、標準的な[[エスケープシーケンス]]の[[ビット組合せ]]自体が出現するとは限りません。
そのために
[CODE[2/15]]
が入っています [SRC[>>18]]。

[47] 
[[UTF-8]]
では[[エスケープシーケンス]]の[[ビット組合せ]]が
[[ISO/IEC 2022]]
の場合と等しくなります。
従ってこの理由なら 
[CODE[2/15]]
は不要なはずで、
実際に[[実装水準]]なしの[[エスケープシーケンス]]は
[CODE[2/15]]
が省かれていますが、
[[実装水準]]ありの[[エスケープシーケンス]]には入っています。
そして[[実装水準]]ありの方はオクテットの詰め込みを行うと規定され
(実質無変換)、
なしの方は詰め込みを行わないと規定していました
[SRC[>>42]]。
この違わない違いが生じた理由は不明です。
([[UTF-1]] は詰め込みを''行う''としていました [SRC[>>53]]
が、
[[UTF-1]] でも[[エスケープシーケンス]]の[[ビット組合せ]]は等しく、
[CODE[2/15]] は入っていませんでした。)

[37] 
[[ISO/IEC 10646]]
状態で[[エスケープシーケンス]]や[[制御シーケンス]]で変更した状態が、
[[ISO/IEC 2022]]
に移行した後や、
その後で再び
[[ISO/IEC 10646]]
に戻った時にも維持されているのかどうかはよくわかりません。

[48] 
[[ISO/IEC 10646]]
に切り替えた直後に
[N[0xFEFF]]
が出現したとき、
[CODE(charname)@en[BOM]]
と解釈されるのか
[CODE[U+FEFF]] [CODE(charname)@en[ZWNBSP]]
と解釈されるのか不明です。

;; [78] [[ISO/IEC 10646]]
は[[符号化文字]]のストリーム (未定義語)
の最初に [CODE(charname)@en[BOM]]
を置けると定めています。
[CODE(charname)@en[DOCS]]
により
[[ISO/IEC 10646]]
に遷移した直後が[[符号化文字]]のストリームの始めに当たるのかどうかは不明です。

[77] 
[[ISO/IEC 10646]] にも [[ISO-IR]]
にも[[エスケープシーケンス]]後の[[エンディアン]]の規定がなく、
どう解釈するべきか不明です。

[49] 
UTF-8 での復帰の表現は ISO/IEC 2022 の「standard return」と
同じです。実際実装水準指定なしの UTF-8 は ESC % G で standard return
に分類されてます。 ISO/IEC 10646-1 を読んでも理由は釈然としません。
(実装水準ありの方では復帰が使えないとかではなさげ。)

[50] 
[[ISO-IR]]
では
UCS-2, UCS-4 は ISO/IEC 10646-1:1993 となってますが、
以降の版や ISO/IEC 10646-2 でも同じのようです。
(以上 [[ISO/IEC10646]]-1 2000 15,16, C.5, D.6)

[52] 
[[ISO-IR]]
に登録された[[制御文字集合]]や[[図形文字集合]]や[[単独制御機能]]は、
[[ISO-IR]]
に完全に登録され掲載されていましたから、
改正で変更があったときは新版が旧版とは別に登録され直すことになっていました。
ところが
[[ISO/IEC 10646]]
は
[[ISO/IEC 2022]]
ではない符号化システムへの切り替えのための[[エスケープシーケンス]]として登録されているので、
[[図形文字集合]]として登録されていませんし、
版に関わらず使えるようです。
([[ISO/IEC 10646]] は非互換変更を繰り返しているので、
バージョンごとに[[エスケープシーケンス]]を登録しなおしていたら何十個にもなっていそうです。)

[66] 
[[ISO-IR]] に最初に登録されてから現在に至るまで、
文字の追加のような互換性への影響の小さな変更以外にも、
次のような深刻な[[非互換変更]]が加えられています。

- [65] [[Korean mess]]
- [67] [[phi mess]]
- [68] [CODE[U-00110000]] [[以上]]の[[符号位置]]の削除
- [69] [[UTF-1]] の廃止
- [70] [[実装水準]]の廃止

[FIG(quote)[
>NOTE - Escape sequence ESC 02/05 04/00 is normally
used for return to the restored state of ISO/IEC 2022. The
escape sequence ESC 02/05 04/00 specified here is
sometimes not exactly as specified in ISO/IEC 2022 due to
the presence of padding octets. For this reason the escape
sequences in 16.2 for the identification of UCS include the
octet 02/15 to indicate that the return does not always
conform to that standard. 
]FIG]

[51] 
ISO/IEC 2022 から ISO/IEC 10646 に移って、再び
ISO/IEC 2022 に戻った時に、状態は復元されるのかどうか。
はっきりと書かれてはいないようですが、上の引用文 (ISO/IEC 10646-1:2000 16.5 の参考)
が復元されることをほのめかしているように思えます。

-*-*-

[23] 
[[ISO/IEC 10646]]
は、
[[制御シーケンス]] [CODE(charname)@en[IUCS]]
で、
[[ISO/IEC 10646]]
が定める[[部分集合]]を識別できるとしていました。
[[ISO/IEC 6429]] [[符号化文字データ要素]]中でも
[[ISO/IEC 10646]] [[符号化文字データ要素]]中でも利用できるとしていました。
[SRC[>>18]]

;; [24] 
[[ISO/IEC 6429]] [[符号化文字データ要素]]中での利用が想定された理由は謎です。
[[ISO/IEC 2022]] 状態で使ってから
[[ISO/IEC 10646]] を[[指示]]しても、状態は保持されるのでしょうか。

-*-*-

[25] 
[[ISO/IEC 10646]]
は、
[[ISO/IEC 10646]] と併用する[[制御機能]]の識別に、
[[ISO/IEC 2022]] における[[制御文字集合]]の[[指示シーケンス]]と同じ形の識別シーケンスが使えるとしていました。
[[ISO/IEC 6429]] [[符号化文字データ要素]]中でも
[[ISO/IEC 10646]] [[符号化文字データ要素]]中でも利用できるとしていました。
[SRC[>>18]]

- [26] [CODE(charname)@en[ESC]] 2/1 [VAR[F]] - [[C0文字集合]]
- [27] [CODE(charname)@en[ESC]] 2/2 [VAR[F]] - [[C1文字集合]]

[28] [[JIS X 0211]] [[制御機能]]はそれぞれ
[CODE[4/0]],
[CODE[4/3]]
を
[VAR[F]]
として使います。それ以外は [[ISO-IR]] に登録された[[終端バイト]]とします。
[SRC[>>18]]

;; [29] 
[[ISO/IEC 2022]] [[符号化文字データ要素]]中での利用が想定された理由は謎です。
[[ISO/IEC 2022]] 状態で使ってから
[[ISO/IEC 10646]] を[[指示]]しても、状態は保持されるのでしょうか。

;; [63] 
この説明は [[IRR]] に言及していませんが、使ってもかまわないのでしょうか。
使うなとは書いていないようですが。。。

* その他文字コード体系におけるエスケープシーケンス

[71] 
[[MS-DOS]] や [[Windows]] の[[コマンドプロンプト]]等では、
その実装する[[コードページ]]において、
いわゆる [[ANSIエスケープシーケンス]]として一部の[[エスケープシーケンス]]が利用できます。

* 関連

[6] [[C1]] を[[エスケープシーケンス]]として表す場合、 [[CSI]]
で始まる[[制御シーケンス]]全体を[[エスケープシーケンス]]と呼ぶことがあります。

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Page name(s)