Ruby » ruby-trunk

まつもと ゆきひろです

In message "Re: [ruby-dev:40528] [Feature #2833] 	絵文字エンコーディングの提案"
    on Tue, 2 Mar 2010 23:00:31 +0900, Kenta Murata <redmine@ruby-lang.org> writes:

|絵文字に対応したエンコーディングを実装しました。
|これらを 1.9.2 のリリース前に trunk にマージすることを提案します。
|redmine のチケットにパッチを添付しました。
|
|このパッチは以下のエンコーディングを実装しています。

エンコーディングを追加することに反対しません。

|そして、これらのエンコーディング間における fallback なしの
|相互変換を行うための transcoder も実装しています。
|
|fallback とは、変換先エンコーディングに対応絵文字が存在しない場合に、
|たとえば "[稲穂]" のようなテキストへ変換する処理をいいます。
|実用上 fallback 処理をカスタマイズ可能な機構が必要ではありますが、
|現在の構成でも Encoding::Converter#primitive_convert を用いて対応可能です。

このfallbackあり/なしの変換についてもう少し解説していただけ
ませんか？

成瀬さんに github で変更点を閲覧できる方法を教えてもらいました。

http://github.com/mrkn/ruby/compare/trunk...emoji

• Shift_JIS-* は SJIS-* にすべき http://home.m05.itscom.net/numa/cde/sjis-euc/sjis-euc.html
• x-emoji.c にそれぞれの encoding の出典へのリンクが欲しいです http://github.com/ruby/ruby/blob/trunk/enc/shift_jis.c みたいな感じで

他はよいと思います。
まつもとさんと Martin さんが OK を出したらコミットしてください

むらたです。

On 2010/03/02, at 23:12, Yukihiro Matsumoto wrote:

> |絵文字に対応したエンコーディングを実装しました。
> |これらを 1.9.2 のリリース前に trunk にマージすることを提案します。
> |redmine のチケットにパッチを添付しました。
> |
> |このパッチは以下のエンコーディングを実装しています。
> 
> エンコーディングを追加することに反対しません。

ありがとうございます。

> |そして、これらのエンコーディング間における fallback なしの
> |相互変換を行うための transcoder も実装しています。
> |
> |fallback とは、変換先エンコーディングに対応絵文字が存在しない場合に、
> |たとえば "[稲穂]" のようなテキストへ変換する処理をいいます。
> |実用上 fallback 処理をカスタマイズ可能な機構が必要ではありますが、
> |現在の構成でも Encoding::Converter#primitive_convert を用いて対応可能です。
> 
> このfallbackあり/なしの変換についてもう少し解説していただけ
> ませんか？

現在の実装では、例えば DoCoMo 用エンコーディングのみで定義されている
絵文字を含む文字列を KDDI 用エンコーディングへ変換しようとすると、
KDDI 用エンコーディングで未定義の文字で Encoding::UndefinedConversionError
が発生するようにしています。
これが、fallback なしの変換です。

fallback ありの場合は、例えば DoCoMo だけで定義されている "\u{E6AD}" (ふくろの絵文字)
を KDDI や SoftBank 用のエンコーディングへ変換するときに、
代わりの絵文字で代替させたり "[ふくろ]" のようなテキストで置き換えたりします。

この置換法則は emoji4unicode の成果物である
http://www.unicode.org/~scherer/emoji4unicode/snapshot/full.html
この表で定義されているものが一般的なんだと思っています。
これが一般的であるという考えは私の推測なので、
実際のところは携帯アプリケーションの開発経験をお持ちの方々に伺いたいです。

以下のような fallback つきのコンバータを標準で提供しておけば、
個々のニーズについては fallback 変換表を gem で配布してもらうだけ
済むかもしれません。

# lib/encoding/fallbacking_converter.rb
class Encoding
  class FallbackingConverter < Converter
    def initialize(senc, denc, ftab, *opts)
      super(senc, denc, *opts)
      unless ftab.respond_to? :[]
        raise TypeError, "fallback table should have [] method"
      end
      @fallback_table = ftab
    end

    def fallbacking_convert(src)
      senc = self.source_encoding
      dst = ''
      while true
        case self.primitive_convert(src, dst)
        when :invalid_byte_sequence
          raise InvalidByteSequenceError
        when :undefined_conversion
          undef_char = self.primitive_errinfo[3].force_encoding(senc)
          if fallback = @fallback_table[undef_char]
            self.insert_output(fallback)
          else
            raise UndefinedConversionError
          end
        else
          break
        end
      end
      return dst
    end
  end
end

# 使用例としてのテストケース
class TestFallback < Test::Unit::TestCase
  def setup
    @utf8_docomo = utf8_docomo("\u{E6AD}")
    @utf8_fallbacked_kddi = utf8_kddi("[\u{3075}\u{304f}\u{308d}]") # [ふくろ]
    @converter = Encoding::FallbackingConverter.new(
      "UTF8-DoCoMo", "UTF8-KDDI",
      @utf8_docomo => @utf8_fallbacked_kddi
    )
  end

  def test_fallbacking_convert_for_non_emoji
    assert_equal utf8_kddi("\u{3075}"), @converter.fallbacking_convert(utf8_docomo("\u{3075}"))
  end

  def test_fallbacking_convert_for_emoji
    assert_equal @utf8_fallbacked_kddi, @converter.fallbacking_convert(@utf8_docomo)
  end
end

--
Kenta Murata
OpenPGP FP = FA26 35D7 4F98 3498 0810 E0D5 F213 966F E9EB 0BCC

本を書きました!!
『Ruby 逆引きレシピ』 http://www.amazon.co.jp/dp/4798119881/mrkn-22

E-mail: mrkn@mrkn.jp
twitter: http://twitter.com/mrkn/
blog: http://d.hatena.ne.jp/mrkn/

むらたです。

テストケースに不備がありました。申し訳ありません。

On 2010/03/03, at 2:23, Kenta Murata wrote:

> # 使用例としてのテストケース
> class TestFallback < Test::Unit::TestCase
>  def setup
>    @utf8_docomo = utf8_docomo("\u{E6AD}")
>    @utf8_fallbacked_kddi = utf8_kddi("[\u{3075}\u{304f}\u{308d}]") # [ふくろ]
>    @converter = Encoding::FallbackingConverter.new(
>      "UTF8-DoCoMo", "UTF8-KDDI",
>      @utf8_docomo => @utf8_fallbacked_kddi
>    )
>  end
> 
>  def test_fallbacking_convert_for_non_emoji
>    assert_equal utf8_kddi("\u{3075}"), @converter.fallbacking_convert(utf8_docomo("\u{3075}"))
>  end
> 
>  def test_fallbacking_convert_for_emoji
>    assert_equal @utf8_fallbacked_kddi, @converter.fallbacking_convert(@utf8_docomo)
>  end

  def utf8_docomo(str)
    str.force_encoding("UTF8-DoCoMo")
  end

  def utf8_kddi(str)
    str.force_encoding("UTF8-KDDI")
  end

> end


上記2メソッドが足りてません。

--
Kenta Murata
OpenPGP FP = FA26 35D7 4F98 3498 0810 E0D5 F213 966F E9EB 0BCC

本を書きました!!
『Ruby 逆引きレシピ』 http://www.amazon.co.jp/dp/4798119881/mrkn-22

E-mail: mrkn@mrkn.jp
twitter: http://twitter.com/mrkn/
blog: http://d.hatena.ne.jp/mrkn/

まつもと ゆきひろです

In message "Re: [ruby-dev:40533] Re: [Feature #2833] 	絵文字エンコーディングの提案"
    on Wed, 3 Mar 2010 02:23:06 +0900, Kenta Murata <muraken@gmail.com> writes:

|> このfallbackあり/なしの変換についてもう少し解説していただけ
|> ませんか？
|
|現在の実装では、例えば DoCoMo 用エンコーディングのみで定義されている
|絵文字を含む文字列を KDDI 用エンコーディングへ変換しようとすると、
|KDDI 用エンコーディングで未定義の文字で Encoding::UndefinedConversionError
|が発生するようにしています。
|これが、fallback なしの変換です。

理解しました。

|fallback ありの場合は、例えば DoCoMo だけで定義されている "\u{E6AD}" (ふくろの絵文字)
|を KDDI や SoftBank 用のエンコーディングへ変換するときに、
|代わりの絵文字で代替させたり "[ふくろ]" のようなテキストで置き換えたりします。

fallbackあり/なしの変換で行うことの違いは理解しました。具体
的な変換を行うコードは、それぞれどのようになりますでしょうか。

|以下のような fallback つきのコンバータを標準で提供しておけば、
|個々のニーズについては fallback 変換表を gem で配布してもらうだけ
|済むかもしれません。

よい考えかもしれませんね。

むらたです。

On 2010/03/03, at 4:15, Yukihiro Matsumoto wrote:

> |fallback ありの場合は、例えば DoCoMo だけで定義されている "\u{E6AD}" (ふくろの絵文字)
> |を KDDI や SoftBank 用のエンコーディングへ変換するときに、
> |代わりの絵文字で代替させたり "[ふくろ]" のようなテキストで置き換えたりします。
> 
> fallbackあり/なしの変換で行うことの違いは理解しました。具体
> 的な変換を行うコードは、それぞれどのようになりますでしょうか。

fallback しない変換は String#encode を使う方法が最も簡単で、
通常通り次のようなコードになります。

  kddi = str.encode("UTF8-KDDI")

この方法では、ソース文字列が valid であれば次の変換が例外なしで実行可能です。

  UTF8-DoCoMo -> UTF8-Google
  UTF8-KDDI -> UTF8-Google
  UTF8-SoftBank -> UTF8-Google
  UTF8-DoCoMo <-> SJIS-DoCoMo
  UTF8-KDDI <-> SJIS-KDDI
  UTF8-KDDI <-> ISO-2022-JP-KDDI
  SJIS-KDDI <-> ISO-2022-JP-KDDI
  UTF8-SoftBank <-> SJIS-SoftBank

つまり、Google 以外の企業から Google への変換、および、同一企業内の相互変換が
例外なしで実行できます。

上記以外の方向の変換では、前回のメールに書いた通り Encoding::UndefinedConversionError
を rescue することで未定義絵文字の混入を発見することが可能です。



fallback を行う変換は、Encoding::Converter#primitive_convert を使って
例外が起きるケースを詳細に扱う方法が最も適切です。
そのコードは前回のメールで示した FallbackingConverter#fallbacking_convert
を参照してください。

これらに加えて、String#gsub を使って未定義絵文字を fallback してから
String#encode を使う方法も考えられます。例えば DoCoMo のふくろの絵文字を
"[ふくろ]" に置き換えてから UTF8-KDDI へ変換するなら

  str.gsub(/\u{E6AD}/, "[ふくろ]").encode("UTF8-KDDI")

こういうコードで実現できます。

--
Kenta Murata
OpenPGP FP = FA26 35D7 4F98 3498 0810 E0D5 F213 966F E9EB 0BCC

本を書きました!!
『Ruby 逆引きレシピ』 http://www.amazon.co.jp/dp/4798119881/mrkn-22

E-mail: mrkn@mrkn.jp
twitter: http://twitter.com/mrkn/
blog: http://d.hatena.ne.jp/mrkn/

むらたです。

On 2010/03/03, at 8:48, KOSAKI Motohiro wrote:

>> - Shift_JIS-DoCoMo
>> - Shift_JIS-KDDI
>> - ISO-2022-JP-KDDI
>> - Shift_JIS-SoftBank
> 
> この４つは直感的に理解出来るとして
> 
>> - UTF8-Google
> 
> これは普通のUTF-8とは違うもの？

違います。UTF8-Google は、DoCoMo, KDDI, SoftBank のそれぞれの
絵文字集合の和集合を持っており、現存する3者が持つすべての絵文字に
一意なコードポイントを割り当てています。以下の URL が対応表です。

http://www.unicode.org/~scherer/emoji4unicode/snapshot/full.html

この表の最初の行を見ると分かるように、UTF-8 と UTF8-Google では
「晴れ」を表す絵文字の扱いが異なります。
DoCoMo, KDDI, SoftBank 各社の「晴れ」絵文字を UTF-8 へ変換すると
U+2600 に変換されるため、元々絵文字であった事実が失われます。
UTF8-Google へ変換すると U+FE000 へ変換され絵文字である事実は
失われません。

>> - UTF8-DoCoMo
>> - UTF8-KDDI
>> - UTF8-SoftBank
> 
> この３つは、utf-8-macのように、utf-8に変換ルールヒントを加えたもの
> という理解でいいのでしょうか？

各 transcoder で絵文字のコードポイントに対して適切な変換結果を対応させています。

> ３社でPUAの使い方が違う？？

PUA が Private User Area の略だということは教えてもらったのですが、
「PUA の使い方」という言葉がよく分かっていません。
複数の使い方があるんでしょうか？

>> - stateless-ISO-2022-JP-KDDI
> 
> stateless iso-2022というのが、どういう状況で使うのか想像できないので
> 解説をお願いしていいですか？

これは内部で使われているだけなので、表に名前を出す必要はなかったですね。

現状では ISO-2022-JP <-> EUC-JP の変換が stateless-ISO-2022-JP を介した
変換で実現されています。stateless-ISO-2022-JP-KDDI は、
ISO-2022-JP-KDDI <-> UTF8-KDDI の変換でこれを真似したために存在しています。

> 第一印象としては、現実の汚さを反映してそれなりに使い方がやっかいなシロモノ
> になっているので、どこかにガイドアーティクルがあるとうれしいんじゃないかと
> 思いました。

なるほど、私もそう思います。達人出版会の出番ですね！

> # それを言ったら日本語コード変換は全般的に罠の宝庫なので「日本語コード変換HOWTO」
> # が必要だ。という気も若干してきますが、発散するので気づかなかったことに

私はなにも見ていません。

> とりあえず、Encodingクラスのリファレンスに加筆する予定の、エンコーディングの
> 説明を見せて頂けると、レビューしやすいです。
> きっと、コード本体については誰も反対しないんだろうし。

るりまの以下のページにある定数表のことですよね？
http://doc.okkez.net/192/view/class/Encoding

こんな感じかなぁ

--- Encoding::UTF8_DoCoMo
DoCoMo 携帯の絵文字を含む UTF-8 エンコーディングです。
絵文字のコード表は以下で公開されています。
[[url:http://www.nttdocomo.co.jp/service/imode/make/content/pictograph/basic/]]
[[url:http://www.nttdocomo.co.jp/service/imode/make/content/pictograph/extention/index.html]]

--- Encoding::UTF8_KDDI
KDDI 携帯の絵文字を含む UTF-8 エンコーディングです。
Web のフォームに入力された絵文字のコードにも対応しています。
絵文字のコード表は以下で公開されています。
[[url:http://www.au.kddi.com/ezfactory/tec/spec/img/typeD.pdf]]

--- Encoding::UTF8_SoftBank
SoftBank 携帯の絵文字を含む UTF-8 エンコーディングです。
絵文字のコード表は以下で公開されています (2つ目はユーザ登録が必要)。
[[url:http://creation.mb.softbank.jp/web/web_pic_about.html]]
[[url:http://www2.developers.softbankmobile.co.jp/dp/tool_dl/download.php?docid=120&companyid=]]

--- Encoding::UTF8_Google
DoCoMo, KDDI, SoftBank 各社の絵文字集合の和集合に含まれる各文字に対して一意なコードポイントを与えた UTF-8 亜種です。
各社の絵文字と Google のコードポイントとの対応関係は emoji4unicode プロジェクトの成果に基づいています。
[[url:http://code.google.com/p/emoji4unicode/]]

--- Encoding::SJIS_DoCoMo
DoCoMo 携帯の絵文字を含む Windows-31J の亜種です。
絵文字のコード表は以下で公開されています。
[[url:http://www.nttdocomo.co.jp/service/imode/make/content/pictograph/basic/]]
[[url:http://www.nttdocomo.co.jp/service/imode/make/content/pictograph/extention/index.html]]

--- Encoding::SJIS_KDDI
KDDI 携帯の絵文字を含む Windows-31J の亜種です。
絵文字のコード表は以下で公開されています。
[[url:http://www.au.kddi.com/ezfactory/tec/spec/img/typeD.pdf]]

--- Encoding::SJIS_SoftBank
SoftBank 携帯の絵文字を含む Windows-31J の亜種です。
絵文字のコード表は以下で公開されています (2つ目はユーザ登録が必要)。
[[url:http://creation.mb.softbank.jp/web/web_pic_about.html]]
[[url:http://www2.developers.softbankmobile.co.jp/dp/tool_dl/download.php?docid=120&companyid=]]

--- Encoding::ISO_2022_JP_KDDI
KDDI 携帯の絵文字を含む ISO-2022-JP の亜種です。
絵文字のコード表は以下で公開されています。
[[url:http://www.au.kddi.com/ezfactory/tec/spec/img/typeD.pdf]]



--
Kenta Murata
OpenPGP FP = FA26 35D7 4F98 3498 0810 E0D5 F213 966F E9EB 0BCC

本を書きました!!
『Ruby 逆引きレシピ』 http://www.amazon.co.jp/dp/4798119881/mrkn-22

E-mail: mrkn@mrkn.jp
twitter: http://twitter.com/mrkn/
blog: http://d.hatena.ne.jp/mrkn/

> 以下のような fallback つきのコンバータを標準で提供しておけば、
> 個々のニーズについては fallback 変換表を gem で配布してもらうだけ
> 済むかもしれません。

String#encode(to, from, opt) の opt[:replace] に Hash を与えられるようにして、
そこに、変換元 encoding の文字 => 変換先の文字、という未定義文字の fallback 変換表を与えられるようにする、
というものを今考えています。
これだと例えば、
fallbacks = {
  ?\uE6AD => "[ふくろ]",
  ?\u{1F4BA} => "[いす]"
}
"\u{3042 E6AD 1F4BA}".encode("UTF8-KDDI", replace: fallbacks) #=> "あ[ふくろ][いす]"

ちなみに、現状でやるならば、次のような感じでしょうか
"\u{3042 E6AD 1F4BA}".gsub(/[#{Regexp.escape(fallbacks.keys.join)}]/, fallbacks).encode("UTF8-KDDI") #=> "あ[ふくろ][いす]"

> - UTF8-DoCoMo
> - UTF8-KDDI
> - UTF8-SoftBank
> この３つは、utf-8-macのように、utf-8に変換ルールヒントを加えたもの
> という理解でいいのでしょうか？
> ３社でPUAの使い方が違う？？

UTF8-MAC ではなくて、各社の端末で現在使われている、「UTF-8」がそれらです。
つまり、文字集合としてはJIS+一部拡張+絵文字で、絵文字の割当先のPUAも異なります。
また、実際問題としても一部KDDIとSoftBankの使用領域が被っているので異なりますね。
具体的にどこになにがいるかは、以下の表で眺められます。
http://www.unicode.org/~scherer/emoji4unicode/snapshot/full.html

> > > - stateless-ISO-2022-JP-KDDI
> >
> > stateless iso-2022というのが、どういう状況で使うのか想像できないので
> > 解説をお願いしていいですか？
>
> これは内部で使われているだけなので、表に名前を出す必要はなかったですね。
>
> 現状では ISO-2022-JP <-> EUC-JP の変換が stateless-ISO-2022-JP を介した
> 変換で実現されています。stateless-ISO-2022-JP-KDDI は、
> ISO-2022-JP-KDDI <-> UTF8-KDDI の変換でこれを真似したために存在しています。

まぁ、完全に実装の都合ですね。

> なるほど、私もそう思います。達人出版会の出番ですね！

あと、るりまとかるびまとか。

> > # それを言ったら日本語コード変換は全般的に罠の宝庫なので「日本語コード変換HOWTO」
> > # が必要だ。という気も若干してきますが、発散するので気づかなかったことに
>
> 私はなにも見ていません。

「Ruby M17N の設計と実装」の改訂版で触れるつもりではあるんですが、いつになるだろう。
http://jp.rubyist.net/magazine/?0025-Ruby19_m17n#l76

> > とりあえず、Encodingクラスのリファレンスに加筆する予定の、エンコーディングの
> > 説明を見せて頂けると、レビューしやすいです。
> > きっと、コード本体については誰も反対しないんだろうし。
> >
> るりまの以下のページにある定数表のことですよね？
> http://doc.okkez.net/192/view/class/Encoding

いい指摘ですね、たぶんるりまじゃなくて rdoc の話なんじゃないでしょうか。
で、今、Encoding クラスの rdoc ってありませんね。
すんません、今度書きます。

> --- Encoding::ISO_2022_JP_KDDI
> KDDI 携帯の絵文字を含む ISO-2022-JP の亜種です。

そういえば、これっていわゆる半角カナとかマイクロソフト標準キャラクタセットの
機種依存文字とかって扱えなくていいんですかね。
CP50221 のレプリカである必要があるような、CP932 拡張部分はいらないような

むらたです。

On 2010/03/02, at 23:42, Yui NARUSE wrote:

> * Shift_JIS-* は SJIS-* にすべき
>  http://home.m05.itscom.net/numa/cde/sjis-euc/sjis-euc.html
> 
> * x-emoji.c にそれぞれの encoding の出典へのリンクが欲しいです
>  http://github.com/ruby/ruby/blob/trunk/enc/shift_jis.c みたいな感じで

対応しました。
http://github.com/mrkn/ruby/commit/ff24598557388749b0dc503506e15696b862fdf8

--
Kenta Murata
OpenPGP FP = FA26 35D7 4F98 3498 0810 E0D5 F213 966F E9EB 0BCC

本を書きました!!
『Ruby 逆引きレシピ』 http://www.amazon.co.jp/dp/4798119881/mrkn-22

E-mail: mrkn@mrkn.jp
twitter: http://twitter.com/mrkn/
blog: http://d.hatena.ne.jp/mrkn/

遠藤です。

パッチを試したところ、make all が 9 分半から 12 分になりました。

大差ないといえばそうですが、節操なく機能を盛り込みまくればどんどん
遅くなり、パッケージも肥大化します。git bisect のようなことも大変に
なり、多くの人に定期ビルドしてもらうための障害にもなりそうです。
標準添付ライブラリを減らしたいという方針にも反すると思います。

絵文字変換はどのくらいの人が必要としている機能なんでしょうか。
個人的には全く恩恵に預からなさそうなので正直嫌だなあと思っています。


といっても取り込みは既定路線で避けられない雰囲気ですね。
せめて、テーブル生成のスクリプトを高速化してからか、configure の
オプションでオフにできるようにしていただけないでしょうか。

-- 
Yusuke ENDOH <mame@tsg.ne.jp>

成瀬です

2010年3月3日10:53 KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>:
> # だって、絵文字を使うのは日本人だけで、日本のＰＣのIMEで晴れのマークとか
> # 普通には入力できないですよね

Microsoft Office IME 2007 では「晴れ」でUnicode の U+2600 と U+263C を入力できますね。

> これはOKだと思います。ただ、携帯の内部表現については普段あまり意識していないと
> 思うのでるりまの説明の方に、もう一言捕捉があるとうれしいかもしれません。

一応確認しておくと、るりまは Ruby 本体とは別プロジェクトですよ。

>> >> - stateless-ISO-2022-JP-KDDI
>> >
>> > stateless iso-2022というのが、どういう状況で使うのか想像できないので
>> > 解説をお願いしていいですか？
>>
>> これは内部で使われているだけなので、表に名前を出す必要はなかったですね。
>>
>> 現状では ISO-2022-JP <-> EUC-JP の変換が stateless-ISO-2022-JP を介した
>> 変換で実現されています。stateless-ISO-2022-JP-KDDI は、
>> ISO-2022-JP-KDDI <-> UTF8-KDDI の変換でこれを真似したために存在しています。
>
> うん。可能であれば、ユーザ非公開にしていただきたいです。
> 文字コードの問題って一番多いのが、無駄に分かりにくい事が原因による使用法誤解だと
> 思うので。

UTF-8 から ISO-2022-JP-KDDI にいきなり変換してもいいかなぁ。

> たぶん、それぞれ一言「主にｘｘで使われています」と書くのがよいと思います。
> 基本路線はこれでよいと思います。
> また、もし現実にはほぼ使われていない物があれば今回は落として欲しいです。

キャリアさえわかれば、とりあえずそれ用の Web ページを書くとき、
またはクライアントからのデータをデコードする際に使う事は自明だと思います。
あとはメールかな。
キャリア+符号化方式が同じものが複数ある場合は区別が必要でしょうけれど。

> 僕が携帯の世界に疎いので若干気にしすぎな面もあるかとは思いますが、世間の
> Webデザイナーの認識なんてそんなもんですよ。と強引に自己正当化。

うーん、それって、リファレンスじゃなくて、ガイドのお仕事じゃないですか。
思うにリファレンスで必要なのは、そのエンコーディングが結局何者なのかの同定情報で、
それが先に指摘している「linkをつけて」って話なのです。

で、ガイドならば、それは個々のエンコーディングの解説ではなく、
あるユースケースに置いて何を使えばいいかという形になるでしょう。

-- 
NARUSE, Yui
naruse@airemix.jp

成瀬です。

2010年3月3日12:43 Yusuke ENDOH <mame@tsg.ne.jp>:
> パッチを試したところ、make all が 9 分半から 12 分になりました。
>
> 大差ないといえばそうですが、節操なく機能を盛り込みまくればどんどん
> 遅くなり、パッケージも肥大化します。git bisect のようなことも大変に
> なり、多くの人に定期ビルドしてもらうための障害にもなりそうです。

エンコーディング絡みの C ソース生成は直接関係するテーブルなどにしか
依存していないので、生成する際にしか影響しないと思います。
毎回 0 からビルドするとか、git bisect はご指摘の通りですが。

まぁ、この処理が遅い事自体は GB18030 絡みで指摘されていて、
そのうち治したいなぁと思っている懸案ではあるんですが。

> 標準添付ライブラリを減らしたいという方針にも反すると思います。

それはメンテナンスコストが背景にあると考えているので、
全く別の話だと思います。

> 絵文字変換はどのくらいの人が必要としている機能なんでしょうか。
> 個人的には全く恩恵に預からなさそうなので正直嫌だなあと思っています。

携帯向けの Web をやってる人は一通り踏むんじゃないですかね。
で、これって Rails 経由で今の Ruby の主たる用途だと思っています。

> といっても取り込みは既定路線で避けられない雰囲気ですね。
> せめて、テーブル生成のスクリプトを高速化してからか、configure の
> オプションでオフにできるようにしていただけないでしょうか。

テーブル生成のスクリプトが遅いのはまぁ問題でしょうけれど、
それがブロック理由ってのはちょっと違うんじゃないですかね。

また、configure のオプションについて、絵文字系エンコーディングのみオフは
ないと思っていて、組み込みエンコーディングのみとかになると思います。
が、それって欲しいですか。
その場合の用途って、make miniruby で十分そうですし。

-- 
NARUSE, Yui
naruse@airemix.jp

佐々木と申します。

Railsのjpmobileというプラグイン
http://jpmobile-rails.org/
で絵文字を変換しています。

> 以下のような fallback つきのコンバータを標準で提供しておけば、
> 個々のニーズについては fallback 変換表を gem で配布してもらうだけ
> 済むかもしれません。

もっと深い「個々のニーズ」を考えると絵文字同士の変換表をカスタマイズしたい場合があります。
Googleの変換表は足がかりとしてすばらしいのですが、案件やサイトごとに微妙に違う変換表を
つくったりします。（顔の表情が気に入らないからこの絵文字は使わない、とか）
Docomo<=>KDDI、KDDI<=>Softbank、Softbank<=>Docomoの３方向で作ります。
具体的にどの絵文字かという話ではなく、案件ごと、サイトごとなのです。

「Ruby標準の絵文字変換で対応できないマニアックな変換は独自の変換ライブラリを
作ってね」でも良いのですが、可能であれば
・ユーザ定義の絵文字transcoderを作れる余地
・fallbackのカスタマイズのように絵文字変換をカスタマイズできる仕組み
があると助かります。

各エンコーディングがサポートされると、バイナリでごにょごにょしなくてよくなるので独自変換器を
作りやすくはなります。


参考ですが、jpmobileの絵文字変換はここに説明があります。
http://rdoc.info/projects/darashi/jpmobile
Jpmobile内では、各キャリアの絵文字はUnicode私的領域上にマッピングされ、管理される。このとき、DoCoMo、Auは公式サイト記載のマッピングが使用される。ただしSoftBankはAuとの重複を避けるため、公式のマッピングに0x1000加算しU+F001以降に割り当てる。テンプレート内ではUTF-8でエンコードするか、数値文字参照の&#xHHHH;形式で指定する。

絵文字は送出時に内蔵の変換表に基づいて変換され、携帯電話のエンコーディングにあわせて送出される。携帯電話から受信した絵文字は上記マッピングに基づいてUTF-8でparamsに渡される。

---
http://d.hatena.ne.jp/urekat/

成瀬です。

2010年3月3日14:45 takeru sasaki <sasaki.takeru@gmail.com>:
> Railsのjpmobileというプラグイン
> http://jpmobile-rails.org/
> で絵文字を変換しています。

jpmobile の設楽さんはこの件の貢献者の一人ですね。

>> 以下のような fallback つきのコンバータを標準で提供しておけば、
>> 個々のニーズについては fallback 変換表を gem で配布してもらうだけ
>> 済むかもしれません。
>
> もっと深い「個々のニーズ」を考えると絵文字同士の変換表をカスタマイズしたい場合があります。
> Googleの変換表は足がかりとしてすばらしいのですが、案件やサイトごとに微妙に違う変換表を
> つくったりします。（顔の表情が気に入らないからこの絵文字は使わない、とか）
> Docomo<=>KDDI、KDDI<=>Softbank、Softbank<=>Docomoの３方向で作ります。
> 具体的にどの絵文字かという話ではなく、案件ごと、サイトごとなのです。

まず、「文字コードの変換」というのはわたしはバイト列同士の変換だと考えています。
つまり、バイト単位で読み込み、判定し、別のバイト列に変えるのが文字コード変換のレイヤです。

一方、そのニーズは文字単位で差し替えたいという話なのですから、レイヤが違うのではないでしょうか。

思うに、そのニーズで真に正しい対処は変換表に手をいれることではなく、
DBに保存する前の UTF-8 などの段階でどれかの絵文字に揃える正規化をかけるか、
それぞれの端末向けの文字コードに変換にしたあとで、独自の正規化をかけるのが正解でしょう。

仮にユーザ定義の transcode を用意したとしてもそれは拡張ライブラリになるんですが、
案件ごとに拡張ライブラリを書きたいという話ではないですよね、きっと。

思うに、Perl の Encode のように、変換表をそのままライブラリにし、
変換を呼んだときにコンパイルしてくれるものを想定していると思うのですが、
Ruby のは現状あれとはかなり違うのです。

> 「Ruby標準の絵文字変換で対応できないマニアックな変換は独自の変換ライブラリを
> 作ってね」でも良いのですが、可能であれば
> ・ユーザ定義の絵文字transcoderを作れる余地
> ・fallbackのカスタマイズのように絵文字変換をカスタマイズできる仕組み
> があると助かります。

また、ユーザが独自のエンコーディングや変換ライブラリを追加できるように
することにはわたしが否定的ってのもあります。


結局のところ、変換前、または変換後に同じ文字符号化方式内で文字を入れ替えた方が、
扱いやすさ的にも速度的にもよいと思われるので、そちらを使ってください。
String#tr で不十分ならばユースケースを提供して頂ければより良い方法があるかもしれません。
どうしても変換しながら処理しないと行けないケースがあれば独自変換を考えますが、
絵文字絡みに関してはそれはないと思います。

-- 
NARUSE, Yui
naruse@airemix.jp

佐々木です。

コメントありがとうございます。

・各絵文字エンコーディングがサポートされることは反対ではないです。
・Googleの絵文字変換組み込まれることも反対ではないです。
  現実的には８割９割以上はこれで十分な機能だと思うからです。



> まず、「文字コードの変換」というのはわたしはバイト列同士の変換だと考えています。
> つまり、バイト単位で読み込み、判定し、別のバイト列に変えるのが文字コード変換のレイヤです。
> 一方、そのニーズは文字単位で差し替えたいという話なのですから、レイヤが違うのではないでしょうか。

emoji4unicodeも文字単位で置き換えているように見えるのですが違うのでしょうか？
>この置換法則は emoji4unicode の成果物である
>http://www.unicode.org/~scherer/emoji4unicode/snapshot/full.html
>この表で定義されているものが一般的なんだと思っています。
明らかに「絵」が違うけど「同じこと/もの」を指しているっぽいから文字単位で置き換えましょう、
という仕様だとおもうのです。



> 思うに、そのニーズで真に正しい対処は変換表に手をいれることではなく、
> DBに保存する前の UTF-8 などの段階でどれかの絵文字に揃える正規化をかけるか、
> それぞれの端末向けの文字コードに変換にしたあとで、独自の正規化をかけるのが正解でしょう。

要件次第なのですが、「どれかの絵文字に揃える正規化」をしてしまうと、掲示板に書き込んだ自分の
コメントの中の絵文字が入力したものと違う絵文字で表示されたりします。GoogleのUTF8ではこれは
起こらなかったはずです。

「それぞれの端末向けの文字コードに変換にしたあとで、独自の正規化」をしようとしてもGoogleの変換
を使ってしまった時点で元の絵文字が「どのキャリアのどの絵文字」だったかがわからなくてどうにも
ならなくて困ったりもします。

まあでも非常にレアなニーズだとおもいます。無視してください。


実はjpmobileの「softbankを0x1000ずらす方式」はGoogleのUTF8よりも良い点があります。
GoogleのUTF8に１度変換してしまうと入力元のキャリアが何であったかがわからなくなってしまう
のですが、jpmobileの方式だと元キャリアはコードの範囲からわかるのです。
情報(=元キャリア)の欠落がありません。



> 仮にユーザ定義の transcode を用意したとしてもそれは拡張ライブラリになるんですが、
> 案件ごとに拡張ライブラリを書きたいという話ではないですよね、きっと。
> 思うに、Perl の Encode のように、変換表をそのままライブラリにし、
> 変換を呼んだときにコンパイルしてくれるものを想定していると思うのですが、
そういうものを想定してました。
Ruby本体に用意されないなら必要になった誰かがカスタマイズ可能な絵文字変換器をつくる
だけのことなのですが、Ruby本体の仕組みをちょっと借りてスマートに実装できないかと思っただけです。

---
http://d.hatena.ne.jp/urekat/

成瀬です。

(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に１度変換してしまうと入力元のキャリアが何であったかがわからなくなってしまう
> のですが、jpmobileの方式だと元キャリアはコードの範囲からわかるのです。
> 情報(=元キャリア)の欠落がありません。

で、この主張は想定していました。

まとめると、
UTF-8 でもどのキャリアかわかればどの絵文字だったかわかる
UTF8-Google だと、もとがケータイ絵文字だったか、PCからの入力か区別できる
jpmobile 方式だと、単体でどのキャリアのどの絵文字だったかわかる
と、考えると、UTF8-Google は中途半端な気がするんですよね。

PC からの「晴れ」マークと、絵文字からの「晴れ」が混同されるのは、
正しいのか意図しない挙動なのか、とかちょっと迷う所。

まぁ、この辺は将来の携帯電話が U+2600 とユーザ定義エリアの「晴れ」を別々に
送って来ない限り対処は可能なので……。

-- 
NARUSE, Yui  <naruse@airemix.jp>

むらたです。

On 2010/03/04, at 22:45, NARUSE, Yui wrote:

> PC からの「晴れ」マークと、絵文字からの「晴れ」が混同されるのは、
> 正しいのか意図しない挙動なのか、とかちょっと迷う所。
> 
> まぁ、この辺は将来の携帯電話が U+2600 とユーザ定義エリアの「晴れ」を別々に
> 送って来ない限り対処は可能なので……。

まさにこの問題がありまして、現在の実装では
以下のように絵文字側に吸引されます。

s = "\u{2600}\u{e04a}".force_encoding("UTF8-SoftBank")
s.encode!("UTF-8")        #=> "\u2600\u2600"
s.encode("UTF8-SoftBank") #=> "\uE04A\uE04A"

--
Kenta Murata
OpenPGP FP = FA26 35D7 4F98 3498 0810 E0D5 F213 966F E9EB 0BCC

本を書きました!!
『Ruby 逆引きレシピ』 http://www.amazon.co.jp/dp/4798119881/mrkn-22

E-mail: mrkn@mrkn.jp
twitter: http://twitter.com/mrkn/
blog: http://d.hatena.ne.jp/mrkn/

(2010/03/03 13:42), KOSAKI Motohiro wrote:
>> 成瀬です
>>
>> 2010年3月3日10:53 KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>:
>>     
>>> # だって、絵文字を使うのは日本人だけで、日本のＰＣのIMEで晴れのマークとか
>>> # 普通には入力できないですよね
>>>       
>> Microsoft Office IME 2007 では「晴れ」でUnicode の U+2600 と U+263C を入力できますね。
>>     
> 知りませんでした。うちのWindowsXP付属のIMEでは入力不可なので撤回された仕様なのかな。
>   
XPの付録でしたら2001年ですから。
>>> たぶん、それぞれ一言「主にｘｘで使われています」と書くのがよいと思います。
>>> 基本路線はこれでよいと思います。
>>> また、もし現実にはほぼ使われていない物があれば今回は落として欲しいです。
>>>       
>> キャリアさえわかれば、とりあえずそれ用の Web ページを書くとき、
>> またはクライアントからのデータをデコードする際に使う事は自明だと思います。
>> あとはメールかな。
>> キャリア+符号化方式が同じものが複数ある場合は区別が必要でしょうけれど。
>>     
> Webページについて自明なのは同意で、私が枝葉を語りすぎている可能性は
> たしかにありますね。
> 実は私はサーバからAU携帯に絵文字メールを送る時、ISO2022-JP-KDDIとSJIS-KDDIの
> どちらが一般的なのか、とか、携帯にUnicodeメール送ったらなにが起きるか、とか
> そういった事情が気になったのですが、これは成瀬さんご指摘のとおり
> ガイドラインの仕事のような気が今はしています。
>   

以前いろいろ探したんですが、携帯電話に対してどのような形でメールを送るの
がよいか、
というのは意外と明示的な文書がみつかりません。

SoftBankだけや唯一文書があって、3GだとUTF-8可ですね。
http://creation.mb.softbank.jp/mail/mail_contract.html

まぁ、絵文字がらみでもゲートウェイで変換しているような記述を方々で見るので、
実のところ文字集合さえ同じなら文字符号化方式はあんまり関係ないんじゃない
かな。

波ダッシュ問題あたりは気になりますけど。

遠藤です。

2010年3月3日12:43 Yusuke ENDOH <mame@tsg.ne.jp>:
> せめて、テーブル生成のスクリプトを高速化してからか、configure の
> オプションでオフにできるようにしていただけないでしょうか。

文句言ってばかりなのも残念なので、自分で最適化してみました。
tool/transcode-tblgen.rb を書き換えてから make にかかる時間が

                  no-opt -> opt
  絵文字パッチ前: 133 秒 -> 124 秒
  絵文字パッチ後: 275 秒 -> 151 秒

となりました。
絵文字パッチのせいで従来より 142 秒ビルドが遅くなっていたところを、
18 秒遅くなるだけになりました。これなら許容範囲かなと思います。
(元々が遅すぎるという話はありますが)


導入した最適化は以下の 2 つです。

1) [byte..byte] の使いまわし
[byte..byte] というオブジェクトが大量に作られていた (しかも破壊的
変更はされない) ので、使いまわすようにしました。

2) memoize の改良
PostMemo にヒットしたとき PreMemo を更新していなかったので、更新
するようにしました。

生成されるプログラムに変化はないようです。


小さい配列やハッシュを大量に生成し、(memoize のために) それらへの
参照を消さないプログラムなので、GC が結構時間を食っているようです。
GC の最適化の題材に良いかもしれません。


diff --git a/tool/transcode-tblgen.rb b/tool/transcode-tblgen.rb
index f8da86d..4f183f1 100755
--- a/tool/transcode-tblgen.rb
+++ b/tool/transcode-tblgen.rb
@@ -23,6 +23,8 @@ HEX2 = /[0-9A-Fa-f]{2}/
 class StrSet
   attr_reader :pat

+  SINGLE_BYTE_RANGES = (0..255).map {|i| [i..i] }
+
   def self.parse(pattern)
     if /\A\s*((#{HEX2}|\{(#{HEX2}|#{HEX2}-#{HEX2})(,(#{HEX2}|#{HEX2}-#{HEX2}))*\})+(\s+|\z))*\z/o
!~ pattern
       raise ArgumentError, "invalid pattern: #{pattern.inspect}"
@@ -33,7 +35,7 @@ class StrSet
       while !seq.empty?
         if /\A(#{HEX2})/o =~ seq
           byte = $1.to_i(16)
-          seq_result << [byte..byte]
+          seq_result << SINGLE_BYTE_RANGES[byte]
           seq = $'
         elsif /\A\{([^\}]+)\}/ =~ seq
           set = $1
@@ -448,7 +450,7 @@ End
     }

     if n = PostMemo[table]
-      return n
+      return PreMemo[[self,valid_encoding]] = n
     end

     if !name_hint

-- 
Yusuke ENDOH <mame@tsg.ne.jp>

むらたです。

On 2010/03/08, at 23:22, Yusuke ENDOH wrote:

> 2010年3月3日12:43 Yusuke ENDOH <mame@tsg.ne.jp>:
>> せめて、テーブル生成のスクリプトを高速化してからか、configure の
>> オプションでオフにできるようにしていただけないでしょうか。
> 
> 文句言ってばかりなのも残念なので、自分で最適化してみました。
> tool/transcode-tblgen.rb を書き換えてから make にかかる時間が
> 
>                  no-opt -> opt
>  絵文字パッチ前: 133 秒 -> 124 秒
>  絵文字パッチ後: 275 秒 -> 151 秒
> 
> となりました。
> 絵文字パッチのせいで従来より 142 秒ビルドが遅くなっていたところを、
> 18 秒遅くなるだけになりました。これなら許容範囲かなと思います。
> (元々が遅すぎるという話はありますが)

遠藤さん、ありがとうございます。
私も手元で確認したのですが、これまでとても遅かった
UTF-8 から絵文字エンコーディングへの変換器を生成する時間が
ほぼ一瞬で終わるようになって驚きました。

これで遠藤さんからの反論については解決したと考えて良いと思います。
他に反論が無いようでしたら、絵文字エンコーディングを trunk にコミットします。


> 導入した最適化は以下の 2 つです。
> 
> 1) [byte..byte] の使いまわし
> [byte..byte] というオブジェクトが大量に作られていた (しかも破壊的
> 変更はされない) ので、使いまわすようにしました。
> 
> 2) memoize の改良
> PostMemo にヒットしたとき PreMemo を更新していなかったので、更新
> するようにしました。
> 
> 生成されるプログラムに変化はないようです。
> 
> 
> 小さい配列やハッシュを大量に生成し、(memoize のために) それらへの
> 参照を消さないプログラムなので、GC が結構時間を食っているようです。
> GC の最適化の題材に良いかもしれません。
> 
> 
> diff --git a/tool/transcode-tblgen.rb b/tool/transcode-tblgen.rb
> index f8da86d..4f183f1 100755
> --- a/tool/transcode-tblgen.rb
> +++ b/tool/transcode-tblgen.rb
> @@ -23,6 +23,8 @@ HEX2 = /[0-9A-Fa-f]{2}/
> class StrSet
>   attr_reader :pat
> 
> +  SINGLE_BYTE_RANGES = (0..255).map {|i| [i..i] }
> +
>   def self.parse(pattern)
>     if /\A\s*((#{HEX2}|\{(#{HEX2}|#{HEX2}-#{HEX2})(,(#{HEX2}|#{HEX2}-#{HEX2}))*\})+(\s+|\z))*\z/o
> !~ pattern
>       raise ArgumentError, "invalid pattern: #{pattern.inspect}"
> @@ -33,7 +35,7 @@ class StrSet
>       while !seq.empty?
>         if /\A(#{HEX2})/o =~ seq
>           byte = $1.to_i(16)
> -          seq_result << [byte..byte]
> +          seq_result << SINGLE_BYTE_RANGES[byte]
>           seq = $'
>         elsif /\A\{([^\}]+)\}/ =~ seq
>           set = $1
> @@ -448,7 +450,7 @@ End
>     }
> 
>     if n = PostMemo[table]
> -      return n
> +      return PreMemo[[self,valid_encoding]] = n
>     end
> 
>     if !name_hint
> 
> -- 
> Yusuke ENDOH <mame@tsg.ne.jp>
> 

--
Kenta Murata
OpenPGP FP = FA26 35D7 4F98 3498 0810 E0D5 F213 966F E9EB 0BCC

本を書きました!!
『Ruby 逆引きレシピ』 http://www.amazon.co.jp/dp/4798119881/mrkn-22

E-mail: mrkn@mrkn.jp
twitter: http://twitter.com/mrkn/
blog: http://d.hatena.ne.jp/mrkn/

むらたです。

On 2010/03/09, at 7:40, Kenta Murata wrote:

> これで遠藤さんからの反論については解決したと考えて良いと思います。
> 他に反論が無いようでしたら、絵文字エンコーディングを trunk にコミットします。

朝はこのように考えていましたが、良く考えると最初の発案から1週間経過していて、
その間に遠藤さん以外の反対意見は出ていないので、もう出ないんじゃないかと思いました。

ということで、コミットしました。

--
Kenta Murata
OpenPGP FP = FA26 35D7 4F98 3498 0810 E0D5 F213 966F E9EB 0BCC

本を書きました!!
『Ruby 逆引きレシピ』 http://www.amazon.co.jp/dp/4798119881/mrkn-22

E-mail: mrkn@mrkn.jp
twitter: http://twitter.com/mrkn/
blog: http://d.hatena.ne.jp/mrkn/

こんにちは、なかむら(う)です。

In message "[ruby-dev:40588] Re: [Feature #2833]  絵文字エンコーディングの提案"
    on Mar.09,2010 18:20:47, <muraken@gmail.com> wrote:
> ということで、コミットしました。

mswin32がビルドできなくなりました。
こんなのが出ます。

x-emoji.def : error LNK2001: 外部シンボル "Init_x-emoji" は未解決です


えーと、つまり、enc/*.cは最終的に拡張ライブラリになるのですが、
全ての拡張ライブラリは必ず Init_ファイル名() という関数を外部
に公開しなければならないという義務があります。
で、enc/x-emoji.cはその義務を果たしていません。

つか、要らないでしょこれ。
ENC_REPLICATEだけならどっか外に書けませんでしたっけ。


それでは。
-- 
U.Nakamura <usa@garbagecollect.jp>

むらたです。

On 2010/03/10, at 7:52, U.Nakamura wrote:

> In message "[ruby-dev:40588] Re: [Feature #2833]  絵文字エンコーディングの提案"
>    on Mar.09,2010 18:20:47, <muraken@gmail.com> wrote:
>> ということで、コミットしました。
> 
> mswin32がビルドできなくなりました。
> こんなのが出ます。
> 
> x-emoji.def : error LNK2001: 外部シンボル "Init_x-emoji" は未解決です
> 
> 
> えーと、つまり、enc/*.cは最終的に拡張ライブラリになるのですが、
> 全ての拡張ライブラリは必ず Init_ファイル名() という関数を外部
> に公開しなければならないという義務があります。
> で、enc/x-emoji.cはその義務を果たしていません。
> 
> つか、要らないでしょこれ。
> ENC_REPLICATEだけならどっか外に書けませんでしたっけ。

enc/x-emoji.c を enc/x_emoji.h へリネームしてコミットしました。

--
Kenta Murata
OpenPGP FP = FA26 35D7 4F98 3498 0810 E0D5 F213 966F E9EB 0BCC

本を書きました!!
『Ruby 逆引きレシピ』 http://www.amazon.co.jp/dp/4798119881/mrkn-22

E-mail: mrkn@mrkn.jp
twitter: http://twitter.com/mrkn/
blog: http://d.hatena.ne.jp/mrkn/