From: TAKADA Toshihiro <takada@mdma.brl.ntt.jp>
Real-Date: Sat, 5 Aug 1995 03:27:46 +0900
Subject: [infotalk,05210] Re: MIME charset
Message-Id: <199508041827.DAA20228@mdma.brl.ntt.jp>
たかだです。今ちょっとヘロヘロなのでまともな答えはできないですが、
とりあえず...
In article <199508041337.WAA00387@coo.wg.omron.co.jp> you write:
>MIME の charset って、
> 1) character set そのもの (例: US-ASCII, ISO-8859-1, UNICODE-1-1)
> 2) character sets ＋ encoding (例: ISO-2022-JP)
>の２種類があってごっちゃになってて美しくないような気がしています。
御意。
> 2) ISO-2022 の範囲で、ほとんどの言語が扱える標準的な MIME的charset を作る。
> ISO-2022-INT-* あたりが発展するとこうなるんだと思います。
> これにより ISO-2022-* が統一できて Accept-Charset の指定が楽になる。
> ...
>1) もおもしろいなぁと思いはじめているのですが、現実的には 2) なんで
>しょうかね。。
> ...
>ところで MIME の charsetって、なぜ ISO-2022-country のような形が多いの
>ですか？ 2) の様な努力があっても不思議ないのに。。あと、ISO-2022-言語
MIMEの思想としては、charsetは使われている最小文字集合を書く、という
のが基本らしいですから。あらかじめ全部入ってるようなcharsetはcharset
ではない(?)、ということかな。(で、あってますか？ > ysatoさん)
charsetが"charcter set"のことならそれはもっともなのですが、出水さんも
書かれていたように、encoding情報もcharsetに埋め込まれてしまうとなると、
ちょっと事情は異なるような気もするけど... よーわからん。
--------
> > 正義を目指して議論を進めている間に、規格＝「Netscapeのインプリ」に
> > なっちゃったらどーにもならん、つーか。:-b
> あ〜、すみません、ここで言う「Netscapeのインプリ」はどういう機能を
> 指してますか？ Netscape にほとんど触ったことないので知らないのです。。
上の部分、現状がそうなっているということではなく、「そうなっちゃった
ら問題だなぁ」「そうなっちゃうんだったら頑張って考える必要もないのか
ひょっとしてぇ」とか、そういう意味で書きました。深く考えないでくださ
い(_o_)。
Netscapeがl10nやi18nについてどのようなビジョンを持っているかは、私の
伺い知るところではありません。
========================================================================
NTT Basic Research Labs. TAKADA Toshihiro
<http://www.ntt.jp/people/takada/> takada@mdma.brl.ntt.jp
========================================================================
From: Noritoshi Demizu (出水法俊) <demizu@nff.ncl.omron.co.jp>
Real-Date: Fri, 04 Aug 1995 22:15:49 +0900
Subject: [infotalk,05209] Re: UNICODE vs. ISO-2022
Message-Id: <199508041315.WAA00370@coo.wg.omron.co.jp>
あさださん> ちなみに
あさださん> protcol://host:port[charset]/location
あさださん> という拡張 URL を提案していた人がいたです。draft 書くつもりらしい
あさださん> ですが…。
HTML-WG, HTTP-WG の ML でも、ファイル名?の encoding 方法として
次の２種類が出てました。
(1) http://www.jacme.co.jp/[EUC]%B0%F5%BA%FE.html
(2) http:[EUC]//www.jacme.co.jp/%B0%F5%BA%FE.html
# `%B0%F5%BA%FE' は「印刷」(0x30753a7e)の EUC 表現だと思います。
あと、HTTP URL の `?' から後ろの encoding については、
(a) application/x-www-form-urlencoded (cf. draft-ietf-html-spec-04.txt)
いま使われている。charset の指定できない。
(b) text/tab-separated-values (どこで定義されているのか知らないです…)
使われているわけではないと思うのですが、charset の指定ができるらしい。
(c) multipart/form-data (cf. draft-ietf-html-fileupload-02.txt)
使われているわけではないと思うのですが、charset の指定ができるらしい。
の案があるようです。
僕自身は (a) しか読んだことないのですが、(a) をベースに考えると、
http://hoge/path?+charest=iso-2022-jp&name=%1b%24B%3dP%3feK%21%3dS%1b%28B
みたいな書き方で charset を埋め込めばできるかなぁと思ったりしています。
'+'で始まる語は、client から server に情報を渡すための予約語と言うこと
で考えてみてます。
# あの Thread に英語で切り込みかけられるほどの実力と英語力が欲しい。。
わたし> HTML において、文書のコードが UNICODE か、ISO-2022 かで問題に
わたし> なるところって、&#xxxx くらいかなぁなんて思ったりしてます。
昨日、HTML 3.0 の I-D の著者の Dave Raggett さんとお話をする機会が
あったのですが、そのとき次のような案が出てきました。これだといいかな。。
案1: &UNICODE-4567; とか &JISX0208-3456; のように書くことにする。
DTD 的?には山のような ENTITY 宣言が必要ですが:-)、
実装上はそう難しくない(と思う)。
案2: &#xx って書き方は ASCII range に限る。
あさださん> 話はそれるですが、今そのへんにある HTTP サーバって、
あさださん> リクエストに ESC 入れても、そのまま通るですか？
世間の HTTP サーバについては全然知らないのですが(;_;)、
・RFC1738 を見てみると URL に ESC(0x1b) を直接入れることはできないです。
・application/x-www-form-urlencoded でも non-alphanumeric characters は
`%HH' で表現することになってます。(draft-ietf-html-spec-04.txt)
からすると、ESC(0x1b) を含んだ URL を client が送ること自体がいまのと
ころは規約違反なので、何をされても文句言えないような気がしたりします。
出水法俊
From: Noritoshi Demizu (出水法俊) <demizu@nff.ncl.omron.co.jp>
Real-Date: Fri, 04 Aug 1995 22:37:59 +0900
Subject: [infotalk,05208] MIME charset
Message-Id: <199508041337.WAA00387@coo.wg.omron.co.jp>
MIME の charset って、
1) character set そのもの (例: US-ASCII, ISO-8859-1, UNICODE-1-1)
2) character sets ＋ encoding (例: ISO-2022-JP)
の２種類があってごっちゃになってて美しくないような気がしています。
特に後者では、character set と encoding scheme の組合せの数だけ
`charset' を定義しなきゃならないので、例えば他国語対応クライアントが
HTTP の Accept-Charset フィールドに自分が知っている charset を全部並べ
ようとすると、下手したら何十と言う数を並べないといけなくなるかもしれま
せん。:-(
さて、今後はどのような方向に進むのでしょうか。
1) encoding scheme と character set を分けて考える。
(例) Content-Type: text/html; encoding=iso-2022;
codeset=jisx0208,iso-8859-1
(注) 特に encoding を使ってないときは `encoding' parameter なし。
encodig 名前から codeset が分かる時は codeset なし。
2) ISO-2022 の範囲で、ほとんどの言語が扱える標準的な MIME的charset を作る。
ISO-2022-INT-* あたりが発展するとこうなるんだと思います。
これにより ISO-2022-* が統一できて Accept-Charset の指定が楽になる。
3) やっぱり ISO-2022-country のような l10n? を行ない続ける。
1) もおもしろいなぁと思いはじめているのですが、現実的には 2) なんで
しょうかね。。
ところで MIME の charsetって、なぜ ISO-2022-country のような形が多いの
ですか？ 2) の様な努力があっても不思議ないのに。。あと、ISO-2022-言語
(例: ISO-2022-ja) でないのもちょっと不思議。。
出水法俊
From: Noritoshi Demizu (出水法俊) <demizu@nff.ncl.omron.co.jp>
Real-Date: Fri, 04 Aug 1995 22:47:05 +0900
Subject: [infotalk,05207] Re: HTML
Message-Id: <199508041347.WAA00438@coo.wg.omron.co.jp>
> 正義を目指して議論を進めている間に、規格＝「Netscapeのインプリ」に
> なっちゃったらどーにもならん、つーか。:-b
あ〜、すみません、ここで言う「Netscapeのインプリ」はどういう機能を
指してますか？ Netscape にほとんど触ったことないので知らないのです。。
出水法俊