OSDN -- オープンソース・ソフトウェアの開発とダウンロード
日本語の翻訳状況 translation status for ja

[Gauche-devel-jp] Gauch****@lists*****のアーカイブ(1/3)

アーカイブの一覧に戻る

Shiro Kawai shiro****@lava*****
2002年 9月 17日 (火) 19:04:13 JST 

gauch****@lists*****で交わされた議論のdigestです。
アーカイブのために、こちらにも投げておきます。 --Shiro


Subject: [Gauche-devel-jp] 「ネイティブエンコーディング」に関して確認事項
From: karaa****@dream*****
To: gauche-devel-jp <gauch****@lists*****>
Date: Sun, 15 Sep 2002 01:18:18 +0900
User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryōmae) APEL/10.3 Emacs/21.3.50 (powerpc-apple-darwin5.5) MULE/5.0 (SAKAKI)


とりあえずMLもできた事ですし、こちらに投げてみます。
# MLの提案記述したのもわしだし、、

一つ確認しておきたいのですが、download-j.htmlなどに記述のある「ネイティ
ブエンコーディング」という単語の意味は、プログラム(Gauche)が日本語文字
列をメモリ上などで処理する時の文字コードとの理解でよいでしょうか？

普通はそういう意味だとおもう��ですが、単純に確認しておきたいと、、

この認識でただしいならば
euc-jp、utf-8、sjis、no 

でnoの時文字コードがなになのかちょと調査してないのですが、あきらかに
utf-8は仲間はずれだとおもうのですが、、
# iso-2022-jpがない程度には、、


----  
(。�゜) からあげうまうま
mailto:karaa****@dream*****

Subject: [Gauche-devel-jp] Re: [Gauche-devel-jp] 「ネイティブエンコーディング」に関して
From: KIMURA Shigenobu <skimu****@mac*****>
To: karaa****@dream*****
Cc: gauche-devel-jp <gauch****@lists*****>
Date: Sat, 14 Sep 2002 18:00:59 -0500
X-Mailer: Apple Mail (2.543)

文字コードのことはほとんど知らないですが、

On 2002.Sep.14, at 11:18 US/Central, karaa****@dream***** wrote:
> 文字列をメモリ上などで処理する時の文字コードとの理解でよいでしょうか？
>
> この認識でただしいならば
> euc-jp、utf-8、sjis、no
> でno��時文字コードがなになのかちょと調査してないのですが、あきらかに
> utf-8は仲間はずれだとおもうのですが、、

no はマルチバイト文字の処理をしないといういみだと思います。
つまり文字列はバイト列と同じ。

utf-8 が仲間はずれな理由を説明してもらせませんか？
僕には文字列処理(文字や部分文字列をとってきたり、挿入したりする操作を考えてます)
はどれも同じような��のだと思っていましたが。。。
; ASCII の範囲ならばどのコーディングでも文字列のバイト並びは同じですし。
; あ、utf-8 は任意のバイトを見てそれがマルチバイト文字の何バイト目かが
; 判別できるんでしたっけ？

あと、「おもうのですが、、」の続きが知りたいです。

木村 栄伸


Subject: [Gauche-devel-jp] Re: [Gauche-devel-jp] 「ネイティブエンコーディング」に関して確認事項
From: Shiro Kawai <shiro****@lava*****>
To: karaa****@dream*****
Cc: gauch****@lists*****
Date: Sat, 14 Sep 2002 14:24:34 -1000 (HST)
X-Mailer: Mew version 2.2 on XEmacs 21.4.6 (Common Lisp)

Shiroです。
文字コードの世界はちゃんと理解しているわけではないので、
間違っていたら突っ込んで下さい。

From: karaa****@dream*****
Subject: [Gauche-devel-jp] 「ネイティブエンコーディング」に関して確認事項
Date: Sun, 15 Sep 2002 01:18:18 +0900

> 一つ確認しておきたいのですが、download-j.htmlなどに記述のある「ネイティ
> ブエンコーディング」という単語の意味は、プログラム(Gauche)が日本語文字
> 列をメモリ上などで処理する時の文字コードとの理解でよいでしょうか？

Gaucheで用いている文字列内部の符号化法(character encoding scheme)
ということです。

> この認識でただしいならば
> euc-jp、utf-8、sjis、no 

noは置いといて��euc-jp, utf-8, sjisはどれも符号化法である
という意味では同レベルだとは思います。ただしそれぞれ、
対象とする符号化文字集合が異なります。

  符号化法 euc-jp→文字集合 ASCII, JISX0201, JISX0213 or JISX0208+JISX0212
  符号化法 sjis  →文字集合 JISX0213 (*)
  符号化法 utf-8 →文字集合 ISO10464

'no' は一文字8ビットで符号化するという符号化法を総称します。
符号化文字集合はJISX0201(*)だろうがISO8859-xだろうがGauche
は気にしません。

文字列から文字を取り出した時にどう表現されるかというのが
ドキュメントでは明確に定義されていないため、それが混乱のもとなの
かもしれません。文字列の符号化法がutf-8の場合は文字の
符号化法はUCS-4に準じます。euc-jpまたはsjisの場合は、
符号化された文字が1バイトの場合はそれをLSBとし、
符号化された文字が2バイトの場合は (第一バイト*256 + 第二バイト)
符号化された文字が3バイトの場合は (第一バイト*65536 + 第二バイト*256 + 第3バイト)
としたコードを文字オブジェクトの値に使っています。
(こういう符号化法に名前があるのかどうかはわかりません)

今までのところ、Gaucheの内部処理で必要な情報は主に符号化法
であって、実はそれがどの文字集合を扱っているかはあまり
関係がないのです。但し、プログラムテキストの解釈をする
ために、7bitで表現できる範囲がASCIIであるという仮定だけ
置いています(*)。

今のままだとchar-upper等がASCIIの範囲しか動作しないため、
本来は文字集合まで考慮に入れた処理を行わなければならないの
ですが、うまい形が見えていません。

(*) なお、困ったことにShift-JISのコード0-127の範囲は
JISX0201なので、厳密に解釈すると0x5cと0x7eがASCIIと
異な��のですが、GaucheではASCIIの該当文字として扱っています。

--shiro


Subject: Re: [Gauche-devel-jp] Re: [Gauche-devel-jp] 「ネイティブエンコーディング」に関して
From: karaa****@dream*****
To: gauche-devel-jp <gauch****@lists*****>
Date: Sun, 15 Sep 2002 10:20:02 +0900
User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryōmae) APEL/10.3 Emacs/21.3.50 (powerpc-apple-darwin5.5) MULE/5.0 (SAKAKI)

失礼、Reply-To�本人のアドレスになっていたので直でメイルしてしまいまし
た。

# あと正直この規模のMLでToにMLアドレスccに投稿者アドレスされると
# だぶってメンドクサイですのでMLだけにポストしていただけるとありがたい
# です。


At Sat, 14 Sep 2002 18:00:59 -0500,
KIMURA Shigenobu wrote:
> 文字コードのことはほとんど知らないですが、
> > 文字列をメモリ上などで処理する時の文字コードとの理解でよいでしょうか？
> > この認識でただしいならば
> > euc-jp、utf-8、sjis、no
> > でnoの時文字コードがなになのかちょと調査してないのですが、あきらかに
> > utf-8は仲間はずれだとおもうのですが、、
> no はマルチバイト文字の処理をしないといういみだと思います。
> つまり文字列はバイト列と同じ。
Shiroさんのメイルで概要はわかりました。

> utf-8 が仲間はずれな理由を説明して�らせませんか？
聞いた事があるかどうか不明ですが、HTMLはiso-2022-jpで記述しなさい、とか
メイルはiso-2022-jpで送信しなさいとかあります。

sjisでHTML書くと文字コードにうるさい人は眉をしかめます。
それはなぜか理由をしっているならわかるはずです。

内部コード、外部コードがどうちがうかなどを認識が必要です。

またEUCといっても内部用にはEUC 2-byte complete format
外部用にはEUC packed formatがある事をしっていますか？

なぜ内部、外部を分割するかを認識いただければ幸いです。

> 僕には文字列処理(文字や部分文字列をとってきたり、挿入したりする操作を考えてます)
> はどれも同じようなものだと思っていましたが。。。
> ; ASCII の範囲ならばどのコーディングでも文字列のバイト並びは同じですし。
> ; あ、utf-8 は任意のバイトを見てそれがマルチバイト文字の何バイト目かが
> ; 判別できるんでしたっけ？
...文字コード勉強してください。

> あと、「おもうのですが、、」の続きが知りたいです。
理由がしりたいです、といった感じで理解してください。

----  
(。�゜) からあげうまうま
mailto:karaa****@dream*****


Subject: [Gauche-devel-jp] Re: 「ネイティブエンコーディング」に関して
From: Shiro Kawai <shiro****@lava*****>
To: gauch****@lists*****
Date: Sat, 14 Sep 2002 15:59:25 -1000 (HST)
Reply-To: gauch****@lists*****
X-Mailer: Mew version 2.2 on XEmacs 21.4.6 (Common Lisp)

Shiroです。

From: karaa****@dream*****
Subject: Re: [Gauche-devel-jp] Re: [Gauche-devel-jp] 「ネイティブエンコーディング」に関して
Date: Sun, 15 Sep 2002 10:20:02 +0900

> # あと正直この規模のMLでToにMLアドレスccに投稿者アドレスされると
> # だぶってメンドクサイですのでMLだけにポストしていただけるとありがたい
> # です。

Reply-toをMLにできるらしきオプションがあったので変えてみました。
このメイルのReply-Toがgauche-devel-jpになったてたら成功です。

# Subjectの[Gauche-devel-jp]が重なる場合一つだけに
# してくれるオプションも探したんだけど見当たりませんでした…

> 聞いた事があるかどうか不明ですが、HTMLはiso-2022-jpで記述しなさい、とか
> メイルはiso-2022-jpで送信しなさいとかあります。

私もoldtype (Cf. http://www.namazu.org/~satoru/misc/ggap.html)
ですんで、iso-2022-jpでないメイルにはいやーんな感じを受けます。
でもContent-typeでcharset指定が付いてたら規格上は文句は
つけられないと思っているんですがまずいでしょうか。

まあメイルに関してはrelayされるところでいろいろ通りますから
7bitなencodingで送って欲しい、という現実があり�すが、
HTMLでiso-2022-jp推奨、という現実的な理由はなんでしょう??
HTMLで8bit throughでないproxyとかありますっけ?
というかヨーロッパ方面のページは基本的にiso-8859-xだし、最近はutf-8
なところも増えてきたので、8bitが問題では無いのかな。

> またEUCといっても内部用にはEUC 2-byte complete format
> 外部用にはEUC packed formatがある事をしっていますか？

じゃあGaucheのは文字列がpacked formatで文字がcomplete format、
と言っておけばよさそうですね。

あと、skimuさんへのリプライですが
> > ; ASCII の範囲ならばどのコーディングでも文字列のバイト並びは同じですし。
Shift JISを厳密に解釈するとちょっと困るのは一つ前のメイルに書いた通りです。
Windowsの日本語のエンコーディングであるCP932はさりげなく
0x5cと0x7eをASCIIにマップしてるんでしたよね?
> > ; あ、utf-8 は任意の�イトを見てそれがマルチバイト文字の何バイト目かが
> > ; 判別できるんでしたっけ？
最初のバイトか2バイト目以降か、だけがわかります。

--shiro


Subject: Re: [Gauche-devel-jp] 「ネイティブエンコーディング」に関して確認事項
From: karaa****@dream*****
To: gauche-devel-jp <gauch****@lists*****>
Date: Sun, 15 Sep 2002 11:31:57 +0900
Reply-To: gauch****@lists*****
User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryōmae) APEL/10.3 Emacs/21.3.50 (powerpc-apple-darwin5.5) MULE/5.0 (SAKAKI)

At Sat, 14 Sep 2002 14:24:34 -1000 (HST),
Shiro Kawai wrote:
> > 一つ確認しておきたいのですが、download-j.htmlなどに記述のある「ネイティ
> > ブエンコーディング」という単語の意味は、プログラム(Gauche)が日本語文字
> > 列をメモリ上などで処理する時の文字コードとの理解でよいでしょうか？
> Gaucheで用いている文字列内部の符号化法(character encoding scheme)
> ということです。
意味は了解しました。

# character encoding scheme(CES)の訳は通常文字列符号化体系のはずです。

> > この認識でただしいならば
> > euc-jp、utf-8、sjis、no 
> noは置いといて、euc-jp, utf-8, sjisはどれも符号化法である
> 'no' は一文字8ビットで符号化するという符号化法を総称します。
> 符号化文字集合はJISX0201(*)だろ��がISO8859-xだろうがGauche
> は気にしません。

> かもしれません。文字列の符号化法がutf-8の場合は文字の
> 符号化法はUCS-4に準じます。euc-jpまたはsjisの場合は、
> 符号化された文字が1バイトの場合はそれをLSBとし、
> 符号化された文字が2バイトの場合は (第一バイト*256 + 第二バイト)
> 符号化された文字が3バイトの場合は (第一バイト*65536 + 第二バイト*256 + 第3バイト)
> としたコードを文字オブジェクトの値に使っています。
> 今までのところ、Gaucheの内部処理で必要な情報は主に符号化法
> であって、実はそれがどの文字集合を扱っているかはあまり
> 関係がないのです。但し、プログラムテキストの解釈をする
> ために、7bitで表現できる範囲がASCIIであるという仮定だけ
> 置いています(*)。
とりあえず以下のように理解しましたが問題ないでしょうか？

�Gaucheにおいては「内部コード」という物は存在しない。(Rubyっぽい？)
・文字コード変換はiconvにておこなっている。
・当然のようにUnicodeとsjisなどの変換表はiconvの物を利用。

これで正しいなら、内部コードという表現は適切ではないかと...
# そもそもUTF-8が内部コードだったら大変な事になります。


とりあえずUFT-8では元の文字を取り出す場合デコードする必要があり、内部�ード
に利用するようなものじゃないです。
# UFT-8での漢字は3〜7の可変長になる。まあはいってきた時わかるからいいですが、、

UTF-8を「内部コード」に使わないのはiso-2022-jp(JISコード)を内部コードに利用しない
のと同じ事です。

うーーん。でもまだすこしもやもやが、、また後でかんがえてみます。
# おそらくShiroさんとわたしで単語の意味が微妙にちがう、、
# あと実装へ��理解がわたしが足りない部分があるのでソースもうすこし熟読します。

----  
(。�゜) からあげうまうま
mailto:karaa****@dream*****

Gauche-devel-jp メーリングリストの案内
アーカイブの一覧に戻る