Mavericksの絵文字バリエーション・シーケンス
- Mavericksでは、文字ビューアの「絵文字」から一部の絵文字を入力すると、「これは絵文字ですよ」ということを示す符号（U+FE0F）が自動的に付加されるようになった。また、文字ビューアの「矢印」「囲み文字」「象形文字」「標識／標準記号」などから一部の文字を入力すると、「これは絵文字ではありません」ということを示す符号（U+FE0E）が付く。
- このような特殊な符号（VS: Sariation Selector）によって、文字を「絵文字スタイル」で表示するか否かを区別するしくみが、絵文字バリエーション・シーケンス。入力した文字にVSが付くかどうかは、文字ビューアの表示で確認できる。
- 文字ビューアのチャートが「Unicode」の場合は、VSが付かない。
- そのようなわけで、親字は同じU+2600であっても、「素のU+2600」「非絵文字スタイルのU+2600 U+FE0E」「絵文字スタイルのU+2600 U+FE0F」の3種類が、同一のドキュメントに混在し得ることとなる。
- あなたの環境における絵文字バリエーション・シーケンスの見え方は、以下のとおり。
| 符号位置 | VSなし | +FE0E | +FE0F |
|---|---|---|---|
| 203C | ‼ | ‼︎ | ‼️ |
| 2049 | ⁉ | ⁉︎ | ⁉️ |
| 2139 | ℹ | ℹ︎ | ℹ️ |
| 2194 | ↔ | ↔︎ | ↔️ |
| 2195 | ↕ | ↕︎ | ↕️ |
| 2196 | ↖ | ↖︎ | ↖️ |
| 2197 | ↗ | ↗︎ | ↗️ |
| 2198 | ↘ | ↘︎ | ↘️ |
| 2199 | ↙ | ↙︎ | ↙️ |
| 21A9 | ↩ | ↩︎ | ↩️ |
| 21AA | ↪ | ↪︎ | ↪️ |
| 231A | ⌚ | ⌚︎ | ⌚️ |
| 231B | ⌛ | ⌛︎ | ⌛️ |
| 24C2 | Ⓜ | Ⓜ︎ | Ⓜ️ |
| 25AA | ▪ | ▪︎ | ▪️ |
| 25AB | ▫ | ▫︎ | ▫️ |
| 25B6 | ▶ | ▶︎ | ▶️ |
| 25C0 | ◀ | ◀︎ | ◀️ |
| 25FB | ◻ | ◻︎ | ◻️ |
| 25FC | ◼ | ◼︎ | ◼️ |
| 25FD | ◽ | ◽︎ | ◽️ |
| 25FE | ◾ | ◾︎ | ◾️ |
| 2600 | ☀ | ☀︎ | ☀️ |
| 2601 | ☁ | ☁︎ | ☁️ |
| 260E | ☎ | ☎︎ | ☎️ |
| 2611 | ☑ | ☑︎ | ☑️ |
| 2614 | ☔ | ☔︎ | ☔️ |
| 2615 | ☕ | ☕︎ | ☕️ |
| 261D | ☝ | ☝︎ | ☝️ |
| 263A | ☺ | ☺︎ | ☺️ |
| 2648 | ♈ | ♈︎ | ♈️ |
| 2649 | ♉ | ♉︎ | ♉️ |
| 264A | ♊ | ♊︎ | ♊️ |
| 264B | ♋ | ♋︎ | ♋️ |
| 264C | ♌ | ♌︎ | ♌️ |
| 264D | ♍ | ♍︎ | ♍️ |
| 264E | ♎ | ♎︎ | ♎️ |
| 264F | ♏ | ♏︎ | ♏️ |
| 2650 | ♐ | ♐︎ | ♐️ |
| 2651 | ♑ | ♑︎ | ♑️ |
| 2652 | ♒ | ♒︎ | ♒️ |
| 2653 | ♓ | ♓︎ | ♓️ |
| 2660 | ♠ | ♠︎ | ♠️ |
| 2663 | ♣ | ♣︎ | ♣️ |
| 2665 | ♥ | ♥︎ | ♥️ |
| 2666 | ♦ | ♦︎ | ♦️ |
| 2668 | ♨ | ♨︎ | ♨️ |
| 267B | ♻ | ♻︎ | ♻️ |
| 267F | ♿ | ♿︎ | ♿️ |
| 2693 | ⚓ | ⚓︎ | ⚓️ |
| 26A0 | ⚠ | ⚠︎ | ⚠️ |
| 26A1 | ⚡ | ⚡︎ | ⚡️ |
| 26AA | ⚪ | ⚪︎ | ⚪️ |
| 26AB | ⚫ | ⚫︎ | ⚫️ |
| 26BD | ⚽ | ⚽︎ | ⚽️ |
| 26BE | ⚾ | ⚾︎ | ⚾️ |
| 26C4 | ⛄ | ⛄︎ | ⛄️ |
| 26C5 | ⛅ | ⛅︎ | ⛅️ |
| 26D4 | ⛔ | ⛔︎ | ⛔️ |
| 26EA | ⛪ | ⛪︎ | ⛪️ |
| 26F2 | ⛲ | ⛲︎ | ⛲️ |
| 26F3 | ⛳ | ⛳︎ | ⛳️ |
| 26F5 | ⛵ | ⛵︎ | ⛵️ |
| 26FA | ⛺ | ⛺︎ | ⛺️ |
| 26FD | ⛽ | ⛽︎ | ⛽️ |
| 2702 | ✂ | ✂︎ | ✂️ |
| 2708 | ✈ | ✈︎ | ✈️ |
| 2709 | ✉ | ✉︎ | ✉️ |
| 270C | ✌ | ✌︎ | ✌️ |
| 270F | ✏ | ✏︎ | ✏️ |
| 2712 | ✒ | ✒︎ | ✒️ |
| 2714 | ✔ | ✔︎ | ✔️ |
| 2716 | ✖ | ✖︎ | ✖️ |
| 2733 | ✳ | ✳︎ | ✳️ |
| 2734 | ✴ | ✴︎ | ✴️ |
| 2744 | ❄ | ❄︎ | ❄️ |
| 2747 | ❇ | ❇︎ | ❇️ |
| 2757 | ❗ | ❗︎ | ❗️ |
| 2764 | ❤ | ❤︎ | ❤️ |
| 27A1 | ➡ | ➡︎ | ➡️ |
| 2934 | ⤴ | ⤴︎ | ⤴️ |
| 2935 | ⤵ | ⤵︎ | ⤵️ |
| 2B05 | ⬅ | ⬅︎ | ⬅️ |
| 2B06 | ⬆ | ⬆︎ | ⬆️ |
| 2B07 | ⬇ | ⬇︎ | ⬇️ |
| 2B1B | ⬛ | ⬛︎ | ⬛️ |
| 2B1C | ⬜ | ⬜︎ | ⬜️ |
| 2B50 | ⭐ | ⭐︎ | ⭐️ |
| 2B55 | ⭕ | ⭕︎ | ⭕️ |
| 303D | 〽 | 〽︎ | 〽️ |
| 3297 | ㊗ | ㊗︎ | ㊗️ |
| 3299 | ㊙ | ㊙︎ | ㊙️ |
| 1F004 | 🀄 | 🀄︎ | 🀄️ |
| 1F17F | 🅿 | 🅿︎ | 🅿️ |
| 1F21A | 🈚 | 🈚︎ | 🈚️ |
| 1F22F | 🈯 | 🈯︎ | 🈯️ |
- 関連するエントリはこちら。
CJK統合漢字拡張Fがヤバイ
- 日本がCJK統合漢字拡張F1/F2に提案している文字には、すでにUCSに入っている漢字と見分けがつかない例がいくつもある。これらは、提案書*1に「Similar and Variation」として既存の文字の符号位置が記載されているものの一部であり、つまり、似ている漢字の存在は百も承知で提案しているわけだ。
- 以下、そのような例を拾ってみた。左右に並べた文字のうち「UCS」欄に符号位置が入っているほうが、既存のもの。個々の文字について述べることはしないが、要するに「別字の衝突であれば、形が同じでも別の符号を与える」ということだろう。
- だが、ちょっと待ってほしい。それって実はものすごく根本的な方針転換じゃないですか？ 「機」の簡体字の「机」も「つくえ」の「机」も、形が同じである以上、同じ符号位置（U+673A）に包摂・統合するというのがCJK統合漢字の大原則であったはず*2。ここでいきなりそれをひっくり返しますか？
- この項追記。「戸籍統一文字は行政システムが使用している文字であるから、そこで区別されている文字はUCSでも区別するべきだ」という主張であれば、（賛成はしないが）それは包摂の原則とは異なるレベルの話だから、まだ理解はできる。しかし、今回の拡張F1/F2への提案は、戸籍統一文字を一律に区別しようというものではない。たとえば以前のエントリ（石井茂吉はおっぱいの夢を見るか）で取り上げた画数違いの「雌」などは提案されていないし、他にもこれに類する例は「紫」などいくつもある。「雌」や「紫」の例については、画数は違っても「別字」ではないから提案していないということだろう。そうであればやはり、今回の提案はCJK統合漢字の大原則をひっくり返そうとするものであると考えざるをえない。
- CJK統合漢字拡張F1/F2に日本が提案している文字すべてのリストは、以下。
日本ソースのCJK統合漢字拡張F1候補・その1
日本ソースのCJK統合漢字拡張F1候補・その2
日本ソースのCJK統合漢字拡張F2候補・その1
日本ソースのCJK統合漢字拡張F2候補・その2
日本ソースのCJK統合漢字拡張F2候補・その3
日本ソースのCJK統合漢字拡張F2候補・その4
日本ソースのCJK統合漢字拡張F2候補・その5
*1:IRGN1882、Attributes、Attributes_NoEvidence。
*2:「机」は日中間の例だが、JIS X 0208における別字衝突の例としては、「芸亭」の「芸（ウン）」と「芸術」の「芸（ゲイ）」の包摂などがよく知られている。
i.softbank.jpから送信した絵文字のフォールバック
- SoftBank iPhoneのメールアプリで@i.softbank.jpアドレスから絵文字入りのメールを送信すると、charset=Shift_JISになる*1。このため、SoftBank絵文字との対応関係を持たない絵文字は、すべて比較的意味合いの似た絵文字または「〓」に置き換えられる。このフォールバック処理は、サーバではなくiPhone側で行われるので、書きかけのメールを下書き保存して開き直しただけで絵文字が置き換えられている。
- 下図は、@i.softbank.jpアドレスから送信すると他の絵文字に置き換えられる絵文字のリスト。
- 下図は、@i.softbank.jpアドレスから送信すると「〓」に置き換えられる絵文字のリスト。ざっと見たかんじ「これなら『〓』にするよりは他の絵文字に置き換えたほうがいいんじゃないの？」という例もいくつかある。
絵文字が表示されない状況について改めてまとめてみる
- 絵文字の送受信に関しては、送り手と受け手の環境やメールアドレスの組み合わせによって結果が異なってくることに加え、文字ごとにキャリアの変換テーブルの影響を受けるため、その全容を記述するのは難しい。そこで今回は、「変換テーブルの影響」はバッサリ切り捨て、どのキャリアでも表示可能なペンギンの絵文字に絞って、基本となる「送り手と受け手の環境やメールアドレスの組み合わせ」について、できるだけ網羅的に記述することとした*1。
- SoftBank iPhoneでは、iOS 7.0.0から7.0.2までの間、メールアプリの仕様が変わったことによる絵文字のトラブルが多発していたが、iOS 7.0.3で以前と同様の仕様にもどって安定した。以下の図はすべて、iOS 7.0.3をベースとしている。
- iPhoneから一般の（キャリアのものではない）メールアドレスで送信した場合（図では「@icloud.com」としてあるが、これはあくまで一例*2）。絵文字はUTF-8で送信され、必要に応じてキャリアの受信側サーバで変換されて届く。現在、キャリアの受信側サーバのなかでは、SoftBankだけがUnicode絵文字の変換に対応していない。iPhoneの販売で先行していたSoftBankだが、iPhone側のハードコードによって絵文字をサポートしてきたぶん、サーバ側の対応が遅れているということだろうか。
- ドコモの携帯またはAndroid端末から@docomo.ne.jpで送信した場合。キャリア独自のShift_JISをiPhone側でデコードできず、絵文字が豆腐として表示される問題は、SoftBank iPhoneではiOS 7.0.3で修正されたが、ドコモiPhoneでは直っていない。今後を考えると、SoftBankのようにiPhone側のハードコードで対応するより、auのように受信側サーバで対応したほうがいいと思う。
- auの携帯またはAndroid端末から@ezweb.ne.jpで送信した場合。キャリア以外のメールアドレス宛にauのISO-2022-JPをそのまま送るのは、auの伝統（？）。Unicode絵文字が浸透しつつあるので、今後の可能性としては「キャリア以外のメールアドレス宛には送信側サーバでUTF-8（Unicode絵文字）に変換する」という実装も考えられるかもしれない。ドコモiPhoneで受信すると絵文字が豆腐になるのは、ドコモ側の問題。
- SoftBank iPhoneの@i.softbank.jpまたは携帯の@softbank.ne.jpで送信した場合。基本的に前項のauと同じだが、SoftBankの送信側サーバは、キャリア以外のメールアドレス宛には、絵文字を「〓」に変換して送信する。
*1:akane_nekoさん、MD5500さんにご協力いただいてテストしました。ありがとうございます！
iPhone間の新しい文字化け「兄化け」
- 「兄化け」は、兄がSoftBankまたはauのiPhoneでメッセージアプリを、妹がiPhoneのメールアプリでdocomo.ne.jpアドレスを使っている場合に発生する。兄が絵文字入りのメールを送信すると、妹の環境では絵文字が豆腐に化け、それを引用して返信すると、今度は兄の側でメッセージ全文が化ける。
- 以下、この文字化けの理屈について。兄のメッセージアプリは、絵文字入りのメッセージをUTF-8で送信。キャリアの送信側のサーバが、これをドコモのShift_JISに変換する。しかし、妹のiPhoneのメールアプリはドコモのShift_JISに対応していないので、ドコモの絵文字を単に「Shift_JISの未定義領域の文字」として機械的な計算でUnicodeの私用領域にマッピングし、豆腐として表示する。
- 妹がこの豆腐入りのメッセージを引用して返信すると、charset=CP932になる。このメールアプリの仕様はまったく謎だが、Shift_JISを解釈（デコード）するときと同じロジックで符号化（エンコード）しているので、来たときと同じ符号にもどり、この後うまくいけば、兄の環境では元の絵文字が表示される可能性もある*3。
- しかし、ドコモの送信側のサーバはcharset=CP932をスルー。結局このまま兄のもとに届く。メッセージアプリはCP932を理解できず、UTF-8として解釈する。この結果、（ASCIIに含まれる文字以外は）すべての文字が化けて表示される。
- 「兄化け」を防ぐためには、「キャリアのメールアドレスを使わない」というのがいちばんシンプルな方法だが、妹が兄に返信する際、引用文中の豆腐を消しておくという対処法によって、兄側の文字化けを防ぐことはできる。
*1:akane_nekoさんにご協力いただいてテストしました。ありがとうございます！
*2:命名の背景などは省略。……と書いたのですが、その後@monokanoさんがまとめてくれました。ありがとうございます！ http://togetter.com/li/580702
*3:図の例では、ドコモのShift_JISにおけるペンギンの絵文字（0xF9F5）がメールアプリではUnicodeの私用領域の文字（U+E750）として表示され、返信のメッセージではこれが再び0xF9F5になっている。
