472.txt

[[ISO-2022-JP]] が [[ISO/IEC2022]] に適合するかについて
いろいろ言われてきました。

[BIS1468] と [JISX0208:1997] は、 ISO/IEC 2022
には適合しないと明言しています。

このことについて、 『RFC1468とISO 2022のカンケイ』
<http://www.xinada.ne.jp/~handa/tech/Scribbles/RFC1468-and-ISO2022>
という文章がとてもよくまとめています。だけどここではあえて
その内容を繰り返します。

ISO-2022-JP が ISO/IEC 2022 に適合するかどうかの問題点
は次のものが挙げられています。

= 漢字 (JIS X 0208-1978, -1983) が[[指示]]されている状態で制御文字や [[SPACE]] などが使用できない
= 改行 ([[CRLF]]) で(指示がなくても) ASCII に戻しても良い
= 更新番号 ([[IRR]]) がなくても JIS X 0208-1990 が使える

[[JISX0208]]:1997 の解説は、 RFC 1468 符号化表現の問題点を
3つ挙げる。
= [[指示]]シーケンスによる文字集合の選択が曖昧である
= 改行後の文字集合の扱いの実装にばらつきがある
= ISO/IEC 2022 の subset であるかの誤解を与える
= (一々文字集合を指示するのは古くさい)

残念なことに、解説は問題点を挙げる以上の説明をしていない。


* 漢字列中での制御文字などの使用

この問題はそもそも [[JUNET]] コードよりまだ昔に起因します。
当時広く流布していた[[漢字イン・漢字アウト]]説によると、
漢字インした状態では制御文字が使えません。この神話に基づく
実装では実際その通りになったので、 JUNET 初期は (あまり深い意図無しに)
漢字列中で制御文字などを使用しないことにしていたみたいです。

[[JUNETの手引き]]にある JUNET コードが成立した頃には、
この説は否定されました。そして制御文字などを漢字列中で
使っても良いことにし、その方向に進めようという姿勢が
手引きにはあります。 (なお、改行だけは、行指向のソフトウェア
が簡単に実装できるように、従来通り ASCII 状態とすることに
なりました。)

ところがこの企みはそううまくいかなかったのか、 RFC 1468 
では一転して禁止されてしまいました。以後の仕様や実装は
それに従っています。

さて本題の ISO/IEC 2022 適合性ですが、この規定は
生の ISO/IEC 2022 より制限するものではありますが、
対立するものではないですから、適合性には影響しない
という解釈が大勢だと思われます。 (特に JUNET コードの場合は
推奨なので、まったく違反しないでしょう。)


* 改行で指示がなくても ASCII に戻してよい

この規定は JIS X 0208:1997 附属書2 にのみあります。

この動作はエラー処理かもしれません。 RFC 1468 も当の JIS X 0208:1997
附属書2 も、改行 [[CRLF]] は漢字列中には現れません。
だけど現れたら・・ってこと。 (だけど、他の考え得るエラー処理
のことは規定されていないしなあ。)

行指向ソフトウェアでは前の行で JIS X 0201 Roman か ASCII
のどちらで終わったか調べ{れ|たく}ないので、 ASCII だと
仮定したいのですが、そういう場面での話かもしれません。
([BIS1468] に似たような話があります。)

いずれにせよ実装の話であってそのような符号列の出力を
認めているわけではありませんから、
([[受信装置]]の適合性は疑わしい可能性がありますが) 
データの適合性には影響しないでしょう。

JIS X 0213:2000 附属書2 の [[ISO-2022-JP-3]]
にも同様の話がありますが、 ISO/IEC 2022 に適合しないとは
書かれていません。 (逆にするとも書かれていませんが。)
ですから、 JIS としてはこの点は ISO/IEC 2022 への適合性に
関して問題ないと判断しているのではないでしょうか。

JIS X 0208:1997 の解説にもこの問題が取り上げられていますが、
解説の解説が欲しいような曖昧な指摘です。
たぶん、実装が行頭で勝手に漢字から ASCII に戻したり、
JIS X 0201 roman から ASCII に替えたりするのは問題だ、
といいたいんじゃないかな。


* 更新番号なしで JIS X 0208-1990 が使える

JIS X 0208-1990 を指示するには更新列 ESC 02/06 04/00
が指示列の直前に必要ですが、 RFC 1468 は使わないことを提案 (suggest)
し、 [BIS1468] ははっきりなくても追加文字を使ってよいこととし、 
JIS X 0208:1997 附属書2 も (JIS としての都合上) そうしています。

このことが ISO/IEC 2022 への不適合の疑いがあるわけです。

ただし、 [[IRR]] が定義されていなかったふるい ISO/IEC 2022
との絡みなどの理由から、不適合には当たらないのではという
説もあります。 (だけど規格に問題ないって書いてあるわけじゃないし、
ちょっと弱い気がする。)


* 文字集合の区別がいい加減

あまり問題視されませんが、 ASCII & JIS X 0201 Roman,
JIS X 0208-1978 & -1983 の code point unify
のほうが問題のような気もします。 ISO/IEC 2022 と [[ISOREG]]
で規定された[[終端バイト]]と[[符号化文字集合]]の対応関係を
適当に無視することを認めているからです。

まあ、この装置では JIS X 0201 を使えないから ASCII
の似たのにエラー処理で変換しただけだ、みたいな
言い訳は思いつきますけど。 (その言い訳が通る (どこを?)
かどうかは知りませんが。)

JIS X 0208:1997 附属書2 は深刻です。 -1978 と -1983
で入れ替えられた文字は (文書に明示するだけで自由に) 
逆にして構いませんし、 -1978 になかった文字は実装しなくて
構いません。堂々と規定してあるのでエラー処理だなんて
言い訳は出来ません。そりゃあ ISO/IEC 2022 には適合しない、
って参考に書きたくもなりますわ。 (そのくせ ASCII と
JIS X 0201 の差異2文字は入れ替えてもいい、みたいな
規定はないなんて、片手落ちな。さすがにそれしたら
ISO/IEC 646 や JIS X 0201 に適合しなくなるから? (なにをいまさら))

(文字を実装しなくて良い、はデータの適合性には影響しないでしょうが、
受信装置の適合性で問題がある可能性があります。
でもまあ参照されてる側の規格がいいと言ってるからいいのかな?
(でも ISO-IR で参照されてるのは -1978 とか -1983 だったりする。
ISO-IR には最新版適用規則はないはず。))

この項と前の項が、 JIS X 0208:1997 解説の言うところの
文字集合選択が曖昧である、の指すところだと思います。


* ISO-2022-JP という名前は ISO/IEC 2022 の subset のような印象を与える

(上の様な非適合性問題がなければ) 確かにそのとおりであって、
別に問題はないんですが・・・。

元々 ISO-2022-JP という名前は、 [[MIME]] で (Internet 
の[[電子メイル]]で) 使う ISO/IEC 2022 に基づく表現の、
日本で使われてるやつ、くらいの意味でつけたんであって、
[[JUNETコード]]の正式名称にしようなんて意気込んでつけた
わけじゃないでしょう。

そもそも当の [[JUNET]] では JIS の符号を使う、という方針で
動いていたわけですから、 ISO/IEC 2022 に不適合とわかれば
頑張って修正したんじゃないでしょうか。 ESC ( H みたいにね。
(もちろん、今じゃもう無理でしょう。 ([[JUNET]] もないし。))

ISO-2022-JP ってのは数奇な運命を辿った
[[符号化文字集合]]だなあと思います。


* その他

- 2002-09-30 (Mon) 17:11:36 ''[[名無しさん]]'' : JIS X 0208:1997 の解説は、 JIS 本体の解説は豊富だけど、新たに (しかも制定間際にとってつけたように) 加えられた RFC 1468 符号化表現については (シフト符号化表現についてもですが) 説明が少なすぎると感じます
- 2002-09-30 (Mon) 17:13:07 ''[[名無しさん]]'' : JIS X 0208:1997 の制定の頃話題になった ISO/IEC 2022 への適合性はもちろんのこと、 JIS に取り入れられるまでの歴史とかを入れて然るべきじゃないでしょうか。

[1]
<http://pc5.2ch.net/test/read.cgi/linux/1003159137/667->

([[名無しさん]] [sage])

[2]
>674 名前:672[sage] 投稿日:04/12/03(金) 03:59:08 ID:9rXlF8ug
>解答例:
改訂番号の識別機能を使うとき、それがエスケープシーケンスとしてCCデータ要素
に埋め込まれている必要はない。
したがって、改訂番号識別シーケンスを使わないことをもってただちに不適合である
とは結論できない。

([[名無しさん]] [sage])