From: nakamori@rinfo.sumiden.co.jp (Hironobu Nakamori) Real-Date: Mon, 8 Nov 93 17:57:00 +0900 Subject: [infotalk,00505] Japanese WAIS Message-Id: <9311080857.AA01358@snoopy.rinfo.sumiden.co.jp>
中森＠住友電工システムズ です。 どなたかWAISの日本語化されたもの(検索キーに日本語が 使えるもの)に関する情報(ソースまたはパッチ、ドキュメ ント等)をお持ちの方がおられましたら御連絡下さい。 以上。 --- 中森 弘修 ( nakamori@rinfo.sumiden.co.jp ) 住友電工システムズ(株)ソフトウェア開発センタ
From: Hitoaki Sakamoto <hitoaki@mahler.ntt.jp> Real-Date: Mon, 08 Nov 1993 16:56:03 +0900 Subject: [infotalk,00504] Re: I18N char encoding for infosystems Message-Id: <9311080756.AA04050@mahler.ntt.jp>
>> えーと、以前、gopher や WWW 用の日本語コードは ISO-2022-JP (7bit JIS) が >> いいと主張していた私ですが、ちょっと宗旨を改めました。日本語に関しては >> EUC にしよう、という主旨です。 既存のgopherでは、電子メール用には JISを選択しないと行けないわけです が、それは別に変換をすればいいのかな。 どちらかというと多言語化というよりも、地域化という気がします。 で実は、最近8bitスルーだったり MIMEみたいなのを考えると、私は文字コー ドは何でも良いような気がしてきました。そのかわりその文字コードが何もの であるかの登録は必要なのですが。 坂本仁明
From: TAKADA Toshihiro (高田敏弘) <takada@seraph.ntt.jp> Real-Date: Mon, 08 Nov 1993 16:47:16 +0900 Subject: [infotalk,00503] Re: I18N char encoding for infosystems Message-Id: <9311080747.AA13723@seraph.ntt.jp>
たかだです。 In <infotalk:00502> "Hitoaki Sakamoto <hitoaki@mahler.NTT>"-san writes: > 補助漢字はどうするの？ JIS X 0201 right halfと補助漢字を考えると、現状の日本語EUCコンパチでは なくなりますね。 現状はJIS X 0201 right halfと補助漢字はG2とG3(どっちがどっちか忘れた) に指示してシングルシフトで呼び出すんですけど、先の案に従うと、 "<ESC> - I" JIS X 0201-1976をG1に指示. "<ESC> $ ) D" JIS X 0212-1990をG1に指示. となります。 ======================================================================== ＮＴＴ基礎研究所 情報科学研究部 高田敏弘 分散コンピューティング原理研究グループ takada@nttlab.ntt.JP ========================================================================
From: Hitoaki Sakamoto <hitoaki@mahler.ntt.jp> Real-Date: Mon, 08 Nov 1993 15:50:02 +0900 Subject: [infotalk,00502] Re: I18N char encoding for infosystems Message-Id: <9311080650.AA01907@mahler.ntt.jp>
補助漢字はどうするの？ 坂本仁明
From: TAKADA Toshihiro (高田敏弘) <takada@seraph.ntt.jp> Real-Date: Mon, 08 Nov 1993 15:48:04 +0900 Subject: [infotalk,00501] I18N char encoding for infosystems Message-Id: <9311080648.AA13401@seraph.ntt.jp>
こんにちは、高田です。 えーと、以前、gopher や WWW 用の日本語コードは ISO-2022-JP (7bit JIS) が いいと主張していた私ですが、ちょっと宗旨を改めました。日本語に関しては EUC にしよう、という主旨です。 以下、提案を文書にしてみましたのでコメントを頂けると嬉しいです。ちょっと 長いですが、読んで貰えれば幸いです。 そいでは、いきます。 ======================================================================== Gopher, World-Wide Webなどにおける, 多言語化を目指した8ビット環境エン コーディング方法の提案 (Ver. 1993/11/08) by takada@seraph.ntt.jp [1] はじめに 当初はUS-ASCII, ISO-8859-1のみで使われてきたGopher, World-Wide Web (WWW)などのInformation Systemも, その急速な広がりと共に世界各国で使わ れるようになった. ここで問題となるのが各国文字コードのエンコーディング 方法である. ここでは様々な文字コードを, ＊それなりに＊ 一つのシステム 内で使うことを目的としたエンコーディング方法を提案する. [2] 現状 Gopher, World-Wide Web等は, ほとんどのシステムが8ビット透過を実現して おり, それを用いたエンコーディングが主流となっている. 以下実例を挙げる. (その他の利用例をご存知の方は, 高田まで教えて頂けると嬉しいです.) ・フランス / フランス語 / ISO-8859-1 <http://zenon.inria.fr:8003/accueil-fra.html> ・フィンランド / フィンランド語 / ISO-8859-1 <http://www.funet.fi/> ・ギリシャ / ギリシャ語 / ISO-8859-7 <gopher://pythia.csi.forth.gr:70/00/Welcome> ・イスラエル / ヘブライ語 / ISO-8859-8 <gopher://VM.BIU.AC.IL:70/11/Bar-Ilan%20information%20%28Hebrew%29> ・韓国 / 韓国語 / KSC 5601-1987 in EUC-KR <gopher://halla.dacom.co.kr:70/00/DACOM> ・台湾 / 中国語 / CNS 11643 in Big5/ETen (???) <gopher://gopher.sw.ccu.edu.tw:70/11gopher_root%3a%5b_cmenu%5d> ・中国 / 中国語 / GB 2312-1980 in GB encoding <ftp://ribm00.rhic.bnl.gov/pub/outgoing/deng/chinese.html> ・日本 / 日本語 / JIS X 0208-1983 in {ISO-2022-JP,EUC-JP,Shift-JIS} <http://www.ntt.jp/japan/note-on-JP/sample-jis.txt> <http://www.ntt.jp/japan/note-on-JP/sample-euc.txt> <http://www.ntt.jp/japan/note-on-JP/sample-sjis.txt> [3] 提案 上に示したように, Information Systemの多言語化は既に始まっている. これ らの現状からなるべく移行が容易なエンコーディングを考える. それを以下に 示す. (一部文章をMuleのdoc/ISO2022.jpから借りました.) ------------------------------------------------------------------------ "ISO-2022-8" (仮称) ISO 2022の8単位符号系(8ビット環境)に基づくエンコーディング. G0とG1のみ を使用する. G2とG3は使用しない. 常にG0がGLに, G1がGRに呼び出(invoke)された状態で使用する. ロッキング・ シフトやシングル・シフトは使用しない. デフォールトではG0にASCII (ANSI X3.4-1986)が, G1にラテン1補助文字(ISO 8859-1 right half)が指示(designate)されている. G0に指示できるのはASCIIのみ(※1). G1にISO 8859-1 right half以外の文字 集合を指示する場合は ESC [I] I <F> という形のエスケープ・シーケンスで行う([I] は, 複数連続する可能性のあ る'I'の意味). ここで'I'は中間文字(intermediate characters)である. 中間文字の意味は, $ [0x24]: 多バイト文字集合を表す(94×94或は96×96) ) [0x29]: G1に終端文字が<F>であるような94文字集合を指示する - [0x2D]: G1に終端文字が<F>であるような96文字集合を指示する となる. 以下に指示の例を挙げる. "<ESC> - G" ISO 8859-7をG1に指示. 例えばギリシャ語. "<ESC> - H" ISO 8859-8をG1に指示. 例えばヘブライ語. "<ESC> $ ) C" KSC 5601-1987をG1に指示. 例えば韓国語. "<ESC> $ ) B" GB 2312-1980をG1に指示. 例えば中国語(中文). "<ESC> $ ) A" JIS X 0208-1983をG1に指示. 例えば日本語. "<ESC> - A" ISO 8859-1をG1に指示. 例えばフランス語. これらの指示を表すエスケープ・シーケンスは, その文字集合を使用する際に 一回のみ使用すればよい. すなわち, 例えば改行する毎に指示をし直す必要は ない(※2). ASCIIと日本語漢字のみを含む文書の例を以下に示す(実際にはJIS X 0208の部 分はEUCにてエンコーディングされる). <ESC>$)BISO2022の8ビット単位系に基づくエンコーディングの記述. ここでもう一度エスケープシーケンスを入れる必要はない. またASCII, ISO 8859-1 right half, 日本語漢字が混在する文書の例を以下に 示す(上と同様に, 実際にはJIS X 0208の部分はEUCにてエンコーディングされ, "small o with circumflex accent" の部分は 0xe4 になる). _ <ESC>$)B"お"の長母音のローマ字表記は<ESC>-Ao<ESC>$)Bと書く. ------------------------------------------------------------------------ [4] 本手法の長所 Bilingual文書の場合は, 現在各言語で使われているエンコーディングとほぼ 等しいものとなる(ISO-2022-JPを除く). 唯一違う点は, ファイルの先頭に指 示を表すエスケープ・シーケンスが入ることだけである. この点は以下のよう に解決できるのではないか？ 例えばディスク中に保存される文書はエスケープ・シーケンスが無いものとし, Gopher Server や HTTP Server がその文書を送信する際に先頭にエスケープ・ シーケンスを挿入するようにする. こうすれば文書の編集などは従来のエディ タなどを用いたままで出来る. また文書の受信時は, 最初から自分が使用している以外の言語を読む気がなけ ればエスケープ・シーケンスを落してしまえば良い. また, エスケープ・シー ケンスが入ったまま放っておいても, 文書の先頭にわずかなゴミが入るだけで, さほど問題ないのではないか(※3). [5] 指示の省略とHTTPプロトコル Bilingual文章をやりとりする者の間でG1に指示される文字集合に関する合意 が取れている場合は, 指示を表すエスケープ・シーケンスを省略しても良いこ ととする. ただしその場合, 合意が取れていない者との間ではその文章は正し く伝わらず, ISO 8859-1 right halfを用いて書かれた文書として取り扱われ ることを了承しなくてはならない. またHTTP 1.0プロトコルのContent-Type:ヘッダにおけるcharsetパラメタを用 いて(※4), bilingual文書のエスケープ・シーケンスを省略することも可能と する. すなわちASCIIと日本語漢字のみを含む場合, Content-Type: text/html; charset=JIS_X0208-1983 Escape Sequenceを省略して書ける. という記述が可能になる(各文字集合とcharset名との対応付けは, 別途議論が 必要). 上記の, 合意に基づく, あるいは, charsetパラメタの使用によるエスケープ・ シーケンスの省略は, bilingual文書の時のみ有効とする(※5). [6] その他 World-Wide Webの場合, HTTP 1.0プロトコルには使用言語を表すLanguage:ヘッ ダが規定されている. クライアント・プログラムの助けとするため, ここで述 べたエンコーディング法と, このLanguage:ヘッダを併用することを推奨する. [7] 未解決な点 (※1) 「G0に指示できるのはASCIIのみ」という制限は必要か否か. 当初 ISO- 2022-JPでエンコーディングされたHTML文書の際に問題となった, ASCII 以外の文字集合に現れる "<" (SGML関係者は"stray less-than"と呼ぶ らしい)の問題などを避けるためにも, この制限はあった方が良いよう な気もするが... (※2) 「改行する毎にエスケープ・シーケンスによる指示をし直す必要はない」 という条件で本当に大丈夫か. Bilingual文書なら問題はないが, multi- lingual文書の場合は問題になると思われる. (※3) 行頭のエスケープ・シーケンスが理解できない場合, 本当に「単なるゴ ミ」で済まされるのか. クライアントの動作がおかしくなったりしない か. (※4) GopherプロトコルにはHTTPプロトコルのcharsetパラメタに相当する機 能はあるのか. Gopher+プロトコルのviewLanguageは意味が異なるため, 必要ならばGopherプロトコルに文字セットを表示する何らかの拡張を提 案する必要がある. (※5) 「エスケープ・シーケンスの省略は, bilingual文書の時のみ有効とす る」という制限は意味があるか. Multilingual文書を扱おうと思ったら, どの道きちんとエスケープ・シーケンスの処理をしなければいけないの で, 省略が出来る必要は余りないと思われるのだが. その他, HTML文書の中でエスケープ・シーケンスの代わりにHTMLのコマンドを 使って指示を行なうことを可能にすべきかどうかも, また別の問題である. 例 えば以下のような記述を認めるかどうか. _ <CHARSET ISO-8859-1>o</CHARSET><CHARSET JIS-X-0208>は 「お」の長母音を表す</CHARSET> あと, 特に書いておくと, この方法はいわゆるISO-2022-JPとは全く互換性が ない. これはそもそも日本において受け入れられるだろうか. しかし, いわゆ る日本語EUCからはその他の言語と同程度の変更であるので, 許容して欲しい と思うのだが. (以上) ======================================================================== ＮＴＴ基礎研究所 情報科学研究部 高田敏弘 分散コンピューティング原理研究グループ takada@nttlab.ntt.JP ========================================================================