しかしこれはデータの設計という観点からすると極めて愚かな行為である。今日は声を大にしてこのような愚行に対して異を唱えたい。絵文字をUnicode化してはいけない理由は次の通りである。
1. 絵はあくまでも絵であって文字ではない。
絵文字は言語の一部を形成するものではない。単語に利用することも出来ないし、文字自体を発音できるわけでもない。文字コードに文字以外のデータを導入するべきではない。
2. 別の解決法が存在する。
そもそも絵文字の問題はマークアップ処理すれば解決する。例えば端末自体がHTMLメールを送信することが出来ればまったく問題にならない。
3. 互換性の問題。
文字を利用するアプリケーションはなにも携帯メールだけではない。Googleが得意とするWebだけでもない。むしろ文字を使わないアプリケーションなど無いと言っていいだろう。特定のアプリケーションだけのために、その他全てのアプリケーションに影響が及ぶことを安易に行ってはならない。文字コードの互換性はOSの互換性やウェブブラウザの互換性(タグがどのように表示されるかがブラウザによって異なる問題)よりも遙かに重要な課題である。
4. 実装の問題
文字を表示するには文字コードだけではなくフォントが必要である。つまりフォント業者は絵文字が増えた分だけフォントを多く作成しなければならない。携帯電話ならサイズがほぼ固定または数種類であるが、PCなどより汎用性が高いところではフォントサイズのバリエーションが非常に多い。全てのフォントサイズ向けに絵文字を収録するというのはとても手間である。アプリケーションが新しく追加された文字を利用するにはフォントを作成するだけではだめで、どのようにそれらのフォントを配布するかという課題が残る。
5. 流行の問題。
100年後も同じ絵文字が流行しているのだろうか。人々は新しい絵文字を利用したくなるのではないだろうか。そうするとキャリアは新しい絵文字を追加したくなるだろう。しかし皆が新しい絵を次々と登録しようとするとどうなるか。登録される絵文字が増え続けて収集がつかなくなるのではないだろうか。また、人によっては絵文字を利用する必要がないという人も居るし、データ容量を減らすために絵文字が含まれていないフォントを使うかも知れない。このような事情から、絵文字あり・なし、または絵文字の種類の違いによってUnicode(またはUnicode用フォント)に複数のバージョンが出来かねない。そうなると、互換性の問題が存在する土俵が、携帯端末同士から文字コードへ移ってしまうことになるだろうが、これは本末転倒である。
6. 文字統一の問題
Unicodeとは世界中の文字を一つの文字コードで表現しようというプロジェクトである。特にアジア圏の文字は膨大な数が存在するため、登録されている文字が重複するとか、非常に似通った複数の異なる文字が存在するなどの問題が存在した。CJK統合漢字のプロジェクトでは、そのような問題に対処するべく鋭意活動中であるが、絵文字が追加されてしまったら文字コードの統一化はさらに難しくなることだろう。絵文字の描き手によっては表情の違いを区別するのが難しい場合も考えられるし、同じ意味の絵文字なのに描き手によって全然違って見えるという事態も生じるだろう。
7. アクセシビリティの問題
視覚障害者にとって絵文字は意味をなさない。文字コードは万人が共通して利用できるべき基盤なので、視覚障害者にとって理解不能な要素を混入させるべきではない。
---
確かに共通のコードを持つことによって携帯端末側のアプリケーションの実装は便利になるかも知れない。しかし、携帯端末における実装が容易になるからといって、一時の便利さだけを追求してはならない。上記のように、特に互換性の問題が存在することから、必ずや将来に禍根を残すことになるだろう。Unicodeに絵文字をゼッタイに収録すべきではない。Unicodeコンソーシアムにおける他のメンバーのリテラシーに期待したい。(MS、IBM、Sun、Oracleには常識があって、こんなアホなことを言うのはGoogleだけ・・・おそらくGoogleの中でも一部の人だけだと信じたい・・・)
元々絵文字は携帯キャリアがリソースの乏しい携帯端末向けに実装した苦肉の策であって、それは使用できる文字数制限などから生まれたものであった。端末の機能やサービスがずっと改善して数千文字のメールを送ることが出来るようになった現在では、以前から文字化けや非互換性の温床であったし、あまり意味のない回避方法だといえる。絵文字はキャリアが導入した功罪であるので、キャリアが率先してこのような愚行を止めなければならないが、どうやら最大手のNTT Docomoは賛同しているようである。嘆かわしい。。。
HTMLは確かに余分なメタデータが多すぎるし、表現のバリエーションが多岐にわたりすぎるので携帯端末向けのメールで利用するには向かないと思う。文章に絵文字だけを埋め込みたいというのであれば、ビットマップデータを文字と同時に送る事ができる新しい規格を作った方がよほどいい。例えばエスケープ記号によってプレースホルダを作成して、文字データに続いて画像データを送信するというような規格である(下図)。
この例では「?」がプレースホルダで、後に続くイメージデータをプレースホルダに埋め込むことで、単純に画像だけをテキストに埋め込むことを実現している。文字コードではなくフォーマットを工夫するべきじゃないだろうか。画像データのサイズは、32x32ピクセルだったとしても、256色ならばたったの1KBである。実際にはもう少しサイズが小さかったり色数を減らせたりできるので、画像のデータサイズは着うたダウンロードなどに比べれば誤差のようなものである。HTMLは重すぎるが、このように画像をテキストに埋め込むということに特化したフォーマットを考えれば、いくらでも軽いものは考えられる。
この手法ならば任意の画像をテキストに埋め込むことが出来るので文字コード自体を改造するよりも遙かに手間も掛からないし、実装も簡単であるし、将来的に任意 の画像を埋め込めるという利点がある。キャリアが絵の種類を統一する必要もないので機種やメーカーによって色を出すことも可能になるだろう。画像を都度送 受信するとネットワークのトラフィックが増えるという問題が生じるが、上記のように絵文字のサイズのデータなんてたかだか知れているし、パケット定額などの料金体系や 高速通信が可能なインフラが定着しつつある現在では問題にはならない。なので各キャリア業者はこのような手法を共通化させて頂きたいものである。
この手法ならば任意の画像をテキストに埋め込むことが出来るので文字コード自体を改造するよりも遙かに手間も掛からないし、実装も簡単であるし、将来的に任意 の画像を埋め込めるという利点がある。キャリアが絵の種類を統一する必要もないので機種やメーカーによって色を出すことも可能になるだろう。画像を都度送 受信するとネットワークのトラフィックが増えるという問題が生じるが、上記のように絵文字のサイズのデータなんてたかだか知れているし、パケット定額などの料金体系や 高速通信が可能なインフラが定着しつつある現在では問題にはならない。なので各キャリア業者はこのような手法を共通化させて頂きたいものである。
ワケの分からないベンチャー企業がこういった「絵文字をUnicodeに!」というような馬鹿な発言をするなら話は分かるが、Googleのような巨大企業がこのような考えのない発言をするのはちょっと恥ずかしすぎるのではないだろうか。本来は導く立場であって良いはずなのに、自社の利益のためにこのようなイニシアティブを取るのは浅ましい。文字と絵をごちゃ混ぜにするということはデータベースでいうと非正規化をするようなもの。データ構造の設計としては誤った方向である。一エンジニアとしてGoogleの愚行には異を唱えたい。
4 コメント:
5. 流行の問題 以外は極めて良い解決法だと思います。
対応フォントがあれば他のすべてのソフトで使えるわけですから、
他の実装方法の方がよっぽど普及させづらいと思います。
だって、MS明朝とかメイリオに付加されてUpdateで配られたら、
その瞬間からすべてのメーラーで過去のメールも含めて文字化けが治る仕組みですよ。
象形文字と思えば、ひとつの文字セットが増えるだけですし、
漢字のマッピングでも意味が違うのに、形が似てるからと同じコードを割り当ててる物もあります。
だから許されるわけではないですが、コードと意味が対応してるわけですから、
そう外れたものは出ないんじゃないでしょうか。
そもそもの問題が、SJISに無理やり割り当てたからで、解決法としても無理がないと思いませんか。
文章全体が絵文字うざい・文字じゃない区別しろと言う主張に見えて、
むしろ受け入れればスッキリするのにと思いコメントさせていただきました。
774さん、コメントありがとうございます。
> 文章全体が絵文字うざい・文字じゃない区別しろと言う主張に見えて、
> むしろ受け入れればスッキリするのにと思いコメントさせていただきました。
これは明確に否定しておきます。
なぜ文字コードに絵文字を入れるのが反対なのかというのは、文字コードの設計にとって良くないからです。もっと言うと、文字コードと絵文字のドメインは違うので、異なったオブジェクトとして扱うべきだと思うからです。異なるドメインのものをごちゃまぜにしてしまうと、その場は都合が良くても、後から負債になってのしかかって来ることになります。特に文字コードのようなものはリファクタリングが難しい分野なので、慎重に議論しないといけないと思います。まあ、もう決まってしまったことなんですけど。
Unicodeに絵文字を入れるのと同様にアイコンフォントにも反対です。というか、こっちはもっと反対ですが。
なるほど。
僕は漢字の進化系だと思っている=同じドメイン・オブジェクトだと思っているけど、
Mikiya Okuno さんは違うものだと思っている。
カラーやアニメーションする絵文字を文章に入れるとチカチカして嫌いですが、
それでもやっぱり絵文字をUnicodeに入れると、バッドノウハウが無くなって良いと思ってます。
これは10年後にならないとどっちが良かったかわからない話だと思いますが。
アイコンフォントとは、WindowsだとWingdingsフォントとかでしょうか。
あれは意味の違う絵を当てはめてるので同じく反対です。
> 僕は漢字の進化系だと思っている=同じドメイン・オブジェクトだと思っているけど、
> Mikiya Okuno さんは違うものだと思っている。
違うと思いますよ。文字としての成り立ちも機能もまったく違います。
文字は組み合わせて単語にすることで、文章に意味を与えますが、絵文字はあくまでもその絵面が印象を伝えるだけです。とりあえず明確に言える問題点は、絵を文字のひとつにしてしまうと、絵の種類を柔軟に増やせないということです。
LINEのスタンプなんかは絵文字の進化系じゃないかと思いますが、文字コードに絵を無理やり入れてもああ言う仕組みは作れません。LINEのように文字と絵を明確にわけないと、より複雑で豊かなデータは表現できないですよ。
> アイコンフォントとは、WindowsだとWingdingsフォントとかでしょうか。
> あれは意味の違う絵を当てはめてるので同じく反対です。
そういう感じですが、最近はWebフォントと組み合わせて色々なところで使われています。通常使用しない文字コードに独自のアイコンを割り当てて、文字として表示してしまうんですね。それによって少しWebのアクセスが速くなるからと。完全にバッドノウハウだと思います。
例えばTwitterの上部にあるHome、Notification、Discover、Meなどの左のアイコンは、実はフォントで表示されています。Twitterでは他にも随所で使われていますが、フォントを固定するとよく分かりますよ。
コメントを投稿