A Reintroduction To Ruby M17 N

A reintroduction to Ruby M17NNARUSE, 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 0208http://www.kanji.zinbun.kyoto-u.ac.jp/~yasuoka/kanjibukuro/japan.html

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

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

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

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

Unicode用語集UCS-2は文字集合ではなくencodingISO/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 I18NInternationalization, 国際化I .{18} NI18NS12N (Scherpenhuizenさんが元祖)http://blog.miraclelinux.com/yume/2007/01/i18n_8bc0.html

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

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

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

http://www.ecma-international.org/publications/standards/Ecma-006.htmECMA-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-MACRuby 1.9.2 サポート予定分

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

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

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

ISO 646の各国ごとの違いhttp://ja.wikipedia.org/wiki/ISO_646http://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 2022Character Code Structure andExtension TechniquesISO 646を拡張した文字コードの作り方を定める具体例ISO 8859シリーズ (8bit化)ISO-2022-JP (エスケープシーケンス)EUC系 (多バイト)シフトJISやUTF-8などは違う

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

ISO/IEC 2022の構造\x20|\x7F\xA0|\xFFAESC ( BA漢ESC $ B 4A\x8E (SS2)JIS X 0208US-ASCIIEUC-JP G1EUC-JP G2JIS X 0212EUC-JP G3JIS X 0201ローマ字JIS X 0201片仮名JIS X 0213

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

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

Unicode1986年頃からXeroxとAppleが始める1988年ISOにUnicode 88を持ち込む1991年1.0 (漢字なし), 1992年1.0.11993年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 -> 32bitUTF-16の制限から1,114,112文字種用字系が同じならば文字統合

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

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

There Ain't No Such ThingAs Plain Text.Joel Spolskyhttp://www.joelonsoftware.com/articles/Unicode.htmlTEXT needsEncoding and Language

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

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

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

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

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

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

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

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

Unicodeと円記号シフトJISの0x5CをUnicodeに変換Shift_JISの0x5Cは本来JIS X 0201JIS X 0201扱いなら、U+00A5ASCII扱いなら、U+005CEUC-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以降では修正済み)

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

CP932風別エンコーディングCP51932Windows版日本語EUCCP932にある機種依存文字があるJIS X 0212がないWeb上の「EUC-JP」はこれかもCP50221Windows版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 SetJava, Perlなどほとんどが採用内部コードを統一入出力で変換が必要入力はそのコードに変換内部コードで処理出力時に再び変換

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

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

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

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

Python 1.62000年リリース内部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.92007年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_byteString#each_codepointString#each_charString#each_lineString#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/ =~ "あ" -> nil1.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-ASCIIMagic CommentがないとソースにASCII以外を書くことはできない#coding:utf-8#!/usr/local/bin/ruby#coding:utf-8# -*- coding: UTF-8 -*-

ERB用 Magic CommentERBでも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 = "\xE3\x81\x82"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 EncodingsUS-ASCIIASCII-8BITUTF-8

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

Windows機種依存Windows-31JCP51932eucJP-msWindows-125X

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

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

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

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

Dummy encodingRuby は名前を知っているだけ「文字」のサポートはしないfor stateful encodingsEncoding#dummy?-> trueISO-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別名 => 本名のHashEncoding.namesEncoding.findの引数になるStringの配列

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

エンコーディング変換nkfkconviconvuconvString#encodeEncoding::Converter

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

異体字セレクタ/IVSIdeographic 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をよ…未実装

A Reintroduction To Ruby M17 N

More Related Content

Viewers also liked (13)

Similar to A Reintroduction To Ruby M17 N (20)

A Reintroduction To Ruby M17 N