[#40528] [Feature #2833] 絵文字エンコーディングの提案 — Kenta Murata <redmine@...>
Feature #2833: 絵文字エンコーディングの提案
まつもと ゆきひろです
=1B$B$`$i$?$G$9!#=1B(B
GyRCOjQhOUxaJEg/PSQ3JF4kOSEjGyhCCgpSYWlscxskQiROGyhCanBtb2JpbGUbJEIkSCQkJCYl
チケット #2833 が更新されました。 (by Yui NARUSE)
=1B$B$`$i$?$G$9!#=1B(B
遠藤です。
遠藤です。
> Feature #2833: 絵文字エンコーディングの提案
[#40573] [bug:1.8] ossl_ssl_session.c:110: warning: implicit declaration of function 'TIMET2NUM' — Tanaka Akira <akr@...>
Ruby 1.8 で、以下の警告が増えています。
2010/3/7 Tanaka Akira <akr@fsij.org>:
[#40597] Re: [ruby-list:46898] 重複組合せは組込みにならないのでしょうか? — "KISHIMOTO, Makoto" <ksmakoto@...4u.or.jp>
きしもとです
まつもと ゆきひろです
遠藤です。
> 同様に、repeated_permutation/combination のデフォルト引数にも反対
まつもと ゆきひろです
[#40614] [Bug #2956] segfault — Tomoki MAEDA <redmine@...>
Bug #2956: segfault
[#40623] Enumerable#interleave — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
2010年3月13日22:44 Yukihiro Matsumoto <matz@ruby-lang.org>:
まつもと ゆきひろです
2010年3月14日0:04 Yukihiro Matsumoto <matz@ruby-lang.org>:
まつもと ゆきひろです
[#40641] [Bug #2965] method `===' called on hidden T_STRING object (NotImplementedError) — Kenta Murata <redmine@...>
Bug #2965: method `===' called on hidden T_STRING object (NotImplementedError)
チケット #2965 が更新されました。 (by Shyouhei Urabe)
[#40643] draft of 1.9.2 release schedule — Yusuke ENDOH <mame@...>
Yugui さん、
[#40649] [Feature #2968] 数値の正負を返すメソッド — Yui NARUSE <redmine@...>
Feature #2968: 数値の正負を返すメソッド
チケット #2968 が更新されました。 (by Yui NARUSE)
> チケット #2968 が更新されました。 (by Yui NARUSE)
成瀬です。
> 成瀬です。
[#40650] [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — Yui NARUSE <redmine@...>
Feature #2969: String#to_f が -h.hhh±pd を解釈できるように
質問ですが、この形式は入力だけでなく、なんらかの方法で出力でも利用でき
成瀬です。
> String#to_f は従来から指数表記を許していたので、
成瀬です。
> to_i がデフォルトで prefix を見ないのは、0377 のような、
成瀬です。
> 先のパッチの対象関数が ruby_strtod である通り、
成瀬です。
> strtod(3) の解釈対象に含まれていない 2 進や 8 進を否定することが、
(2010/03/26 3:05), Tadayoshi Funaba wrote:
> なぜ同じなのでしょう。
(2010/03/26 4:02), Tadayoshi Funaba wrote:
>> strtod(3) を参考にしたり、影響されたりすることは普通にあるとは思います
(2010/03/27 18:19), KOSAKI Motohiro wrote:
えぐち@エスアンドイーです
(2010/03/27 20:26), EGUCHI Osamu wrote:
> つまり、ふなばさんは 16 進よりも 2 進や 8 進形式が好みであるところ、
まつもと ゆきひろです
[#40672] URI methods for application/x-www-form-urlencoded — Tanaka Akira <akr@...>
最近、成瀬さんが追加した URI.encode_www_form など、
[#40695] keiju, please check tickets assigned to you — Yusuke ENDOH <mame@...>
いしつかさん
けいじゅ@いしつかです.
いしつかさん
けいじゅ@いしつかです.
遠藤です。
[#40735] [Bug #2995] TestHash#test_recursive_check fails — Shugo Maeda <redmine@...>
Bug #2995: TestHash#test_recursive_check fails
[#40746] [Bug #1031] -U オプションの説明が --help にない — Yusuke Endoh <redmine@...>
チケット #1031 が更新されました。 (by Yusuke Endoh)
前田です。
[#40779] [Feature #3018] UNINITIALIZED_VAR() マクロの導入 — Motohiro KOSAKI <redmine@...>
Feature #3018: UNINITIALIZED_VAR() マクロの導入
まつもと ゆきひろです
> |Linuxではこの問題にたいして以下のようなマクロで解決しており、同様の手法を導入したいと
まつもと ゆきひろです
本題じゃないですが、
[#40805] Improvement of Fiber switching cost with system dependent way — SASADA Koichi <ko1@...>
ささだです.
こんにちは、なかむら(う)です。
[#40832] Process.daemon() returns -1 on failure ifndef HAVE_DAEMON — "Akinori MUSHA" <knu@...>
Process.daemon() 失敗時の挙動が、 HAVE_DAEMON 定義時と非定義時
2010年3月29日19:52 Akinori MUSHA <knu@idaemons.org>:
> 2010年3月29日19:52 Akinori MUSHA <knu@idaemons.org>:
[#40833] [Bug: trunk] Fiber transfer limitation — SASADA Koichi <ko1@...>
ささだです.
[#40855] revert 1.9 \w limitation to ASCII — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
[#40884] [Feature #3065] [TypedData] という名前について — Tadashi Saito <redmine@...>
Feature #3065: [TypedData] という名前について
[ruby-dev:40560] Re: [Feature #2833] 絵文字エンコーディングの提案
成瀬です。 (2010/03/04 13:29), takeru sasaki wrote: >> まず、「文字コードの変換」というのはわたしはバイト列同士の変換だと考えています。 >> つまり、バイト単位で読み込み、判定し、別のバイト列に変えるのが文字コード変換のレイヤです。 >> 一方、そのニーズは文字単位で差し替えたいという話なのですから、レイヤが違うのではないでしょうか。 > > emoji4unicodeも文字単位で置き換えているように見えるのですが違うのでしょうか? >> この置換法則は emoji4unicode の成果物である >> http://www.unicode.org/~scherer/emoji4unicode/snapshot/full.html >> この表で定義されているものが一般的なんだと思っています。 > 明らかに「絵」が違うけど「同じこと/もの」を指しているっぽいから文字単位で置き換えましょう、 > という仕様だとおもうのです。 その変換は変換元と文字集合が違いますから。 >> 思うに、そのニーズで真に正しい対処は変換表に手をいれることではなく、 >> DBに保存する前の UTF-8 などの段階でどれかの絵文字に揃える正規化をかけるか、 >> それぞれの端末向けの文字コードに変換にしたあとで、独自の正規化をかけるのが正解でしょう。 > > 要件次第なのですが、「どれかの絵文字に揃える正規化」をしてしまうと、掲示板に書き込んだ自分の > コメントの中の絵文字が入力したものと違う絵文字で表示されたりします。GoogleのUTF8ではこれは > 起こらなかったはずです。 > > 「それぞれの端末向けの文字コードに変換にしたあとで、独自の正規化」をしようとしてもGoogleの変換 > を使ってしまった時点で元の絵文字が「どのキャリアのどの絵文字」だったかがわからなくてどうにも > ならなくて困ったりもします。 変換を使っても、変換途中なら元がどのキャリアかまではわかりますよね。 で、原規格分離 (ソース分離) されていれば、どの絵文字かまで理屈としては特定可能なはずです。 ちょっと考えた限りでは、「どうにもならない」事にはならないと思います。 なるケースがあったら考え直すので教えてください。 > 実はjpmobileの「softbankを0x1000ずらす方式」はGoogleのUTF8よりも良い点があります。 > GoogleのUTF8に1度変換してしまうと入力元のキャリアが何であったかがわからなくなってしまう > のですが、jpmobileの方式だと元キャリアはコードの範囲からわかるのです。 > 情報(=元キャリア)の欠落がありません。 で、この主張は想定していました。 まとめると、 UTF-8 でもどのキャリアかわかればどの絵文字だったかわかる UTF8-Google だと、もとがケータイ絵文字だったか、PCからの入力か区別できる jpmobile 方式だと、単体でどのキャリアのどの絵文字だったかわかる と、考えると、UTF8-Google は中途半端な気がするんですよね。 PC からの「晴れ」マークと、絵文字からの「晴れ」が混同されるのは、 正しいのか意図しない挙動なのか、とかちょっと迷う所。 まぁ、この辺は将来の携帯電話が U+2600 とユーザ定義エリアの「晴れ」を別々に 送って来ない限り対処は可能なので……。 -- NARUSE, Yui <naruse@airemix.jp>