ブログトップ 記事一覧 ログイン 無料ブログ開設

Mac OS Xの文字コード問題に関するメモ このページをアンテナに追加 RSSフィード

2014-03-05

PRI 259にコメントした

  • 文字情報基盤(Moji_Joho)のIVS登録にともなう公開レビュー(PRI 259)にコメントした。PDFこちら。日本語。もう、最初から最後まで日本語。
  • 安岡孝一さんが挙げていた(yasuokaの日記:文字情報基盤のIVS登録第1弾)ような「Hanyo-DenshiとMoji_JohoでIVSをシェアしようとしてるが、グリフに差異が見られる例」については、いくつか見つけたものの、リストの最初のほうしかチェックできなかったので、言及するのを断念。他にも、CJK互換漢字グリフの扱い、Ken Lundeさんが挙げていた(CJK Type: PRI 259)U+6723とU+81A7の問題など、いろいろ論点はあると思うが、今回はスルーした。

2014-01-16

SoftBankの絵文字の扱いに関するお願い



その1・受信側サーバUnicode絵文字→SoftBank絵文字の変換をサポートしてほしい

  • 現在、iPhoneの(メッセージアプリで)@softbank.ne.jpから携帯の@softbank.ne.jp宛に絵文字を送ると、空白になってしまう(下図)。

  • また、(これは以前からの仕様だが)iPhoneのメールアプリで@icloud.comなどから携帯の@softbank.ne.jp宛に絵文字を送った場合も同様(下図)。

  • 受信側サーバUnicode絵文字の変換をサポートすれば、この問題は解決する(下図)。ドコモiPhoneの登場により、ドコモの受信側サーバUnicode絵文字の変換をサポートするようになった。auの受信側サーバは、以前からこれをサポートしている。


その2・そうすればiPhoneのメールアプリのハードコードはもう不要

  • 以前からSoftBank iPhoneは、SoftBank絵文字をcharset=Shift_JISで送信するようカスタマイズされていたが、iOS 7.0.0では、SoftBank iPhoneのメールアプリは(他社のiPhoneと同様に)送信者が@i.softbank.jpアドレスである場合も絵文字をUTF-8で送信するようになり、また、受信したSoftBankShift_JISデコードできない仕様となった。このため、絵文字が表示できないトラブルが多発し、iOS 7.0.3ではiOS 6以前の仕様に戻された。しかし、受信側サーバUnicode絵文字の変換をサポートしていれば、メールアプリをカスタマイズする必要はない。charset=UTF-8で送信すれば、下図のような不要なフォールバック(i.softbank.jpから送信した絵文字のフォールバック)がなくなり、ユーザにとってメリットが大きい。


その3・送信側サーバではUTF-8をスルーしてほしい

  • 現在、iPhoneの(メッセージアプリで)@softbank.ne.jpからiPhoneの@docomo.ne.jp宛に絵文字を送ると、豆腐になってしまう(下図)。これは、iOS 7.0.0から7.0.2の間@i.softbank.jp宛で発生していた問題と同じ(docomo iPhoneのメールアプリがdocomoのShift_JISデコードできない)。docomoのサーバは、iPhoneを販売するようになってからはUTF-8の変換に対応しているので(ドコモのUnicode絵文字対応表123)、(@docomo.ne.jpを利用している宛先の端末がiPhoneなのか携帯なのかを知る術のない)送信側のSoftBankサーバで一律にUTF-8をdocomoのShift_JISに変換することには利点がなく、一方、デメリットは大きい。

  • また、iPhoneの(メッセージアプリで)@softbank.ne.jpからiPhoneの@ezweb.ne.jp宛に絵文字を送ると、auのケータイ絵文字以外は、消えるか(下図)、文字にフォールバックする。絵文字以外でも「⌘」など、携帯のレパートリにない文字は消える(コメント欄でお願いされた件は、たぶんこれ)。これらすべてはもちろんau iPhoneで表示できる文字だし、受け手がau携帯の場合はauの受信側サーバUTF-8ISO-2022-JPの変換をしてくれる。送信側サーバauISO-2022-JPに変換することには利点がなく、一方、デメリットは大きい。

  • docomoもauも、受信側サーバはキャリアのアドレスを使用している端末がiPhoneか否かを知っているので、UTF-8を送れば、あとはうまくやってくれる。


その4・受信側サーバShift_JISUTF-8の変換をサポートしてほしい


おわりに

  • 以上で「送受信できるはずの絵文字のやりとりに失敗する」という事態を一掃できると思うのだが、どうだろう。
  • これら4つの要望は相互に関連していたりもするが、「その3」のうち「docomoまたはau宛のUTF-8のメールをSoftBankの送信側サーバで変換せずスルーしてほしい」という部分については、単独で実行しても問題がなく、メリットが大きいと思うので、まずこれだけでも検討してもらえると、たいへんありがたい。

2014-01-14

最近、モリサワのようすがちょっとおかしいんだが。

  • twitterで話題になってたね。
  • まとめを読んでも、ちょっとわかりにくかったんですけど、どういうことなんですか?
  • リュウミンとかのPr6/Pr6Nには複数のバージョンが存在して、新バージョンで作ったデータを旧バージョンの環境で開くと、豆腐になっちゃう文字があるんだよね。
  • うー、それはかなりイヤですね。
  • だよね。新バージョンのほうは、IVS(異体字シーケンス)対応版なんだけど、cmapも新しいのになってるから。
  • しーまっぷ?
  • 入ってますね。
  • Unicodeに入ってない字」はcmapには載ってない。でも、そういう字が後からUnicodeに収録されることも多いわけで、そのたびに新しいバージョンのcmapが定義される。
  • なるほど。
  • ところが、フォント内部のcmapをホイホイ新しいのに変更しちゃうと、さっき言ったような問題が起きる。たとえば最近Unicodeに入った「黒丸のなかにA」のグリフは、新しいcmapのフォントではU+1F150として入力されるけど、旧cmapのフォントはそんな符号位置は知らないから、当然、豆腐になるよね。
  • あー。
  • だからモリサワはこれまでずっと、一度リリースしたフォントのcmapは変えなかったんだったんだけどね。今回(といっても去年だけど)、突然アナウンスもなしにPr6/Pr6Nのcmapを変更するなんて、ちょっとどうしちゃったの、と。
  • いま、釣りタイトルを強引に回収しましたね。
  • 「モリちょ」って呼んでね!
  • ……えーっと。今回モリサワはIVS対応だけにして、cmapは変えなきゃよかったのにってことですか?
  • いやいや、それはない。
  • どうしてですか?
  • 話せば長いんだけどね。
  • じゃあ、またの機会に……。
  • ま、座れよ。Adobe-Japan1のIVSっていうのはさ、「Adobe-Japan1-6に含まれるすべての漢字をプレーンテキストで表現できるようにすること」をゴールにしているわけだ。
  • それは当然そうでしょう。
  • ところがIVSの登録だけじゃ、その目標は達成できないのよ。
  • ん?
  • IVSには親字が必要だからね。「親字のバリアント」として扱えない字は、どうしようもない。なので、Adobeはそういう字を、新たなCJK統合漢字としてUnicodeに提案してきたわけだ。
  • はあ。
  • CJK統合漢字の提案は、IVSの登録よりもずっとハードルが高くて時間もかかるんだけど、いろいろあったすえに、遂に最後の1文字が収録されたのが、Unicode 6.1。
  • おおー。
  • つまり、IVSとUnicode 6.1は、野望の扉を開くためにどちらも欠かせない2つカギなんだね。
  • 微妙にわかりにくい例えが出ました。
  • しましたか!
  • ドリーム・カム・トゥルーですよ。
  • はいはい。
  • それに対して「Unicode 6.1対応のcmapのほうはサポートするのをやめておこうよ」と言うのは、たとえばせっかく緑一色をテンパったのに、そこから「發」を切れって言ってるようなもんでしょ?
  • 例えがまったくわからなくなってきました。
  • まあ、そんなわけでモリサワがこれまでの掟に逆らってcmapを変更した気持ちは理解できる気がするんだけどね。
  • でも、それだと「旧バージョンで開くと豆腐になる」問題を避けられないんですよね。
  • うん。だから、大切なのはそういう問題をはっきりさせておくことじゃないの。で、具体的には、新バージョン(2.000)のリュウミンPr6/Pr6Nでcmapに追加されたのは、以下の158文字。

  • わあ! このへんよく使うじゃないですか!
  • これを旧バージョン(1.002または1.004)で開くと、こうなる。
  • あー。

2014-01-10

豆腐のいろいろ

  • 欠字を意味するいわゆる「豆腐」の表示には、フォントGID=0に割り当てられているグリフが用いられる*1

  • こんなかんじ。まあ、XP以前のMSフォントが表示するような「・」は「豆腐」とは呼ばないだろうけど。

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

2013-12-25

Moji_Johoの公開レビュー(PRI 259)に含まれない文字


  • PRI 259を逆方向から見てみるエントリ。
  • Moji_JohoのIVS登録は、原則として「文字情報基盤が対象としている(MJ番号の振られている)すべての漢字をIVS対応アプリで利用可能とする」ことを目指していると思われる。言い換えると、MJ番号の振られている文字のうち、CJK統合漢字に含まれるか提案中のもの以外は、ほとんどすべてが今回のリストに含まれている。例外は、下図の32文字。以下、これらのグリフ(今回のエントリに含まれるすべての図において黄色地で示す)がリストから外された理由を考えてみる。

  • 下図は、諸橋大漢和の重複文字。大漢和で(部首違いで)区別されていることを典拠として戸籍統一文字に入ったと思われるもの。今回の登録では、1つの基底文字に「見た目で区別できない複数のグリフ」あるいは「部首の異なるグリフ」をぶら下げることはしていないようだ。ただし、基底文字の部首を区別できる「朣(U+6723)」と「膧(U+81A7)」のようなケースでは、Hanyo-Denshiでは共通だった識別子をわざわざ分離して、見た目では区別できないグリフを登録しようとしている(http://blogs.adobe.com/CCJKType/2013/12/pri-259.html)。

  • 下図は、文字情報基盤のMJ文字情報一覧表において「UCS対応カテゴリー」欄に「B」と記されているもの。この「カテゴリーB」は「既存の符号位置との統合の可否に付き、結論が出ていないもの。文字情報基盤事業及び情報規格調査会SC2専門委員会としての結論が出次第、UCSへの新規符号化提案もしくはIVSのMJ_Collectionへの追加登録を行う予定」(http://mojikiban.ipa.go.jp/1313.html)の文字。

  • 下図は、IPAmj明朝の実装字形に平成明朝とのズレがあるためにIVSのシェアを見送ったと思われる例。今後字形を修正した上で登録するのだろうか。戸籍統一文字の239770は、平成明朝の形もソースと違っているので、IPAmj明朝の字形を修正するとしたら、どちらに合わせるのかという問題もある。

  • 下図は、IPAmj明朝の実装字形がソースである住基ネット統一文字における区別を反映していないために登録を見送ったと思われる例。今後字形を修正した上で登録するのだろうか。

  • 下図のMJ057449とMJ028027は、単純になぜリストに含まれていないのかわからない。MJ057449の「UCS対応カテゴリー」は「A4」(文字情報基盤整備事業において個別に確認したもの)となっているが、「B」なのかなという気もする。

  • 12画の「御」(MJ029032)と11画の「御」(MJ011324)のうち11画のほうがリストに含まれていないのは、見た目で区別が付かないからだと思うが、12画のMJ029032(要するに普通の「御」)を平成明朝のJA2470(要するに普通の「御」)とのシェアではなく新規に登録しようとしている理由がわからない。

  • 下図のMJ060383がリストに含まれていないのは、MJ015994と見た目で区別が付かないからだと思うが、そもそもソースである住基ネット統一文字のC0BFとB494が何を区別したかったのだかわからない。