[#40528] [Feature #2833] 絵文字エンコーディングの提案 — Kenta Murata <redmine@...>

Feature #2833: 絵文字エンコーディングの提案

32 messages 2010/03/02
[#40530] Re: [Feature #2833] 絵文字エンコーディングの提案 — Yukihiro Matsumoto <matz@...> 2010/03/02

まつもと ゆきひろです

[#40597] Re: [ruby-list:46898] 重複組合せは組込みにならないのでしょうか? — "KISHIMOTO, Makoto" <ksmakoto@...4u.or.jp>

きしもとです

17 messages 2010/03/12
[#40598] Re: [ruby-list:46898] 重複組合せは組込みにならないのでしょうか? — Yukihiro Matsumoto <matz@...> 2010/03/12

まつもと ゆきひろです

[#40601] Re: [ruby-list:46898] 重複組合せは組込みにならないのでしょうか? — Yusuke ENDOH <mame@...> 2010/03/12

遠藤です。

[#40608] Re: 組込みの重複順列・重複組合せ — "KISHIMOTO, Makoto" <ksmakoto@...4u.or.jp> 2010/03/13

> 同様に、repeated_permutation/combination のデフォルト引数にも反対

[#40610] Re: 組込みの重複順列・重複組合せ — Yukihiro Matsumoto <matz@...> 2010/03/13

まつもと ゆきひろです

[#40641] [Bug #2965] method `===' called on hidden T_STRING object (NotImplementedError) — Kenta Murata <redmine@...>

Bug #2965: method `===' called on hidden T_STRING object (NotImplementedError)

12 messages 2010/03/15

[#40649] [Feature #2968] 数値の正負を返すメソッド — Yui NARUSE <redmine@...>

Feature #2968: 数値の正負を返すメソッド

17 messages 2010/03/15

[#40650] [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — Yui NARUSE <redmine@...>

Feature #2969: String#to_f が -h.hhh±pd を解釈できるように

38 messages 2010/03/15
[#40728] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — Tadayoshi Funaba <tadf@...> 2010/03/22

質問ですが、この形式は入力だけでなく、なんらかの方法で出力でも利用でき

[#40732] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — "NARUSE, Yui" <naruse@...> 2010/03/22

成瀬です。

[#40736] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — Tadayoshi Funaba <tadf@...> 2010/03/23

> String#to_f は従来から指数表記を許していたので、

[#40738] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — "NARUSE, Yui" <naruse@...> 2010/03/23

成瀬です。

[#40745] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — Tadayoshi Funaba <tadf@...> 2010/03/24

> to_i がデフォルトで prefix を見ないのは、0377 のような、

[#40747] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — "NARUSE, Yui" <naruse@...> 2010/03/24

成瀬です。

[#40749] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — Tadayoshi Funaba <tadf@...> 2010/03/24

> 先のパッチの対象関数が ruby_strtod である通り、

[#40759] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — "NARUSE, Yui" <naruse@...> 2010/03/25

成瀬です。

[#40762] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — Tadayoshi Funaba <tadf@...> 2010/03/25

> strtod(3) の解釈対象に含まれていない 2 進や 8 進を否定することが、

[#40763] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — "NARUSE, Yui" <naruse@...> 2010/03/25

(2010/03/26 3:05), Tadayoshi Funaba wrote:

[#40764] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — Tadayoshi Funaba <tadf@...> 2010/03/25

> なぜ同じなのでしょう。

[#40782] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — "NARUSE, Yui" <naruse@...> 2010/03/26

(2010/03/26 4:02), Tadayoshi Funaba wrote:

[#40786] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — KOSAKI Motohiro <kosaki.motohiro@...> 2010/03/27

>> strtod(3) を参考にしたり、影響されたりすることは普通にあるとは思います

[#40788] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — "NARUSE, Yui" <naruse@...> 2010/03/27

(2010/03/27 18:19), KOSAKI Motohiro wrote:

[#40695] keiju, please check tickets assigned to you — Yusuke ENDOH <mame@...>

いしつかさん

15 messages 2010/03/18

[#40779] [Feature #3018] UNINITIALIZED_VAR() マクロの導入 — Motohiro KOSAKI <redmine@...>

Feature #3018: UNINITIALIZED_VAR() マクロの導入

12 messages 2010/03/26

[#40805] Improvement of Fiber switching cost with system dependent way — SASADA Koichi <ko1@...>

 ささだです.

10 messages 2010/03/28

[ruby-dev:40560] Re: [Feature #2833] 絵文字エンコーディングの提案

From: "NARUSE, Yui" <naruse@...>
Date: 2010-03-04 13:45:57 UTC
List: ruby-dev #40560
成瀬です。

(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>

In This Thread