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

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

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

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

この項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) 常用漢

『Unicode IVS/IVD入門』（田丸健三郎、小林龍生）のなかで、目玉がWindows 8のIVS対応を紹介している第2章だとするなら、背骨といえるのが、IVSという枠組み自体について解説している第5章だよね。 たとえがしっくりきませんが、こだわらずに先に進みましょう。 その第5章のなかでも、IVSの基本中の基本をわずか1行に凝縮して視覚化しているのが、図5-7だ。 はいはい。 で、今日は図5-7に突っ込んでみようと。 もちろん、突っ込みますよー！ あのさ、そういうテンションいらないから。この図なんだけど、どう？ んー、解説抜きで見せられても、ちょっと難しいですね。 いや、本当は難しくないんだよ。「漢字に異体字セレクタを付けるとグリフを指定できます」って言ってるだけの図なんだから。 この真ん中の「E010B」が右では「E0110」に変化してるのは、どういう意味なんですか？ 誤植だね。

『Unicode IVS/IVD入門』（田丸健三郎、小林龍生）を読んでいたら、いくつか気になる点があったので、まとめてみることにした。とりあえず、第4章（37ページ分）だけ。時間と気力があれば、今後、他も追加していくかも*1。組版上の突っ込みは（ひどい例以外は）省いた*2。 p.103 ISO/IEC 8859は《中略》パート16まで定義されています（パート15は破棄）。 破棄されたのはパート12。 p.104 「ISO-10646」の文字集合 「ISO-10646」→「ISO/IEC 10646」。 たとえば、1面19区75点を符号位置とする文字をシフトJISで8ビット符号化した場合0x8A6Bとなる文字を例に見てみましょう。この文字は、葛飾区の「葛」という文字ですが 「葛」はシフトJISで「0x8A6B」ではなく「0x8A8B」。 p.106 「U+000000」→「U+0000」（U

そんなわけで、アイルランドがUCS（Unicode）に押し込んだ3つのハンドジェスチャーのうち最後の1つが、これなんだけどね。 わあ！　またやばそうなのが来ました！ これがやばく見えるなら、それは心の鏡に映ったきみ自身のやばさを見てるんじゃないかな。 ちょっと何言ってるかわかんないです。 『スタートレック』って観たことある？ わりと最近のリメイク版なら観ましたけど。 んー、それはリメイク版じゃなくて、映画版の第11作だろうな。まあ、そんなことはいいんだけど、つり眉でおかっぱ頭でエリートくさいスポックっていうバルカン星人が出てきたでしょ？ 名前は忘れましたけど、いましたね、おかっぱ星人。 で、そのバルカン星人のスポックが、手をこんな形にして「長寿と繁栄を！」って言ってなかった？ 言われてみれば、そんなシーンがあったような、なかったような。 それがバルカン式挨拶（Vulcan salute）だ

だれかにメールを出すとき、どんな宛名で届いてるのか、不安になることってないですか？ ん、なんで？ MacやiPhoneのメールって、表示されてる差出人や宛先を見ただけじゃ、本当はそこに何が書いてあるかわからないじゃないですか。で、気付かないうちに本人に見られたくない名前が送られちゃたりしないかな、と。 あー、たとえば「ほげ山」さんのメールアドレスを自分の連絡先には「バカ先生」って名前で登録してますみたいなこと？　そういうの（下図）は危険だぞ。 こっちで「バカ先生」って表示されてるメールに返信すると、相手にも「バカ先生」で届くんですか？ いや、そうとは限らなくて、けっこう複雑なんだよね。たとえば、連絡先に「バカ先生」が登録されている環境で、ほげ山さんからFrom欄に「ほげ山 」と書いてあるメールを受け取ったとすると、山ライオンやiOSのメールアプリでは、こんなふうに見える（下図）*1。リスト

たとえば、仕事用のメールの署名に「☎」という文字を入れていたら、iPhoneではそれが絵文字の赤電話として表示されてびっくり。というような経験をしたことがある人は、たぶん少なくないと思う。こういうことが起きるのは、「絵文字じゃない文字」と「絵文字」がUnicodeでは同じ符号位置に包摂されていて、どちらが表示されるかはフォント（の優先順位）次第だからだ。 ケータイ絵文字をUnicodeに収録する際、Appleはすべての絵文字に独立した（通常の文字とは別の）符号位置を与えたかったようだが、それはかなわなかった。そこで次善の策として、「絵文字じゃない文字」と「絵文字」をプレーン・テキストで区別するメカニズムをUnicodeに提案した。それが絵文字バリエーション・シーケンス（EVS）だ*1。EVSはUnicode 6.1に入り、Mountain Lionでサポートされた。下図は、Mountain

昨日のエントリ（「iPhoneのMailから送ったメッセージ全体が文字化け」のまとめ）読みましたよー。iPhoneから送るメールの文字化け防止策は、署名に「♡」を入れておけばOKなんですよね？ うん。ただまあ、ちょっと気にする人はいるかもなあ。 男子に誤解されちゃう、と？ いや、そういうのじゃなくて、つまり、化けちゃうんだよね。 えっ？ 相手の環境によっては「♡」が化けるんだよ。 何ですかそれ。文字化け対策で入れた文字が化けたら意味ないじゃないですか。 意味はあるよ。iPhoneから送ったメールは相手先で全体が化けて読めなくなる可能性があるけど、「♡」でcharset=UTF-8にしておけば、この「全体化け」を防げるんだから。ただし、相手がケータイだったりすると、「♡」自体は「･」とか「?」とかになっちゃうってこと。 自らは捨て石となってメッセージ全体を救うということですか。UTF-8にな

Unicode絵文字に「オレンジ色の本」（U+1F4D9 ORANGE BOOK）ってあるじゃないですか。 うん。auがソースだっけ。 それが、Lionの絵文字で表示したら、ほら、紫色なんですよ。 ああ、それね。もっと大きいサイズで表示すればオレンジ色になるよ。 えーっ、ホントですか？ いや、ウソだけどさ。 ……。 ま、座れよ。マジレスすると、絵文字の場合、Unicodeの文字名に入ってる色の情報は、そのまま実装しなくてもいいんだよ。文字名と実装の色が一致しない絵文字って、けっこうあるぜ。このあたりとか。 でもそれは、もともとUnicodeに入っていた白や黒の文字に、ケータイ絵文字が統合されちゃった例ですよね。純粋なケータイ絵文字とは違うんじゃないですか。 そうでもないんだな。たとえばこの緑と紫のボタンなんてSoftBank絵文字だけをソースとしてUnicodeに入ったんだけど、文字名は黒

ここに2匹のプードルがいるんだけどね。 間違い探しですか？　ズバリ、左にだけ眉毛がありますね。 うん。眉毛があるほうが、iPhoneやLionに入ってる絵文字フォントのプードル。眉毛のないほうが、Unicodeのコードチャートに載ってるプードル。 えっ、どういうことですか？ そもそもUnicodeにケータイ絵文字を入れようって提案したのがGoogleとAppleだからね。提案書のための絵文字をAppleが用意して、それがUnicodeに収録された。そのあとで、iPhone絵文字に含まれていなかった文字については、データを流用して絵文字フォントに追加したってことじゃないかな。 だからほとんど同じなんですね。でも、眉毛はどうなりました？ ケータイ絵文字をUnicodeに収録する過程では、いろいろあってさ。たとえば、日本の絵文字のマンガっぽさをめぐる戦いとか。ほら、アイルランド・ドイツ修正案って

もうすぐお正月だし、こんな図を作ってみたんだけどね。 十二支ですか？　いろんな国の十二支？ そうそう。実はこれ全部、「どこの国の十二支の何番目の動物」という情報まで含めて、Unicodeのコードチャートに載ってるものなんだよね。 いちばん左の列が標準的な十二支ってことですね。 うん。日本だと、12番目のイノシシだけが独自仕様だな。それが標準仕様だとブタ。 カザフスタンでは、来年の干支はカタツムリですか。 よくわからないけど、そうなのかな。 このペルシアのネズミは、どうして小さいんですか？　標準仕様のネズミの絵を縮小したみたいに見えますけど。 それはネズミの種類が違うんだよ。ドブネズミとハツカネズミ。 え？　でもこれ、文字なんだから、たとえばゾウでもアリでも同じ大きさに描かれるものですよね。 原則は、そうだね。 じゃあ、どうしてドブネズミを縮小したのがハツカネズミなんですか？ まあ、ちょっと

Appleカラー絵文字って何？ iPhoneやLionに搭載されている絵文字フォントの名前だよ。Lionをインストールすると、iPhoneのカラー絵文字がMacでも使えるようになるんだ。文字ビューアの「絵文字」から入力できるよ。 iPhoneとLionでは、絵文字に違いはあるの？ いちばん目立つ違いは、Lionでは文字が増えてることかな。 わあ、どんなのが増えたの？ ナマハゲとか天狗とかナルトとか。 これ、モノクロじゃん。 増えてるぶんは、ぜんぶモノクロ。Lionは、Unicodeに収録されたケータイ絵文字のうち、Softbank絵文字以外を、いわば「docomo/au互換絵文字」としてモノクロでサポートしている*1。このモノクロの絵文字は、文字ビューアの「絵文字」には表示されない。Font Bookでレパートリーを表示すると、下のほうに入ってるよ。 Gmailを使えば、以前からMacでも

以前「雪だるまの親子関係」という記事を書いたことがある。そのころ、Unicodeに雪だるまは1つ（U+2603 SNOWMAN）しか入っていなかった（下図、左端はUnicodeの例示字形）。 その後、Unicode 5.2で、降雪なしの雪だるま（U+26C4 SNOWMAN WITHOUT SNOW）と黒雪だるま（U+26C7 BLACK SNOWMAN）が入った。これにともない、U+2603 SNOWMANの例示字形も、他の2つと統一感のあるものに変更された。雪だるま3兄弟の例示字形はかなり抽象化されており、雪だるまというより、むしろサルの顔のアップに見える。 Unicode 5.1以前には、U+2603 SNOWMANにおける降雪の有無は包摂されていたと見なすことができるが、Unicode 5.2で白雪だるまの「降雪あり」と「降雪なし」はU+2603とU+26C4に包摂分離される。この

（ホー先生）Macの画面で「●▲■」の「●」と「■」だけが小さく見えることがあるのはなぜじゃ*1。 「●」と「■」が欧文フォントで表示されているからだよ。たとえばMacのFinderでは、ファイル名は「Lucida Grande優先」で表示される。Lucida Grandeは「●（U+25CF）」や「■（U+25A0）」のグリフを持っているけれど、「▲（U+25B2）」のグリフを持っていない。だから「▲」はヒラギノで表示されて、「●」と「■」だけが小さく見えるんだ。同じ理由で起きる現象としては、三点リーダの位置が下にズレたりすることも、よくあるよね。 Finder以外でもよくあるんじゃが。 Appleのソフトは世界共通の仕様なので、デフォルトは欧文フォントだよ（下図）。 日本語フォントを指定すれば、この問題は避けられるのか。 うん。Finderでは基本的にフォントの変更はできないけどね。そ

日本語EUC（EUC-JP）にはいろいろあって頭がこんがらがってきたので、サルにもわかるように（つまり、自分があとから見て理解できるように）まとめてみた*1。まず、EUC-JPにはどんな種類があるのだろうということで、わたしの環境で実装例を確認できるものをピックアップしてみた。下図のうちeucJP-openとIANAのEUC-JPについては身近な実装例を思いつかなかったが、これを外すわけにはいかないだろうと思って入れておいた。 各EUC-JPのレパートリをまとめたのが、下図。eucJP-openには上図に示したようなバリエーションがあるが、レパートリは共通。「JIS X 0208の国際基準版・漢字用8ビット符号 + JIS X 0201片仮名」については、これを一言で表現できる呼称を思いつかないので、以下の図では仮に「TextEdit」と表記する。 下図は、各EUC-JPのレパートリと符号