まつもと ゆきひろです

In message "[ruby-list:25156] Re: Ruby I18N (Re:  Re: file separator for Ruby in Windows)"
    on 00/09/25, Hiroshi IGARASHI <igarashi / ueda.info.waseda.ac.jp> writes:

|もう1.8(2.0?)に向けて議論を始めちゃうのでしょうか?
|とりあえず一点。

わたしとしては始めちゃっても全然構わないんですが。
それともPerl/Ruby Conferenceまで大事にとっとく?

|> |でも、EUC-JPって、UCS2のサロゲートペア用の領域も使ってしまう
|> |ので、素朴にUTF-8風変換をすることはできないはずです。
|> 
|> え? そうなんですか? 私の理解ではUTF-8は31bitまでの任意の整
|> 数を1から6バイトまでのマルチバイトで表現するものだと思ってま
|> した。UTF-8のエンコーディング法(えーとFSS-UTFでしたっけ)は文
|> 字集合と独立に使えるという私の考えが浅はかだったんでしょうか?
|
|UTF-16(ですよね。surrogate pairを使うということは)にすることを
|考えなければ、31bitの空間をまるまるUTF-8にencodingできるのでは?
|確かにUCS-4の値で0x0000d800-0x0000dfffの範囲(と0x00110000以降)は
|surrogate領域とぶつかるのでUTF-16に変換できませんが。

あ、UTF-16にはしません。使いたいのはUnicode(だけ)ではないの
であのようないびつな(かつ、文字集合に依存した)エンコーディン
グを選ぶ必然性はゼロなので。

私としてはRuby 2.0では「文字」を統一的に扱えるStringクラスが
欲しくて、かつ実装の都合などから内部表現エンコーディングは文
字集合に関わらず統一したいと考えています。しかし、文字集合に
関してはASCIIのスーパーセットを仮定すれば、自由に選択できた
方が良いと思っています。Unicodeで表現できない文字や、変換で
曖昧性が生じる文字、ラウンドトリップで失敗する文字などの問題
が完全に解決する日は(Unicode以外の文字集合が駆逐されるまでは)
来ないように思うので。

となると、

  * 文字コードは31ビットで表現できる範囲
  * ASCIIのスーパーセット

という仮定は設けても良いと思うので、それに対応できるエンコー
ディングは

  * 固定幅(1文字4バイト)    UCS4風
  * 可変幅(1文字1〜6バイト) UTF-8風

のいずれかだと思っているわけです。

|とはいえ文字集合(CCS)がUCS/Unicodeでない場合に
|UCS Transformation Format(UTF)の名を使うのは
|誤解の元のような気がしますね。
|UTF-2000みたいに別名をつけた方が...
|# それはそれで挑戦的なんですけどね。

全然構いません。

UTF-8のエンコーディング法のみを表現する名前をご存知の方はい
らっしゃいますか? 私はそれに該当しそうなのは FSS-UTF(File
System Safe Universal Transfer Format - plan9の用語のようで
す)[1]しか知らないんですが。

                                まつもと ゆきひろ /:|)

[1] Standard C/C++ 「多バイト文字ファイル」
    P. J. Plauger
    C Magazine 2000年8月号 p.96〜p.99