[2] 公開文指示シーケンスは、最小データですが、 その公開識別子で参照する文字集合の ISO/IEC2022 による指示シーケンスを外部表現したものでなければなりません。 その文字集合が ISO-IR 登録集合であるなら、 その登録してある指示シーケンスでなければなりません。 (JIS X 4151‐1992 9.2.2.4 参照。)
[3] 例:
[4] 登録済み文字集合に対する公開文指示シーケンスは公開文 (符号化文字集合) を一意に識別しますが、 そうでない場合はその所有者識別子ごとに一意な公開分を識別するのだそうです。
[13]
例えば ESC 2/4 2/8 3/0
(94n図形文字集合を G0 に指示する私用のエスケープ・シーケンス。
[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 に指示するなんて気違いじみたことは普通はしませんが、そういうことは置いといて。)
実際にはその辺りは適当に
(登録されている終端バイトをとでも読み替えて)
解釈すればいいでしょう。
[7] ところで、「外部表現」でビット組合せの記述に 2/8 のほかに 02/8 や 2/08 や 02/08 のような表現が認められているのかどうか不明です。 規格の例示の通り、 2/8 としておけば問題はないでしょう。
頭に 0 をつけるかどうかは、
符号化文字集合の規格では昔は7ビットか8ビットかの関係と絡んでややこしいことになっていましたが、
今はどうでもいいことになっています。 SGML ではどうなんでしょう?
CHARSET[17] 用例のある、公開文種別が CHARSET
な公開識別子:
[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年代終わりなら仕方ない, のかなあ? 既にインターネットもパソ通もあった時代。自己中委員は反省するべき。