I18n, M17n, Unicode, and all that

Ruby 翻訳
  • Posted by Nick Sieger

http://blog.nicksieger.com/articles/2006/10/22/rubyconf-i18n-m17n-unicode-and-all-that


Speaker: Tim Bray


発表スライドはこちら。
http://www.tbray.org/talks/rubyconf2006.pdf


Tim Brayはキャラクタと文字列について話すようだ。腕が抜け落ちるまで彼は嬉しそうにテキストについて語り、ビールを半分おごってくれるだろう。

  • はじめに

Web上において、英語はもはや大部分を占める言語ではありません。今後のアプリケーションでi18n問題を無視するのはナンセンスです。
以下はおそらくバグです。

     /[a-zA-Z]+/
  • 利点
    • 幅広さ
    • 成長の余地 - 真ん中の面にたくさんのスペースが残っています
    • 私的利用
    • 健全なプロセス
    • キャラクタデータベース
    • ユビキタス標準とツール類
  • 問題
    • 結合形 - (たとえば1/2と½など)対照用にキャラクタを標準化する必要あり、String#==メソッドのなかで役立つものではありません
    • 他のエンコーディングとの扱いづらい歴史的な妥協
    • 漢字統合(Han Unification)問題(注意: Timはwikipediaの記事は偏っているとみてる) - アジアの言語専門家によって、異なるものを意味する文字がひとつのコードポインタに与えられています


でも映像が最大の大域幅を占めるなか、テキストサイズは本当に重要でしょうか？

  • 識別

テキストが含まれているものをどのように識別しますか？

    • 推測 - ブラウザ、python lib
    • キャラクタヘッダ、間違ってると知られてます
    • 信頼 - あらかじめ交換パターンを2人に間で同意
    • XML[最後のこれは明らかに正しかった]
  • 言語のアプローチ
    • Java - 設計不備: 不幸なことにキャラクタはUTF-16。実装はよくテストされているようですが、Javaはださい
    • Perl5には理論的に素晴らしいサポートがありますが、実際には、なんの破損もなしにDBを通じたテキストのやりとりをするのは難しい
    • Pythonにはバイト配列と文字列、そしてバイト配列、バイナリ/テキストデータに対する文字列ライクなメソッドがあり、プラットフォームのファイルエンコーディング問題に関する注釈があります
  • Ruby
    • 数え上げ、正規表現、等式、ホワイトスペース問題に起因して、あるコアの文字列メソッドはi18n問題をもっています
    • String#each_charはあるべきところにないメソッドのようです: Stringクラスは自身のエンコーディングを知っているべきかもしれません
    • String#[]の振る舞いはバイトバッファに対してはよいようですが、おそらくキャラクタにとって効率的である必要はありません。Stringのイテレーションにおけるほとんどのユースケースはキャラクタに対してであるべきです。(例外: Expat)
    • 大文字小文字変換(Case-changing)メソッド - 混在した言語環境では絶対に避けましょう
    • 正規表現には、(数字に対する＼p{N}や小文字に対する＼p{L}といった)安全なマッチングのためのUnicodeプロパティが必要です
    • RubyにCharacterクラスやCharsetクラスは必要でしょうか？


Rubyの次は何でしょうか？[話の残りはruby-talkに向かって占い棒を振ってみましょう！]
Matzはm17nに対応しています: JulikとManfredとそのチームにはRailsのActiveSupport::MultiByteがあります: JRubyはすでにUnicode文字列をもつプラットフォーム上で作られています
そして議論は過熱し続けています

  • Q&A

Q.もしエンコーディングの知識なしにバイトストリームを扱ったらどうなりますか？
A.文字のレベルより上にエンコーディングの眼鏡をかけないようにしてください。プログラマは関連したメソッドで文字を文字として扱いたいでしょう。


Q.もしテキストの大文字小文字を変換したかったらどうしますか？
A.必ずしも正しく動かないという事実に慣れなさい。
Q.有限の言語を文字化するのはどうですか？
A.Javaはそうしました。依然として本当に可能にはなっていませんが。
Q.Stringクラスはエンコーディングを知らないべきじゃないでしょうか？最適化はできないのでは？例外をあげることができないのでは？
A.ならそうしなければいい！
Q.大文字小文字について必要となる知識の集まりはないのでは？
A.むぅ、次の質問は大文字小文字以外から！


Q.XMLでテキストを処理する先端事例の情報源はありますか？
A."xml test cases"を探してみなさい。提供されたメタデータを無視するか、それを処理しないことを選択するかの間の決断になります。


Q.キャラセットを推測できるPythonのライブラリは何ですか？
A.feedvalidator一式です。