🚀 go-pugleaf

>>>>> In <4epe99$i8s@lakshmi.tdc.unisys.co.jp> 
>>>>>	tomo@tdc.unisys.co.jp (Tomo Muramatsu) wrote:

村松さん> 守岡 知彦 /  MORIOKA Tomohiko (morioka@jaist.ac.jp) wrote:

守岡>>   それはともかくとして、現在の Internet の mail や news にはそ
守岡>> のままでは ISO-10646 や Unicode は技術的に流すのが困難だという
守岡>> のは事実です。

守岡>>   普通、『8bit を通す』とかいった場合に念頭においているのはしば
守岡>> しば ISO-2022 に基づいた 8bit code で、8bit の制御 code の領域
守岡>> に図形文字を入れていないという仮定があるような気がします。
守岡>> ISO-10646 や Unicode や Shift_JIS を通す場合は、binary 扱いにし
守岡>> ないと問題が起こるでしょう。

村松さん> ISO-10646 Annex F に UCS transformation format (UTF)
村松さん> というのが定義されていて、ISO-2022 で言う所の C0,SPACE,
村松さん> DEL, or C1 を使わない表現形式があるようです。

村松さん> これなら、ISO-2022 に基づいた 8bit code で行けますよネ。

  つまり、

守岡>>  つまり、何らかの encoding を使って 16 bit もしくは 32 bit の 
守岡>> code を 7bit もしくは 8bit の network 用の表現に変換しなければ
守岡>> なりません

ということですよね。

  そして、こうした code は私にはあんまり Unicode の売りが感じられない
のです。UTF-7 や UTF-8 を使う場合、MIME の charset mechanism を使うこ
とになるでしょうが、内部 code として Unicode や ISO-10646 を使っている 
system を想定すると、ISO-2022-JP 等を使っている場合と同様、statefull 
な network code と内部 code の変換が必要です。

  しかも、この変換は Unicode 固有のものです。それぐらいなら、base64 の
ような一般的な機構を用いた方がましな気がします。また、おそらく、現状で
は ISO-2022 系との変換は必要ですから、network code としては ISO-2022 
系のものを使う方が良いと思います。

＃ そういえば、Eric さんが提案していた ``jpu'' はどうなったんでしょう
＃ ね？今だったら、結構、賛同者が集まるかも。

-- 
┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━
││ ─ │  ─  ／    ─   ┼─     ┬                ─   ─┼ ┬┴─
┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) <morioka@jaist.ac.jp>─
┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━