Tomoyuki Asakawa
tom****@asaka*****
2006年 4月 29日 (土) 10:02:54 JST
あさかわ > 前のメールにちょっとだけ書きましたが，ISO-2022-JPは，ISO/ > IEC 2022を > ベースにしてはいますが，実際には異なる文字符号化だと認識した方 > がよいと > 思います．実際に，かなり制限していますし（これは意図的です）， > 相反する > 部分も多少あります． そうですね。 ISO-2022-JPを決めるとき、EUCに変換した時に、困らない様にと いう、ご都合主義できめられてる事がISO-2022の不幸だとおもて います。 これは、SJISが、MSBASCOMを、CP/Mで使うときに困 らない様にというご都合主義で決められたのと同じです。 そもそもISO-2022-JPが決められた前（以後も)は、 UNIX圏以外では、JISというと、 GL = ISO646日本版 GR = JISX0201（当時はC6220) を初期状態としていました。 漢字をつかう時は ESC $ @ で、GLに、X0208を呼び出していたわけです。 不要になると ESC ( Bで、GLに、ISO646日本語版を呼び出す こういう切り替えが、一般的にJISと呼ばれていました。 なのに、EUCで扱えないという理由で、半角カナを、GRに 呼び出すことを、禁止した形でISO-2022-JPをRFCにしてし まった。 当時、インターネットなんて使っていた人は、一部の人だったけれども この一部の人が、作成した、RFCが、現在の混乱の一つの芽をこ こで作ってるのです。 ７ビットに押さえるという目的なら、GLに、よびだせばよかった のです。 当時の実装としてそういうものもあったのですから。 純粋なISO-2022原理主義者だった私から言えば,SJISも EUCも内部コードです。 内部コードで外部コードを規定すべきではない。ISO-2022-JPは EUCの7ビット版になってしまってる。 ISO-2022には、初期状態は、当事者間の想定のみで決まるという「欠 陥」がありますこれを補う為に 初期状態を、どこかで管理する必要はあるとおもっていました。なの で、ISO-2022-JPをRFCにしたと聞いたとき これは、前述の初期状態を規定したものだとおもっていました。 ところが、初期状態だけではなく、状態遷移まで規定していた。 しかも、GLは、ISO646日本語版ではなく、ASCII だった。(5cがバックスラッシュ) （それがわからなかった自分を悔やみます) 各国も同様な基準でISO2022の初期状態を規定するだけにしてお けば、 ISO-2022という、規格にしたがってる文字集合はすべてあつかえたはず なわけです ネット上は、ISO2022だけで扱うことにして、UTFを、垂れ 流しする必要はなかったはずです。 UTFは処理系の内部コードとして扱うことができたはずなのです。 EUCやSJISという内部コードを外部に垂れ流しした、パソコン通 信と同じ轍を踏んでる。 まあ、過去を後悔しても仕方ないのですが、 Unicodeで統一すればというのは理想ですが、わたしの知ってる過去２ ５年間の歴史から考えると無理ですね。 すべて併存されてしまうでしょう。 その、併存を前提にものを考えないと、いつまでたっても、同じ話を繰 り返す事になる。 そうすると、新しい、コードページを作るというのは、非常に危険です。
