公開テキスト指示シーケンス
[1] 【SGML】
- 公開文指示シーケンス
- 公開文の中の文字集合の宣言のときに使われ、
文字集合を指示する JISX0202
に規定するエスケープシーケンスを含む文識別子の一部分。 (JISX4151‐1992 定義 (87)
[2] 公開文指示シーケンスは、最小データですが、
その公開識別子で参照する文字集合の ISO/IEC2022
による指示シーケンスを外部表現したものでなければなりません。
その文字集合が ISO-IR 登録集合であるなら、
その登録してある指示シーケンスでなければなりません。
(JIS X 4151‐1992 9.2.2.4 参照。)
[3] 例:
- [8] ESC 2/8 4/0 (ISO/IEC646 旧 IRV を G0 に指示)
- [9] ESC 2/8 4/2 (ISO/IEC 646:1991 IRV = ASCII を G0 に指示)
- [10] ESC 2/5 4/0 (未登録の128文字の文字集合・・・と JIS X 4151 には書いてあるけど、 ISO/IEC 2022 ではこれは ISO/IEC 2022 自身を指す DOCS のはずだ。それとも昔は違ったのか?, を指示)
- [12] 昔はそれっぽい感じだったらしい DOCS
- [11] ESC 2/6 4/0 ESC 2/4 2/9 4/2 (JISX0208‐1990 を G1 に指示)
[4] 登録済み文字集合に対する公開文指示シーケンスは公開文
(符号化文字集合) を一意に識別しますが、
そうでない場合はその所有者識別子ごとに一意な公開分を識別するのだそうです。
[13]
例えば ESC 2/4 2/8 3/0
(94n図形文字集合を G0 に指示する私用のエスケープ・シーケンス。
私用終端バイト )
だけでは符号化文字集合を特定できませんが、例えば
+//IDN mule.example//CHARSET Mule Big5-1//ESC 2/4 2/8 3/0
とすれば、それが MULE Big5‐1
だとわかります。
[5] 公開識別子一般に言えることですが、
この公開文指示シーケンスも、実際には役に立ちません。
その指示シーケンスと ISO/IEC 2022 処理系が連動して符号拡張法をうまく処理してくれるとか、
そういうことはありません。
単に備忘とか、一意な識別子としやすくするための便宜のためのものでしょう。
ですから、 SGML宣言の文書文字集合の指定で、
日本語EUC を使いたいとして、 G1
に JISX0208‐1990 を指示する時に、
その公開文指示シーケンスを
ESC 2/6 4/0 ESC 2/4 4/2 (G0 に指示)
とか
ESC 2/6 4/0 ESC 2/4 2/10 4/2
としても (たぶん) 構わないわけです。でも、
ESC 2/6 4/0 ESC 2/4 2/9 4/2 (G1 に指示)
にした方が分かりやすい (かもしれない)
ので、そうする方がよい、と思われます。
[6] >>2 を厳密に解釈すると、 ISO/IEC 646:1991 IRV
を G2 に指示する (ESC 2/10 4/2)
ような真似はできません。なぜなら、この指示シーケンスは
ISO‐IR に登録されていないからです。
(当時の古い ISO/IEC 2022 の仕様に基づいて登録されていたからです。)
(もちろん、 IRV を G2 に指示するなんて気違いじみたことは普通はしませんが、そういうことは置いといて。)
実際にはその辺りは適当に
(登録されている終端バイトをとでも読み替えて)
解釈すればいいでしょう。
ISO-IR
[7] ところで、「外部表現」でビット組合せの記述に 2/8 のほかに
02/8 や 2/08 や 02/08
のような表現が認められているのかどうか不明です。
規格の例示の通り、 2/8 としておけば問題はないでしょう。
頭に 0 をつけるかどうかは、
符号化文字集合の規格では昔は7ビットか8ビットかの関係と絡んでややこしいことになっていましたが、
今はどうでもいいことになっています。 SGML ではどうなんでしょう?
公開文種別 CHARSET
[17] 用例のある、公開文種別が CHARSET
な公開識別子:
| 公開識別子 | 説明 | 出典 |
|---|
ISO 646-1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0 | 旧IRV | [ISO 8879] |
ISO 646-1983//CHARSET International Reference Version (IRV) //ESC 2/5 4/0 | 旧IRV |
ISO 646-1991//CHARSET International Reference Version (IRV)//ESC 02/5 04/0 | 旧IRV | NCALS-HTML 2.0 |
ISO Registration Number 87//CHARSET JIS X 0208//ESC 2/6 4/0 ESC 2/4 2/9 4/2 | IRR |
ISO Registration Number 87//CHARSET JIS X 0208 Japanese Character Set//ESC 2/6 4/0 ESC 2/4 4/2 | IRR |
ISO Registration Number 87//CHARSET JIS X 0208-1990//ESC 2/6 4/0 ESC 2/4 4/2 | IRR |
ISO Registration Number 100//CHARSET ECMA-94 Right Part of Latin Alphabet Nr. 1//ESC 2/13 4/1 | | HTML 2.0 |
ISO Registration Number 109//CHARSET ECMA-94 Right Part of Lation Alphabet Nr.3//ESC 2/9 4/3 | 2/13 が正しい | ISO 8879‐1986 |
ISO Registration Number 109//CHARSET ECMA-94 Right Part of Latin Alphabet Nr. 3//ESC 2/13 4/3 |
ISO Registration Number 159//CHARSET JIS X 0212//ESC 02/4 02/11 04/4 | | NCALS-HTML 2.0 |
ISO Registration Number 159//CHARSET JIS X 0212-1990//ESC 2/4 2/8 4/4 |
ISO Registration Number 168//CHARSET JIS X 0208//ESC 02/6 04/0 ESC 02/4 02/9 04/2 | IRR | NCALS-HTML 2.0 |
ISO Registration Number 176//CHARSET ISO/IEC 10646-1:1993 UCS-2 with implementation level 3//ESC 2/5 2/15 4/5 | DOCS | [W3C] |
ISO Registration Number 176//CHARSET ISO/IEC 10646-1:1993 UCS-4 with implementation level 3//ESC 2/5 2/15 4/6 | 177が正しい / DOCS | Web SGML:1999 |
ISO Registration Number 177//CHARSET ISO/IEC 10646-1:1993 UCS-4 with implementation level 3//ESC 2/5 2/15 4/6 | DOCS | [W3C] |
[14] Code configuration in this www server http://www1.u-netsurf.ne.jp/~7l1rll/codeWWW.html: SGML の文字コードの扱いと ISO/IEC2022 符号拡張法の相性が悪い話。日本の委員は修正するように提案したけど、 ISO/IEC 2022 は難解云々で分かってもらえなかったと。
[15] ちなみに、 XML の時代の文書文字集合 (SGML の CHARSET; IETF/W3C の CCS) と転送符号化方式 (IETF/W3C の CES) は別だとする考え方は後付け。 SGML にはそんな概念はない。
[16] >>14 によると、シフトJIS があるからいいじゃん☆的な関係者もいたらしいにゃ。1980年代終わりなら仕方ない, のかなあ? 既にインターネットもパソ通もあった時代。自己中委員は反省するべき。