まだプログラマーですが何か?

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

タグ:unicode

emoji(絵文字)はもともと(当時の) NTT ドコモのエンジニアであった栗田穣崇さんが 1990 年代にiモードの立ち上げ時のコミュニケーション手段の1つとして開発されました。当時は 12x12 ピクセルの中で記号やピクトグラムが表現されていました:
d_202110_001


この「コミュニケーション手段としての emoji」や「感情を効果的に伝える emoji」は 2000 年以降になって日本だけでなく世界中に広がり、iPhone や Android の入力モードにも採用され、広く使われるようになりました。現在は Unicode コンソーシアムによって Unicode(ユニコード)の一部としても管理されています(以下 "Unicode Emoji" と表記します)。2022年11月の時点では Ver.15 の文字セットが登録されています。この Ver.15 で新しくリリースされた文字はここから参照することができます:
https://www.unicode.org/emoji/charts/emoji-released.html


そして、この Unicode Emoji はコンソーシアムによる提案・採用だけでなく、現在規定されていない文字を誰でも提案することができます。世界中で新たな文字として使われるべき理由・背景などを具体的なサンプル画像と合わせて規定のフォーマットで申請することができます。もちろん申請=即採用!とはならず、審査を経た上で主張に同意された場合のみ新しい Unicode Emoji として採用されることになります。

この Unicode Emoji の申請方法は原則英語で記述する必要があり、また1年ごとの申請となるので次回(2023年)申請時のルールは現在わかっているもの(2022年)とは変わる可能性もあります。が、大まかには変わらないだろう、という希望的観測の元で、申請方法を日本語でまとめ直してみました。


【理解しておくべき大原則】
まず(私も最初は誤解していたのですが)理解しておくべき大原則として、「採用=申請した画像が採用される」ではないという点を理解しておく必要があります。申請時にサンプルとして画像ファイルを添付する必要はありますが、その画像がそのまま Unicode Emoji として採用されるわけではない、ということです。あくまで Unicode Emoji の登録文字としての採用であって、例えば iPhone や Android の入力時にどのように表示されるかや、Twitter で表示される時にどのような文字グラフィックで表示されるか、はあくまでスポンサー企業である Apple, Google, Twitter 社が決めることです。ただその際の参考画像にはなると思っています。

次に Unicode Emoji は世界中で使われる可能性がある点を理解した上で申請する必要がある、という点です。日本独自の(世界的にはマイナーな)文化であったり、世界中で知られている文化であった場合でもそのサンプル画像が日本独自なもの(日本以外では見た目が異なる場合)だと、その Unicode Emoji 画像を見ても日本以外では意味が通じなくなってしまう可能性がある、という点です。

これらを誤解して内輪ネタを提案しても(決めるのはあくまで Unicode コンソーシアムですが)採用される可能性は高くないし、採用されても提案されたイメージとは違う画像になる可能性もある、ということは理解した上で申請すべきことを最初に書いておきます。

以下に記載する内容は 2022 年11月時点で、ここに記載されているものをベースに日本語で書き直したものです。最新の条件は変わっている可能性があるので、申請する場合は忘れずに一次情報を確認するようにしてください:
https://unicode.org/emoji/proposals.html


【申請タイミング】
Unicode Emoji の申請は年中募集中というわけではありません。毎年 4/1 から 7/31 まで受け付けており、2022 年の募集は終わっています。今から申請する場合は 2023 年募集分として 2023/04/01 から受け付けることになる、という点に注意してください(とはいえ準備する項目が多いので、早い段階から準備を進めておくことは悪い事ではないと思っています)。


【申請前に調べておくこと】
Unicode Emoji を申請する上では、既にその Unicode Emoji が採用されていたり、過去に同様の申請がされていたりしないことを確認しておくべきです。採用されているかどうかは実際にスマホで探してみることもできますが、過去に申請されているかどうかは調べてみないとわかりません。

過去に(Unicode コンソーシアムからではなく)一般から応募のあった Unicode Emoji はこちらから調べることができます:
https://www.unicode.org/emoji/emoji-requests.html

(英語の壁はありますが)ここから過去に申請された Emoji と、その結果が色分けされて表示されています。少なくともこれから申請しようとしている Emoji が既に登録済みではなく、過去に申請されてもいないことは確認しておきましょう。


【申請時の判断基準】
Unicode Emoji として提案したい文字画像を1つ用意すればよい、という簡単なものではありません。むしろ心が折れそうになるくらい面倒で膨大な準備が必要です。

ただ申請内容をどのように判断するか、その基準は公開されています:
https://www.unicode.org/emoji/proposals.html#selection_factors

↑ここに書かれた内容を1つずつ確認しつつ、何を準備する必要があるのかを確認してみます。以下、英語で書かれている内容を日本語化して紹介します:

(プラス要素(ポジティブに評価される要素))
A. 互換性

Twitter などのシステムでは用意されているアイコンで、まだ Unicode Emoji としては登録されていないものか?

B. 使用レベル

世の中でどのくらい頻繁に使われているものか?キーワードで検索した結果であったり、既存の絵文字の組み合わせでも表現できないものであったり、同じアイコンが違う意図でも使えたりする要素があるか?

C. 独自性

絵文字は明確であるか?視覚的にも象徴的であるか(他と間違えにくいか)?

D. 完全性

似たようなものが既に登録されていないか? 狭いカテゴリー内での異なる種別であったりしないか?


(マイナス要素(ネガティブに評価される要素))
E. 過度に頻繁な申請

「ツイッターで話題」とか「嘆願書」は客観性を欠くと判断される。

F. 過度に具体的

ある大きなグループの中の特定種別だけが切り出されて申請されていないか?

G. オープンエンドであるもの

大きなグループ内の他のものと比較して、その1つを選ぶ理由がないもの

H. 他の Unicode Emoji の組み合わせで実現できそうなもの

例:「ジャックオランタン」+「ゴースト」=「ハロウィン」

I. 著作権に関わるもの

ロゴ、ブランド、知的財産権のある画像、架空の人物、歴史上の人物、特定の建物、神々、・・など

J. 人気が一時的なもの

一時的に使用レベルは上がる可能性はあるが、今後も続く可能性が低いと判断されるもの

K. 誤った比較

「これとは似ていない」という主張が間違っていると判断されるもの

L. 正確な画像が要求されるもの

どのような画像が用意されるかはスポンサー企業が決めるものです

M. 地域フラグのないもの

特定の地域だけで使われるものではなく、世界中で同じ意味で使われるもの

N. 権利やライセンスが欠如しているもの

例えば画像に利用ライセンスが必要な場合は、そのための書類も必要

O. 方向のバリエーションがあるもの

例えば「(右に向かって走る)ランナー」が存在している場合の、「左に走るランナー」のようなものは認めない(といいつつ、上のリンク先でもある Ver.15 ではこれに該当するような新採用文字も含まれているような・・・)

P. 画像内にテキストを含むもの

国際的に認識できない可能性があるため


【申請時に必要なもの】
以上の要件を頭に入れた上で、実際の申請時に必要そうなものを書きだしてみます。

・同意書
https://www.unicode.org/emoji/emoji-proposal-agreement.pdf

申請時に使う画像が自分のもの、あるいはパブリックドメインであることに同意する書類です。ダウンロードして署名する必要があります。


・申請フォーム
2022 年版の申請フォームが有志によって公開されています:
https://docs.google.com/document/d/1cTHKDI_AQrEdp3YHjeyP3L3RZxU_S0rfMZ16BJYmrGo/edit#

(2023 年申請のルールがどれほど変わるかわかりませんが)とりあえずこのフォームをダウンロードして、上述の情報となる画像やスクリーンショットを含めたり、書き埋めていくのが基本的な流れになります。

最終的には PDF で提出する必要があるため、PDF 化します。


・画像ファイル

用意するアイコン画像は以下の4つです:
・18x18 モノクロ
・18x18 カラー
・72x72 モノクロ
・72x72 カラー

72x72 がスマホ向け、18x18 がフィーチャーフォン(ガラケー)向けのようです。

なお「モノクロ」とは白と黒の2色だけからなるものです。「グレースケール(灰色も含む)」ではありません


これら申請に必要なファイルを1つの zip ファイルにまとめます。


【申請先】
2023 年の応募が始まってから、こちらからアップロードできるようになるようです(現在は受け付けしていません):
https://forms.gle/VYh55rc3seGjGNtEA



(↑新しい情報が分かり次第に上の情報を更新したり、追加したりするつもりです)


来年(2023年)、自分も1つ申請に挑戦するつもりです。上の情報だけでは足りなかったり、よく分からない点が出てきたりするかもしれませんが、興味ある方同志で協力しあって進めていければ、と考えています。






 

Linux ラブ!なプログラマーが陥った罠(おそらく多くの人が陥る罠)を紹介します。業務で Windows 機を使い、開発したアプリは Linux で上で動かす、という(よくある)環境で育ってきました。個人では Linux をデスクトップ用途でも使ってます。

なお、以下では全角文字で「¥(円)」と「\(バックスラッシュ)」を記述していますが、全て半角文字の時に起こる問題です。


そんな自分が Mac mini を支給され、Mac OS で Node.js の開発をしていた時です。「テキストファイルを読み取って、行ごとに分解(して何らかの処理を)する」という、珍しいとも思えない行分解プログラムをこんな感じで正規表現を使って書いてました:
const fs = require( 'fs' );
var text = fs.readFileSync( "xxxx.txt" );
var lines = text.split( /¥r¥n|¥r|¥n/ );     //. 改行コードがどうなっているのかわからないので、考えられる3通りで
console.log( "#lines = " + lines.length );  //. 試しに何行のデータだったのかを確認

これで改行コードが LF+CR でも LF でも CR でも、どのパターンのファイルでも split できるはず! と思っていたのですが、どんなファイルを試しても
  #lines = 1
と表示されてしまうのでした。"1" ということは1行、つまり分割ができておらず、元のデータがまるごと1つの配列要素になっただけ、ということ。

あれ? 正規表現の指定の仕方はこれじゃないかな?? ちょっと自信がなくなって、改行コードをオペレーティングシステムの設定値から取得するように変えてみたのですが、これでも結果は変わりません(そりゃそうだ、元のファイルの改行コードが OS の設定値になっている保証はない):
const fs = require( 'fs' );
const os = require( 'os' );
var text = fs.readFileSync( "xxxx.txt" );
//var lines = text.split( /¥r¥n|¥r|¥n/ );
var lines = text.split( os.EOL );           //. オペレーティングシステムの改行コードを指定
console.log( "#lines = " + lines.length );  //. 試しに何行のデータだったのかを確認

今まで普通にできていたことが急にできなくなって、ついに若年性ナントカの症状が・・とか不安になったのですが、このことを先人に相談したら一発で解決しました。
  「マックは¥(円マーク)と\(バックスラッシュ)のコードが違う」


え?、どういうこと?? 何言ってるのかよくわからないんですけど。。 

というわけで、歴史的にもややこしい経緯ごと振り返って紹介します。以下は表記上でわかりやすくするために全角で¥と\を書きますが、実際は半角文字だと思ってください。

昔々、国際規格においては(日本の通貨記号である)¥という文字はありませんでした。国際規格では\という文字がキー文字として定義されており、その文字コードは 0x5C でした。ここまでは何の問題もありません。

ここから話がややこしくなってくるのですが、この 0x5C というコードには国際規格的には\(バックスラッシュ)文字が定義された上で「各国が別の文字記号を割り当ててもよい」とされたのでした。そこで日本ではよく使われる¥(円)文字を割り当てました。つまり日本規格では¥というキー文字が定義されており、その文字コードはやはり 0x5C となりました。ここまでもあくまで割り当てルールの話なので、まあわからなくもないです。


そして時代は流れ、コンピュータが世の中に普及してくるにつれ、これまでの先進国だけでなく発展途上国でも使われるようになってきました。すると、これまでのコンピュータ文字体系の仕組みの中で新しい言語を更に追加して個別に扱うことに無理が生じてきました。そして「あらためて世界中の文字を単一体系で表現できるようにしよう」というユニコード(Unicode)の規格が生まれ、これが広まっていきました。このユニコードでは\(バックスラッシュ)と¥(円)も別の文字として区別して定義されました。基本的にはこの Unicode が現在も世界中で使われている規格です。


この新しい規格では¥と\がちゃんと区別されたのはいいのですが、これに移行するにあたってこれまでに日本語のファイルの中で "¥" として書かれた文字は、ユニコードでは "¥" とするべきなのか "/" とするべきなのか、という正解のない新しい問題が生じてしまいました。

この時に、内部的にシフト JIS というコードを採用していた当時のマイクロソフトの日本語版 Windows では Unicode 対応するにあたって「シフト JIS の日本語の¥は、Unicode では全て\として扱う。ただし表示では¥とする」という「見た目を変えない」ことを重視した解決策を取りました。つまり日本語版 Windows で¥のつもりで入力していたものは、実際には全て\でした。その表示上の見た目だけが(本来は異なる)¥になっていたのでした。見た目を変えない現実的な方法だったと思いますが、これがわかりにくい混乱の原因にもなったのでした。

一方、アップルの Mac OS X では元から Unicode 規格が採用されていました。つまり元から¥と\は区別されていました。日本語版のキーボード右上の¥キーを表示されるものは、あくまで¥であり、Option キーと一緒に¥キーを押して表示されるものが\でした(つまり Mac OS X では \ を出す方がややこしい)。


僕自身はこの段階でも「この違いって普通に使ってて問題にならないの?」と感じたのですが、実際はあまり大きな問題にはなっていないようです。マイクロソフトの「見た目を¥にして、内部的に\を使う」という解決策がいかに現実的なものだったかということだと思いますし、なにより自分がいままで¥のつもりで入力していた文字が実は(内部的には)\だった、ということを知りませんでした。知らなくてもどうにかなっていた、という事実の説得力がとても大きく感じられます。


これで¥と\をめぐる歴史的な問題は解決されました。めでたし、めでたし・・・ というわけにはいかない問題が残ってました。日本語でも英語でもない、プログラミング言語が関わった場合の話です。


多くのプログラミング言語においてはバックスラッシュはタブや改行などの目に見えない制御文字を定義する時に使うなど、特殊な意味を持つ記号とされています。この特殊記号が日本のコンピュータ規格では(バックスラッシュではなく、同じコードを共有する)¥とされていました。例えばタブ記号は国際規格的には "\t"(バックスラッシュ+t) ですが、同じものが日本では "¥t" と表示されていたのでした。見た目は異なりますが、元々\と¥は 0x5C という同じコードを共有していたので「要するに同じ文字」で、この段階では日本においては ¥ イコール \ と思っておけばまあ問題ない、とされていました。事実自分も「この2つは同じもので、使うシステムやフォントによって表示時の見た目が変わる」程度に理解していました。

ところが厳密に Unicode が使われるようになると話が変わってきます。例えば画面上で "¥t" と表示されている文字の内部コードは、タブを意味する「バックスラッシュ+t」のことなのか、「円記号+t(こちらは特別な意味のない2文字)」のことなのかが、使っている機種によって違ってくる、という事態が起こってしまいました。例えば Windows を使っている人が書いた "¥t" という文字列(正確には「画面上で "¥t" と表示されている文字列」)と、Mac OS を使っている人が書いた "¥t" という文字列は内部的には別のものになる、ということになります。


で、冒頭の話です。自分はもともと Windows を使っていて(Linux を使う時も Windows のターミナルアプリから使っていて)、その感覚で改行コードは「¥r¥nと¥rと¥nの3種類を考えればいい」と判断して、
var lines = text.split( /¥r¥n|¥r|¥n/ );  //. 本当は全部半角

という、改行制御を行う特殊記号を指定した正規表現の書き方にしました。でもこれは Mac OS では特殊記号を指定する時には¥ではなく\を使って、
var lines = text.split( /\r\n|\r|\n/ );  //. 本当は全部半角

のように書くのが正解だったのでした。要するに慣用的に「¥と\は一緒」と思ってしまうと、この落とし穴に気付くことができず、見て写したり、コピペしたりした結果動かなくなる、という症状に悩まされることになるのでした。

プログラミング以外にも、文字コードで一致を探す検索の機能などでも意識する必要があると思うのですが、裏を返すとプログラミングとかしない人にとっては特に¥と\の違いを意識する必要もなく Mac も Windows も使えているわけで、すごい歴史の一端を垣間見る経験でした。


このページのトップヘ