56.md
第11回Asakusa.rb議事録
日時
6/23(Tue) 19:00～
場所
秋葉原ダイビル 13F http://www.i.u-tokyo.ac.jp/map/index.shtml#aki
内容
成瀬さんの誰でも知りたがっているくせにちょっと聞きにくいRuby M17Nのすべてについて教えましょう
(※元ネタはウッディ・アレン監督の映画ですよ)
参加者
成瀬さん
ささださん
松田さん
かくたにさん
吉川さん
豊福さん
宮内さん
後藤裕蔵さん
おぐらさん
（来た人順）
買出し
ダイビル裏手のスーパーで買ってきました。
「多すぎ」という声もありましたが、最後はお酒もつまみも足りなかったですよ。
ただ持ち込みに関しては、ゴミ分別はしっかりとのことです。（燃える/燃えない/缶/ペット）
Rails3の最近の疑惑のコミットについて
http://github.com/rails/rails/commit/cf3ccd7be0caae67dfddf5bc5056dcfdaab6f369
-
Encoding.default_internal / Encoding.default_externalを決めてしまう
- Rubyから利用されるライブラリで default_internal/ default_external を決め打ちしてしまうのはダメだけど、「Railsの世界はUTF-8で」というのはフレームワーク的にはアリ
- Railsは（文化的には）Rubyじゃないので、別に流儀に反することはない
- !を「破壊的メソッド」としてではなく、「例外を発生させるメソッド」の意で使うような観点で「文化が違う」
- 余談だけど、「!?」メソッドとかを作りたいな
http://github.com/rails/rails/commit/30a3b6b4fc56390eec762c879644c95cd09622b0
-
String#force_encoding(::Encoding::BINARY)してから非UTF-8をとり除いている
- これはまず発想が間違っている
- JSONはUTF-8を前提としているフォーマットなので、::Encoding::BINARYじゃなくて::Encoding::UTF_8でよい
- これじゃ動かないんじゃない？
- default_internalが設定されていれば、String#encode!を使っても良い（内部エンコーディングへと変換できない文字を置換しつつ変換される）
- だけどencodingがASCII-8BITのままだとダメなので、この場合変換元encodingを正しく設定すればいい
成果物
https://rails.lighthouseapp.com/projects/8994/tickets/2849-encode-json-in-utf-8-instead-of-binary
http://github.com/rails/rails/commit/94911c7af7f2e1da0a23d64d2055b77bc1f6ece8
-
ERBのcompileメソッドで1行目にマジックコメントを埋め込んでいる部分
- これはよくある手法らしい
- viのマジコメに対応するため、正規表現の一部で[:=]としてcodingの前のセパレータを許容してあげてください
- 添付の写真（豊福さんがプリントしてきたるびまのM17N記事記載の内容）を参照
- この正規表現は定数にでもしておいたほうがいいかもね
- ていうかRuby本体に持つべき？
- むしろこの処理はERB本体にあったほうがいいかも
成果物
https://rails.lighthouseapp.com/projects/8994/tickets/2188
-
Rails2.3系+Ruby1.9でエンコーディングエラーが出る問題
- これは前述のとおり、Railsの世界の中ではUTF-8決め打ちにしちゃえばよさそう(含 ERB, I18n)
http://rack.lighthouseapp.com/projects/22435/tickets/48
-
Rackで扱う文字列については？
- Rackの世界ではUS-ASCII/ASCII-8BITのままにしておいて、Railsに入ってくるところでforce_encodingでよいのでは(つまり現状どおり)
- なぜかというと、Rackのレイヤーでは本当に指定したいencodingを決定できないため。
- たとえば、Shift_JISで送られてきてもそれは本当はWindows-31Jだし、EUC-JPでもCP51932だったり、ISO-2022-JPもCP50221だったり
https://rails.lighthouseapp.com/projects/8994/tickets/2476
-
RailsとDBの間のエンコーディング問題
- これはRailsじゃなくて各DBのドライバが頑張ってただしいencodingを設定するべき
NKFをRubyのM17Nで置き換える必要があるの？
-
元々NKFは日本に特化した形のライブラリなので議論する位相が違う
- 単に-sだけだとCP932まわりで波ダッシュ（WAVE DASH）問題とかに遭っちゃうけど、ルーズに使えて使用感が良いというニーズもある
- to_sjis使っちゃうじゃないですか(これはShift_JISだけど)
Ruby1.9.1からはM17Nをちゃんと意識するようにしていこう
-
Rubyistは基本スクリプトエンコーディングUS-ASCIIで書いて、多言語を意識したコードを書く責務を負うべき
- めんどくさいとかじゃなくて、責務と考えて(シングルバイトの幸せな世界にいたアメリカ人をマルチバイトの世界にひきずりこんだんだから)
-
HTTPのContent-Typeは送ってこない人多過ぎ、窓が破れちゃってる
- あとShift_JISと名乗っているのに中身がWindows-31Jだったりする
- RailsはRequestの文字セットにUTF-8を期待するので、正しいUTF-8文字が送られてこない場合Bad Requestで返そう
-
そもそもRubyはPOSIXべったりな仕様なので…
- 文字セットとの絡みは失念。UTF-8を期待してよい？ということだったか
- windowsの話しをしていたのだったか
- ファイルシステムエンコーディングとファイル名とUnixではファイル名がバイト列だけどWindowsやMac OS XではUnicode文字だけどRubyはPOSIXべったりだからどうなのかなぁとかそんな話だったような
-
HTTP周りの論争が成瀬さんと後藤さんの間で盛り上がっていた気もしますが、失念
- 残りはRubyKaigiでやってくださいという締りでした
JUNETとISO-2022-JPネタ
- 自主規制。私からは何もいえないです
- まぁ、「名前のない悪魔よりは名前のある悪魔の方が扱いやすい」という言葉でしめておきましょう
Rubyが不安定で困るとか、そういういつもどこでも起こりそうな議論について
-
パッチを送ろう。Rubyはやさしさだけで出来ている訳ではない
- お金を頂けるなら･･･
文句があるならJ***を使ってください
Asakusa.rbはJ***を応援しています
TRONコードに対して豊福さんからの質問
-
例えば<赤>abc</赤>みたいな文書構造があるとする
- 文書をツリー状に解析するコストが高いので、拡張文字にして正規表現で取り扱いたいという欲求
- 何らかの拡張？文字セットを定義するのは番地が空いてるのであればよくあることなので感覚的に普通といえば普通
-
そもそもTRONコードはエンコーディングがステートフルなので、Rubyの立場からすると取り扱わない
こういう構造的な「言語タグ」的なものにたいするMatz言及 http://www.rubyist.net/~matz/20070312.html
-
私感
- TRONコードがキャラセットに対してメタ的な意味合いを持つ文字を自由に定義していいと推奨しうる文化？なのかが、前提としてよく分からないです
- 文字コードにおいて、既に一部存在するとはいえ、反する気がするのですが
- 私は、上記の構造記述的タグは、文字だろうが表記だろうがアプリケーション層において処理されるべき問題なのではないかと思います
- なので、ツリーか正規表現かどうかは解析効率の話しなので、あんまり重要じゃない気もします
まぁ、とりあえずTRONコードの仕様を一通り理解した上でやってください
鬼車
- 今の鬼車の実装を把握してる人って誰か居るの？
- Joniすごすぎ
SQLite3の標準添付の件
- これ話したっけ?
来年のRubyKaigiについて
-
場所は今年の場所か、去年のつくばか。どうしよう
- 東京から離れると宿泊にお金かかる問題が
-
それより入場者数増加に関して、多少は高くして敷居を高くしてもいいのではないか
- 今年きっと･･･立ち見が出ちゃうよ
- 10000円くらいが心情的に払える境界値かな
学生が来やすい（現在半額にする学割制度あり）チケット値段設定は大事にしたい
次回
未定。こんな豪華コンテンツで人が少なかったのは幸なのか不幸なのか
END
- Close