テキスト・スクリプトの殿堂TSNET最新発言

[TSabc]世界言語文字列ソートプロジェクト(Re: Re: UTF-8 フラグの立て方・降ろし方)(davi)

2008-06-30T05:34+09:00

Bruce.さん＜こん？？はでびです

On Sun, 29 Jun 2008 23:48:18 +0900
"Bruce." wrote:

> > 自分だけではなかろうに…」と「そんなに特殊な希望なの？これ？」
> > との狭間で、不思議な感じがします。

> Matz を説得する方法のスライドがすばらしい件 - TokuLog 改めB日記
> http://d.hatena.ne.jp/tokuhirom/20080629/1214717545

|自分がすごい重要な問題だとおもっていても、作者にとっては
|瑣末な問題、ということがよくあります。

この辺の見極めが難しいですよね。

lemmaの話を出したのは無駄に話題が大きくなって
しまって、マズかったかも、と反省しています。

> MSORT
> http://billposer.org/Software/msort.html

漢数字表記を実数に展開してSortする機能が強調されていますが、

|For each key an effectively unlimited number of
|multigraphs (sequences of characters to be treated
|as a single unit for purposes of sorting, "collating
|elements" in Unicode parlance) of effectively unlimited
|length may be defined.

つーことは、文字列についても任意の順序指定ができる、
と読み取って良いのかな？

あ、でも残念ながらwin32なバイナリは無いみたいですね。

MinGWでコンパイルとかの必要がある、と。
ちと腰を据えてやる時間を作らねばならなそうです。

> Collation - Wikipedia, the free encyclopedia
> http://en.wikipedia.org/wiki/Alphabetical_order
>
> Lexicographical order - Wikipedia, the free encyclopedia
> http://en.wikipedia.org/wiki/Lexicographic_order

そこからUnicode collation algorithmと、International
Components for Unicode (ICU) へ行きました。

ICUはIBMがやっているUnicodeを各ロケール毎に便利に
対応させるプロジェクトのようですね。

各種文字コード規格を混ぜ合わせたのがUnicodeだから、
各ロケールの粒度で処理したいときには扱いにくい、
という認識は技術者の側にも存在する、ということが
わかりました。

でび http://davi.txt-nifty.com/1984/

[TSabc]世界言語文字列ソートプロジェクト(Re: Re: UTF-8 フラグの立て方・降ろし方)Sender: きむらこういち hogemuta@gmail.com(Bruce.)

2008-06-29T23:48+09:00

Bruce.です。

> ただ、「Unicodeのデータについて、自分で並べ順を指定するための
> テーブルさえ用意すれば、思い通りの価値観の順でSortできますよ」
> という（場当たり的に個人のニーズでスクリプト言語で書くのではなく、
> Cで書かれていて高速に動く）プログラムの枠組みは是非とも必要だろう
> と思うのですよね。

> 存在して然るべき（と思われるような）プログラムが、スコーンと
> 抜けて存在していない、ってのに出くわすと、「欲しいと思うのは
> 自分だけではなかろうに…」と「そんなに特殊な希望なの？これ？」
> との狭間で、不思議な感じがします。

でびさんはこの辺に目を通しておくといいのじゃないかと思いましたまる

MSORT
http://billposer.org/Software/msort.html

Collation - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Alphabetical_order

Lexicographical order - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Lexicographic_order

Matz を説得する方法のスライドがすばらしい件 - TokuLog 改めB日記
http://d.hatena.ne.jp/tokuhirom/20080629/1214717545

http://cvs.m17n.org/~akr/diary/2008-06.html#a2008_06_22_1

--
木村浩一/KIMURA Koichi
I thought what I'd do was, I'd pretend I was one of those deaf-mutes or
shoud I?
mail kbk at kt.rim.or.jp
web www.kt.rim.or.jp/~kbk/zakkicho/index.html

[TSabc]Lingua::JA::Sort::JISを試す(Re: JIS X4061について)(藤岡和夫)

2008-06-29T22:59+09:00

On Sun, 29 Jun 2008 18:47:14 +0900
藤岡和夫 wrote:

> ASPN : Lingua::JA::Sort::JIS 0.04
> http://aspn.activestate.com/ASPN/CodeDoc/Lingua-JA-Sort-JIS/JIS.html

　ActivePerl5.8.8にモジュールがあるので試しました。仕様は下記の通り。

-----^
About this implementation

[according to the article 6.2, JIS X 4061]

(1) charset: UTF-8.

(2) No limit of the number of characters in the string considered
to collate.

(3) No character class is added.

(4) The following characters are added as collation elements.

IDEOGRAPHIC SPACE in the space class.

ACUTE ACCENT, GRAVE ACCENT, DIAERESIS, CIRCUMFLEX ACCENT,
MACRON, HORIZONTAL BAR, EN DASH, TILDE, PARALLEL TO
in the class of descriptive symbols.

APOSTROPHE, QUOTATION MARK in the class of parentheses.

HYPHEN-MINUS in the class of mathematical symbols.

(5) Collation of Latin alphabets with macron and with circumflex
is supported.

(6) Selected kanji class:
the minimum kanji class (Five kanji-like chars).
the basic kanji class (Levels 1 and 2 kanji, JIS).
the extended kanji class (CJK Unified Ideographs).
-----$

　まあ、サンプルとしてはまだ仕様を確認するレベルではないけど^^;)動きますね。

　UTF-8で保存して試してください。UTF-8で出力します。

-----^
use Lingua::JA::Sort::JIS;

$jis = Lingua::JA::Sort::JIS->new(3,3);
@data = qw(いぬとちのきにんじんはむたろうろばへらぶなとりほらがい藤岡和夫 Bruce. Zazel ねこ丸Ｙさでび);
@sorted = $jis->jsort(@data); # utf-8 encoded
foreach (@sorted){
print $_,"\n";
}
-----$

　結果は、

-----^
bash-3.2$ /c/perl5.8/bin/perl jsort.pl
Bruce.
Ｙさ
Zazel
いぬ
でび
とちのき
とり
にんじん
ねこ丸
はむたろう
へらぶな
ほらがい
ろば
藤岡和夫
-----$

　これぐらい(JISX4061)で、でびさんの望みが叶えられればいいんですけどね。

藤岡和夫
kazuf@...
日曜プログラマのひとりごと http://homepage1.nifty.com/kazuf/renewal.html

[TSabc]形態素解析について(藤岡和夫)

2008-06-29T19:14+09:00

On Sun, 29 Jun 2008 19:07:22 +0900
藤岡和夫 wrote:

> 　lemmatisationは英辞郎だとlemmatization。うーむ、lemmatizerで検索するとそれ以
> 上出てきますね。lemmatizationとは要は形態素解析のこと。

　ちょっと違う。形態素解析は英辞郎だとmorphological analysis、Wikipedia
では、Analysis of morphology。

morphology (linguistics)
http://en.wikipedia.org/wiki/Morphology_%28linguistics%29

藤岡和夫
kazuf@...
日曜プログラマのひとりごと http://homepage1.nifty.com/kazuf/renewal.html

[TSabc]Lemmatizerについて(藤岡和夫)

2008-06-29T19:07+09:00

On Sun, 29 Jun 2008 16:50:06 +0900
藤岡和夫 wrote:

> Lemmatisation - http://en.wikipedia.org/wiki/Lemmatisation
>
> にある Collatinus がその一つだと思いますね。Lemmaという用語自体があるわ
> けだから、ないわけがない^^;)

　lemmatiser でGoogleを検索すると、4,000件以上ヒットしますね。

　lemmatisationは英辞郎だとlemmatization。うーむ、lemmatizerで検索するとそれ以
上出てきますね。lemmatizationとは要は形態素解析のこと。

Lemmatizer.org
http://lemmatizer.org/

がトップに出てきます。

藤岡和夫
kazuf@...
日曜プログラマのひとりごと http://homepage1.nifty.com/kazuf/renewal.html

[TSabc]JIS X 4061について(藤岡和夫)

2008-06-29T18:47+09:00

On Sun, 29 Jun 2008 14:25:11 +0900 (JST)
Zazel さんwrote:

> 例えば全員が日本語文字列照合順番(JIS X 4061:1996)で納得するとは
> 到底思えません。

　JIS規格そのものは、

日本工業標準調査会：データベース検索-JIS検索
http://www.jisc.go.jp/app/JPS/JPSO0020.html

で、「X4061」で検索すると見ることができます。

　JIS X 4061で調べるといろいろ見つかりますね。

ShiftJIS/Collate.pm
http://homepage1.nifty.com/nomenclator/perl/ShiftJIS-Collate.html

Collator クラス / 日本語PHPマニュアル
http://onur.profcode.com/class.collator.html

ASPN : Lingua::JA::Sort::JIS 0.04
http://aspn.activestate.com/ASPN/CodeDoc/Lingua-JA-Sort-JIS/JIS.html

藤岡和夫
kazuf@...
日曜プログラマのひとりごと http://homepage1.nifty.com/kazuf/renewal.html

[TSabc]世界言語文字列ソートプロジェクト(ねこ丸)

2008-06-29T17:52+09:00

ねこ丸です。

Zazel writes:

> 例えば全員が日本語文字列照合順番(JIS X 4061:1996)で納得するとは
> 到底思えません。
>
> # 「辞書順にしてくれ」と言われて困ったことはありませんか?(-_-;)

読み仮名付けて五十音順、程度ですかねぇ。
その五十音も機械の都合でこうなってるんですよぉ〜みたいな。

# 何か恣意的なものがあるならそれを先に定義してほしいと思うことはある

--
ねこ丸

[TSabc]世界言語文字列ソートプロジェクト(藤岡和夫)

2008-06-29T16:50+09:00

On Sun, 29 Jun 2008 15:39:25 +0900
"davi" さんwrote:

> > 　この部分は、過去の資産の問題もあるので、OKというわけにはいかないですね。
>
> 個人的には、データそのものをUTF-8に変換しちゃえばいいじゃん、
> と思っています。

　もう一つの理由は、Windowsの文字コードがいまだにSJISということがありま
すね。僕の場合はどちらでも自在に扱える方が便利だという気持ちの方が強い。
実際、全部手持ちのデータをUTF-8に変換しないと使えないというのでは面倒だ
と思うから。まあ、UTF-8が扱えれば、でびさんの基準は満たすわけでOKでしょ
う。僕はそれだけでは不満足というだけのこと。環境がUTF-8に対応できていな
い。

> いまだに「EUCの固定長データこそ至上の持ち方！」みたいな
> 昔からのメインフレーム屋（で、顧客用のWebサーバを単なる
> フロントエンドと見下しているような人々）には、そろそろ
> 意識改革しても良いんじゃないっすか？、と。
>
> 銀行の預金システムとかで、異体字がJIS範囲では表示でき
> ないから未だにカタカナなのって、おかしいじゃん、と。
> せめてUnicode範囲の文字までなら異体字表示可能ですよ、
> まではやっておくべきだよね、と。

　ぼくはその領域の話はよく知らないですけど、自分の知っている範囲、自分の
できる範囲で考えるのが人間の習性ということはありますね。

> > 　これは、私も日本語をソートしていつも思うのですが、コード順にソートして
> > 何の意味があるのかなということです。何か発音順のあいうえお順のようにも思
> > えるのですが・・・
>
> JISの第1水準は漢字のヨミの五十音順、第2水準は部首・画数順で定義されています。
> これを全部、部首・画数順でSortするためのプログラムを、パソ通時代の太古、
> 益山健（massangeana）さんが公開していたような気がします。

　なるほど、読みの順のような気がしたり、一貫性もないような気もしていまし
たから、JIS第1水準と第2水準の違いですか。

　ただ、漢字は、文字コード順にソートしてもあまり意味がないのではと思いま
すね。並びを漢字の状態で見て意味が分からないのです。並んでいるという感じ
がしない。前の記事に書いたPukiwikiのページ一覧のソート結果を見ての感想で
すけどね。まあ、類似した文字列は近くに並びますが。

　辞書順というのはすなわち読みの順ですね。文字コード順のソートでそれが実
現できないなら、まずは標準としてこれを実現することを目的とするかな。そう
すればアルファベットと同様に「かな」順に表示できる。

> > 　少なくとも、日本人だから、日本語のソートについてはこうあるべきという考
> > え方があってもよいと思います。それさえあれば、日本語文字列ソートプロジェ
> > クトみたいなものはできるかもしれない。それを拡げて、世界言語文字列ソート
> > プロジェクトに発展させることも可能かと(^^)
>
> Zazelさんの仰るように、色んな価値観があるから、難しいかと。
>
> ただ、「Unicodeのデータについて、自分で並べ順を指定するための
> テーブルさえ用意すれば、思い通りの価値観の順でSortできますよ」
> という（場当たり的に個人のニーズでスクリプト言語で書くのではなく、
> Cで書かれていて高速に動く）プログラムの枠組みは是非とも必要だろう
> と思うのですよね。

　Perlのままでも実用的には十分だと思います。昔のCよりは今のPerlのほうが
速い^^;)リアルタイムは難しいだろうけどね。

> で、GnuのツールAspellみたいに、有志がテーブルを作って公開すれば
> 良いんじゃないかな、と。

　そうですね。

> でも、Unicode Consortiumでは、そういうフレームワーク部分に
> 該当するようなソフトを公開していないようです。
> gnuwin 32とかでも無いみたい。
>
> 欧文言語圏の人も、単語の格変化や複数形などによる変化形が
> あるとSortしたりCountするときに困る、ってことは
> コーパス言語学ではlemma化が必要なんだから、当然、理解して
> いるはずだとは思うんですけど、lemma化ツールを探してみると、
> 日本人が作ったPerlスクリプトに行き当たりました。
> （http://www.eng.ritsumei.ac.jp/asao/resources/lemma/）
>
> 私の探し方が悪かったのか、元々欧米人自身にはそういうニーズが
> ないのか…。
>
> 存在して然るべき（と思われるような）プログラムが、スコーンと
> 抜けて存在していない、ってのに出くわすと、「欲しいと思うのは
> 自分だけではなかろうに…」と「そんなに特殊な希望なの？これ？」
> との狭間で、不思議な感じがします。

Lemmatisation - http://en.wikipedia.org/wiki/Lemmatisation

にある Collatinus がその一つだと思いますね。Lemmaという用語自体があるわ
けだから、ないわけがない^^;)

　それに機能は単純だから自作も多いでしょう。

藤岡和夫
kazuf@...
日曜プログラマのひとりごと http://homepage1.nifty.com/kazuf/renewal.html

[TSabc]世界言語文字列ソートプロジェクト(Re: Re: UTF-8フラグの立て方・降ろし方)(davi)

2008-06-29T15:39+09:00

藤岡和夫さん Zazelさんみなさん＜こん？？はでびです

On Sun, 29 Jun 2008 12:38:35 +0900
藤岡和夫 wrote:

> 　この部分は、過去の資産の問題もあるので、OKというわけにはいかないですね。

個人的には、データそのものをUTF-8に変換しちゃえばいいじゃん、
と思っています。

いまだに「EUCの固定長データこそ至上の持ち方！」みたいな
昔からのメインフレーム屋（で、顧客用のWebサーバを単なる
フロントエンドと見下しているような人々）には、そろそろ
意識改革しても良いんじゃないっすか？、と。

銀行の預金システムとかで、異体字がJIS範囲では表示でき
ないから未だにカタカナなのって、おかしいじゃん、と。
せめてUnicode範囲の文字までなら異体字表示可能ですよ、
まではやっておくべきだよね、と。

> 　これは、私も日本語をソートしていつも思うのですが、コード順にソートして
> 何の意味があるのかなということです。何か発音順のあいうえお順のようにも思
> えるのですが・・・

JISの第1水準は漢字のヨミの五十音順、第2水準は部首・画数順で定義されています。
これを全部、部首・画数順でSortするためのプログラムを、パソ通時代の太古、
益山健（massangeana）さんが公開していたような気がします。

> 　少なくとも、日本人だから、日本語のソートについてはこうあるべきという考
> え方があってもよいと思います。それさえあれば、日本語文字列ソートプロジェ
> クトみたいなものはできるかもしれない。それを拡げて、世界言語文字列ソート
> プロジェクトに発展させることも可能かと(^^)

Zazelさんの仰るように、色んな価値観があるから、難しいかと。

ただ、「Unicodeのデータについて、自分で並べ順を指定するための
テーブルさえ用意すれば、思い通りの価値観の順でSortできますよ」
という（場当たり的に個人のニーズでスクリプト言語で書くのではなく、
Cで書かれていて高速に動く）プログラムの枠組みは是非とも必要だろう
と思うのですよね。

で、GnuのツールAspellみたいに、有志がテーブルを作って公開すれば
良いんじゃないかな、と。

でも、Unicode Consortiumでは、そういうフレームワーク部分に
該当するようなソフトを公開していないようです。
gnuwin 32とかでも無いみたい。

欧文言語圏の人も、単語の格変化や複数形などによる変化形が
あるとSortしたりCountするときに困る、ってことは
コーパス言語学ではlemma化が必要なんだから、当然、理解して
いるはずだとは思うんですけど、lemma化ツールを探してみると、
日本人が作ったPerlスクリプトに行き当たりました。
（http://www.eng.ritsumei.ac.jp/asao/resources/lemma/）

私の探し方が悪かったのか、元々欧米人自身にはそういうニーズが
ないのか…。

存在して然るべき（と思われるような）プログラムが、スコーンと
抜けて存在していない、ってのに出くわすと、「欲しいと思うのは
自分だけではなかろうに…」と「そんなに特殊な希望なの？これ？」
との狭間で、不思議な感じがします。

でび http://davi.txt-nifty.com/1984/

[TSabc]セマンティック・ソーティング・プロジェクト(Re: Re:世界言語文字列ソートプロジェクト)(藤岡和夫)

2008-06-29T15:11+09:00

On Sun, 29 Jun 2008 14:25:11 +0900 (JST)
Zazel さんwrote:

> Zazelです。
>
> === 藤岡和夫さんが書かれた
> === <20080629121949.18F8.KAZUF@...> にて
>
> > 　少なくとも、日本人だから、日本語のソートについてはこうあるべきという考
> > え方があってもよいと思います。それさえあれば、日本語文字列ソートプロジェ
> > クトみたいなものはできるかもしれない。それを拡げて、世界言語文字列ソート
> > プロジェクトに発展させることも可能かと(^^)
>
> 十人十色なのでそれは無理です。例えば“教育漢字の学年順”とか
> 出版社によって異なる“国語辞書の順番”や“漢字の画数順”など、
> 他人には意味がない順番がいくらでも出てくるでしょう。
>
> 例えば全員が日本語文字列照合順番(JIS X 4061:1996)で納得するとは
> 到底思えません。
>
> # 「辞書順にしてくれ」と言われて困ったことはありませんか?(-_-;)

　コメントありがとうございます。

　おもしろいですね。本質的な話ですね。困るぐらいの話でないと取り組む意味
がないと思うんですね。辞書順というのもいいですね。というか、任意の順に並
べることができるというのがよいと思うのですね。自分の使いたいソート順を選
択できるようにする。そうすると十人十色、ソート対象の性質によって基準を変
えることができる。

　すなわち、意味的なソートができる。題して、セマンティック・ソーティング
・プロジェクト^^;)

　ソートするための辞書を作ろうというプロジェクトになるのかもしれない。ち
ょっとここが大変そうなので工夫がいるのか、要領がいるのか、まだよくわかり
ませんが、バベルの塔になるかもしれない^^;)

　ぼくが最近感じたのは、「Pukiwikiに「一覧」というページがあって、アルファ
ベットのページは問題なくアルファベティカルに並べることができるのですが、
日本語は一括してまとめて表示されるだけになっている。これはなんとかならな
かいか」ということです。人の名前のソートなら、あいうえお順でよいのではと
思いますね。

　パターンでソートするというのもおもしろそうだと思ったり、それはソートで
はない、分類だ・・・なんて^^;)しかし、Zazelさんの問題指摘にあるがごとく、
この問題は分類と絡んでくると感じています。

　連想は限りなく拡がってしまうのですが、取りあえず、でびさんの問題を明確
に定義するところから取り組みたいと考えています。ちょっとUnicodeを勉強し
よう。

藤岡和夫
kazuf@...
日曜プログラマのひとりごと http://homepage1.nifty.com/kazuf/renewal.html

[TSabc]世界言語文字列ソートプロジェクト(Zazel)

2008-06-29T14:25+09:00

Zazelです。

=== 藤岡和夫さんが書かれた
=== <20080629121949.18F8.KAZUF@...> にて

> 　少なくとも、日本人だから、日本語のソートについてはこうあるべきという考
> え方があってもよいと思います。それさえあれば、日本語文字列ソートプロジェ
> クトみたいなものはできるかもしれない。それを拡げて、世界言語文字列ソート
> プロジェクトに発展させることも可能かと(^^)

十人十色なのでそれは無理です。例えば“教育漢字の学年順”とか
出版社によって異なる“国語辞書の順番”や“漢字の画数順”など、
他人には意味がない順番がいくらでも出てくるでしょう。

例えば全員が日本語文字列照合順番(JIS X 4061:1996)で納得するとは
到底思えません。

# 「辞書順にしてくれ」と言われて困ったことはありませんか?(-_-;)

(* SEKI Masatoshi // Zazel *)
(* Would you hold my hand? Softly, let's linger. *)

[TSabc]世界言語文字列ソートプロジェクト(Re: Re: UTF-8フラグの立て方・降ろし方)(藤岡和夫)

2008-06-29T12:38+09:00

On Sun, 29 Jun 2008 12:01:41 +0900
"davi" さんwrote:

> また、U+FF00〜定義されている「半角・全角」文字ブロックはUnicode
> のBMP領域の中では鬼っ子のような扱いをされていたようで、（今のバー
> ジョンはわかりませんが、）当時のPerl5.8ではCJK統合漢字の最後の部分
> 9FFFまで扱えればいいでしょ、みたいな実装だったのかもしれません。
>
> まぁ、いずれにせよ、この辺りから、Perlはとにかくイヤなの！が
> 脳内で固定化しちゃったような気がします。

　なるほど、確かに5.6時代を含めて、非ascii文化圏のperlユーザーは不遇だった
かもしれませんね。そのためにRubyユーザーが増えたかもね^^;)

> ま、いずれにせよ、そろそろ色んな問題点の洗い出しも済んで、実装も
> 落ち着いてきた頃でしょうから（…と信じたい）、再入門するには
> 良い頃合いなのかもしれませんね。

　確かにそうかもしれません。ようやく行けそうな気がしてきましたね^^;)

> > 　これまでは、僕はUTF-8フラグを一切立てずにスクリプトを書いてきて、HTML/XML/RDF
> > の処理だから問題なかったのですが、でびさんの問題のように本来の日本語の処
> > 理をしようとすると、やはりUTF-8フラグを無視できないねと
>
> えーと、「本来の日本語の処理」というのは、ちょっとズレがあるような
> 気がするので、訂正しておきます。

　なるほど確かにそうですね。

> 「もうね、入力も内部処理も出力も、全部UnicodeのUTF-8でいいじゃん。」
> と思っています。

　この部分は、過去の資産の問題もあるので、OKというわけにはいかないですね。
ただ、UTF-8の処理がもっとも便利な仕様にして欲しいですね。

> 今の問題意識は「日本語」というよりも「漢字文化圏の言語処理」の問題
> という意識の方が強いです。
>
> もうちょっと汎用化した表現をすれば、
>
> Ａ：文字文化圏毎に必要となる文字種ブロックを選択的に組み合わせて使いたい。
> Ｂ：各文字種ブロックでの標準的な配列意識を意識した処理をしたい。
>
> になるのかなぁ、と思います。
>
> まず、Ａですが、日本人なら「漢字」ブロック＋「かな／カナ」ブロック＋
> 「アルファベット」ブロック＋「数字」ブロック＋…みたいな感じでしょうし、
> 韓国人なら「かな／カナ」ブロックの代わりに「ハングル」ブロックが必要でしょう。
>
> これは、Unicodeではちゃんと実現できている。
>
> しかし、Ｂになると、困ったことになっています。
>
> 様々な文字種の各ブロックを組み合わせて各言語毎に文章表現が成立して
> いるわけですが、Unicodeという規格の性質上、増補作業によって
> １つの文字種のブロックが２箇所以上に分かれてしまっている場合がある。
>
> そうすると、特にソーティング処理でとても困る。
>
> その最もわかりやすい部分が漢字文化圏で使用する「漢字」ブロックだ、と。

　これは、私も日本語をソートしていつも思うのですが、コード順にソートして
何の意味があるのかなということです。何か発音順のあいうえお順のようにも思
えるのですが・・・

　少なくとも、日本人だから、日本語のソートについてはこうあるべきという考
え方があってもよいと思います。それさえあれば、日本語文字列ソートプロジェ
クトみたいなものはできるかもしれない。それを拡げて、世界言語文字列ソート
プロジェクトに発展させることも可能かと(^^)

藤岡和夫
kazuf@...
日曜プログラマのひとりごと http://homepage1.nifty.com/kazuf/renewal.html

[TSabc]UTF-8フラグの立て方・降ろし方(davi)

2008-06-29T12:18+09:00

みなさん＜こん？？はでびです

On Sun, 29 Jun 2008 12:01:41 +0900
"davi" wrote:

> そうすると、特にソーティング処理でとても困る。
>
> その最もわかりやすい部分が漢字文化圏で使用する「漢字」ブロックだ、と。

補足：

ソーティング処理だけでなく、範囲指定でも困惑しますね。

「漢字」の範囲指定はSJIS時代は[亜-熙]だけで良かったけど、
Unicodeでこれを動かしても全く無意味とか。

で、更にそこに、ユーザの側で「言語」の範囲と、「文字種」の範囲を
厳密に区別できていないという事情も被さってくる。
これも、議論を無用に複雑化し感情的にさせがちなような気もします。

でび http://davi.txt-nifty.com/1984/

[TSabc]UTF-8フラグの立て方・降ろし方(davi)

2008-06-29T12:01+09:00

藤岡和夫さんねこ丸さんみなさん＜こん？？はでびです

> > ただ、なぜこれが必要なのかを説明するためには UTF8 フラグを理解しない
> > といけないわけですが。

初期バージョンの頃のPerl5.8系で、[A-z]ではなく、全角の[Ａ-ｚ]を
指定したりして、困ったことになった経験があります。

そもそも、PerlIOレイヤだけいじっても内部的にはUTF8フラグが付く、
ってのが全く理解不能でした。

また、U+FF00〜定義されている「半角・全角」文字ブロックはUnicode
のBMP領域の中では鬼っ子のような扱いをされていたようで、（今のバー
ジョンはわかりませんが、）当時のPerl5.8ではCJK統合漢字の最後の部分
9FFFまで扱えればいいでしょ、みたいな実装だったのかもしれません。

まぁ、いずれにせよ、この辺りから、Perlはとにかくイヤなの！が
脳内で固定化しちゃったような気がします。

> > 結局日本語周りをまとめた - あーありがち (2007-08-03)
> > http://aligach.net/diary/20070803.html#p02

これ、端的にまとまっているようですね。

ま、いずれにせよ、そろそろ色んな問題点の洗い出しも済んで、実装も
落ち着いてきた頃でしょうから（…と信じたい）、再入門するには
良い頃合いなのかもしれませんね。

−−−−−−−−−−−−−−

> 　これまでは、僕はUTF-8フラグを一切立てずにスクリプトを書いてきて、HTML/XML/RDF
> の処理だから問題なかったのですが、でびさんの問題のように本来の日本語の処
> 理をしようとすると、やはりUTF-8フラグを無視できないねと

えーと、「本来の日本語の処理」というのは、ちょっとズレがあるような
気がするので、訂正しておきます。

「もうね、入力も内部処理も出力も、全部UnicodeのUTF-8でいいじゃん。」
と思っています。

今の問題意識は「日本語」というよりも「漢字文化圏の言語処理」の問題
という意識の方が強いです。

もうちょっと汎用化した表現をすれば、

Ａ：文字文化圏毎に必要となる文字種ブロックを選択的に組み合わせて使いたい。
Ｂ：各文字種ブロックでの標準的な配列意識を意識した処理をしたい。

になるのかなぁ、と思います。

まず、Ａですが、日本人なら「漢字」ブロック＋「かな／カナ」ブロック＋
「アルファベット」ブロック＋「数字」ブロック＋…みたいな感じでしょうし、
韓国人なら「かな／カナ」ブロックの代わりに「ハングル」ブロックが必要でしょう。

これは、Unicodeではちゃんと実現できている。

しかし、Ｂになると、困ったことになっています。

様々な文字種の各ブロックを組み合わせて各言語毎に文章表現が成立して
いるわけですが、Unicodeという規格の性質上、増補作業によって
１つの文字種のブロックが２箇所以上に分かれてしまっている場合がある。

そうすると、特にソーティング処理でとても困る。

その最もわかりやすい部分が漢字文化圏で使用する「漢字」ブロックだ、と。

でび http://davi.txt-nifty.com/1984/

[TSabc]UTF-8フラグの立て方・降ろし方(藤岡和夫)

2008-06-29T10:50+09:00

On Sun, 29 Jun 2008 09:33:49 +0900 (JST)
wtnabe@... (ねこ丸) さんwrote:

　再度コメントありがとうございます。

> 藤岡和夫 writes:
>
> > http://www.rwds.net/kuroita/program/Perl_unicode.html
> >
> > が、うまくまとめてますね。
> >
> > 　これでほぼ自在に取り扱えそうです。
>
> どういう結論になったのか分からないですが、自分としては
>
> use open
> binmode
>
> でいいような気がします。TSabc ですしね :-)

　なるほどね。方法論は別にして、僕がなぜ大体わかったと思ったのかは、Bruce.
さんへの返答に書きましたので省略しますが、コマンドラインオプションで選択
できるとスクリプトのポータビリティが上がりますね。特に出力のエンコーディ
ングを設定できるとうれしいです。ここで言ってもしかたがないかもしれないけ
ど・・・

> ただ、なぜこれが必要なのかを説明するためには UTF8 フラグを理解しない
> といけないわけですが。

　これまでは、僕はUTF-8フラグを一切立てずにスクリプトを書いてきて、HTML/XML/RDF
の処理だから問題なかったのですが、でびさんの問題のように本来の日本語の処
理をしようとすると、やはりUTF-8フラグを無視できないねと考え始めていたの
で、グッドタイミングなテーマではありました。

> 正直この Perl のUTF-8周りは面倒なだけじゃんと自分も思いまし
> た。という話は以下に書いてあります。
>
> 結局日本語周りをまとめた - あーありがち (2007-08-03)
> http://aligach.net/diary/20070803.html#p02
>
> たどりついてもらえなかったのが残念です :-)

　Googleで「UTF-8フラグ」を検索すると2ページ目に出てきますね(^^)見逃して
すみません^^;)よく整理されているし、要点が押さえられているのでわかりやす
いですね。

TSperl
http://text.world.coocan.jp/TSNET/?TSperl

にリンクを置きました。

> 以下余談。
>
> 正確に「内部エンコーディング」と呼べるものを持っていない PHP 5.x 以下
> も藤岡さんの要望には合うかも。UTF-8 なら preg で処理できるし。ただ 6 だ
> と「内部エンコーディング」ができちゃうとか？よく調べてませんけど。
>
> ※ 5.x までの PHP の mbstring.internal_encoding は様々な変換などの処理
> でデフォルトのエンコーディングとして働くだけで、PHP の内部的に何か特
> 別な意味があるわけではありません。特別な意味があるように見えるのはこ
> れをもとにいろんなフィルタが自動で働くからです。

　PHPはPukiwikiを使っているので、勉強すればもっと高度な使い方ができるの
かもと思いながら、まだ触る機会を得ないという感じです。

　少しずつでも話題になれば勉強していきたいと考えています^^)

藤岡和夫
kazuf@...
日曜プログラマのひとりごと http://homepage1.nifty.com/kazuf/renewal.html

[TSabc]UTF-8フラグの立て方・降ろし方(Re: Re: Sort の考え方)(藤岡和夫)

2008-06-29T09:46+09:00

On Sun, 29 Jun 2008 01:06:47 +0900
"Bruce." さんwrote:

　長文のコメントありがとうございます。

> use encoding は失敗例とみなしていいような状況ですし、spamフィルタを見れば
> 想像がつくように文字コードに関しても100%正しく判定し、誤判定がありえない
> 手法なんてありません。
>
> ある種の制約条件。たとえばuse なり require で取り込むモジュールにおいても
> まったく同じ条件で動作することを使う側が保証するとか、あるいはモジュールを
> 一切使わないというような条件をおいていいのなら、jperl的なものがつくれる
> かもしれません。しかしながらその場合においても、入力される文字の
> エンコーディングは複数存在することが当然のことで、決め打ちできる状況のほうが
> むしろまれなことでしょう。
>
> であれば、処理系の作り手としては今のようなやり方になってしまうのは
> 「汎用」のものであればやむを得ない判断であろうと考えています。
>
> 〜すべきとおっしゃるのは結構ですが、漠然と望んでいたってそれがかなうことは
> ないと思います。Larryを筆頭としたコアチーム、は無理としても名の知れた
> 日本人Perlハッカーにでも訴えてみたらいかがですか。

　私が「あるべき」と考えていることは、既に考えられていることだと思います
が、Perl 6でどのようになっていくのかに期待しています。Perl 5で作り直すこ
とは現実的でないでしょう。Perl 6だから簡単ということでもないでしょうが、
よりよいものになるだろうと思っています。

>
> > 1. 文字列はUTF-8を使うことが前提。
> > 2. 入力時にUTF-8フラグを必ず立てる。
> > 3. UTF-8フラグを立てた状態で文字列処理を行う。
> > 4. 出力時はUTF-8フラグを降ろす。
> >
> > このフラグを立てたり、降ろしたりというのが、どうもスマートには思えないん
> > ですね。しかし、ないものねだりをしても仕方がないので、フラグを立てたり、
> > 降ろしたりに何を使うかを考えました。
>
> encode/decode をきちんとやっていれば、フラグがどうこうなんてことは
> ほとんどありません。

　encode/decodeというのは具体的にどの操作を指されているのですか。utf8プ
ラグマですか、Encodeモジュールの話ですか。これらは同じことをやるのだろう
か。

> perluniadvice - daily dayflower
> "抄訳 perluniadvice
>
> Perl 付属のドキュメント perlunitut はもう読んだ？もしまだなら，そこから読み始めること :)
>
> * perlunitut - perldoc.perl.org
> * perlunifaq - perldoc.perl.org

　Unicode関係のPerlドキュメントはすべて目を通していますが、体系的に頭に
入りにくいのですね。いろいろなことが有るので複雑だという印象を否めない。

　昨年からのTSNETでのでびさんや林さんの関連のスクリプトに触ってきた経験
の御蔭もあって、今回、いろいろ具体的に書いてみたり、Webの情報を読んでい
ると少しずつ頭の中が整理できてきました。僕は日常的にスクリプトを書いてい
るわけではないので、進歩が極めて遅いのです^^;)

　よく考えると当たり前のことなんだなあ。それぞれの場面でフラグを立てたり、
降ろしたりする必要がある。それぞれの場面とは、

1. スクリプト中に書いてあるUTF-8テキストデータ。
2. 標準入出力
3. ファイル入出力
4. モジュール入出力(データベース入出力などを含む)
5. 既に開いている入出力

　そう考えると、自在に対応できそうだと考えたわけです。

> 以下にわたし（http://juerd.nl/）からのアドバイスの要約を挙げる。perlunitut には記述しなかった内容も含んでいる。
>
> * もしあなたが古い Perl を使っているのなら，最新版にアップグレードしよう
> * もしあなたが古い CPAN モジュールを使っているのなら，最新版にアップグレードしよう
> * 「外界」からやってくるデータはすべて decode() しよう
> * 「外界」へ出力するデータはすべて encode() しよう
> * 「テキスト文字列」と「バイト列」をあなたのプログラムの中で完全に分離しよう
> * ある「string」が「テキスト文字列」なのか「バイト列」なのか Perl は判断できない，ということを認識しよう
> * 「Unicode 文字列」とは「Unicode」文字列であって「UTF-8」文字列ではない，ということを認識しよう(!!)
> * UTF8 flag なんて存在しないかのように振る舞え
> * UTF8 flag を明示的にいじるな（on したり off したり）
> * UTF8 flag の状態を取得するな（Encode::is_utf8(), utf8::is_utf8()）
> * 「string」に UTF8 flag が立っている場合にそれが「テキスト文字列」であるとは言えるけれど，逆は必ずしも成り立たない
> ことを認識しよう
> * もしあなたが「string」を utf8::downgrade() しなきゃいけないとしたら，それはたいていそれ以前の処理が間違っている
> * ソースコードが UTF-8 エンコーディングで書かれているときだけ use utf8; を使え
> * use bytes; を使うな
> * bytes:: ネームスペースの関数を使うな
> * 正規表現で \C を使うな
> * use encoding; を使うな
> * pack() で「バイト列」を生成する場合，「C*」テンプレートを使え
> * 「テキスト文字列」を unpack() するとき「U」テンプレート以外を使うな
> * 「バイト列」を unpack() するとき「U」テンプレートを使うな
> * pack() / unpack() で「U」テンプレートと「非 U」テンプレートを混ぜて使うな
> * pack() で「U0」や「C0」テンプレートを使うな
> * lc() / lcfirst() / uc() / ucfirst() する前に utf8::upgrade() しよう
> * 大文字小文字を区別しないマッチングをする前に utf8::upgrade() しよう
> * \w や \s などのキャラクタクラスをマッチングで使う場合，その前に utf8::upgrade() しよう
>
> 内部のごちゃごちゃ（UTF8 flag など）を直接さわらないと解決できないことがあるかもしれない。Perl の Unicode サポートと相性
> が悪いモジュールを使ったり，実装が間違っているモジュールを使ったりしなきゃいけない時とか。ということで，以上にあげた項目
> は大まかな原則である。"
> http://d.hatena.ne.jp/dayflower/20080625/1214374293
>
> perlunitut 和訳 - Perl Unicode Tutorial
> http://www.r-definition.com/program/perl/perlunitut.htm
>
> > $chars = "い,ろ,は,に,ほ,へ,と,ち,り,ぬ,る,を,わ,か,よ,た,れ,そ,つ,ね,な,ら,む,う,ゐ,の,お,く,や,ま,け,ふ,こ,え,て,あ,さ,き,ゆ,め,み,し,ゑ,ひ,も,せ,す,ん";
> > @tbl = split(",", Unicode::Japanese->new($chars)->getu);
>
> 元のawk版はまあ仕方ないにしてもなんでわざわざカンマ区切りの文字列を使うのでしょうか?

　これは、単に機械的に置き換えただけですね。考えていないです(^^;)意図ど
おり動作すればOK。Ruby版も変えることは可能ですね。splitの部分。

tbl = "いろはにほへとちりぬるをわかよたれそつねならむうゐのおくやまけふこえてあさきゆめみしゑひもせすん".split(//)

> #!/usr/bin/perl
> use strict;
> use warnings;
> use Fatal qw(:void open close);
> use feature ':5.10';
>
> use utf8;
> binmode STDOUT, ':encoding(cp932)';

　ShiftJIS出力ですね。私の書いているUTF-8出力スクリプトはWindowsでは、Cygwin
を入れてck/ckstartup.jsを使うか、Aprotool TM Editorのコンソールを使わな
いと文字化けします。

>
> my @chartbl1 = qw(いろはにほへとちりぬるをわかよたれそつねならむ);

　これは思いつきませんでした^^)

> my @chartbl2 = split q{}, qw(いろはにほへとちりぬるをわかよたれそつねならむ);
>
> say join ':', @chartbl1;
> say join ':', @chartbl2;

　sayも便利ですね。

>
> ------
> い:ろ:は:に:ほ:へ:と:ち:り:ぬ:る:を:わ:か:よ:た:れ:そ:つ:ね:な:ら:む
> い:ろ:は:に:ほ:へ:と:ち:り:ぬ:る:を:わ:か:よ:た:れ:そ:つ:ね:な:ら:む
>
>

藤岡和夫
kazuf@...
日曜プログラマのひとりごと http://homepage1.nifty.com/kazuf/renewal.html

[TSabc]UTF-8 フラグの立て方・降ろし方(ねこ丸)

2008-06-29T09:33+09:00

ねこ丸です。

藤岡和夫 writes:

> http://www.rwds.net/kuroita/program/Perl_unicode.html
>
> が、うまくまとめてますね。
>
> 　これでほぼ自在に取り扱えそうです。

どういう結論になったのか分からないですが、自分としては

use open
binmode

でいいような気がします。TSabc ですしね :-)

ただ、なぜこれが必要なのかを説明するためには UTF8 フラグを理解しない
といけないわけですが。

正直この Perl のUTF-8周りは面倒なだけじゃんと自分も思いまし
た。という話は以下に書いてあります。

結局日本語周りをまとめた - あーありがち (2007-08-03)
http://aligach.net/diary/20070803.html#p02

たどりついてもらえなかったのが残念です :-)

以下余談。

正確に「内部エンコーディング」と呼べるものを持っていない PHP 5.x 以下
も藤岡さんの要望には合うかも。UTF-8 なら preg で処理できるし。ただ 6 だ
と「内部エンコーディング」ができちゃうとか？よく調べてませんけど。

※ 5.x までの PHP の mbstring.internal_encoding は様々な変換などの処理
でデフォルトのエンコーディングとして働くだけで、PHP の内部的に何か特
別な意味があるわけではありません。特別な意味があるように見えるのはこ
れをもとにいろんなフィルタが自動で働くからです。

--
ねこ丸

[TSabc]UTF-8フラグの立て方・降ろし方(Re: Re: Sort の考え方)(Bruce.)

2008-06-29T01:06+09:00

Bruce.です。

藤岡和夫さんは書きました (2008/06/28 18:48):

>> あまり複雑なことをしないのなら
>>
>> ・入力は必ず decode する
>> ・文字列操作は必ずフラグ付きの文字に対して行う
>> ・出力は必ず encode する
>>
>> などいくつかの縛りをつけてやればそれほど難しい話でもないと思いますが
>> どんなもんでしょうか。
>
> 　なるほど、そうですね。実は、それはスクリプティング言語側の仕事であるべ
> きというのが私の意見ですけどね。入出力の作業が増えたのが気に入らない。も
> ちろん、バイト列として取り扱いたい場合がありうるのかもしれませんが、むし
> ろそちらを例外的な操作としたほうがわかりやすい。

use encoding は失敗例とみなしていいような状況ですし、spamフィルタを見れば
想像がつくように文字コードに関しても100%正しく判定し、誤判定がありえない
手法なんてありません。

ある種の制約条件。たとえばuse なり require で取り込むモジュールにおいても
まったく同じ条件で動作することを使う側が保証するとか、あるいはモジュールを
一切使わないというような条件をおいていいのなら、jperl的なものがつくれる
かもしれません。しかしながらその場合においても、入力される文字の
エンコーディングは複数存在することが当然のことで、決め打ちできる状況のほうが
むしろまれなことでしょう。

であれば、処理系の作り手としては今のようなやり方になってしまうのは
「汎用」のものであればやむを得ない判断であろうと考えています。

〜すべきとおっしゃるのは結構ですが、漠然と望んでいたってそれがかなうことは
ないと思います。Larryを筆頭としたコアチーム、は無理としても名の知れた
日本人Perlハッカーにでも訴えてみたらいかがですか。

> 1. 文字列はUTF-8を使うことが前提。
> 2. 入力時にUTF-8フラグを必ず立てる。
> 3. UTF-8フラグを立てた状態で文字列処理を行う。
> 4. 出力時はUTF-8フラグを降ろす。
>
> このフラグを立てたり、降ろしたりというのが、どうもスマートには思えないん
> ですね。しかし、ないものねだりをしても仕方がないので、フラグを立てたり、
> 降ろしたりに何を使うかを考えました。

encode/decode をきちんとやっていれば、フラグがどうこうなんてことは
ほとんどありません。

perluniadvice - daily dayflower
"抄訳 perluniadvice

Perl 付属のドキュメント perlunitut はもう読んだ？もしまだなら，そこから読み始めること :)

* perlunitut - perldoc.perl.org
* perlunifaq - perldoc.perl.org

以下にわたし（http://juerd.nl/）からのアドバイスの要約を挙げる。perlunitut には記述しなかった内容も含んでいる。

* もしあなたが古い Perl を使っているのなら，最新版にアップグレードしよう
* もしあなたが古い CPAN モジュールを使っているのなら，最新版にアップグレードしよう
* 「外界」からやってくるデータはすべて decode() しよう
* 「外界」へ出力するデータはすべて encode() しよう
* 「テキスト文字列」と「バイト列」をあなたのプログラムの中で完全に分離しよう
* ある「string」が「テキスト文字列」なのか「バイト列」なのか Perl は判断できない，ということを認識しよう
* 「Unicode 文字列」とは「Unicode」文字列であって「UTF-8」文字列ではない，ということを認識しよう(!!)
* UTF8 flag なんて存在しないかのように振る舞え
* UTF8 flag を明示的にいじるな（on したり off したり）
* UTF8 flag の状態を取得するな（Encode::is_utf8(), utf8::is_utf8()）
* 「string」に UTF8 flag が立っている場合にそれが「テキスト文字列」であるとは言えるけれど，逆は必ずしも成り立たない
ことを認識しよう
* もしあなたが「string」を utf8::downgrade() しなきゃいけないとしたら，それはたいていそれ以前の処理が間違っている
* ソースコードが UTF-8 エンコーディングで書かれているときだけ use utf8; を使え
* use bytes; を使うな
* bytes:: ネームスペースの関数を使うな
* 正規表現で \C を使うな
* use encoding; を使うな
* pack() で「バイト列」を生成する場合，「C*」テンプレートを使え
* 「テキスト文字列」を unpack() するとき「U」テンプレート以外を使うな
* 「バイト列」を unpack() するとき「U」テンプレートを使うな
* pack() / unpack() で「U」テンプレートと「非 U」テンプレートを混ぜて使うな
* pack() で「U0」や「C0」テンプレートを使うな
* lc() / lcfirst() / uc() / ucfirst() する前に utf8::upgrade() しよう
* 大文字小文字を区別しないマッチングをする前に utf8::upgrade() しよう
* \w や \s などのキャラクタクラスをマッチングで使う場合，その前に utf8::upgrade() しよう

内部のごちゃごちゃ（UTF8 flag など）を直接さわらないと解決できないことがあるかもしれない。Perl の Unicode サポートと相性
が悪いモジュールを使ったり，実装が間違っているモジュールを使ったりしなきゃいけない時とか。ということで，以上にあげた項目
は大まかな原則である。"
http://d.hatena.ne.jp/dayflower/20080625/1214374293

perlunitut 和訳 - Perl Unicode Tutorial
http://www.r-definition.com/program/perl/perlunitut.htm

> $chars = "い,ろ,は,に,ほ,へ,と,ち,り,ぬ,る,を,わ,か,よ,た,れ,そ,つ,ね,な,ら,む,う,ゐ,の,お,く,や,ま,け,ふ,こ,え,て,あ,さ,き,ゆ,め,み,し,ゑ,ひ,も,せ,す,ん";
> @tbl = split(",", Unicode::Japanese->new($chars)->getu);

元のawk版はまあ仕方ないにしてもなんでわざわざカンマ区切りの文字列を使うのでしょうか?

#!/usr/bin/perl
use strict;
use warnings;
use Fatal qw(:void open close);
use feature ':5.10';

use utf8;
binmode STDOUT, ':encoding(cp932)';

my @chartbl1 = qw(いろはにほへとちりぬるをわかよたれそつねならむ);
my @chartbl2 = split q{}, qw(いろはにほへとちりぬるをわかよたれそつねならむ);

say join ':', @chartbl1;
say join ':', @chartbl2;

------
い:ろ:は:に:ほ:へ:と:ち:り:ぬ:る:を:わ:か:よ:た:れ:そ:つ:ね:な:ら:む
い:ろ:は:に:ほ:へ:と:ち:り:ぬ:る:を:わ:か:よ:た:れ:そ:つ:ね:な:ら:む

[TSabc]UTF-8フラグの立て方・降ろし方(藤岡和夫)

2008-06-28T21:42+09:00

On Sat, 28 Jun 2008 21:00:52 +0900
藤岡和夫 wrote:

> 　binmodeを使う方法もありますね。
>
> 　それで、どのような場合にどれを使うのか。副作用はあるのかないのか。そう
> いうことが知りたいわけです。なぜ、同じような作用のある複数の方法が存在す
> るのか。それぞれ存在意義があるのか、単に同じ機能が複数の方法で実装されて
> いるだけなのか。

　そう。調べていると御蔭さまで大体分かってきましたね^^)v

http://www.rwds.net/kuroita/program/Perl_unicode.html

が、うまくまとめてますね。

　これでほぼ自在に取り扱えそうです。

藤岡和夫
kazuf@...
日曜プログラマのひとりごと http://homepage1.nifty.com/kazuf/renewal.html

[TSabc]UTF-8フラグの立て方・降ろし方(藤岡和夫)

2008-06-28T21:00+09:00

On Sat, 28 Jun 2008 20:42:34 +0900 (JST)
wtnabe@... (ねこ丸) さんwrote:

> > B. utf8プラグマを使う方法
>
> これで
>
> binmode STDOUT => ":utf8";
>
> すれば出力は気にする必要ないんじゃないかと。

　コメントありがとうございます。

　binmodeを使う方法もありますね。

　それで、どのような場合にどれを使うのか。副作用はあるのかないのか。そう
いうことが知りたいわけです。なぜ、同じような作用のある複数の方法が存在す
るのか。それぞれ存在意義があるのか、単に同じ機能が複数の方法で実装されて
いるだけなのか。

藤岡和夫
kazuf@...
日曜プログラマのひとりごと http://homepage1.nifty.com/kazuf/renewal.html

[TSabc]UTF-8 フラグの立て方・降ろし方(ねこ丸)

2008-06-28T20:42+09:00

ねこ丸です。

藤岡和夫 writes:

> B. utf8プラグマを使う方法

これで

binmode STDOUT => ":utf8";

すれば出力は気にする必要ないんじゃないかと。

--
ねこ丸

[TSabc]UTF-8フラグの立て方・降ろし方(Re: Re: Sortの考え方)(藤岡和夫)

2008-06-28T18:48+09:00

On Sat, 28 Jun 2008 11:11:02 +0900
"Bruce." さんwrote:

> あまり複雑なことをしないのなら
>
> ・入力は必ず decode する
> ・文字列操作は必ずフラグ付きの文字に対して行う
> ・出力は必ず encode する
>
> などいくつかの縛りをつけてやればそれほど難しい話でもないと思いますが
> どんなもんでしょうか。

　なるほど、そうですね。実は、それはスクリプティング言語側の仕事であるべ
きというのが私の意見ですけどね。入出力の作業が増えたのが気に入らない。も
ちろん、バイト列として取り扱いたい場合がありうるのかもしれませんが、むし
ろそちらを例外的な操作としたほうがわかりやすい。

1. 文字列はUTF-8を使うことが前提。
2. 入力時にUTF-8フラグを必ず立てる。
3. UTF-8フラグを立てた状態で文字列処理を行う。
4. 出力時はUTF-8フラグを降ろす。

このフラグを立てたり、降ろしたりというのが、どうもスマートには思えないん
ですね。しかし、ないものねだりをしても仕方がないので、フラグを立てたり、
降ろしたりに何を使うかを考えました。

A. 日本語文字列しか使えませんが、Unicode::Japaneseモジュールを使う方法。

-----^
use Unicode::Japanese;
$chars = "い,ろ,は,に,ほ,へ,と,ち,り,ぬ,る,を,わ,か,よ,た,れ,そ,つ,ね,な,ら,む,う,ゐ,の,お,く,や,ま,け,ふ,こ,え,て,あ,さ,き,ゆ,め,み,し,ゑ,ひ,も,せ,す,ん";
@tbl = split(",", Unicode::Japanese->new($chars)->getu);
foreach (@tbl){
$char{$_} = $i++;
}
while(){
chomp;
@chars = split(//, Unicode::Japanese->new($_)->getu);
print scalar(@chars),"\n";
for($j=0;$j<=$#chars;$j++){
$numstr .= sprintf("%02d", $char{$chars[$j]});
}
$words{$numstr} = $_;$numstr = "";
}
foreach $numstr (sort keys %words){
print "$numstr ", Unicode::Japanese->new($words{$numstr})->get,"\n";
}
__END__
いぬ
とちのき
にんじん
はむたろう
ろば
へらぶな
とり
ほらがい
-----$

B. utf8プラグマを使う方法

----^
use utf8;
@tbl = split(",","い,ろ,は,に,ほ,へ,と,ち,り,ぬ,る,を,わ,か,よ,た,れ,そ,つ,ね,な,ら,む,う,ゐ,の,お,く,や,ま,け,ふ,こ,え,て,あ,さ,き,ゆ,め,み,し,ゑ,ひ,も,せ,す,ん");
foreach (@tbl){
$char{$_} = $i++;
}
while(){
chomp;
@chars = split(//, $_);
print scalar(@chars),"\n";
for($j=0;$j<=$#chars;$j++){
$numstr .= sprintf("%02d", $char{$chars[$j]});
}
$words{$numstr} = $_;$numstr = "";
}
foreach $numstr (sort keys %words){
utf8::encode($words{$numstr});
print "$numstr ",$words{$numstr},"\n";
}
__END__
いぬ
とちのき
にんじん
はむたろう
ろば
へらぶな
とり
ほらがい
-----$

いずれも、UTF-8で保存して試すこと。

藤岡和夫
kazuf@...
日曜プログラマのひとりごと http://homepage1.nifty.com/kazuf/renewal.html

[TSabc]Ruby版(Re: Re: Sortの考え方)(藤岡和夫)

2008-06-28T13:41+09:00

On Sat, 28 Jun 2008 09:38:00 +0900
藤岡和夫 wrote:

> 　このようにutf8フラグの話が入ってくるとPerlは躓いてしまうことが多くなる
> と思います。使いにくい。Rubyなら簡単なのかも。

　言うだけではなんなので、試してみました。もりきゅうさんの「Perlユーザー
のためのRuby入門」を参考に。

Rubyが変数やハッシュの未定義を許さないのに戸惑ったぐらいで^^;)、予想通り、UTF-8
でスクリプトを保存して

ruby -Ku daviusort.rb

だけで済んだ^^)v

-----^
chars = "い,ろ,は,に,ほ,へ,と,ち,り,ぬ,る,を,わ,か,よ,た,れ,そ,つ,ね,な,ら,む,う,ゐ,の,お,く,や,ま,け,ふ,こ,え,て,あ,さ,き,ゆ,め,み,し,ゑ,ひ,も,せ,す,ん"
tbl = chars.split(/,/)
j = 0
char = Hash.new
for i in 0..(tbl.length - 1) do
j += 1
char[tbl[i]] = j
end
numstr = ""
words = Hash.new
while line = DATA.gets
wchars = line.chomp.split(//)
p wchars.length
for k in 0 .. (wchars.length - 1) do
numstr += sprintf("%02d", char[wchars[k]])
end
words[numstr] = line
numstr = ""
end
words.keys.sort.each{|numstr| print "#{numstr} #{words[numstr]}"}
__END__
いぬ
とちのき
にんじん
はむたろう
ろば
へらぶな
とり
ほらがい
-----$

藤岡和夫
kazuf@...
日曜プログラマのひとりごと http://homepage1.nifty.com/kazuf/renewal.html

[TSabc]Sort の考え方Sender: きむらこういち hogemuta@gmail.com(Bruce.)

2008-06-28T11:11+09:00

藤岡和夫さんは書きました:

> 　このようにutf8フラグの話が入ってくるとPerlは躓いてしまうことが多くなる
> と思います。使いにくい。Rubyなら簡単なのかも。

あまり複雑なことをしないのなら

・入力は必ず decode する
・文字列操作は必ずフラグ付きの文字に対して行う
・出力は必ず encode する

などいくつかの縛りをつけてやればそれほど難しい話でもないと思いますが
どんなもんでしょうか。

> 　それはそうと、Ext.Bとはなにですか。

話の流れからして

CJK Unified Ideographs Extension B でしょう。

--
木村浩一/KIMURA Koichi
I thought what I'd do was, I'd pretend I was one of those deaf-mutes or
shoud I?
mail kbk at kt.rim.or.jp
web www.kt.rim.or.jp/~kbk/zakkicho/index.html

[TSabc]Sort の考え方(藤岡和夫)

2008-06-28T09:38+09:00

On Sat, 28 Jun 2008 03:54:18 +0900
"davi" さんwrote:

> >2バイト文字がうまく扱えなかったので、
> >> substr($0,i,1) substr($0,i+1,1)
> >超適当に1バイトずつ処理しました
>
> の所をもう少し「1文字」を処理系の側でキチンと認識してくれる
> ような書き方ってできないもんかな、というような気持ちなんですが。
>
> そうでないと、Ext.Bの処理も盛り込もうとすると、困るだろうなぁと。

　最初は、jperlで書いて試したのですけど、よく考えるとでびさんの要求は文
字コードがuft8という前提なので、utf8用に書き直しました。

　use utf8を使うと、splitの文字を区切る動作が変わるので、文字単位に切り
出すのが簡単になるということと、print出力でutf8フラグをencodeではずす必
要があるということが、このスクリプトのポイントですね。

　このようにutf8フラグの話が入ってくるとPerlは躓いてしまうことが多くなる
と思います。使いにくい。Rubyなら簡単なのかも。

　それはそうと、Ext.Bとはなにですか。

藤岡和夫
kazuf@...
日曜プログラマのひとりごと http://homepage1.nifty.com/kazuf/renewal.html

[TSabc]Sort の考え方(Bruce.)

2008-06-28T04:18+09:00

Bruce.です。

davi さんは書きました (2008/06/28 3:54):

>> 文字種ごとのバイト幅とか
>
> 半角英数、全角カナを昔のJPerlはjlengthとか書いたけど、今はそんな
> 必要はない、という件。

ああなるほど。
でもUTF-8(Unicode)だと半角カナは3バイトになるのでは?

>> shiftを利用ってどういうことでしょう?
>
> for in do みたいに比較対象を一つずつずらしてゆく、という処理は、
> Ｙささんもお書きですが、その後にある、
>
>> 2バイト文字がうまく扱えなかったので、
>>> substr($0,i,1) substr($0,i+1,1)
>> 超適当に1バイトずつ処理しました
>
> の所をもう少し「1文字」を処理系の側でキチンと認識してくれる
> ような書き方ってできないもんかな、というような気持ちなんですが。
>
> そうでないと、Ext.Bの処理も盛り込もうとすると、困るだろうなぁと。
>
> # あ、これが「複雑にしすぎる」ってヤツなんでしょうね。
> # ロシア人の会議好き、みたいな性格なんでしょう。
> # 達成されない五カ年計画の連続。

あー、単位がきちんと「バイト」じゃなくて「文字」でということなら
きちんとエンコーディングを処理してやればPerlでもPythonでもできますがな。
ただし自動的にUnicodeで扱うことになりますが。

#Rubyはちと微妙なところがあるので保留

> 南アジアのタミル語とかベンガル語とかは、結合文字の嵐で、
> 見た目は１文字に合成するわけですが、その後に空白が多量に
> 表示されてしまうソフトウェアが結構あります。
>
> BackSpaceを押したときに、結合結果を丸ごと削除するのか？
> 部品を一つずつ削除するのかの挙動をどうすべきか？
>
> で西アジアのアラビア語などとなると、横書きで右から左に
> 書きますので、英文や日本語横書きと混在させるとなると、
> さて、どうなっちゃうんでしょう？という世界です。

アラビア語の中に左→右の言語の表記が入るときは

アラビア語 (左←右) 日本語(左→右) アラビア語(左←右)

と間に埋まって、directionが変わるというルールだったのでは?
#対応ソフトでこの手の入力するとカーソルの飛び方が楽しい(笑)

--
木村浩一
I thought what I'd do was, I'd pretend I was one of those deaf-mutes or should I?
mail kbk [at] kt.rim.or.jp
web www.kt.rim.or.jp/~kbk/zakkicho/
homepage3.nifty.com/farstar/

[TSabc]Sort の考え方(davi)

2008-06-28T03:54+09:00

Bruce.さん＜こん？？はでびです

On Sat, 28 Jun 2008 02:55:44 +0900
"Bruce." wrote:

> それなりに「らしく」書いても、たぶん「わけわからない」とか返されるのが
> オチだよなあという予感。

まぁ、そうかもしれません。perlだとあらゆる書き方があり得そうです。

> 文字種ごとのバイト幅とか

半角英数、全角カナを昔のJPerlはjlengthとか書いたけど、今はそんな
必要はない、という件。

>shiftを利用ってどういうことでしょう?

for in do みたいに比較対象を一つずつずらしてゆく、という処理は、
Ｙささんもお書きですが、その後にある、

>2バイト文字がうまく扱えなかったので、
>> substr($0,i,1) substr($0,i+1,1)
>超適当に1バイトずつ処理しました

の所をもう少し「1文字」を処理系の側でキチンと認識してくれる
ような書き方ってできないもんかな、というような気持ちなんですが。

そうでないと、Ext.Bの処理も盛り込もうとすると、困るだろうなぁと。

# あ、これが「複雑にしすぎる」ってヤツなんでしょうね。
# ロシア人の会議好き、みたいな性格なんでしょう。
# 達成されない五カ年計画の連続。

> 西南アジアってどの辺のことですか? って

昔は中東って言ったらしいですが、極東と同じで西欧を中心として
見た言い方だよね〜。ということで、最近の中学校の社会の教科書
とかでは西南アジアって言う方が主流みたいです。

でも、『ビルマの竪琴』は『ミャンマーの竪琴』になりませんし、
スリランカティーだとセイロン紅茶の雰囲気が出ませんな…。

南アジアのタミル語とかベンガル語とかは、結合文字の嵐で、
見た目は１文字に合成するわけですが、その後に空白が多量に
表示されてしまうソフトウェアが結構あります。

BackSpaceを押したときに、結合結果を丸ごと削除するのか？
部品を一つずつ削除するのかの挙動をどうすべきか？

で西アジアのアラビア語などとなると、横書きで右から左に
書きますので、英文や日本語横書きと混在させるとなると、
さて、どうなっちゃうんでしょう？という世界です。

そんなこんなで、ソフトウェアの作り手側にとっては、
色々面倒なことが多いみたいです。

> Strawberry Perlってのがありますがまだβ段階ですから

じゃ、当分ActivePerlですね。
サーバが生き返った頃に頂に行くことにしましょう。

でび http://davi.txt-nifty.com/1984/

[TSabc]Sort の考え方(Bruce.)

2008-06-28T02:55+09:00

Bruce.です。

davi さんは書きました (2008/06/28 1:47):

>> Ｙささんのawkスクリプトを理解するために、perlに移植してみました。ご参考まで。
>
> 早速ありがとうございます。
>
> ちょうど週末ですので、みなさん、ちょっと構ってくれる「気持ちの余裕」
> もあろうかと、
>
> ＊Perlならどう書くの？

なんぼなんでもawkバージョンのベタ移植すぎるだろうと思いつつも、
それなりに「らしく」書いても、たぶん「わけわからない」とか返されるのが
オチだよなあという予感。

> ＊sprintf("%02d"という書き方ではなく、awkやPerlが
> それぞれ内部で勝手に認識してくれる文字種毎のバイト幅
> を利用して、SHIFTを利用して書くわけにはいかないの？

?
なにが云いたいのかよくわかりません。
文字種ごとのバイト幅とか shiftを利用ってどういうことでしょう?

> # そして週末になると、狙いすましたように色々おっかぶせられるのは
> # 何でだろう…。今月末はUnicodeの西南アジア系言語の扱いについての
> # 分析と、Excel関数講座のオリジナル教材作成が振ってきました。

西南アジアってどの辺のことですか? って

西南アジア - Wikipedia
http://ja.wikipedia.org/wiki/%E8%A5%BF%E5%8D%97%E3%82%A2%E3%82%B8%E3%82%A2

西南アジアって言い回しがあるこたあるんですか。

> ActivePerlで良いですか？
> なんだか最近、他にもPerlのディストリビューション（って言って
> 良いのかな？）が出ているようなので、「とりあえずこれが普通」が
> 最近はどれなのか、ちとわかっていません。

Strawberry Perlってのがありますがまだβ段階ですから
普通というところまではいかないでしょう。それなりに使えるみたいですけど。

ActivePerlもActiveStateの持っているPPMのリポジトリサーバが死んだとか
なんとか。
#別のを立てようとしているみたいですけど

--
木村浩一
I thought what I'd do was, I'd pretend I was one of those deaf-mutes or should I?
mail kbk [at] kt.rim.or.jp
web www.kt.rim.or.jp/~kbk/zakkicho/
homepage3.nifty.com/farstar/

[TSabc]Sort の考え方(藤岡和夫)

2008-06-28T02:43+09:00

On Sat, 28 Jun 2008 01:47:26 +0900
"davi" さんwrote:

> ＊sprintf("%02d"という書き方ではなく、awkやPerlが
> それぞれ内部で勝手に認識してくれる文字種毎のバイト幅
> を利用して、SHIFTを利用して書くわけにはいかないの？

　この方法は、Ｙささんの独創的なアイデアですね。でびさんの要求は任意の文
字の順にソートしたいというように読めるので、文字コード順に頼れないから、
自前で順番を決める必要があるのです。文字種が多くなれば、一つの文字に対応
させる数文字列はそれに応じて増やす必要があります。

　僕のスクリプトは、入力する文字列は、必ず、ソートする順番を指定する文字
種からのみ構成されている必要があります。

> でもまだ自分の方では、トッパンムーアのawk本、鞄に入れて出かけた
> けど開く暇がなくて、Ｙささんの解法例もまだ解読しきっていません。
>
> # そして週末になると、狙いすましたように色々おっかぶせられるのは
> # 何でだろう…。今月末はUnicodeの西南アジア系言語の扱いについての
> # 分析と、Excel関数講座のオリジナル教材作成が振ってきました。
> # 「何でも屋」稼業をやっていると、フリーライターって凄いなぁと
> # 尊敬するばかりです。
>
> 何事に付け、勉強しつつあるものについては、どうあがいても、
> インプット50に対してようやくアウトプット1くらいが出せるかどうか、
> という割合になってしまいますね。
>
> 藤岡さんが以前書いていた「それって要するに勉強したくないって
> ことじゃないの？」ってのに対する返信をいまだ書きそびれていましたが、
> 結局、自分の技術レベルに見合ったお題を見極めて自分に課すのが
> 藤岡さんはとても上手で、私はヘタ、ということなんだろうな、というの
> が今のところの結論です。
>
> ExcelでSUM関数すら使えない状態なのに、ピボットテーブルとか分散分析を
> やりたがるような人と、大局的には同じなのだろうな、と。
>
> 百戦すれば危ういことこの上なし。

　そうですね。確かにでびさんは問題を最も複雑にしてしまう傾向がありますね。

　取り扱うデータの性質をよく見て、問題を簡単に取り扱えるようにして、処理
することを考えるとスクリプトも簡単になって勉強しやすいでしょうね。

　しかし、そうは言っても現実は複雑ですからね。それに自在に対応できるのが
スクリプティング言語と言えるかもしれません。

> > utf8で保存して試してください。
>
> ActivePerlで良いですか？
> なんだか最近、他にもPerlのディストリビューション（って言って
> 良いのかな？）が出ているようなので、「とりあえずこれが普通」が
> 最近はどれなのか、ちとわかっていません。

　ActivePerlなら、5.8でも5.10でもどちらでも大丈夫です。

> でび http://davi.txt-nifty.com/1984/
>
> # Blogも藤岡さんの年末以来の問題意識提起に自分なりにアクション
> # してみようとて、始めて見たのですが、五月の連休以来、更新でき
> # ていないっす。反省反省。

　仕事と趣味をなかなか一緒にするわけにはいかないですから、むずかしい面は
ありますね。仕事と趣味が一緒になると幸せになれるかどうかは疑問な気もしま
すが、人間、次第に応用を始めてしまうので、最近は少し困ったものだと思って
います。

藤岡和夫
kazuf@...
日曜プログラマのひとりごと http://homepage1.nifty.com/kazuf/renewal.html

[TSabc]Sort の考え方(davi)

2008-06-28T01:47+09:00

藤岡和夫さん＜こん？？はでびです

On Sat, 28 Jun 2008 01:20:58 +0900
藤岡和夫 wrote:

> Ｙささんのawkスクリプトを理解するために、perlに移植してみました。ご参考まで。

早速ありがとうございます。

ちょうど週末ですので、みなさん、ちょっと構ってくれる「気持ちの余裕」
もあろうかと、

＊Perlならどう書くの？

＊sprintf("%02d"という書き方ではなく、awkやPerlが
それぞれ内部で勝手に認識してくれる文字種毎のバイト幅
を利用して、SHIFTを利用して書くわけにはいかないの？

という追加質問を上げようと思っていたところでした。

でもまだ自分の方では、トッパンムーアのawk本、鞄に入れて出かけた
けど開く暇がなくて、Ｙささんの解法例もまだ解読しきっていません。

# そして週末になると、狙いすましたように色々おっかぶせられるのは
# 何でだろう…。今月末はUnicodeの西南アジア系言語の扱いについての
# 分析と、Excel関数講座のオリジナル教材作成が振ってきました。
# 「何でも屋」稼業をやっていると、フリーライターって凄いなぁと
# 尊敬するばかりです。

何事に付け、勉強しつつあるものについては、どうあがいても、
インプット50に対してようやくアウトプット1くらいが出せるかどうか、
という割合になってしまいますね。

藤岡さんが以前書いていた「それって要するに勉強したくないって
ことじゃないの？」ってのに対する返信をいまだ書きそびれていましたが、
結局、自分の技術レベルに見合ったお題を見極めて自分に課すのが
藤岡さんはとても上手で、私はヘタ、ということなんだろうな、というの
が今のところの結論です。

ExcelでSUM関数すら使えない状態なのに、ピボットテーブルとか分散分析を
やりたがるような人と、大局的には同じなのだろうな、と。

百戦すれば危ういことこの上なし。

> utf8で保存して試してください。

ActivePerlで良いですか？
なんだか最近、他にもPerlのディストリビューション（って言って
良いのかな？）が出ているようなので、「とりあえずこれが普通」が
最近はどれなのか、ちとわかっていません。

でび http://davi.txt-nifty.com/1984/

# Blogも藤岡さんの年末以来の問題意識提起に自分なりにアクション
# してみようとて、始めて見たのですが、五月の連休以来、更新でき
# ていないっす。反省反省。