A Reintroduction To Ruby M17 N

A reintroduction to Ruby M17N
NARUSE, Yui

序
今日はみなさんに日本を生まれた事を後悔してもらいに来ました
の、つもりだったのだが……
「地球に生まれた事に」になってしまった……

話す事・話さない事
話す事
文字コード
Ruby M17N
話さない事
メッセージの切り替え
時刻・時間とか通貨とか

コンピュータで文字を扱う
表示・印刷
字形 (グリフイメージ)
字体 (グリフ)
書記素クラスタ (grapheme cluster)
コードポイント符号化文字集合
(コードユニット) (UTF-16/32)
バイト文字符号化方式
処理・格納

「文字コード」とは
「文字」をコンピュータで扱う仕組みのうち、比較的低層の部分
つまり、グリフやフォントよりちょっと下まで
扱う文字を決め、番号を振る
文字列を番号列、バイト列、ビット列にする

文字集合
Abstract Character Repertoire
どのような文字を扱うか
ある文字とある文字が同じか違うかの決定
何文字扱うか、扱えるか
必要な文字 vs. メモリサイズ・性能

何を扱うか
アラビア数字
アルファベット大文字 ― 6bit
アルファベット小文字 ― 7bit
カタカナ ― 8bit
ひらがな
漢字
絵文字
など ― 16bit
などなどなど ― 21bit

文字の同定
ある文字とある文字が等しいかどうかの決定
包摂規準 (その文字の射程範囲の決定)
何が一文字か e.g. リガチャ「ﬃ」
典拠の確保―いい加減だと幽霊文字が混じったり、重複したり
e.g. 妛𡚴「あけんばら」で検索

字形の違い
色々な「フォント差」「書体差」
aaaaaaaaa
「g」「g」メガネg「l」「l」ループL
言言言

字体の違い
JISでは同じだがUnicodeでは別
「高」と「髙」「吉」と「𠮷」
JISでもUnicodeでも同じコードポイント

符号化文字集合
CCS / Coded Character Set
文字集合を構成する「文字」、一つ一つに番号を振ったもの
一般にはこの番号を「コードポイント」
Unicode の場合
「Unicode Scalar Value」
「あ」->U+3042 (Unicode)
JIS X 0208
「ビット組合せ」や「区点コード」
「あ」->04区02点 (JIS X 0208)

符号化文字集合の例
ASCII 英数記号
ISO/IEC 8859-1 アクセント付き文字
JIS X 0201 いわゆる半角カナ
JIS X 0208 第一・第二水準漢字など
JIS X 0212 補助漢字など
JIS X 0213 第三・第四水準漢字など
Unicode いろいろ

JIS X 0208
http://www.kanji.zinbun.kyoto-u.ac.jp/~yasuoka/kanjibukuro/japan.html

文字符号化方式
CES, Character Encoding Scheme
符号化文字集合の番号をバイト列に変換する方式
Shift_JIS
「あ」 -> 04区02点 -> "x82¥xA0"
「い」 -> 04区04点 -> "x82xA2"
UTF-8
「あ」 -> U+3042 -> "xE3x81x82"
「い」 -> U+3044 -> "xE3x81x84"

エンコーディング
encoding (W3C)
charset (IETF)
あるバイトデータを解釈するには、「文字符号化方式」と「符号化文字集合」を共に特定する必要
Shift_JIS
"x82¥xA0" -> 04区02点 -> 「あ」
UTF-8
"xE3x81x82" -> U+3042 -> 「あ」

IANA Charset
各々のエンコーディングに名前を付けて登録管理
インターネット上に流すデータは登録されてる必要
一部のエンコーディングは実態と乖離も
http://www.iana.org/assignments/character-sets
ISO-2022-JP
EUC-JP
Shift_JIS
Windows-31J

用語の整理
charset
Character setが由来と思われるため、「文字集合」の意味に感じられるが、用法としてはencodingと同じ
文字コード
文字集合
encoding
ある文字のコードポイント

Unicode用語集
UCS-2は文字集合ではなくencoding
ISO/IEC 10646の定義13.1 Two-octet BMP form (UCS-2)
This coded representation form permits the use of characters from the Basic Multilingual Plane with each character represented by two octets.
Unicodeの定義
“UCS-2. ISO/IEC 10646 encoding form: Universal Character Set coded in 2 octets, limited to the Basic Multilingual Plane.”
http://www.unicode.org/glossary/#UCS_2

History of I18N
Internationalization, 国際化
I .{18} N
I18N
S12N (Scherpenhuizenさんが元祖)
http://blog.miraclelinux.com/yume/2007/01/i18n_8bc0.html

略語解説
L10N (Localization) (地域化)
それぞれの地域・言語に適したようにすること
ある言語に対応すること
cf. nls (national language support)
I18N (Internationalization) (国際化)
地域化しやすいように、あらかじめソフトウェア側を抽象化しておくこと
言語を切り替えて使用できるようにすること
M17N (Multilingualization) (多言語化)
複数の言語などで利用するためにローカライズ
同時に複数の言語を扱えるように (Ruby)

国際化というからには
元は国際対応じゃない
最初はどうだったのか?

始まりはASCII
1970年頃
ASCII以前から文字コードはあった
ASCIIは電信の遺産を継承している
まぁ情報通信的にはASCIIから始まる
ていうかISO/IEC 646でしょ
EBCDICのことを忘れないでください

http://www.ecma-international.org/publications/standards/Ecma-006.htm
ECMA-6 IRV(≒ ASCII)

ASCIIに含まれる文字種
アラビア数字
アルファベット大文字
アルファベット小文字
記号
全94文字

文字が足りない
アクセント付きアルファベット(ISO 8859シリーズ) 577文字
いわゆる半角カタカナ(JIS X 0201) 56+7文字
漢字など(JIS X 0208) 6355+524文字

ASCIIを拡張しよう
JIS X 0201 (ASCII 亜種・8bit化)
ISO-8859-1 (8bit化)
ISO-2022-JP (エスケープシーケンス)
SJIS / EUC / UTF-8 (マルチバイト)
UTF-16 (16bit化)
UTF-32 (32bit化)

拡張したよ！
ASCII-8BIT, UTF-8, US-ASCII, Big5, Big5-HKSCS, Big5-UAO, CP949, Emacs-Mule, EUC-JP, EUC-KR, EUC-TW, GB18030, GBK, ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-11, ISO-8859-13, ISO-8859-14, ISO-8859-15, ISO-8859-16, KOI8-R, KOI8-U, Shift_JIS, UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE, Windows-1251, IBM437, IBM737, IBM775, CP850, IBM852, CP852, IBM855, CP855, IBM857, IBM860, IBM861, IBM862, IBM863, IBM864, IBM865, IBM866, IBM869, Windows-1258, GB1988, macCentEuro, macCroatian, macCyrillic, macGreek, macIceland, macRoman, macRomania, macThai, macTurkish, macUkraine, stateless-ISO-2022-JP, eucJP-ms, CP51932, GB2312, GB12345, ISO-2022-JP, ISO-2022-JP-2, CP50221, Windows-1252, Windows-1250, Windows-1256, Windows-1253, Windows-1255, Windows-1254, TIS-620, Windows-874, Windows-1257, Windows-31J, MacJapanese, UTF-7, UTF8-MAC
Ruby 1.9.2 サポート予定分

どうしてこうなった?
制約の中でベストを尽くそうとするため
メモリ容量
処理速度
プログラミングの複雑さ
必要な文字の違い
ベンダ間の調整不足
結局、ほっとけば文字コードは増える
->統一への努力

どうしよう……?
敵を知るしかない
知った上で個別撃破
たいていの罠は「歴史的経緯」
歴史を知る事が重要

ISO 646―分裂の始まり
ISO/IEC 646
ASCIIのISOバージョン
一部の文字の置き換えを認めている
択一 #/￡ $/¤
任意 [ ＼ ] ^ { | } ~

ISO 646の各国ごとの違い
http://ja.wikipedia.org/wiki/ISO_646
http://en.wikipedia.org/wiki/ISO/IEC_646

ISO 646 文字の意味論の違い
赤字は文字合成を許すもの。例: <A BS “>-> Ä

まだまだ足りない
アクセント付きアルファベット(ISO 8859シリーズ) 577字
いわゆる半角カタカナ(JIS X 0201) 56+7字
漢字など(JIS X 0208) 6355+524字

ISO/IEC 2022
Character Code Structure andExtension Techniques
ISO 646を拡張した文字コードの作り方を定める
具体例
ISO 8859シリーズ (8bit化)
ISO-2022-JP (エスケープシーケンス)
EUC系 (多バイト)
シフトJISやUTF-8などは違う

http://www.ecma-international.org/publications/standards/Ecma-035.htm
ECMA-35(≒ ISO/IEC 2022)

ISO/IEC 2022の構造
x20
|
x7F
xA0
|
xFF
A
ESC ( BA
漢
ESC $ B 4A
x8E (SS2)
JIS X 0208
US-ASCII
EUC-JP G1
EUC-JP G2
JIS X 0212
EUC-JP G3
JIS X 0201
ローマ字
JIS X 0201
片仮名
JIS X 0213

ISO 2022のバイト列
どの文字集合を使うか指定
バッファへの指示 (stateful)
バッファからの呼び出し
シングルシフト
ロッキングシフト(stateful)
その文字集合のどの文字を使うか指定

ISO/IEC 2022系の欠点
状態を持つ事 (持たないものもあるが)
文字コードがどんどん増える
文字コードごとに別のコードが必要になる
規格が複雑になってしまった

Unicode
1986年頃からXeroxとAppleが始める
1988年ISOにUnicode 88を持ち込む
1991年1.0 (漢字なし), 1992年1.0.1
1993年1.1でISOと同期
1996年2.0, UTF-8とUTF-16登場
2002年3.2でJIS X 0213対応
2010年末6.0で絵文字対応?

Design Of Unicode
文字コードから地域・言語を分離
1つのUnicode文字列には複数の言語を混ぜられない
フラットな空間に全ての文字を入れる
16bit -> 32bit
UTF-16の制限から1,114,112文字種
用字系が同じならば文字統合

漢字統合
plaintext+encodingからフォントを決定できない

一見大きな問題に見えるが
トルコ語では”i”.upcase->“İ”
ドイツ語では”ss”.upcase->“ß”
実はASCIIの範囲も言語の指定が必要

There Ain't No Such ThingAs Plain Text.
Joel Spolsky
http://www.joelonsoftware.com/articles/Unicode.html
TEXT needs
Encoding and Language

Legacy Encoding
Unicode以前の文字コードたち
Unicode時代のプログラムで動かすには変換して取り込む必要
変換表をどうするか?
人によって変換表が異なると問題

ご存じですか? CP932
他の話がさっぱりでも「CP932の存在」だけは知って帰って頂きたい
Windows Codepage 932
IBM Codepage 932とは微妙に違う
Windows版シフトJIS
正式名称: Windows-31J
JIS規格由来のShift_JISと変換表が異なる
CP932を用いるといくつかの問題を回避可能

円記号問題「」
問題の始まり
ISO 646系の0x5C
JIS X 0201 円記号￥
ASCII バックスラッシュ＼

ISO 646の各国ごとの違い
http://ja.wikipedia.org/wiki/ISO_646
http://en.wikipedia.org/wiki/ISO/IEC_646

どこで問題になるか?
まずは表示上の問題
「円記号」のつもりが「バックスラッシュ」で表示
JIS X 0201データをASCII端末で表示
「バックスラッシュ」のつもりが「円記号」で表示
ASCIIのデータをJIS X 0201端末で表示
取り違えると「文字化け」する

制御コードとの衝突
バックスラッシュは制御記号扱い
C言語のエスケープ記号
MS-DOSのパス区切り文字
同じ0x5Cの円記号も同じ扱いに

e 「えんいー」

シフトJISと円記号問題
「表」はシフトJISでは x95 x5C
シフトJISを理解しないプログラムで問題
% cat yen.rb
puts "表"
% ruby1.8 ./yen.rb
./yen.rb:1: unterminated string meets end of file

理由
puts "表"
puts "x95x5C"
p u t s " x95 "
puts "x95"
引用符を閉じていない扱いに!
unterminated string meets end of file

回避方法
Ruby 1.8の場合 -Ks
Ruby 1.9の場合 magic comment
% cat yen.rb
#coding:Windows-31J
puts "表"
% ruby1.8 -Ks ./yen.rb
表

Unicodeと円記号
シフトJISの0x5CをUnicodeに変換
Shift_JISの0x5Cは本来JIS X 0201
JIS X 0201扱いなら、U+00A5
ASCII扱いなら、U+005C
EUC-JPの0x5CはASCIIのはず

それぞれの変換の問題
ASCII: 0x5CがU+005Cになると、
表示がバックスラッシュになる?
JIS X 0201: 0x5CがU+00A5になると、
パス区切りではなくなる
ソースコードのエスケープじゃなくなる

Windowsでの解決
0x5CはU+005Cに変換する (ASCII風)
日本語用フォントでは、U+005Cのグリフを「円記号」にする
5C = U+005C : REVERSE SOLIDUS (YEN SIGN)
http://msdn.microsoft.com/en-us/goglobal/cc305152.aspx
韓国のウォンでも同様の問題
5C = U+005C : REVERSE SOLIDUS (WON SIGN)
http://msdn.microsoft.com/en-us/goglobal/cc305154.aspx

波ダッシュ問題「～」
JIS X 0208: U+301C(WAVE DASH)
CP932: U+FF5E(FULLWIDTH TILDE)
問題
WindowsはU+301CをシフトJISに戻せない
CP932の変換テーブルにないから
XP添付のフォントでU+301Cを表示しようとすると、誤ったグリフになる「〜」(Vista以降では修正済み)

Shift_JISとCP932の違い

機種依存文字
マイクロソフト標準キャラクタセット
NEC特殊文字
①Ⅰ㌶など
IBM拡張文字
ⅰ￤﨑髙など
NEC選定IBM拡張文字

CP932風別エンコーディング
CP51932
Windows版日本語EUC
CP932にある機種依存文字がある
JIS X 0212がない
Web上の「EUC-JP」はこれかも
CP50221
Windows版ISO-2022-JP
いわゆる半角カナがある
CP932にある機種依存文字がある

シフトJIS関連の名前
「シフトJIS」マイクロソフトウェア・アソシエイツが名付けた。総称として用いられる
「Shift-JIS」「Shift JIS」「シフトJIS」の英語表記
「MS漢字コード」開発者の山下による命名
「SJIS」 Unix方面での名前
「Shift_JIS」 IANA Charsetでの名前
「シフト符号化表現」 JIS X 0208:1997 附属書1
「Shift_JISX0213符号化表現」 JIS X 0213:2000 付属書1
「Shift_JIS-2004符号化表現」 JIS X 0213:2004付属書1
「CP932 (Windows Codepage 932)」 Microsoft実装
「Windows-31J」 CP932のIANA Charsetでの名前
「IBM CP932」 MS CP932とは別物
「IBM943」 MS CP932とおおむね同じ、JIS X 0201
「IBM943C」 MS CP932と同じ、ASCII

日本語EUC関連の名前
「日本語EUC (圧縮形式)」情報交換用のEUC、普通はこれ
「日本語EUC (固定長形式)」 System V での内部表現
「eucJP」 UI-OSF日本語環境実装規約で定義
「EUC-JP」 IANA Charsetでの名前
「UJIS」 ΣOSでの名前
「CP51932」 Internet　Explorerでの日本語EUC実装
「eucJP-ms」 TOG/JVC CDE/Motif 技術検討 WGが定義
「EUC-JISX0213」 JIS X 0213:2000 付属書3
「EUC-JP-2004」 JIS X 0213:2004 付属書3

処理系の課題
内部エンコーディングを何にするか
様々なencodingの入力の扱い
地域・言語ごとに異なる規則

内部コードはどうするか
UCS正規化
内部では特定の1つに変換する
CSI (Code Set Independent)
それぞれの文字コードに対応する

UCS正規化
Universal Character Set
Java, Perlなどほとんどが採用
内部コードを統一
入出力で変換が必要
入力はそのコードに変換
内部コードで処理
出力時に再び変換

CSI方式
それぞれのencodingに対応
入出力を変換しない
入力そのまま取り込む
そのまま処理
そのまま出力

Java
開発時期: 1990～1995
内部コード: UTF-16 (サロゲートペアは1.5から)
文字型: char (コードポイントは int)
文字列型: java.lang.String
グリフ列: CharSequence, BreakIterator等
「Javaにおける Unicode補助文字のサポート」
Windows NT も同時期

.NET Framework
2000年リリース
内部コード: UTF-16
文字型: Char構造体
(コードポイントは Int32)
文字列型: System.String
グリフ列: System.Globalization.StringInfo
http://msdn.microsoft.com/ja-jp/library/system.globalization.stringinfo.aspx
http://msdn.microsoft.com/ja-jp/library/system.globalization.cultureinfo.aspx

Perl 5.6
2000年リリース
内部コード: UTF-8
文字型: なし
文字列型: バイト列 / 文字列 (utf8 フラグ)
Perlは「型」の概念が薄い
http://github.com/github/perl/blob/blead/utf8.c

Python 1.6
2000年リリース
内部UTF-16
文字型: char (UTF-16 code unit; 16bit)
文字列型: String (UTF-16)
http://www.egenix.com/www2002/python/unicode-proposal.txt

Ruby1.8
内部コード: ASCII/SJIS/EUC/UTF-8
文字型: Fixnum(8bit)
文字列型: String
$KCODEでプロセスの文字コードを指定
「文字」のサポートはほとんどない

Ruby 1.9
2007年1.9.0リリース
2009年1.9.1リリース
内部コード: N/A (CSI)
文字: 1文字String
文字列型: String
グリフ列: なし

Ruby 1.9の特徴
Stringが文字単位になった
バイト操作と文字操作を区別する必要
CSI方式
特定の内部エンコーディングがない
Stringそれぞれがencodingを持つ
正規表現エンジンの刷新
鬼車ベースに変更

文字志向なString
"あいう".length-> 3
"あいうえお"[0]-> "あ"
"あい".gsub(/あ/,"か")-> "かい"
"abc".tr("abc","あいう")-> "あいう"

String#each_*
String#each_byte
String#each_codepoint
String#each_char
String#each_line
String#eachは削除された

1文字String
専用の文字型は無い
文字は1文字Stringで表す
?a -> "a"
"abc"[0] -> "a"
"abc"[0] == ?a は1.9でも成り立つ

「文字」型に必要なもの
コードポイント, Encoding, (言語)
Stringは両方持っている
Rubyは大クラス主義
Stringを使えばよい

Ruby 1.9のRegexp
/(.)/ =~ "あ" -> 0
$1 -> "あ"
/w/ =~ "あ" -> nil
1.9.1-p376 以降、1.9.2
以下はUnicode系
/(p{Alphabetic})/ =~ "あ"
$1 -> "あ"
/(p{Ideographic})/ =~ "漢"
$1 -> "漢"

1.9のStringに必要なこと
適切にencodingが設定されていること
理由
Stringのencodingを見て処理するから
設定方法
Magic comment(リテラル)
IO のオプション (入出力)
String#force_encoding(強制指定)

encodingが誤っている時
invalid multibyte char (US-ASCII)
Magic comment忘れ
Encoding::CompatibilityError
異なったencodingのStringを混ぜた時
文字列をバイナリ扱いのままにしている時
ArgumentError: invalid byte sequence
単純な指定ミス
壊れた入力

Magic Comment
リテラルのエンコーディングを指定
String, Regexp
デフォルトはUS-ASCII
Magic CommentがないとソースにASCII以外を書くことはできない
#coding:utf-8
#!/usr/local/bin/ruby#coding:utf-8
# -*- coding: UTF-8 -*-

ERB用 Magic Comment
ERBでもMagic Commentが必要
<%# coding: UTF-8 %>

IOとEncoding
入出力のencodingを指定する
外部リソースのencodingを指定
open("foo.txt","r:UTF-8")
未指定ならEncoding.default_external

ネットワークからの入力
Socket, Net::HTTPなど
現在はバイナリAPI扱い
->文字列の場合は自分でEncodingを設定する必要

Encodingの強制指定
String#force_encoding(enc)
任意のencodingの文字列をバイナリから作りたい時
str = "xE3x81x82"str.force_encoding("UTF-8")str #=> "あ"
外部から来たデータに設定する時
IOなら外部エンコーディングを設定するべき
socketやnet系のライブラリで必要

$KCODE is obsolete
$KCODEは内部コード指定のため使われた
Ruby1.9ではシステム全体の内部コードは、
決定不可能なため、廃止。
$KCODEを参照しているスクリプトは注意

結局encodingとは
Stringにとっての「型」
型が違えばエラー
型同士で互換性があれば、自動変換されることも->ASCII互換でのasciionly

Encodingの3分類
ASCII互換
ASCII非互換
ダミー

ASCII互換
フルサポート
Rubyスクリプトのソースエンコーディングとして使用可能
UTF-8, Shift_JIS, EUC-JP, ...

Major Encodings
US-ASCII
ASCII-8BIT
UTF-8

日本語用
Shift_JIS
EUC-JP

Other Encodings
Big5, Big5-UAO, EUC-KR, EUC-TW, GBK,
ISO-8859-X, KOI8-R, KOI8-U, etc

Windows機種依存
Windows-31J
CP51932
eucJP-ms
Windows-125X

ASCII-8BIT
ASCII互換バイト列
バイナリだけどASCII互換
ASCII互換の恩恵を得るため

ASCII Only
特別扱い
ASCII互換エンコーディング
内容が7bit
"abcde".ascii_only?->true
"abcde" + "あいうえお"
ASCII互換エンコーディングなら、両者のエンコーディングによらず成功

ASCII非互換
限定サポート
ソースコードには使えない
UTF-{16,32}{BE,LE}

UTF-16 & UTF-32
UTF-16BE, UTF-16LE
UTF-32BE, UTF-32LE
しかし、UTF-16 や UTF-32 には非対応
BOM対応が困難なため

Dummy encoding
Ruby は名前を知っているだけ
「文字」のサポートはしない
for stateful encodings
Encoding#dummy?-> true
ISO-2022-JP, UTF-7

Encoding
「エンコーディング」を司るクラス
CSIではエンコーディングが内部処理でも使われるから活躍
でも、たいていエンコーディング名を表す文字列でよい

Encodingの取得
enc = Encoding.find(“UTF-8”)=> #<Encoding:UTF-8>
Encoding.find(“external”)デフォルト外部エンコーディング
Encoding.find(“internal”)デフォルト内部エンコーディング
Encoding.find(“filesystem”)ファイルシステムエンコーディング
Encoding::UTF_8定数も定義されている

Encodingの一覧
Encoding.listオブジェクトの配列
Encoding.aliases別名 => 本名のHash
Encoding.namesEncoding.findの引数になるStringの配列

Encodingの情報
enc.name=> “UTF-8”
enc.names=> ["UTF-8", "CP65001", "locale", "external", "filesystem"]
enc.dummy?ダミーエンコーディングかどうか
enc.ascii_compatible?ASCII互換かどうか

エンコーディング変換
nkf
kconv
iconv
uconv
String#encode
Encoding::Converter

nkf
Network Kanji Filter
歴史ある変換コマンド
使うなら --ic, --ocオプションを使う事

kconv
nkfのラッパー
String#tosjisなどと簡単
歴史的経緯による意図しない挙動
勝手にMIMEデコード
いわゆる半角カナが全角に
もはやオススメしない

iconv
POSIX由来のiconv(3)のラッパー
挙動が環境依存
glibc/GNU libiconv/Citrus/…
1.9ではあえて使う必要はないはず

uconv
Unicode 変換用拡張モジュール
0.5.3から1.9.1に対応しているが、互換性確保用に止めるべきであろう
http://www.yoshidam.net/Ruby_ja.html

String#encode
Ruby 1.9独自のtranscode
String#encode(to, from, opt)
たいていの用途はこれでいけるはず

Encoding::Converter
transcodeのエンジン
変換を一時停止・再開したい時
常人は使わないはずだが、何かの間違いで必要になるかもしれない

Don't forget…
不必要な変換は避ける
open()等の引数に指定

Ruby M17N の難しさ
テストがしづらい
US-ASCII
ASCI-8BIT
UTF-8 (ASCII Compatible)
UTF-16 (ASCII Incompatible)
ISO-2022-JP (dummy encoding)

SJISとWindows-31J
Windows環境
Magic commentなどでSJISを指定
Encoding::CompatibilityError
入力はWindows-31Jだから
->Windows-31J指定が正しい
あなたがSJISだと思っているのは、実はWindows-31Jです

ASCII-8BIT
Ruby M17N未対応のライブラリを使った時
ネットワーク系やDB系など
明示的にエンコーディングを指定
String#force_encoding(enc)

ASCII非互換の正規表現
ASCII非互換エンコーディングな正規表現はリテラルで書けない
UTF-16LEの正規表現リテラルは書けない
Regexp.newを使う
Regexp.new( "あ".encode("UTF-16LE"))

Open problems
ケータイ絵文字
WindowsのUnicodeパス
結合文字
異体字セレクタ/IVS
Stringと言語
Stateful encoding
Unicode用ユーティリティ

ケータイ絵文字
mrknさんや設楽さんたちが作業中
1.9.2に入るかも

WindowsのUnicodeパス
一部対応その他非対応
方針としては、現在WindowsのA系APIを叩いているものを、W系APIを使うように変える
そこら中で踏むのでリソース不足
いじれる方が居たらパッチください
Win32-unicode-testブランチ

結合文字
「が」を「か」+「゛」で表す
複数のコードポイントを1文字扱いする必要
Stringの「文字」をこれにする変更が入った事はあるが巻き戻された [ruby-dev:36375]
「文字」の単位がUnicodeのバージョンに依存
エスケープなどに影響
JavaのBreakIteratorっぽいものが必要?
検討中

異体字セレクタ/IVS
Ideographic Variation Sequence
結合文字同様、複数のコードポイントを1文字扱いする必要

Stringと言語
日本語と中国語を同時に扱いたい
日本語と中国語を1つのStringに入れたい
可能かは文字コードによります
UTF-8ではできません
Unicodeは言語を別に与えないといけない
Stringにencodingとlangを持たせる必要
現状ユースケース不足

Stateful encoding
現状ダミーエンコーディング
改善予定無し

Unicodeユーティリティ
文字幅
Unicode正規化
Unicode大文字小文字化
APIをどうするか
そもそもどこにいれるのか

String#sort
デフォルトでは文字コード順
シフトJISや日本語EUCの系統と、Unicode系のエンコーディングで並び順が変わる
現状ではsortにblock引数を指定する
RubyにはCollationとかは添付されていない
自分で比較ルーチンを用意して渡す

Feedbackを
よいAPIを設計するには、ユースケースの収集が大事なのでfeedbackが重要
失敗談等はruby-listへ
バグ・提案はruby-devへ
オレはようやくのぼりはじめたばかりだからなこの果てしなく遠いM17Nをよ…
未実装

http://www.slideshare.net	24
http://coderwall.com	10
http://twitter.com	1

A Reintroduction To Ruby M17 N

by Yui NARUSE

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 35

Statistics

A Reintroduction To Ruby M17 N Presentation Transcript