- 1 名前：デフォルトの名無しさん [2009/06/28(日) 16:29:28 ]
- オブジェクト指向スクリプト言語Rubyについて扱うスレッドです。
前スレに変なのが沸いて流れてしまいましたが、まったりと行きましょう。
Ruby Home Page
www.ruby-lang.org/ja/
= 前スレ
Rubyについて Part 35
pc12.2ch.net/test/read.cgi/tech/1238194350/
過去スレ・関連スレは >>2-
- 255 名前：デフォルトの名無しさん mailto:sage [2009/07/20(月) 18:50:16 ]
- AOPってなに？
アスペクト指向とかいう現状バズワードまがいの代物ですか？
- 256 名前：デフォルトの名無しさん mailto:sage [2009/07/20(月) 18:56:43 ]
- バズワードだってｗ
使ってみたかったんだねｗ
- 257 名前：デフォルトの名無しさん mailto:sage [2009/07/20(月) 19:58:59 ]
- そういえば、matzが言ってたnloopパッチって
結局何で適用されないんだろう
高速化は正直どうでもいいけど、
多重ループが圧縮できるのは嬉しいと思うんだけどなあ
ネストが浅くなるし、行数も減るし
- 258 名前：デフォルトの名無しさん mailto:sage [2009/07/20(月) 23:22:08 ]
- 名前とか？
nloopでは分かりづらくね
- 259 名前：デフォルトの名無しさん mailto:sage [2009/07/22(水) 00:57:45 ]
- 今時は、なんでもeco。
名前にecoを付ければ、政府援助が付いて、双方ウマウマ。
なわけで、
ecoloop
おいらは、実態を知らんが、高速になるならecoに違いない。
- 260 名前：デフォルトの名無しさん mailto:sage [2009/07/22(水) 06:58:47 ]
- >>255
>アスペクト指向とかいう現状バズワードまがいの代物ですか？
アスペクト指向は、Javaではけっこう使われているちゃんとした技術だよ。
DIコンテナでは標準的な技術。
- 261 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 02:44:03 ]
- 実現方法は別としてLISPとかでも普通にやってることだしね。 > AOP
昔ながらのやり方に新しい名前が付いただけで「バズワード(笑)」になっちゃうわけもなく。
- 262 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 02:57:50 ]
- NokogiriがWindows-31Jエンコーディングをサポートしていない気がする。
正確にはNokogiriが使っているlibxml2が呼んでいるiconvかもしれないけど。
>irb -Ks -rrubygems -rnokogiri
#Shift_JISの範囲外の文字を含んだWindows-31J(=CP932)エンコーディングの文字列
irb(main):001:0> s="<html><HEAD><TITLE>1１①1１①</TITLE></HEAD><body></body></html>"
=> "<html><HEAD><TITLE>1１①1１①</TITLE></HEAD><body></body></html>"
#エンコーディング指定なしでHTMLパース。当然失敗。
irb(main):002:0> Nokogiri::HTML.parse(s)
encoding error : output conversion failed due to conv error, bytes 0x82 0x50 0xC
2 0x87
I/O error : encoder error
=>
#Windows-31JエンコーディングでHTMLパース。失敗。
irb(main):003:0> Nokogiri::HTML.parse(s,nil,'Windows-31J')
encoding error : output conversion failed due to conv error, bytes 0x82 0x50 0xC
2 0x87
I/O error : encoder error
=>
- 263 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 03:00:30 ]
- #CP932エンコーディングでHTMLパース。成功。
irb(main):004:0> Nokogiri::HTML.parse(s,nil,'CP932')
=> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "www.w3.
org/TR/REC-html40/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=CP932">
<title>1１①1１①</title>
</head>
<body></body>
</html>
#Shift_JISエンコーディングでHTMLパース。Shift_JISの範囲内のところまで中途半端にパース。想定通り。
irb(main):005:0> Nokogiri::HTML.parse(s,nil,'Shift_JIS')
=> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "www.w3.
org/TR/REC-html40/loose.dtd">
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">
<title>1１</title>
</head></html>
ちなみに環境はこんな感じ。現在入手できる最新のActiveScriptRubyとNokogiri。
>ruby -v
ruby 1.8.7 (2009-06-12 patchlevel 174) [i386-mswin32]
>gem list nokogiri
I:\home\a_i\script>gem list nokogiri
*** LOCAL GEMS ***
nokogiri (1.3.2)
- 264 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 03:18:51 ]
- さくっとパッチ書いて配布しないの？
wktk
- 265 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 03:36:14 ]
- Nokogiri::HTML.parse(s,nil,'Windows-31J')
のときに実際には
Nokogiri::HTML.parse(s,nil,'CP932')
とやるようなのはすぐに出来るだろうけど、
変換結果とかエンコーディング情報はCP932になっちゃうから、
パース時に明示的に指定したエンコーディングと、
パース後に取得できるエンコーディングの内容が同一と仮定してるような
プログラム、具体的にはMechanizeとかが困ったことになる悪寒。
- 266 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 06:46:26 ]
- 個々人の環境でインストールされている iconv が実際にどんだけの範囲をサポートしているかは
iconv 利用ライブラリ側ではもうどうしようもない
「自動でやりたいなら WINDOWS-31J をサポートしてる iconv を自分でインストールしろ」で終了
そんなこと言ったらそもそも x-sjis なんかも読めないわけだし
ちなみに手元の Ubuntu では普通に動作する
irb> s = Iconv.conv('WINDOWS-31J', 'UTF-8', "<html><HEAD><TITLE>1１①1１①</TITLE></HEAD><body></body></html)"
irb> Nokogiri::HTML.parse(s,nil,'Windows-31J')
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-31J">
<title>1?P?@1?P?@</title>
</head>
<body></body>
</html>
- 267 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 07:39:51 ]
- 1.8もiconvも捨てて、1.9/transcode使おうぜ！
- 268 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 07:41:36 ]
- Ruby って不幸なんですね
日本語得意っていうのが嘘に聞こえる
- 269 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 07:50:24 ]
- iconv と小文字で書いてるのが読めんようだが、
まあ Encode.pm を再発明しなかったのが罪だというならそれはそれで
- 270 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 07:51:48 ]
- Rubyが日本語が得意だと言ってるユーザーはぶっちゃけいないと思う
- 271 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 07:57:22 ]
- 比較スレとかで「日本語処理が得意」とか書かれてるのは時々見る
つまりRubyを使ってない人にはそう見えるんだろう
- 272 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 08:26:58 ]
- つまりRubyを使ってない人が
比較スレとかで「日本語処理が得意」とか書いてるのか
- 273 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 08:35:47 ]
- ・文字列処理は得意
・日本語の取り扱いもできる
→日本語処理も得意なはず！
こういう図式が成立してそうなイメージが
嘘じゃあないが、他のスクリプト系言語と比べて
とりたてて得意かと言われると微妙な所
- 274 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 08:46:08 ]
- 日本語版Windowsの標準エンコーディングがUTF-8になれば
UTF-8以外を使う人間はごく短期間で絶滅寸前になるような気もするので、
これから本当にそれほどまでの対応が必要なのかという疑問がいつもある。
- 275 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 09:05:08 ]
- そもそも「日本語処理が得意」って言い方からして曖昧すぎる
どうすれば得意だと言えるんだ？
たとえばruby1.8のように、あまり難しいこと考えずにエンコーディングを扱えるのが良いのか？
ruby1.9のように、各文字列のエンコーディングを厳密に扱えるのが良いのか？
それとも他言語のように、すべてUTF-8で統一されてるのが良いのか？
やっぱりRuby使ったことない人が書いてるだけなんじゃないか、と疑いたくもなる
- 276 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 09:05:44 ]
- 朝から活発だな
- 277 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 09:16:21 ]
- >日本語版Windowsの標準エンコーディングがUTF-8になれば
I agree, but there are many SJIS records on HDD.
- 278 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 09:18:13 ]
- >>275
各文字列のエンコーディングを厳密に扱えるのが良い
- 279 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 11:11:31 ]
- ShiftJIS というか CP932（相当）で作ったファイルがもれなく UTF-8（と共通で決まったもの） で表現できるなら
そりゃ移行はもうあっさり済むと思うんだが
実際はそうではないわけで
- 280 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 11:14:23 ]
- Summer holidays has come.
- 281 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 11:47:25 ]
- >>279
漏れなくは無理でも、実際に数えてみたら無視出来る程度の数だったりしてな。
大体、それこそMSお得意の「コードページの切り替え（バグ込み込み）」で
対応できるんじゃねーのとか。
- 282 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 12:04:12 ]
- ファイルそのものにファイルのエンコーディング情報を含めなかったのが間違いの元
Macと違って
- 283 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 12:38:14 ]
- >>281
>漏れなくは無理でも、実際に数えてみたら無視出来る程度の数だったりしてな。
この手の問題は、数が少ないからといって無視できるものではない。
というより、データ変換については間違いがあってはならないのが前提であり、
すこしでも間違いがあれば大きな問題。
１文字でもうまくいかないのがあれば、移行しない人が大勢いても不思議ではない。
- 284 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 13:13:38 ]
- cp932はもれなくユニコードで表現できるでしょ？
じゃなきゃW系APIとかどうすんのかと
- 285 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 13:16:48 ]
- マクはいろいろ問題が。
- 286 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 13:31:41 ]
- UTF-8だと日本語が1文字3バイトになるから嫌だと言って譲らない人が稀にいるけど、
そういう人に限って、コンピューターが高速になってるからインタープリタ言語でも問題ないとか言うんだよね。
- 287 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 13:34:12 ]
- Perlがまだjcode.pl全盛期でUnicodeなんか誰も使ってなかった頃、
Rubyは既に日本語(EUC-JP, SJIS)に対応していた。
というだけで今となっては別に日本語処理がとりわけ得意なわけではない。
1.9はノウハウがたまってくれば良いかも。
- 288 名前：262 mailto:sage [2009/07/23(木) 13:53:35 ]
- >>266
>「自動でやりたいなら WINDOWS-31J をサポートしてる iconv を自分でインストールしろ」で終了
>ちなみに手元の Ubuntu では普通に動作する
ああ、やっぱりそんなところですよね。
で、今回問題となってるiconvですが、
Nokogiriの公式のWindows向けgemパッケージに同梱されてるiconv.dllなんですよね。
つまりWindowsでgem install nokogiriしたときに標準で使われるものがこの状態という。
一番丸く収まる対処としては公式にお願いして同梱するiconvを変えてもらうとかそんなところでしょうか。
さすがにIANAに登録されてる分ぐらいはエイリアスが効かないとHTML/XMLの処理という
趣旨から困るはずなので。
現状、Mechanize経由で使ったりする分には、
コンテンツ取得後にレスポンスボディをNKFでUTF-8に変換して差し替えて
レスポンスのコンテントタイプのキャラクターセットもUTF-8に差し替えてしまえば
実用上はほとんど問題なさそうです。
もちろんWindows-31J->UTF8->Windows-31Jと変換したときに
変換前と後とでバイナリが一致しなくて困るケースとか、
サーバから取得した時点でのエンコーディングを意識しておく必要があるケースとかは
マズいんですが、まあそう多くはないだろう、という。
- 289 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 14:13:03 ]
- 文字コード変換はJavaとかPerlとかがまあ道を切り開いてはくれてるけど
Javaの文字コード周りの大変さとか、
Perlが4から5へ上がったときに配布サイズが膨れ上がった原因の大半が
文字コード変換テーブルのせいだった、とか考えると
Rubyでやるべきかどうか、ってのは悩ましいな。
特にRubyはCSIで頑張るつもりなわけで、より大変な道だし。
- 290 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 14:23:46 ]
- >>284
もういちど>>279を読もうぜ
>>279
>ShiftJIS というか CP932（相当）で作ったファイルがもれなく UTF-8（と共通で決まったもの） で表現できるなら
>そりゃ移行はもうあっさり済むと思うんだが
>実際はそうではないわけで
- 291 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 14:25:39 ]
- >>288
Mechanize::Page#encoding= 使え
引数を Nokogiri::HTML.parse の第3引数に渡して page の HTML を再パースしてくれる
agent.get(windows_31j_uri)
agent.page.encoding = 'CP932'
今の iconv の CP932 は WINDOWS-31J と全く同じだから
（つまり、WINDOWS-31J 以前の CP932 には非対応）、
WINDOWS-31J の代わりに CP932 を渡しても構わない
あと、Ubuntu にインストールされている iconv は非公式パッチが入ったものだ
オフィシャルな iconv は
ttp://www.gnu.org/software/libiconv/
> Japanese
> EUC-JP, SHIFT_JIS, CP932, ISO-2022-JP, ISO-2022-JP-2, ISO-2022-JP-1
> EUC-JISX0213, Shift_JISX0213, ISO-2022-JP-3 (--enable-extra-encodings 有効時)
これ以外をサポートしないし、サポートする義理もない
- 292 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 15:08:47 ]
- >>291
事前にコードが仮定できればそれでOKというかベストですね。
ちなみに当初ハマっていたシナリオだと
とあるページをパースすると途中で内容が途切れたようなパース結果が帰ってくる
->元データを確認したらWindows-31J相当の内容のページに設定されたmetaタグの内容がShift_JIS
->encodingにWindows-31J指定->内部的には未知のエンコーディングでエラー。なかったことに。
->再パースされるもmetaタグのエンコーディングでパース
->外観的には何度encodingを再設定してもencodingがShift_JISのまま
->大☆混☆乱
とかまあそんな感じでしたw
- 293 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 15:44:28 ]
- >>290
具体的にどの文字がUTF-8で表現できないんだ?
- 294 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 16:09:56 ]
- CP932→UTF-8自体は、記号の意味上はともかく文字の見掛けの形だけは大丈夫だったはず
逆は不可だが
- 295 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 16:14:24 ]
- >>293
その辺の話はCP932については
ttp://ja.wikipedia.org/wiki/Microsoftコードページ932
がまとまってるんじゃないかな
- 296 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 18:19:41 ]
- UNICODEってあほなの？
文字コード統一するどころか
種類増やしてさらに面倒にしただけじゃないの？
- 297 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 18:25:18 ]
- iso-8859-*は統一されたんだろ
- 298 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 18:56:04 ]
- 日本国内の文字コードも統一できない民族よりはマシ
- 299 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 19:01:14 ]
- >>296
JIS EUC-JP Shift_JISを使い分け続けるよりは遙かに分別があるよ
- 300 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 19:09:45 ]
- 100年後も使い分けしつづけてるんじゃないかなぁ？w
- 301 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 19:13:33 ]
- 毛沢東の文化大破壊みたいな歴史的事件でも起こさない限り統一は無理だろ
- 302 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 19:24:07 ]
- >>291
ubuntuのiconvはglibcのiconv
- 303 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 19:25:18 ]
- >>301
必要に応じてうだうだ追加してきただけの既存規格が
もうそんなに文化的なものになってるのかｗ
って、もとから超人工的で場当たり的なものなんだからそれはねーよ
、とマジレスｽﾏｿ
- 304 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 19:59:21 ]
- 文化で人工的でなくて場当たり的でないものはあるのか
それこそ非文化だろ
- 305 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 20:23:45 ]
- Perl、インターネット、日本語漢字コードあたりは、「とりあえず作ってみた」が
実用に供されていろいろ問題が尾を引いている事物の代表だな。
- 306 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 20:25:39 ]
- Cもしかり
Javaもしかり
GAEもしかり
- 307 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 20:27:02 ]
- Rails もしかり www
- 308 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 20:28:10 ]
- >>305
>「とりあえず作ってみた」
Rubyもその代表なんだが
- 309 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 20:34:18 ]
- 長く大勢に使われる人工物で統一取れているものなんていくつあるんだか。
- 310 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 20:40:12 ]
- 車のエンジンレーキハンドルを変えようかって話は出たり出なかったり
- 311 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 20:49:00 ]
- > Ruby って不幸なんですね
> 日本語得意っていうのが嘘に聞こえる
> Rubyが日本語が得意だと言ってるユーザーはぶっちゃけいないと思う
> 比較スレとかで「日本語処理が得意」とか書かれてるのは時々見る
基本的に自然言語は難しい、「得意」というよりは、「比較的マシ」と言い換えた方が実情に近い。
> こういう図式が成立してそうなイメージが
> 嘘じゃあないが、他のスクリプト系言語と比べて
> とりたてて得意かと言われると微妙な所
確かにPerl5.8以前においては、Rubyは-Kがあるだけかなりマシだった。
> まあ Encode.pm を再発明しなかったのが罪だというならそれはそれで
Ruby 1.9のEncoding/transcodeはソレですよ。
まぁ、再発明すれば解決ってほど文字コードの世界は甘くない。
Rubyより下のレイヤーに依存しないだけマシって話ですな。
> 日本語版Windowsの標準エンコーディングがUTF-8になれば
Windowsは互換性にかなり気を使うからどうだろうねぇ。
デフォルトがUTF-8になるまでまだまだかかると思うよ。
> UTF-8以外を使う人間はごく短期間で絶滅寸前になるような気もするので、
> これから本当にそれほどまでの対応が必要なのかという疑問がいつもある。
で、その時にはデータ移行しないといけないんだ。
また、すでにあるWebデータは多分そのままだよ
- 312 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 20:49:53 ]
- > そもそも「日本語処理が得意」って言い方からして曖昧すぎる
> どうすれば得意だと言えるんだ？
とりあえず8bitの文字列が通れば「得意」って言っていいんじゃないの。
> たとえばruby1.8のように、あまり難しいこと考えずにエンコーディングを扱えるのが良いのか？
Ruby 1.8はエンコーディングは扱っていない、扱っているのはバイト列です。
エンコーディングを扱っているのは、Rubyでなくもっと上のレイヤーだね、jcode.rbとかはのぞいて。
> ruby1.9のように、各文字列のエンコーディングを厳密に扱えるのが良いのか？
Ruby 1.9みたいなCSIプログラミング環境ってのは他に例がきわめて少ないので、是非お試しください。
> それとも他言語のように、すべてUTF-8で統一されてるのが良いのか？
これは結構あるよね、Rubyも将来的にはUnicodeに統一する方向になっていくのかもしれん。
まぁ、少なくとも1.9ではCSIのまま突っ走るはずなのでご安心ください。
> やっぱりRuby使ったことない人が書いてるだけなんじゃないか、と疑いたくもなる
Rubyを使ったことがないか、Rubyよりはるかに悲惨な環境での経験が長いかの二択だろうね。
- 313 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 20:51:08 ]
- > ShiftJIS というか CP932（相当）で作ったファイルがもれなく UTF-8（と共通で決まったもの） で表現できるなら
> そりゃ移行はもうあっさり済むと思うんだが
> 実際はそうではないわけで
>>281 一応理論上はもれなく表現可能だよ、最近はテーブルも統一されてきたし。
ただ、とりあえずWindowsがロケールをUTF-8に移行しないうちは無理でしょうね。
> 漏れなくは無理でも、実際に数えてみたら無視出来る程度の数だったりしてな。
> 大体、それこそMSお得意の「コードページの切り替え（バグ込み込み）」で
> 対応できるんじゃねーのとか。
>>283 1文字でもあれば普通は移行不可能だと考えるべきでしょう。
まぁ、一応一度片道切符で移行するだけなら、先述の通り大丈夫。
> ファイルそのものにファイルのエンコーディング情報を含めなかったのが間違いの元
> Macと違って
Joelが言ってたけど、plain textはplainじゃないんだよね、外部からエンコーディングを指定しないと。
まぁ、外部からのエンコーディング指定がまたそれはそれで腐ってたりするんだけど。
- 314 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 20:54:41 ]
- > マクはいろいろ問題が。
Macは「ごかんせい？なにそれ？おいしいの？」だからなぁ、MacJapanese仕様変わりすぎ。
> UTF-8だと日本語が1文字3バイトになるから嫌だと言って譲らない人が稀にいるけど、
もうそんな時代錯誤な人いないよね？オレオレUTFとかやめてよ、ほんとに。
> で、今回問題となってるiconvですが、
> Nokogiriの公式のWindows向けgemパッケージに同梱されてるiconv.dllなんですよね。
> つまりWindowsでgem install nokogiriしたときに標準で使われるものがこの状態という。
> > 一番丸く収まる対処としては公式にお願いして同梱するiconvを変えてもらうとかそんなところでしょうか。
>>288 ライブラリとしてマルチプラットフォームで使えるiconvは今のところGNU libiconvしかないと思う。
しかし、GNU libiconvはメンテナがDQNなせいで、MS系エンコーディングを整理するパッチが取り込まれていない。
ので、パッケージやバイナリの配布者が別にパッチをあてる必要がある。
例えばFreeBSDのportsはlibiconvが入っているのだが、これには森山さんのパッチが当てられてる。
ので、同様なことをしてもらえばいいんだけど……。
- 315 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 21:04:24 ]
- >>312
CSIは仕様？それとも実装依存？
- 316 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 21:26:15 ]
- >>314
DQNというより問題点が理解されてないんでは?
- 317 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 21:50:32 ]
- > 現状、Mechanize経由で使ったりする分には、
> コンテンツ取得後にレスポンスボディをNKFでUTF-8に変換して差し替えて
それよりはCP932に差し替えた方がいいのでは
> >>289
> 文字コード変換はJavaとかPerlとかがまあ道を切り開いてはくれてるけど
> Javaの文字コード周りの大変さとか、
> Perlが4から5へ上がったときに配布サイズが膨れ上がった原因の大半が
> 文字コード変換テーブルのせいだった、とか考えると
> Rubyでやるべきかどうか、ってのは悩ましいな。
彼らは大変だったのでしょうねぇ、先人の苦労には頭が下がります。。
まぁ、彼らが残したShift_JIS変換テーブルみたいなゴミに苦労もしてたりするんですけど。
> 特にRubyはCSIで頑張るつもりなわけで、より大変な道だし。
まぁ、CSIだと変換表を用意しないって技もあったりするんですよ。
> 今の iconv の CP932 は WINDOWS-31J と全く同じだから
実装依存です。
> あと、Ubuntu にインストールされている iconv は非公式パッチが入ったものだ
Ubuntu は glibc iconvで、libiconvとは別物ですね。
glibc iconvには森山さんのパッチが取り込まれています。
> CP932→UTF-8自体は、記号の意味上はともかく文字の見掛けの形だけは大丈夫だったはず
> 逆は不可だが
意味的にも大丈夫ですよ、問題が出るのはShift_JISと混ぜた時の話。
- 318 名前：デフォルトの名無しさん mailto:sage [2009/07/23(木) 21:54:49 ]
- > UNICODEってあほなの？
> 文字コード統一するどころか
> 種類増やしてさらに面倒にしただけじゃないの？
UnicodeがなかったらJIS X 0213対応とかで確実に大惨事になってた。
UnicodeのおかげでShift_JISX0213とかを無視することが出来た、すばらしい。
> 日本国内の文字コードも統一できない民族よりはマシ
別にSJIS<->EUC<->JISは計算の問題だからたいしたことはないのさ。
> 毛沢東の文化大破壊みたいな歴史的事件でも起こさない限り統一は無理だろ
まぁ、順次UTF-8に移っていくとは思うよ、やっぱりよくできたエンコーディングだし。
バイト列として扱う時の事を考えてよく設計されてるよ。
> >>301
> 必要に応じてうだうだ追加してきただけの既存規格が
> もうそんなに文化的なものになってるのかｗ
>>304 と同意見で、場当たり的拡張の積み重ねこそが、取り決めを文化にするんだと思いますよ。
> >> 315 CSIは仕様？それとも実装依存？
Ruby 1.9はCSIが仕様なので、MacRubyとかはCSIなはずです、Rubyレイヤでは。
> >>316
> >314
> DQNというより問題点が理解されてないんでは?
www2d.biglobe.ne.jp/~msyk/cgi-bin/charcode/bbs.cgi?c=gr&n=416
とかをはじめとして、なんどもコンタクトは取っているようなので、
たぶんあまりのカオスっぷりにびびってデジュールの気持ちよい世界に逃げたんだと思っています。
Safari/Webkitとかもそう言う傾向があるので、海外だと一定存在するかな。
まぁ、勘違い・偏見である可能性を否定はしませんけど。
- 319 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 01:02:58 ]
- 本家に取り込んでください
www.moongift.jp/2009/07/ruby-php/#more-16888
- 320 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 01:30:24 ]
- >>319
勘弁してくれ。
- 321 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 01:34:01 ]
- LTネタだって知らないと本気の拡張に見えそうだな。
- 322 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 08:43:00 ]
- >>317
>> 現状、Mechanize経由で使ったりする分には、
>> コンテンツ取得後にレスポンスボディをNKFでUTF-8に変換して差し替えて
>それよりはCP932に差し替えた方がいいのでは
コンテンツのcharsetが予測できない場合だとどれかに決め打つことになるわけですが、
その場合だと文字集合的に一番広いUnicodeにせざるをえないかと。
この場合でもNKFで対応できないコードが入ってくればアウトなのでまあ、
実用上そうそう困らなくてそれなりに楽、って程度の話ではありますが。
>>318
>まぁ、順次UTF-8に移っていくとは思うよ、やっぱりよくできたエンコーディングだし。
>バイト列として扱う時の事を考えてよく設計されてるよ。
ですね。
ASCIIがそのまま通って、かつファイルシステムクリーンというのは素晴らしい。
- 323 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 08:53:01 ]
- ISO-2022-JP-* みたいなイビツなシロモノがスタンダードにならなくて本当に良かったわ
「Unicodeでは全ての文字を含められない」ってのが理由だったがぶっちゃけどうでもいいし
- 324 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 09:09:25 ]
- 新しい文字は放っておいても生まれる。絵文字とか。
というわけで、 UTF-8 系列をとりあえずの基盤として受け入れたのはたぶん結果的にはマシ。
- 325 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 09:11:43 ]
- 余裕をもってUCS4にしようぜ
- 326 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 09:28:58 ]
- >>324
その割にはサロゲート対応だの、4バイトまでだの、
なかなか中途半端な現状だけどな
UTF-16ってのが諸悪の根元か？
- 327 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 09:39:34 ]
- UTF-8 は尖兵
ユニコードとやらも意外と悪くないではないかとか思わせるために敢えて本筋を剥いだ草
- 328 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 09:48:30 ]
- I'm perfect soldier.
- 329 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 09:49:35 ]
- 草とか言うな(w
気がついたら UTF-8 ファイルと UTF-8 アプリケーションばっかで
他のエンコーディング系列に移行できなとかそんなのか
- 330 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 09:59:43 ]
- 最強の尖兵乙
- 331 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 11:03:52 ]
- >>321
最初からRejectKaigiを狙ってたんじゃないのか?
- 332 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 11:45:19 ]
- あああ、LTじゃなくてRejectKaigiか。
- 333 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 01:02:24 ]
- rubyってjisちゃんと扱えないのか。苦労するはずだわ。
ruby捨ててjavaでがんばる。
- 334 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 01:06:25 ]
- > rubyってjisちゃんと扱えないのか。苦労するはずだわ。
何の話をしてるの？
- 335 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 01:10:08 ]
- > 余裕をもってUCS4にしようぜ
UCS-4も最新のISOでは0x10FFFFまでしか文字を定義しないことになったよ。
> その割にはサロゲート対応だの、4バイトまでだの、なかなか中途半端な現状だけどな
サロゲートペアはUTF-16の話で、UTF-8にはあまり。4バイトまでなのは困らないでしょ。
> UTF-16ってのが諸悪の根元か？
本質的にはUCS-2が根源かな。
> UTF-8 は尖兵
UTF-8が最終形じゃないかな、UCS-2やUTF-16の方がむしろpreview。
- 336 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 01:11:42 ]
- 一文字64bitの新文字コード作ろうぜ
- 337 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 01:24:59 ]
- >>335
そこが今ひとつわからんのだが、31bitあったのを21bit？にしたのは、
なにか技術的な要請があったの？
それとも、先行したUCS2に引きずられただけ？
256*256*17面（だっけ）にしたのは、どういうことなんだろう。
- 338 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 03:13:11 ]
- >>337
まず、31bitだったのはsigned int32ね。
0x10FFFFまでなのは、UTF-16の収録限界が由来で、
BMPの0xFFFF+サロゲートペアの(0xDC00-0xD800)*(0xE000-0xDC00)だから
- 339 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 06:35:23 ]
- そもそもUnicode自体がクソだろ
文字鏡をつかっていればあるいわ
- 340 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 07:24:13 ]
- 現実的にUnicodeより良い物があるの？
- 341 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 09:45:27 ]
- Unicode一本化されたとこから漸次さらに優れたものに移行すればいいじゃん
カオス状態がUnicodeのおかげでずいぶんましになってる所なのに
- 342 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 11:29:26 ]
- Rubyスレなのに気付いたらUnicodeの話になってた!
- 343 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 11:30:10 ]
- 文字コードの話はなぜか妙に食いつきがいい
- 344 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 11:35:23 ]
- 開発コアメンバが語るRubyの今とこれから（前編）
www.atmarkit.co.jp/news/200907/24/ruby.html
そろそろ1.8系から1.9に移るころなのかな？
- 345 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 12:35:10 ]
- >>341
Unicodeがある意味全てを終わらせてしまったので、
優れたものが出てくる余地はない。
Unicodeが優れたものなんじゃなくて、悪貨は良貨を駆逐するという意味で。
- 346 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 12:46:51 ]
- 日本の3つの文字コードへの対応ライブラリパッチのファイルサイズ見れば、色々間違いだと思えるようになるよ
>>344
なんでこう、ちょっとカッコいいポーズしてください写真なん？
や、写真使うのは取材側の人だから要望聞いたほうがいいんだけどさ
Ruby1.9 に移行するのは絶対に間違いない
問題は、そのためのライブラリサポートの手間をいつ誰が取るかだと思う
外国の人はいろんな意味で慎重な移行をやりたがらないと思うんで、
それこそマルチバイトユーザーで最大Rubyコミュニティである日本人の出番なのではないかと
英語のライブラリ作者向けガイド書いた人がどっかにいたが、ああいうの頑張るべきかもしれない
- 347 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 12:50:53 ]
- 弾子飼かと思った
- 348 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 12:55:37 ]
- とりあえず rubyrb1.9 test/ で Ruby1.9 対応完了とかほざく外人作者さんの調教から
古い rubygem でしか動かないライブラリが捨てられていくのと同じように、
Ruby 1.9 で実際上動作しないライブラリが捨てられていくようになればいいんだけど
- 349 名前：デフォルトの名無しさん [2009/07/25(土) 13:11:14 ]
- Railsが1.9でまともに動けば移行が進むんじゃね。
- 350 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 14:20:13 ]
- つまり asakusa.rb 期待 age?
- 351 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 19:38:39 ]
- >>344
記事内容とはまったく関係ないし、たぶん写真写りのせいだと思うんだが
2枚目の写真のYugui氏が怖い
- 352 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 19:39:58 ]
- UTFが、8859と互換なのが大きいからなあ。日本人が使えないって騒いだって、欧米圏は、もう他に移行はしないだろう。
- 353 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 19:48:08 ]
- >>344
率直に言って恥ずかしいな
写真が気になって記事が頭に入らない
- 354 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 19:49:35 ]
- >>352
使えるのに使いたくないって騒いでるだけじゃないかと
- 355 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 19:54:58 ]
- >>351
全てがマイナスに働いている、ある意味レア写真
著者近影に使ったら書籍自体が山積みでお祓いに出されるレベル
もうちょっちいいのなかったんかね
|
 |
