XMLと文字メーリングリスト メッセージ閲覧

ずいぶん古い記事へのリプライですが...

> > しかし、なにか、ここまでくると見苦しい気もします。
> > 
> > Compatibility Encoding Scheme for UTF-16: 8-Bit (CESU-8)
> > 
> > http://www.unicode.org/unicode/reports/tr26/
> 　プログラムの内部処理で使うものだと主張しているようですが。
> 　いったい、どんなプログラムで使うんだろう、と言うのが第1印象。

これはOracleで使われているUTF-8もどきencodingです。Oracle仕様のUTF-8で
は、Surrogateの各ペアを機械的にUTF-8に変換して、supplementary
characterは6byteで表現されます。実際はこれはただの内部コードなんかじゃ
なくて、Oracleから文字列をUTF-8で取って来たらこのencodingになります。

こうすることによって、UTF-16とUTF-8の文字列を同じようにソートできると
か、分けのわからん理屈を並べています。単純にコード順ソートするなら
Unicode code point順にソートするのが筋でしょう。

なぜかOracleはこのような仕様のUTF-8を実装してしまった。それを使ってい
るPeopleSoftもその仕様に沿ってプログラムを書いている。いまさら変更する
のは嫌だ。じゃ、そのencoding登録してしまおう、ということらしいです。
CESU-8は以前はUTF-8Sと呼ばれていました。

> あの記述をみて、UTRの作者の深層心理のなかに、
> IANA に登録さえしていまえば、しめたもので、
> Surrogate 完全対応を未来永劫延期してしまおうという意図が
> 垣間見えてきます。

Oracleは標準のUTF-8も実装しているんですよ。でもencoding名はAL32UTF8と
言います。encoding名UTF-8は実際はCESU-8です。

> 実は、この問題、根が深くて、業界「UTF-16 vs UTF-32戦争」勃発の
> 第一幕でしょう。まず、UTF-8 をコントロールするのはどちらか？
> から始まり、そのうち、いろいろなところで、現実問題として
> ユーザーに混乱を招く事態が顕在化するでしょう。

すみません。教えてください。UTF-16とUTF-32でなにかカクシツでもあるので
しょうか。それからUTF-8を巡って覇権を争っているグループがあるのでしょ
うか。

-----------------
Shigemichi Yazawa
yazawa@globalsight.com

前寺です。ちょっと身辺がバタバタしているうちに
かなり未読ログがたまっていたようです。

> > 実は、この問題、根が深くて、業界「UTF-16 vs UTF-32戦争」勃発の
> > 第一幕でしょう。まず、UTF-8 をコントロールするのはどちらか？

> すみません。教えてください。UTF-16とUTF-32でなにかカクシツでもあるので
> しょうか。それからUTF-8を巡って覇権を争っているグループがあるのでしょ
> うか。

そう解釈されると、大袈裟な書き方だったなぁと反省もしますが、
基本的には、Unicode値を 16bit で正規化しているシステムと、
32bit で正規化しているシステムでは、97% 程度は同じことを考えても、
やはり、残りの 3% を我田引水的に、自分の都合のいいように
実装したいということです。それに伴うテクニカルレポートなどの
具体的動きは今後とも続くのではないかと思ったりします。

基本的にあるカスタマーが一度導入したA社システムを、
類似機能のB社システムに乗り換えるのは大変ですから、
ある意味で、スペックを自社システムに有利に作るというのは
セールス的に大きな意味をもっていたりします。

　川俣です。

　"Masahiko Maedera <SGQ00310@nifty.ne.jp>"さんは書きました：
> 基本的には、Unicode値を 16bit で正規化しているシステムと、
> 32bit で正規化しているシステムでは、97% 程度は同じことを考えても、
> やはり、残りの 3% を我田引水的に、自分の都合のいいように
> 実装したいということです。
　ちょっと話は違いますが、16bitで正規化するのと、32bitで正規化するのって、
どちらがプログラミング的に良いでしょう?
　32bitで正規化する方が、コードがすっきりするような気がしていましたが、
Unicodeの動向を見る限り、日本語に限っても32bitにしても、32bit=1文字にな
らない世界に行ってしまいそうで、ひたすらメモリ効率が悪い面だけが目立つよ
うな気がしないでもありません。
　では、16bitで十分だから32bitなど要らない、と思うとUTF-8との整合性が悪
くなります。
　いや、別にだからどうしたというわけではありませんが。ふとそんなことを思
ったもので。

-- 
 (株)ピーデー 川俣 晶 (http://www.autumn.org/ mailto:autumn@piedey.co.jp)

  Akira Kawamata <autumn@piedey.co.jp> wrote:
> 　ちょっと話は違いますが、16bitで正規化するのと、32bitで正規化するのって、
> どちらがプログラミング的に良いでしょう?

これについては、もし読者の皆さんで、新しくUnicodeの実装を
はじめる予定がある人がいれば、ぜひとも、8bitで正規化する UTF-8 も
内部コードの選択肢に含めてみてください、としかいえません。

隠語で Shift-Unicode といわれる UTF-16 を新規に実装するのなら、
おなじ、Shift状態をもつ UTF-8 で新規に実装するのと
手間は変わらないかもしれません。
いずれにせよ、個々の文字をチェックするときは、
UTF-32 という 32bit表現形で扱う必要があるので、
どちらの符号化でも変換が必要になってくるのは確かです。

メモリ使用効率でいえば、単純な日本語漢字かな混じり文だけの
データをもつテキストはのぞき、XML のように ASCII 文字がかなり
混じるテキストでは UTF-8 もひとつの候補になります。

　川俣です。

　"Masahiko Maedera <SGQ00310@nifty.ne.jp>"さんは書きました：
> いずれにせよ、個々の文字をチェックするときは、
> UTF-32 という 32bit表現形で扱う必要があるので、
> どちらの符号化でも変換が必要になってくるのは確かです。
　そうでもないと思います。
　たぶん、JavaやC#(UTF-16で内部処理する言語)では、サロゲートペアで表現さ
れた文字は文字列比較で一致判定することが前提ではないかな?
　最近のJavaは詳しくないのですが、少なくとも、C#では文字列から32bit値で
文字コードを取り出す手段は標準ライブラリには無いはず。最初から最後まで
16bit値2個のシーケンスとして扱うと思います。

　いや、その方が良いという主張ではないんですが^^;
　これも、方法の1つとしては、ありかなと。

-- 
 (株)ピーデー 川俣 晶 (http://www.autumn.org/ mailto:autumn@piedey.co.jp)