はてなブックマーク

iPhoneや携帯における絵文字の扱いに関して、SoftBankへの要望がいくつかあるので（それから、先日コメント欄でお願いされたので）、メモ。 その1・受信側サーバでUnicode絵文字→SoftBank絵文字の変換をサポートしてほしい 現在、iPhoneの（メッセージアプリで）@softbank.ne.jpから携帯の@softbank.ne.jp宛に絵文字を送ると、空白になってしまう（下図）。 また、（これは以前からの仕様だが）iPhoneのメールアプリで@icloud.comなどから携帯の@softbank.ne.jp宛に絵文字を送った場合も同様（下図）。 受信側サーバがUnicode絵文字の変換をサポートすれば、この問題は解決する（下図）。ドコモiPhoneの登場により、ドコモの受信側サーバもUnicode絵文字の変換をサポートするようになった。auの受信側サーバは、以前からこれを

ところで、モリサワのPr6Nフォントがやばいらしいですね。 twitterで話題になってたね。 まとめを読んでも、ちょっとわかりにくかったんですけど、どういうことなんですか？ リュウミンとかのPr6/Pr6Nには複数のバージョンが存在して、新バージョンで作ったデータを旧バージョンの環境で開くと、豆腐になっちゃう文字があるんだよね。 うー、それはかなりイヤですね。 だよね。新バージョンのほうは、IVS（異体字シーケンス）対応版なんだけど、cmapも新しいのになってるから。 しーまっぷ？ cmapっていうのは、符号位置とグリフの対応表。DTP用の日本語OpenTypeフォント（Adobe-Japan1フォント）には、Unicodeに入ってないグリフもたくさん入ってるでしょ。 入ってますね。 「Unicodeに入ってない字」はcmapには載ってない。でも、そういう字が後からUnicodeに収録さ

欠字を意味するいわゆる「豆腐」の表示には、フォントのGID=0に割り当てられているグリフが用いられる*1。 こんなかんじ。まあ、XP以前のMSフォントが表示するような「・」は「豆腐」とは呼ばないだろうけど。 *1:このエントリの最初のバージョンには「ヒラギノなどのAdobe-Japan1フォントではGID=0にグリフが割り当てられていないので、OS X上のInDesignでよく見かける豆腐は、フォールバックで表示されるAquaKanaのGID=0だと思う」と書きましたが、それは勘違いでした。Adobe-Japan1フォントも豆腐（nofdef）グリフを持っています。@monokanoさん、ご指摘ありがとうございます！

IPAmj明朝を含むPDFを、iOSのメールアプリやiBooksで表示すると、特定のグリフが爆発する。 爆発前というか、爆発しない環境での表示は、こんなかんじ。 爆発するグリフをOTMaster Lightというツールで見てみた。爆発していた。 「Gridfit」のチェックを外したら、普通に表示された。 GridfitというのはTrueTypeフォントのヒンティング処理（の一部）だと思うが、そこから先はよくわからない。ただ、まったく別系統のアプリ（OTMasterとAppleのiOSアプリ）で同じ現象が見られるということは、たぶん（少なくとも）IPAmj明朝側には問題がありそう。メリー・クリスマス。

文字情報基盤のIVS登録（公開レビューはPRI 259）について検討したいのだけれど、その前に、前提となる基本的なことについて、ざっとおさらい。 文字情報基盤は汎用電子の後継プロジェクトだが、汎用電子が戸籍統一文字・住基ネット統一文字・登記統一文字を対象としていたのに対し、文字情報基盤は登記統一文字を対象としていない。 汎用電子（Hanyo-Denshi）コレクションは平成明朝で例示されている。文字情報基盤（Moji_Joho）コレクションはIPAmj明朝で例示されている。 Adobe-Japan1コレクションではすべての漢字のグリフが登録されているが、汎用電子コレクションではバリアントを持つグリフのみが（デフォルトグリフも含めて）登録されている。文字情報基盤は、汎用電子と同様のやり方。 Hanyo-Denshiコレクションは、言わば途中段階のものであって、戸籍統一文字・住基ネット統一文字

Mavericksでは、文字ビューアの「絵文字」から一部の絵文字を入力すると、「これは絵文字ですよ」ということを示す符号（U+FE0F）が自動的に付加されるようになった。また、文字ビューアの「矢印」「囲み文字」「象形文字」「標識／標準記号」などから一部の文字を入力すると、「これは絵文字ではありません」ということを示す符号（U+FE0E）が付く。 このような特殊な符号（VS: Sariation Selector）によって、文字を「絵文字スタイル」で表示するか否かを区別するしくみが、絵文字バリエーション・シーケンス。入力した文字にVSが付くかどうかは、文字ビューアの表示で確認できる。 文字ビューアのチャートが「Unicode」の場合は、VSが付かない。 そのようなわけで、親字は同じU+2600であっても、「素のU+2600」「非絵文字スタイルのU+2600 U+FE0E」「絵文字スタイルのU

日本がCJK統合漢字拡張F1/F2に提案している文字には、すでにUCSに入っている漢字と見分けがつかない例がいくつもある。これらは、提案書*1に「Similar and Variation」として既存の文字の符号位置が記載されているものの一部であり、つまり、似ている漢字の存在は百も承知で提案しているわけだ。 以下、そのような例を拾ってみた。左右に並べた文字のうち「UCS」欄に符号位置が入っているほうが、既存のもの。個々の文字について述べることはしないが、要するに「別字の衝突であれば、形が同じでも別の符号を与える」ということだろう。 だが、ちょっと待ってほしい。それって実はものすごく根本的な方針転換じゃないですか？　「機」の簡体字の「机」も「つくえ」の「机」も、形が同じである以上、同じ符号位置（U+673A）に包摂・統合するというのがCJK統合漢字の大原則であったはず*2。ここでいきなりそれ

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」としてあ

iPhone間の新しい文字化けパターンが発見されたのでメモ*1。この少なくとも3つのダメな仕様が重なって発生する文字化けは、発見者によって「兄化け」と命名された*2。 「兄化け」は、兄がSoftBankまたはauのiPhoneでメッセージアプリを、妹がiPhoneのメールアプリでdocomo.ne.jpアドレスを使っている場合に発生する。兄が絵文字入りのメールを送信すると、妹の環境では絵文字が豆腐に化け、それを引用して返信すると、今度は兄の側でメッセージ全文が化ける。 以下、この文字化けの理屈について。兄のメッセージアプリは、絵文字入りのメッセージをUTF-8で送信。キャリアの送信側のサーバが、これをドコモのShift_JISに変換する。しかし、妹のiPhoneのメールアプリはドコモのShift_JISに対応していないので、ドコモの絵文字を単に「Shift_JISの未定義領域の文字」として

（たぶん）ドコモiPhoneの登場にともなって、ドコモのサーバがUnicode絵文字に対応した。ドコモのケータイ宛にcharset=UTF-8でUnicode絵文字を送ると、ドコモのサーバがドコモのShift_JISに変換する。 どのような変換テーブルを用いているのか、確認した結果を以下にまとめておく。はてなダイアリーの文字数制限があるので、今回はUnicodeの絵文字対応表（http://www.unicode.org/Public/UNIDATA/EmojiSources.txt）でドコモと対応のある文字（要するに、iモードで表示できるはずの文字）について。 「目覚まし時計」「メリーゴーランド」「ポーチ」「座席」については、ドコモはEmojiSources.txtとは異なる解釈を採り、わざわざテキストに置き換えている（備考欄の絵文字が、EmojiSources.txtのマッピングに従っ

この項10月28日追記。iOS 7.0.3でSoftBank iPhoneのメールアプリの仕様が修正された。iOS 7.0.3にアップデートした場合、いちばん下の図（au→SoftBank）における2つの豆腐は、絵文字で表示される。 iOS 7のメールアプリでは（原因の多くはサーバ側にあるのだが）絵文字の表示におけるトラブルが多発している。これらの問題は、キャリアのメールアドレスを利用している場合に発生するので、ドコモ（@docomo.ne.jp）、au（@ezweb.ne.jp）、SoftBank（@i.softbank.jp）の組み合わせとトラブルの関係を、しくみも含めてまとめてみた*1。 受信側が@docomo.ne.jpで送信側が他のキャリアのアドレスである場合、絵文字は表示できない。iモード絵文字にない文字のほうが（フォールバックによってテキストとして）表示される可能性がある、と

ドコモiPhoneのメールアプリでdocomo.ne.jpアドレスを使用している場合、相手の環境にかかわらず送信も受信もできない文字が存在する*1。絵文字以外については、BMP（Unicodeの0面）外の文字がダメっぽい（下図）。たとえば「しかる」は「叱る」ではなく（改定常用漢字表の）「𠮟る」と書きたい人もいるかと思うが、それは化ける。 絵文字の送受信の可否は、相手の環境に左右される。その問題については、前回のエントリで述べた。しかし今回挙げる絵文字（キャリアのケータイ絵文字をソースとしないもの）は、相手が誰であっても送信も受信もできない（下図）。 サーバ側の仕様がAndroid端末の制限に引きずられているのかもしれない。 *1:akane_nekoさんにご協力いただいてテストしました。ありがとうございます！

ドコモiPhoneのメールアプリで@docomo.ne.jpを使った場合の絵文字について調べてみた*1。細かい話はいろいろあるし、すべての組み合わせについて検証したわけではないが、おおまかに言えば、下図のようなかんじだと思う。 送られてきた絵文字の表示については、UTF-8のUnicode絵文字は表示できるが*2、（キャリアのサーバが）「@docomo.ne.jp」というアドレスを見てドコモのShift_JISに変換して送ってきた絵文字は全滅。ドコモのケータイ→ドコモのiPhoneでもダメ。 ドコモiPhoneの@docomo.ne.jpアドレスから送信した絵文字については、（理由はわからないが）ドコモ以外の「ケータイのアドレス」宛の場合、すべて「〓」に変換される。 *1:akane_nekoさんにご協力いただいてテストしました。ありがとうございます！ *2:ただし、ケータイ絵文字をソース

この項10月28日追記。iOS 7.0.3でSoftBank iPhoneのメールアプリの仕様が修正された。 「iOS 7にしてから文字化けするようになった」という話には、知る限りにおいて2つのパターンがある。1つ目は「SoftBank iPhoneで受信したメールの絵文字が表示されない」というもの。その原因については、前回と前々回に述べた。2つ目は「送信したメールのすべての文字が相手先で化ける」というもの。今回は、こちらについて述べる。 この現象も、前回・前々回の話とつながっている。簡単に言うと、iOS 7のメールアプリは「SoftBank独自」の処理を行っていないように見える。このため、「これまでは（au iPhoneなどではcharset=CP932になるが）SoftBank iPhoneではcharset=Shift_JISになっていた」というケースで、charset=CP932に

この項10月28日追記。iOS 7.0.3でSoftBank iPhoneのメールアプリの仕様が修正され、charset=Shift_JISのSoftBank絵文字が表示されるようになった。 昨日のエントリの続き。iOS 6のSoftBank iPhoneでは、メールアプリはShift_JISのSoftBank絵文字（下図、黄色字の領域）をテーブル変換していたが、iOS 7ではこのプロセスが落ちていて、0xF040以降は機械的にUnicodeの私用領域の文字に変換されるようになった。このため、charset=Shift_JISで送られてきた絵文字は、大半が豆腐に化ける。 ただしiOSは、Unicodeの私用領域にSoftBank絵文字を収録している。このため、「機械的に私用領域の符号位置に変換された絵文字が、たまたま別の絵文字と衝突する」（つまり、別の絵文字に化ける）というケースもある。下

iOS 7では、ある種の絵文字を入力したとき、「これは絵文字ですよ」ということを示す符号（U+FE0F）が自動的にくっつくようになった。 これまで、「♥」のように絵文字と普通の文字が同じ符号位置を共有している例では、環境によってカラー絵文字で表示されたり、普通の文字として表示されたりした。たとえば、iOS 6のメールからMacに「赤いハートの絵文字」を送ると、Macのメールでは「黒いハート記号」が表示される。 このような表示のズレを解消するために、Appleが提案してUnicodeに導入されたしくみが、絵文字バリエーション・シーケンス（詳しくは「絵文字バリエーション・シーケンスとは何か」を参照）。iOS 7は、これを利用する。U+FE0Fの付いた「赤いハートの絵文字」は、Macのメールでも黒くならない。 ただしもちろん、絵文字バリエーション・シーケンスに対応していない環境（たとえば初代iP

改定前の常用漢字表では、「闘」の旧字体（康熙別掲字）がつぶれていて、字体が判別できない。この字を、JIS X 0213は下図のような例示字体で収録した。そして改定常用漢字表も、おそらくそれに倣っている。以下、「どうしてこれがこれになるの？」という素朴な疑問を出発点として調べてみた*1ことをメモしておくが、あらかじめ断っておくと、特におもしろい新事実が明らかになったりするわけではない。 「闘」の康熙別掲字の可能性があるのは、Unicodeの符号位置でいえばU+9B2CまたはU+9B2D。汎用電子（Hanyo-Denshi）のIVDには5種類、Adobe-Japan1のIVDには3種類の異体字が登録されている。 また、わたしのMacに入っている中文フォント（Songti SC）の字体、『明朝体活字字形一覧』（文化庁文化部国語課）に掲載されている字体なども含めると、「鬥」の中の「斲」の左の部分（

戸籍統一文字、住基ネット統一文字、登記統一文字に含まれる漢字の数について、面積比が正確になるように図を描いてみた*1。 法務省が戸籍のオンライン手続きのために整理した文字集合が、戸籍統一文字。この戸籍統一文字を拡張した文字集合が登記統一文字であり、拡張部分を登記固有文字と呼ぶ。図にすると、こんなかんじ。 総務省の住民基本台帳ネットワーク統一文字（住基ネット統一文字）には、法務省の戸籍統一文字・登記統一文字との互換性はない。図にすると、こんなかんじ。 この図に、JIS X 0208とJIS X 0213も入れてみる。住基ネット統一文字は基本的にJIS X 0213ベースだが、「JIS X 0213に含まれていて戸籍統一文字に含まれていない漢字」は、けっこうある。 IPAの文字情報基盤整備事業が対象としているのは、オレンジ色の枠で囲んだ部分。登記固有文字がんばれ。 *1:使っている数字は、『汎

この「雌」の字、IPAmj明朝では区別してるんだけど、どこが違うかわかる？ んー。無理に違いを探すなら、右上のあたりですかねー。 確かに、右側の「雌」のほうが、おっぱいが小さい。 おっぱい？　字源的にそうなんですか？ いや、ノリでそう呼んでみただけだが。 ……はあ。 で、このおっぱいの小さい「雌」がどこから来たかというと、戸籍統一文字なんだけどね。 あー、戸籍統一文字の時点で、すでにおっぱいのサイズが違いますね。 ところがこれ、画数の情報を見ると、左は14画で、右は13画なんだよ。 ん？ そもそも、おっぱい差は字体差ではなくデザイン差だから、そんな違いで戸籍統一文字に登録されるわけがない。 おっぱい差？ おっぱい差はサイズの差であって、骨格の差じゃないってこと。ポイントは、実はおっぱいじゃなく偏のほうで、3画目がそのままハネるかどうかの違いだな。 うーん。そう言われて見直してみても、右側の

この項6月20日追記。twitterでこのエントリのURLを添えて孫社長と宮川CTOに対応をお願いしたところ、わずか2日で対応していただきました（https://twitter.com/miyakawa11/status/347614628685180928）。ありがとうございます！ Appleのサポートコミュニティで見かけた事例。SoftBank iPhoneの@i.softbank.jpアカウントからau iPhoneの@ezweb.ne.jpアカウントにメールを送ったとき、以前は表示されていた特殊顔文字など（要するに、Unicodeでしか表現できない文字）が豆腐や空白に化けるようになった。 何が原因なのか調べてみた*1結果、SoftBankの@i.softbank.jp用のサーバの仕様が（望ましくない方向に）変更されたようなので*2、SoftBankのサポートに電話で訴えてみたのだけ

半年くらい前にツイートした件なのだけれど、より詳しい情報も含めてまとめておく。発端は@tree3yamaさんの、この発言。 えっ？と思ってjp90タグのターゲットとなる160字（Adobe-Japan1フォントではjp90グリフとjp04グリフが異なる字）について調べてみたところ、下図のようにjp90グリフだったりjp04グリフだったりバラバラの結果だった*1。「mj」欄がIPAmj明朝002.01、「Koz」欄は比較用の小塚明朝Pr6N。ピンク地がjp90グリフ、白地はjp04グリフ。 IPAmj明朝の実装方針についての資料を探したところ、第3回文字情報基盤推進委員会配布資料（http://ossipedia.ipa.go.jp/doc/476/）の資料4「文字情報検討状況について」における「4. IPAmj明朝での符号化実装の優先順位について」に、次のような記述があった。 1) 常用漢

関連するエントリのインデックス。タイトルだけでは中身がわかりにくかったりするので、こういう形でまとめておくことにした。基本的に、説明は上から順に読んでいただくのがいいかと。 説明（対話形式） MS122とは何か（昔のグリフで出ています） VistaにおけるMS明朝の字形変更（俺のMS明朝がこんなに可愛いわけがない） MS明朝・MSゴシックのIVS実装（人生がときめくWindows 8のIVS実装） メイリオのIVS実装（もし田村ゆかりがメイリオの実装に突っ込んだら） Windows 8のIVS実装一覧表 HTML版 画像版

前回の「Windows 8のIVS実装一覧表」を見てて思ったんですけど、これ見よがしに色を付けて強調されてる例がありますよね。 ああ、メイリオだけがサポートしている（MS明朝・MSゴシックがサポートしていない）IVSね。 これって、どこから来た字なんですか？ その話については、深夜アニメ「刀語」の奇策士とがめ（声：田村ゆかり）が正拳突きを繰り出しながらメイリオの実装に「めいりおー！」って突っ込むネタを構想してたんだけどさ。 ……？ 着地できずに断念した。ちなみに、とがめは向かって右のほうだぞ。 ちょっと何を言ってるんだかわかりませんが、思いとどまって正解でした。 で、丁寧な説明と簡単な説明があるけど、どっちがいい？ じゃあ、丁寧なほうで。 この5文字が何者かって言うと、「Windows 8のメイリオで新たにUnicodeの符号位置と対応づけられた漢字」なんだけどね。*1 んー。要するに、新

Windows 8のMS明朝・MSゴシックは122字、メイリオは127字のIVSをサポートしている。以下、その一覧表。 この表はIVSを含むソースを作成してCSSでフォントを指定したものなので、Windows 8以外の環境では、もちろんそれなりにしか見えない。ピンク地は、MS明朝・MSゴシックではサポートされていないIVS。 基底文字 VS IVS（基底文字＋VS） 符号位置 MS明 MSゴ Meiryo 符号位置 MS明 MSゴ Meiryo 識別子 5026 倦 倦 倦 E0100 倦󠄀 倦󠄀 倦󠄀 CID+1863 50C5 僅 僅 僅 E0100 僅󠄀 僅󠄀 僅󠄀 CID+1735 5132 儲 儲 儲 E0100 儲󠄀 儲󠄀 儲󠄀 CID+3813 51A4 冤 冤 冤 E0100 冤󠄀 冤󠄀 冤󠄀 CID+4228 537F 卿 卿 卿 E0101 卿