From: Noritoshi Demizu (出水法俊) <demizu@nff.ncl.omron.co.jp>
Real-Date: Sat, 19 Aug 1995 19:27:22 +0900
Subject: [infotalk,05358] Re: See mail from other countries
Message-Id: <199508191027.TAA02863@coo.wg.omron.co.jp>
> みなさんは、海外に行った時に、メールはどのように見ているのですか?
> 方法はいくつかあるとおもうのですが、どの方法がおすすめでしょうか?
私は netcom の ppp に入ってます。月額 $19.95 で 40 時間まで使えます。
それを越えると追加料金がつきます。Netcom にアクセスするためのソフトウェ
アとして NetCruiser というのがあります。Fry's とか本屋に無料で置いてあ
るので、もらってきてインストールして起動すればサインアップできます。
(See http://www.netcom.com/. 料金表のページは見つけられなかったです)
PSI の PPP はもっと安いそうで、月額 $9 で 9時間まで使えるそうです。
それを越えると追加料金 $1.50/hr だそうです。東京にもアクセスポイントが
あって、上記 $9 とは別枠の重量制課金で $6/hr だそうです。たくさん
使う人には、月額 $29 で29 時間までというのもあります。
(See http://www.psi.net/indivservice.html.
アクセスソフトもftpできます。料金表もあります。)
他についてはあまり知らないのですが、私は PSI がいいかなぁと思っています。
PSI は、基本料金が安くてかつ東京でも使えるので、今度 PSI に乗り換えようかと
思っています。:)
出水法俊
From: Komatsuzaki Koji <koji@ulis.ac.jp>
Real-Date: Sat, 19 Aug 1995 18:24:44 +0900
Subject: [infotalk,05357] Re: draft-ietf-html-i18n-00.txt
Message-Id: <9508190924.AA22834@ares.ulis.ac.jp>
戸籍上では、右上が「立」の小松崎＠図書館情報大です。
文字コードについては（も）全くの素人です。
> 川幡＠東大理情報です。いきなり、fj.kanjiになってしまいます。
> 同じような問題には、右上が「立」の崎とか、「はしご高」問題（一時期、
> UCS調査研究委員会の委員長である芝野氏と、太田昌孝氏の間でfj.kanjiで激
> 論がありました)などがあります。これらは、世間一般では区別している（と
> 私は思う）ものの、JISでは同一の符号が割り当てられている例です。（信じ
> られないかもしれませんが、右上が「立」の崎は、大漢和にもありません。
ええと、中学のとき（かな？）、「崎」と「嵜」と立の「崎」を
調べたところ、「崎」は正字、「嵜」は部首が移動しただけのもの、
「島」、「嶋」、「嶌」の場合と同じ（？）、立の「崎」は、
行書体の名残で、楷書の場合は誤字だというのをどこかの漢和辞典で
引いたことがあります。
> 世間がこれらを区別するように要求すれば、それは区別されるという、象形文字
> を採用している言語の独特の事情があると思います。そして、未だ日本では
> これを区別して扱う土壌がないために、単に区別して符号化していないだけだと。
あと、「富」と「冨」のような忌字という歴史的背景で、字形が変わった
ものとかもあるので、統一化するのって難しいですよね。
図書館情報大学 大学院 図書館情報学研究科 情報構成論講座
修士課程 １年次 小松崎浩司
mailto:koji@ulis.ac.jp / http://www-student.ulis.ac.jp/~koji
From: tsujioka@exa.onlab.ntt.jp (Tetsuo Tsujioka)
Real-Date: Sat, 19 Aug 1995 18:21:00 +0900
Subject: [infotalk,05356] EC PROJECT
Message-Id: <9508190921.AA14782@exa.onlab.ntt.jp>
> 通産省が、電子取引全般に関して、アイデアを募集しています。
> 全体で、１００億円の補正予算をつけるそうです。
これは、話題のＣＡＳＬ関連の動きでしょうか。(間違っていたらすみません)
米国主導の状態に日本がどう入り込んでいくか興味のあるところです。
しかし、そのためにはもっと日本の中小企業にネットワークを普及させる
ことが前提になりますね。
----------
辻岡哲夫 (日本電信電話(株) NTT光ネットワークシステム研究所 Y-1006C)
tsujioka@exa.onlab.ntt.jp
From: saty@ossi.com (Mr. Tsuchiya)
Real-Date: Sat, 19 Aug 1995 01:59:20 +0800
Subject: [infotalk,05355] draft-ietf-html-i18n-00.txt
Message-Id: <9508190859.AA00583@skuld.ossi.com>
遠隔フォロウになりますが、
TAKADA> (質問1) 2022-basedのような状態遷移を含む形態を記述することは、そも
TAKADA> そもSGMLの枠組みで可能なのか？ そんなDTDは書けるのか？
SGMLには 2022に対応していると書いてある部分があります。そのココロは、
SGMLパーサはESCがくるとSGMLマークアップの解釈を中断する、ということで
す。
2022の呼出し列(でしたよね)が来ると今までSGMLマークアップの判定(例えば、
'<'とか'>')をやっていた文字集合とは別の文字集合となるからSGML文字の判定を中
断し、戻りの呼出し列がくるとまた解釈を再開する。別のいい方をすると
切り替えられた文字集合については、パーサはそれを解釈せず
データ文字としてアプリケーションにわたす、ということです。
日本の利用例を考えるとウームとうなってしまいますが、例えば アメリカ、
西ヨーロッパの場合、マークアップで使用する文字(<title>など)には a-z以
外使用しないということにして、8859-1とか 8859-Xにある文字はデータ文字
としてエスケープシーケンスのままアプリケーションに渡してアプリケーショ
ンが表示なり印刷なりをする、ということを考えてもそれほど不便には感じな
かったのでしょう。
質問に戻りますと、状態遷移については マークアップを解釈するモードとし
ないモードの記述として MSO (markup scan open) とか MSC (markup scan
close)といった文字を SGML宣言で記述できたと思います。あと 2022にはエス
ケープシーケンスに続くひと文字分だけ文字集合を切り換えるという(シング
ルシフトっていうんでしたっけ？)手法があると理解していますが、これにつ
いてはたしか MSS(markup scan suppress)という文字が記述できたと思います。
(この辺記憶が曖昧ですが。)
あ、これらはあくまでも SGMLという規格上のお話です。HTMLでも、特に日本
語を記述する HTMLでもSGMLのこの規則を厳密に適用すべきだといっているわ
けではありません。
entity managerという魔法の小人さんに活躍してもらうのがいいじゃないでしょ
うかね。というのは doc char setはパーサが文字の意味を判定するときのテー
ブルとするものであって、doc char setにしたがった文書ファイルの物理的存
在が必要とされるわけではないからで、ネットワーク転送上のコードは しば
らくは ISO-2022-INTだ、ということで合意を形成していき、SGMLとの準拠を
気にする人にはUCS-2をテーブルとすればSGMLに違反するわけではない、と説
明する。
取り込み中なので、あまりものを考えずに書いてます。
--
---------------------------------------------------------------------------
TSUCHIYA Satoshi | tsuchiya@sysrap.cs.fujitsu.co.jp | NIFTY-ID:GDC02435
土 屋 哲 (狼疾の人) | 富士通マルチメディアプロジェクト推進本部 企画部
From: KAWABATA Taichi <kawabata@is.s.u-tokyo.ac.jp>
Real-Date: Sat, 19 Aug 1995 15:58:34 +0900
Subject: [infotalk,05354] Re: draft-ietf-html-i18n-00.txt
Message-Id: <9508190658.AA22024@tjm.is.s.u-tokyo.ac.jp>
川幡＠東大理情報です。いきなり、fj.kanjiになってしまいます。
>>>>> "出水さん" == 出水法俊 <Noritoshi> writes:
>> ところで UNICODE では「吉」と「吉」をはじめてとして、
出水さん> う〜む、上の棒の方が長いのと、下の棒の方が長いのとを例として
出水さん> あげたつもりだったのに、良く見たら両方とも同じ形ですね。。
出水さん> JISX0208 側の問題なのかな。それとも僕の勘違いかな。。いづれ
出水さん> にしても失礼いたしました。(_O_)
士 土
口 と、口は、JISでも区別していません。しかし、だからといって、これらを
区別するのは間違いであるとも言えないと思います。ようするに、基本的には
世間がこれらを区別するように要求すれば、それは区別されるという、象形文字
を採用している言語の独特の事情があると思います。そして、未だ日本では
これを区別して扱う土壌がないために、単に区別して符号化していないだけだと。
同じような問題には、右上が「立」の崎とか、「はしご高」問題（一時期、
UCS調査研究委員会の委員長である芝野氏と、太田昌孝氏の間でfj.kanjiで激
論がありました)などがあります。これらは、世間一般では区別している（と
私は思う）ものの、JISでは同一の符号が割り当てられている例です。（信じ
られないかもしれませんが、右上が「立」の崎は、大漢和にもありません。
「はしご高」は、もともとは普通の「くち高」の楷書体のようですが、世間で
は段々と別の文字として認知されつつあると思います。でも、これを区別する
と、例えば同じような問題は「亭」とかにもあるわけで...ああ頭痛い。）
出水さん> ftp://unicode.org/pub/MappingTables/EastAsiaMaps/JIS/ から
出水さん> JIS0208.Z と JIS0212.Z を入手して、それぞれについて grep,
出水さん> awk, sort, uniq で調べたところ、異なる文字には UNICODE でも
出水さん> 異なるコードがあてられていました。誤解がひとつ解けました。
ISO 10646については、結構誤解があるようですね。
JIS X 0208-1990とJIS X 0212-1990に入っている漢字は、全て、ISO 10646に
対応する文字符号が割り当てられています。
しかし！！以下のような事実はあります。
●JIS X 0208-1990の単一の文字図形が、ISO 10646で複数のコードポイントに割
り当てられる。
→本当です。これは、JIS X 0208/ASCII(JIS X 0201ではなく)での重複文字が
何故か全角、半角文字として別個に割り当てられており、その上、JIS X
0212/ISO 8859の文字は、その解釈に従えば全角、半角に区別されるはずが、
統合されています。さらに、漢字も幾つかが0xf900〜0xfa2dまで複数個割り当
てられています。これは、主にKS C 5601とのすりあわせで生じた重複です。
また、「はしご高」や「中が点々の黒」など、JISで同一の符号が割り当てられ
ているものが、区別されています。
●ECMAで登録されて、ISO 2022で使用できる漢字(i.e. Muleで使える漢字)は、
ISO 10646で使える。
→嘘です。CNS 11643の中の数万文字は、ISO 10646では使えません。
●新JISからISO 10646へ変換したものと、旧JISからISO 10646へ変換したものは
同じである。(すなわち、旧JIS←→新JISの変換を、ISO 10646を介して行なう
ことができる。)
→嘘です。剥、屏、昂、柵、梍など９文字は別の文字符号が割り当てられてし
まいます。これはGBやCNSとのすりあわせのためです。ただし、その
他のものは同じ文字符号を割り当ててしまったために、旧JISからISO 10646へ
の変換は中途半端なものになってしまいます。
●中国で情報交換用に定められた漢字は全てISO 10646に入っている。
→これも嘘です。GB 7589とGB 7590にある漢字は入っていません。これを中国
が認めたのは、中国が文字符号をより意味的に割り当てるポリシーをもってい
るからです。JIS X 0221には、GB/T 13131とGB/T 13132をそれぞれGB 7589,
GB 7590として入れています。ここで、大問題が起きます。すなわち、「ごん
べん」や、「いとへん」などは、ISO 10646では繁体字と簡体字を区別して扱っ
ていますが、それらを同一と見倣す中国側では必ずしもそれに従うとは限らない
からです。（具体的には、これらの漢字の中で、Hanzi-Gで、3-xxxxとなっている
漢字または5-xxxxとなっている漢字のことです。）
これは、各国でポリシーが異なる文字を無理に統合した弊害の一つです。例え
ば、韓国のKSC 5601では、漢字をその発音で文字符号を振っています。そのた
め、例えば、「女」とか「金」とかは、発音の種類の数だけ複数の文字符号が
存在します。そうするとソートが楽になりますが、漢字の統合は難くなります。
簡単に言えば、
中国 ： 漢字を意味的に区別し符号化。(簡体字も、繁体字も同じ符号）
台湾 ： 漢字を図形的に区別し符号化。(極力、異体字は個別の符号を割り当てる)
韓国 ： 漢字を発音で区別し符号化。
日本 ： 日本で一般に区別されていると思われる漢字を個別に符号化し、それ以外は
同一に符号化。
という違いを無理に統合してしまっています。
結局、その他にも無理はあるので、ISO 10646は、暫くは普及することがあっ
ても、結局はISO 646のように使われなくなるようになると思います。
そういえば、ISO 646とISO 10646をひっかけて、ISO 102022が要る、という冗
談がありましたね。
-------------------------------------------------------------
川幡 太一 Taichi Kawabata kawabata@is.s.u-tokyo.ac.jp
東京大学大学院理学系研究科情報科学専攻１年
-------------------------------------------------------------
From: masayang@msushi.com
Real-Date: Fri, 18 Aug 1995 23:44:35 -0700
Subject: [infotalk,05353] Re: See mail from other countries
Message-Id: <199508190644.XAA14592@chirashi.msushi.com>
>>>>> On Sat, 19 Aug 95 15:03:34 +0900, yano@catv.sumiden.co.jp (Takashi Yano) said:
Reiko>あちらの、プロバイダーに一時的に入ってしまうのも、手だということを聞き
Reiko>ました。みなさんの意見をお聞かせ下さい。
>> これはどうやったら可能なんですか？ 最低の期間は？
中村＠カリフォルニアです。
こっちでは、いろんな本の付録で「インターネットフリートライアル」とかい
うのがついています。要はインターネット加入のためのプログラムなんですが、
最初の何十時間かはフリーというものです。
加入はカード(VISA or Master)があれば即できます。オンラインサインアップ
が多いですね。で、加入してメールアドレスが確定したら、telnetするなり電
話するなりして、日本の方のメールのforwardを設定すればいいんじゃないで
しょうか。
これで加入して、不要になったら脱退すればいいわけです。でも、最近は月額
$20でオッケーとかいうところもあるから、頻繁に出張するとか、米国に逃亡
する（笑）意思があるとかいうのなら、そのまんまにしてもいいんじゃないで
しょうか。
なかむら
From: yano@catv.sumiden.co.jp (Takashi Yano)
Real-Date: Sat, 19 Aug 1995 15:08:43 +0900
Subject: [infotalk,05352] Re: See mail from other countries
Message-Id: <9508190601.AA14886@cation.catv.sumiden.co.jp>
At 2:35 PM 95.8.19 +0900, Reiko Sawada wrote:
Reiko>みなさんは、海外に行った時に、メールはどのように見ているの
僕の方法はあまりお勧めできませんが、niftyserve に.forward してます。
こまめに見ないと溢れますが、緊急時には役に立ちます。
海外のアクセスポイントが利用できますが、米国以外はなかなか通信事情が
よくなく、国際電話で直接アクセスしても途中で落ちることもしばしばです。
欧州は経験在りません。
Reiko>あちらの、プロバイダーに一時的に入ってしまうのも、手だということを聞き
Reiko>ました。みなさんの意見をお聞かせ下さい。
これはどうやったら可能なんですか？ 最低の期間は？
From: Reiko Sawada <abath@mag.keio.ac.jp>
Real-Date: Sat, 19 Aug 1995 14:35:07 +0900
Subject: [infotalk,05351] See mail from other countries
Message-Id: <199508190535.OAA03945@ss10.mag.keio.ac.jp>
澤田@慶応大学です。
みなさんは、海外に行った時に、メールはどのように見ているの
ですか?方法はいくつかあるとおもうのですが、どの方法がおすすめでしょうか?
あちらの、プロバイダーに一時的に入ってしまうのも、手だということを聞き
ました。みなさんの意見をお聞かせ下さい。
慶應義塾大学大学院
政策メディア研究科２年
澤田 玲子
abath@mag.keio.ac.jp
tel: 0466-49-1071
fax: 0466-47-5013
From: 広瀬雄二 (HIROSE Yuuji) <yuuji@ae.keio.ac.jp>
Real-Date: Sat, 19 Aug 1995 13:03:00 +0900
Subject: [infotalk,05350] Re: draft-ietf-html-i18n-00.txt
Message-Id: <199508190403.NAA15875@inspire.comp.ae.keio.ac.jp>
慶應義塾の広瀬と申します。
脇道にそれてしまいますが。
>> On Sat, 19 Aug 95 05:52:59 +0900
>> demizu@nff.ncl.omron.co.jp (Noritoshi Demizu (出水法俊 )) said:
>
> > ところで UNICODE では「吉」と「吉」をはじめてとして、
>
> う〜む、上の棒の方が長いのと、下の棒の方が長いのとを例としてあげたつも
> りだったのに、良く見たら両方とも同じ形ですね。。JISX0208 側の問題なの
> かな。それとも僕の勘違いかな。。いづれにしても失礼いたしました。(_O_)
土 士
口 と 口
は言語学的に見ても同じ文字です。これはひらがなの「そ」を
ソ フ
て とかくか て という違いと同じ性質のものです。
(と金田一春彦氏がいっていました)
したがって「違う文字に同じコードを当てる」という例に用いる文字としては不
適当だと思います。
--
/// 慶應義塾大学理工学研究科管理工学専攻後期博士課程大駒研究室 /
// 広瀬雄二 [yuuji@ae.keio.ac.jp, yuuji@educ.cc.keio.ac.jp] //
/ 〒223 神奈川県横浜市港北区日吉3-14-1 045-563-1151:内線3678 ///
From: 22406680@people.or.jp
Real-Date: 19 Aug 95 10:19:20 JST
Subject: [infotalk,05349] ec project
Message-Id: <30353C18.D480.001@people.or.jp>
テキスト版を登録しました。
majordomo@iijnet.or.jp
に本文で、get nettalk 35 を送ってください。
We are Information Volunteers! Let's Learn & Share!
*nettalk producer* Tadashi Nagao
From: Hirotaka Yoshioka <hyoshiok@oracle.co.jp>
Real-Date: Sat, 19 Aug 95 7:29:11 JST
Subject: [infotalk,05348] Re: draft-ietf-html-i18n-00.txt
Message-Id: <9508182229.AA16741@jphp1.jp.oracle.com>
> > ところで UNICODE では「吉」と「吉」をはじめてとして、
> う〜む、上の棒の方が長いのと、下の棒の方が長いのとを例としてあげたつも
> りだったのに、良く見たら両方とも同じ形ですね。。JISX0208 側の問題なの
> かな。それとも僕の勘違いかな。。いづれにしても失礼いたしました。(_O_)
> 出水法俊
吉岡の吉は士のほうしかＪＩＳにはないです．
大漢和字典をみると土の方は間違いとかなんとか（だったと思う）
ので，まあ入っていないのはしょうがないかなと．
よ
--
Hirotaka Yoshioka
email: hyoshiok@jp.oracle.com (office)
hirotaka@st.rim.or.jp (home)
http://www.st.rim.or.jp/~hirotaka/
From: Noritoshi Demizu (出水法俊) <demizu@nff.ncl.omron.co.jp>
Real-Date: Sat, 19 Aug 1995 05:49:31 +0900
Subject: [infotalk,05347] Re: draft-ietf-html-i18n-00.txt
Message-Id: <199508182049.FAA05324@coo.wg.omron.co.jp>
土屋さん wrote:
> Unicodeと ISO10646のすり合わせが行われたときに source code separation
> という原則が提案されて、10646の文字の元となる集合(source code)である
> JIS X0208、JIS X0212などの文字同士をunification しないことになって
> いると思います。(私の理解では。) つまり、現実には jisx0208上で
> 異なる文字で Unicode上で同じである文字はないはずです。
ftp://unicode.org/pub/MappingTables/EastAsiaMaps/JIS/ から JIS0208.Z
と JIS0212.Z を入手して、それぞれについて grep, awk, sort, uniq で調べ
たところ、異なる文字には UNICODE でも異なるコードがあてられていました。
誤解がひとつ解けました。(_O_)
> ところで UNICODE では「吉」と「吉」をはじめてとして、
う〜む、上の棒の方が長いのと、下の棒の方が長いのとを例としてあげたつも
りだったのに、良く見たら両方とも同じ形ですね。。JISX0208 側の問題なの
かな。それとも僕の勘違いかな。。いづれにしても失礼いたしました。(_O_)
出水法俊
From: Noritoshi Demizu (出水法俊) <demizu@nff.ncl.omron.co.jp>
Real-Date: Sat, 19 Aug 1995 03:27:07 +0900
Subject: [infotalk,05346] Re: draft-ietf-html-i18n-00.txt
Message-Id: <199508181827.DAA03278@coo.wg.omron.co.jp>
せきぐちさんwrote:
> > (質問1) 2022-basedのような状態遷移を含む形態を記述することは、そも
> > そもSGMLの枠組みで可能なのか？ そんなDTDは書けるのか？
> > (質問2) もし書けるとしたら、どうやって書けばよい？
>
> short reference mapping を使えばできるような気がします。
う〜む。こんな感じでしょうか。。というわけでちょっと書いてみました。
素人なのでむちゃくちゃ書いてるかもしれません。。:(
省略なしの場合には、ISO-2022 の部分を <ISO2022> ... </ISO2022> で囲ん
で、さらにその中で code set を示す TAG を使うことにしてるつもりです。
つもりでは、次で「(JISX0201)アイウ(JISX0208)あいう」を表しています。
<ISO2022> <JISX0201> 123 <JISX0208> $"$$ </ISO2022>
省略ありの場合は、上記が次にかわります。
ESC ( I 1 2 3 ESC $ B $ " $ $ ESC ( B
# JISX0201 のカナを例に使ったのは失敗と思いつつも、いまさら書き直す
# 元気はないのです…。:(
<!ELEMENT ISO2022 - - (JISX0201|JISX0208)* >
<!ELEMENT JISX0201 - 0 (#PCDATA) >
<!ELEMENT JISX0208 - 0 (#PCDATA) >
<!ENTITY MAP-JISX0201 "<!USEMAP JISX0201>" >
<!ENTITY MAP-JISX0208 "<!USEMAP JISX0208>" >
<!ENTITY MAP-ISO8859-1 ENDTAG "ISO2022" >
<!SHORTREF MAP-ISO2022 "(H" MAP-JISX0201
"$B" MAP-JISX0208
"(B" MAP-ISO8859-1 >
<!USEMAP MAP-ISO2022 ISO2022 >
<!-- JISX0201 の entity の定義。JISX0201 を外部参照できないかな -->
<!SHORTREF JISX0201 1 JISX0201-A
2 JISX0201-I
.... .... >
<!ENTITY JISX0201-A CDATA "&#???;"--=片仮名の「ア」-->
<!ENTITY JISX0201-I CDATA "&#???;"--=片仮名の「イ」-->
.... ....
<!-- JISX0208 の entity の定義。JISX0208 を外部参照できないかな -->
<!SHORTREF JISX0201 "$"" JISX0208-HIRA-A
"$$" JISX0208-HIRA-I
.... .... >
<!ENTITY JISX0208-HIRA-A CDATA "&#???;"--=片仮名の「ア」-->
<!ENTITY JISX0208-HIRA-I CDATA "&#???;"--=片仮名の「イ」-->
.... ....
この場合、各文字の ENTITY 宣言の CDATA の次にはなんて書くと良いのです
か？document character set の文字の番号以外を書く方法ってないのですか？
そうだとすると、
SGMLで使える文字の集合 = document character set
ということになるので、BASESET, DESCSET をきちんと定義しなくてはいけな
くなっちゃって、せっかく shortref 使って一所懸命定義しても、そのおいし
さがひとつもなくなってしまうような気がします。。
勉強不足でわからない〜(;_;)。引続き勉強してみます。
出水法俊
From: Noritoshi Demizu (出水法俊) <demizu@nff.ncl.omron.co.jp>
Real-Date: Sat, 19 Aug 1995 02:20:02 +0900
Subject: [infotalk,05345] Re: draft-ietf-html-i18n-00.txt
Message-Id: <199508181720.CAA02712@coo.wg.omron.co.jp>
引続き勤務先がネットワーク工事中なのでメールが届かなくなっています。
infotalk ML archive を見て返事を書いているので遅くなりがちですみません。
よしおかさん wrote:
> ここでよくわからないのはｉｓｏ２０２２を利用するとどんな問題を
> どのように解決するのでしょうか？
逆に、ISO-2022 を HTML で使えなくすると、どんな問題をどのように解決す
るのでしょうか？
ISO-2022 を使えると嬉しいことは(この裏返しが使えなくなると悲しいこと)、
・すでに作成されている HTML データ、クライアント・ソフトがそのまま使える。
既存のエディタで HTML を編集できる。
・中国や台湾など 16bit では文字が足りない国でも困らない。
・JIS,GB,KC 等で新しく文字集合が定義された時、ECMAに登録した瞬間に
使えるようになる。UNICODE よりずっと早い。(ほんと?誤解?)
・複数の言語の文字を自然に表現できる。(ここはEUC,Sjisとの比較)
とりあえず思いつくのはこんなところです。
出水法俊
From: Noritoshi Demizu (出水法俊) <demizu@nff.ncl.omron.co.jp>
Real-Date: Sat, 19 Aug 1995 01:48:52 +0900
Subject: [infotalk,05344] Re: draft-ietf-html-i18n-00.txt
Message-Id: <199508181648.BAA01179@coo.wg.omron.co.jp>
引続き勤務先がネットワーク工事中なのでメールが届かなくなっています。
infotalk ML archive を見て返事を書いているので遅くなりがちですみません。
土屋さん wrote:
> Unicodeと ISO10646のすり合わせが行われたときに source code separation
> という原則が提案されて、10646の文字の元となる集合(source code)である
> JIS X0208、JIS X0212などの文字同士をunification しないことになって
> いると思います。(私の理解では。) つまり、現実には jisx0208上で
> 異なる文字で Unicode上で同じである文字はないはずです。
UNICODE については聞きかじり程度の知識しかないのでいつも反省してます。
勉強するにはどの本が良いですか？やはり The Unicode Consortium が出して
いる ``The UNICODE Standard'' の Vol.1, 2 でしょうか。
ところで UNICODE では「吉」と「吉」をはじめてとして、異なる文字に同じ
コードが割り当てられているのがあるとよく聞くのですが、これは嘘なのです
ね？ UNICODE に関する噂のウソ、ホント・リストみたいなのが欲しいです。:)
というか、UNICODE, ISO-2022 等についてきっちり書いてあるドキュメントが
欲しいです。やっぱり原典にあたるしかないのかな。
> 例えば、0から127番目までは ISO646 IRVで、128から 255までは iso 8859-1
> という既存の*文字集合*を借りてきてひとつの document character setを作
> ることができる、ということだと思っています。ギリシャとか東欧の人は後半
> の部分を 自分のところの文字集合 iso8859のなんとかに置き換えて自分の言
> 葉用の document character setを宣言することができる。
これはわかるのですが、具体的にはどのように宣言すると良いのですか？例え
ば BASESET, DESCSET を繰り返して必要な数だけ宣言すれば良いのですか？
だとすると楽だな。これができないと思ってたので、document character set
として使える文字集合をひとつ新たに定義しなくちゃいけないのかと思ったの
でした。
> 一般に誤解されやすいのは、ファイルやネットワークで使用されている文字表
> 現までUnicodeにしなければならないと思われてしまう点で、draft-i18n.txt
> に出てくるように entity managerという魔法のモジュールが*想定*されてい
> るので、基本的には外部コードに制限はありません。
entity manager が魔法なのかどうかわかりませんが:)、外部コードに何を使っ
ても良いことや、実装上の内部表現として document character set を使う必要
はないことは draft-ietf-html-i18n-00.txt に書いてあったので理解してます。
けど、*モデル上*、document character set として UCS-2 を使うと言った瞬間に、
1) あ〜、「吉」と「吉」を同じ文字として処理しなくちゃいけないんだな。
(これは誤解だそうですが、今朝はそう思ったので書いときます:)
2) UNICODE に入ってない文字は(建前上は)使えなくなるのね。
(中国の全漢字が 16bit に入るとは思えないので.)
3) 漢字を Ӓ って表記するには UNICODE 表を持ってないといけないのか。
(漢字コード辞典買いなおさなきゃ)
とか思ってしまったのです。少なくとも、1), 2) に従っている実装に対して
文句が言えなくなるなぁとと思ったのです。
そこで、1), 2) を解決できる document character set ってのを新たに定義
しなくてはいけないのかなぁって思ったのでした。もし entity manager が
魔法使いで、次が言えるのであればすごくありがたいことです。
SGMLで使える文字の集合 = document character set
+ entityで宣言されている文字の集合
もしこうなら、document character set は ASCII で十分ではないかと思いま
す。そのかわり、鬼のような量の entity 宣言が必要になりますが。:)
というわけで、document character set と entity の関係についてもちょっ
と勉強してみようと思います。
出水法俊