Unicodeの脳みそ星人はどこからやってきたのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
ねえねえ。これ何に見える？ もしかして何かエッチなこと言わそうとしてます？ いや、そういうのじゃないから。 宇宙人……でしょうね。 ふーん。宇宙人に見えるかあ。 宇宙人に見えるっていうより、宇宙人とでも言うしかないというか。 うん。これ、U+1F47E ALIEN MONSTERっていうUnicode絵文字の例示字形なんだけどね。ちょっとアレだよね。その元になった携帯キャリアの絵文字は、SoftBankのインベーダーのカニ星人*1。それから、auのタコ星人。 どっちもわかりやすい宇宙人ですよね。それがどうしてこんな不吉な脳みそ星人になっちゃったんですか？ 話せば長いんだけどね。 じゃあ、またの機会に……。 ま、座れよ。ケータイの世界には、SoftBankにはアリ星人（「宇宙人」）とカニ星人（「ゲーム」）がいて、auにはタコ星人（「宇宙人」）とUFOがいる。 はい。ありますね、これ。 こいつ
[ruby-dev:40868] Re: revert 1.9 \w limitation to ASCII
Subject: [ruby-dev:40868] Re: revert 1.9 \w limitation to ASCII From: "NARUSE, Yui" <naruse@ r i j Date: Wed, 31 Mar 2010 10:11:56 +0900 References: 40863 40866 In-reply-to: 40866 成瀬です。 2010年3月31日7:09 Yukihiro Matsumoto <matz / ruby-lang.org>: > まつもと ゆきひろです > > In message "Re: [ruby-dev:40863] Re: revert 1.9 \w limitation to ASCII" > on Wed, 31 Mar 2010 02:39:18 +0900, "NARUSE, Yui" <naruse / aire
Firefoxなどで半角濁点が前の文字と一緒に選択される理由 - しろもじメモランダム
Firefox などで下の半角濁点「ﾞ」・半角半濁点「ﾟ」を選択してみてほしい。 ｶﾞ、あﾞ、漢ﾞ、aﾞ、 ﾞ、☃ﾞ、✐ﾞ えﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞっ!! ふﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟ。 ぬﾞﾞﾟﾞﾞﾞﾟﾟﾟﾟﾞﾞﾞﾞﾟﾞﾟﾞﾞﾟﾞﾞﾞﾞﾞﾟﾞﾞﾞﾟﾞﾟﾟﾟﾞﾞﾞﾟﾟﾟﾟﾟﾟﾟﾞﾞﾞﾟーん いくら半角（半）濁点だけを選択しようとしても、前の文字まで（それがスペースだろうが記号だろうが）一緒に選択されてしまうと思う。もう少し正確に言えば選択されるのは [^ﾞﾟ][ﾞﾟ]* にマッチする部分で、カーソルの移動の際にも [^ﾞﾟ][ﾞﾟ]* が一文字として扱われる。delete キーを押すと [^ﾞﾟ][ﾞﾟ]* が一気に消えるが、backspace キーでは半角（半）濁点がひとつずつ消える。 Windows のメモ帳*1など昔ながらのアプリケーショ
Unicode 5.2以降のCMap - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
前回、LionのヒラギノProNは最新のCMapであるUniJISX02132004-UTF32の1.009を採用している、と書いた。今回は「UniJISX02132004-UTF32の1.009って何だよ」という問いに答えておこうと思う*1。 2007年までのCMapのバージョン間の違いは「CMapのバージョンの違い」にまとめてあるので、その後の変更分について。比較的新しいCMapには4つの系統があり、対応するバージョン間で、バージョン番号が一致しない。そこで、公開された時期によって、仮に「2010-April版」などと呼ぶこととする。今回のまとめに含まれる範囲では、変更点はすべて、マッピングの追加である。 2010-April版は、Unicode 5.2に対応したもの*2。 2010-June版は、Unicode 6.0のうちCJK統合漢字拡張Dについて、先行して対応したもの。 201
iPhoneのSafariで文字化けするのはtwitterのバグ（直りました） - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
追記。このエントリで取り上げている問題は、8月13日に修正されたようです。 iPhoneやiPadのSafariでtwitterを見ると、Unicodeの追加面（BMP外）の文字が、すべて化ける*1。キャプチャ画像は、上がLionのSafari、下がiPhoneのSafari。 化け方の理屈は、Unicodeの符号位置（Unicodeスカラ値）の5桁目が落ちてしまうというもの（下図）。 おそらく、twitterがiPhoneやiPadに最適化されたページのソースを動的に生成するスクリプトにおいて、UTF-8でもサロゲートペアがバラで符号化されているようなつもりで処理してしまっているのだと思う*2。 *1:iPadのSafariは以前は化けなかったのだが、iPad版新twitterに移行してからは化けるようになった。 *2:という結論に達するまでに、twitter経由で貴重な情報をいただきま
Appleカラー絵文字（Lion版）のUnicodeマッピング - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
これまで、ケータイ絵文字は「外字」であり、一般の文字とは明確に区別されていた。しかし今後は、ケータイ絵文字がUnicodeの（私用領域ではない）符号位置を用いて表現されるようになってくるだろう。LionのAppleカラー絵文字は、その先駆けである。たとえばU+2665「♥」は、JIS X 0213にも含まれるポピュラーな文字だが、これをAppleカラー絵文字で表示すると、トランプの絵になる（下図）。今までの常識とは異なる世界だ。というわけで、Appleカラー絵文字とUnicodeの関係を把握するためのリストを作成した。以下、リンク先のPDFはUnicodeのチャート。その下の図は、Appleカラー絵文字のマッピングを示す。 C0 Controls and Basic Latin（http://www.unicode.org/charts/PDF/U0000.pdf） C1 Controls
[Real Studio][REALbasic]JSONでサロゲートペアを処理する - Real Studio / REALbasic
つい最近、自分でTwitterクライアントを作ってみようと思いいろいろ調べていたところこちら http://www.charcoaldesign.co.uk/source/realbasic で公開されている 「JSON Dictionary」 なるものを発見。JSON形式の文字列を手軽にREALbasicのDcitionaryにしてくれるというありがたいモジュールだ。 Twitterの呟きをAPI経由で取得するとJSON形式でデータが送られてくるのでこちらのモジュールを利用して処理することに決定。ところがこのモジュールを経由して取得したメッセージをみると日本語が化け化けで読めないじゃないか。ということで原因を調べたところ、問題はJSONの中で使用されている文字列（Strings）表記への対応にありました。 JSONの仕様であるRFC4627 に以下のような部分があります。 2.5. St
スマートフォンにおける厄介な漢字の表示実験
情報交換でよく問題になる「厄介な漢字」は、流行のスマートフォンではどのように表示されるのだろう？ これを明らかにするため、公募による実験を試みた。具体的には、実施者が問題になる文字を選定、 ツイッターにて送出、そのツィートのスクリーンショットをスマートフォンのオーナーに送ってくれるよう呼びかけた。 スマートフォン以外からの応募もあったので併せて掲載する。当日の詳細なやり取りは 「文字化けの饗宴：スマートフォンにおける厄介な文字の表示実験」を参照されたい。 実施日は2011年6月21日、実施者は小形克宏である。 送出した漢字の内訳 0面以外にある常用漢字…… 𠮟（U+20B9F） その他の0面以外の文字…… 𠮷（U+20BB7） UnicodeにあるがJIS X 0213にない字…… 髙（U+9AD9） IBM拡張文字…… 神（U+FA19） IBM拡張文字ではないJIS X
正規化・互換漢字・IVS
Koji Ishii @kojiishi OS、アプリ、IMEにきれいに入ればユーザーに対して透明にできると思うんですが、今のIVSだとこれらの層との協調が悪くて、それを解決しないと難しいな、と @0guma 私の周囲3m内外でも、その技術を誰も使いこなせないだろうな、と思える辺り、如何ともし難い @ogwata 2011-06-08 15:50:53 tomo.（むにゃむにゃ） @MnjaMnia （既存の IVD よりも荒い）字体／抽象グリフレベルの IVD（ないしは、そういう風な運用）は現実問題として必要だと思うんだけども（だから、私も細々と試行錯誤してる訳だけども）、現実問題としてなかなか難しそうなのも事実なんだよなぁ。 2011-06-08 20:24:52 Kiyonori Nagasaki @knagasaki おお！ RT @MnjaMnia: 理想的なグリフオントロジーを
IVSに対するfont fallback | yasuokaの日記 | スラド
「UnicodeのIVSがもたらすメリットとデメリット」の読者から、IVSに対するフォント・フォールバックはどうあるべきか、という趣旨の御質問をいただいた。たとえば、CSSのfont-familyで複数のフォントが指定してある場合に、最初のフォントに表示したいIVSが収録されていなかった時、表示プログラムはフォントの中をどう探していくべきか、という問題だ。 例として、3つのフォントが指定されている時に、「U+845B U+E0103」を表示するための理想的なフォント・フォールバックを、私(安岡孝一)なりに考えてみよう。 最初のフォントから「U+845B U+E0103」を探す。なければ 最初のフォントから「U+845B U+E0101」を探す。なければ 2番目のフォントから「U+845B U+E0103」を探す。なければ 2番目のフォントから「U+845B U+E0101」を探す。なければ
Unicode - JISマークは一文字! : 404 Blog Not Found
2009年08月07日15:00 カテゴリCode Unicode - JISマークは一文字! 私もびっくりしたのですが、事実です。 まずは以下をご覧下さい。 〄は一文字です(U+3004)。 フォントまわりをカスタマイズしていないIEでも表示を確認できました。UbuntuのFirefoxでは空白でしたが。 なぜ気がついたかと言えば、unicode@unicode.org にこんな書き込みが登場したからです。 At http://en.wikipedia.org/wiki/Japanese_Industrial_Standards, a new symbol for JIS is shown and discussed. Will there be a new character in the Standard? (Not a new glyph in the same codepoint
L'eclat des jours(2011-02-05)
_ OSXのファイル名について教えてもらったこと 昨日の東京Ruby会議で、かわばたさんからNFCとかNFDとかについて教えてもらった。 Unicodeでは、文字の合成がサポートされている。たとえば「か」と濁点「゛」は合成することもできるし、「が」という1つの文字で登録もされている。しかし「あ」と濁点を組み合わせた1つの文字は登録されていない。でも「あ」と「゛」を組み合わせた「あ゛」も作れる。作った場合にどう表現するかはフォント(描画エンジンかも知れないな)に依存する（日本語よりも、おそらくウムラウトとかを使う欧州言語のほうで意味を持つ仕様だと思う）。 ということは、「が」という文字が実際には登録されている「が」という1つの文字なのか、それとも「か」＋「゛」なのかは、特に文字列の比較をする場合には問題となりうる。人間としては等価として扱いたいが、コンピュータとしてはかたや1文字、かたや2文
漢字が廃止されても漢字コードは無くならない | yasuokaの日記 | スラド
『UnicodeのIVSがもたらすメリットとデメリット』の読者から、ここのTogetterの「議論」を読んでみてほしい、と連絡があった。昨日の「出版物のUnicode化推進セミナー」に関連したモノらしいが、発表をちゃんと聞いてない上に「議論」があまりに低レベルで呆れかえった。 だって、たとえ漢字を廃止したとしても、漢字コードは無くならない。IVSだって無くならない。そもそも文字コードってのは、現在の文字を伝えるだけじゃなくて、過去の文献をデジタル化しておくためにもある、っていうか、実際のデータ量はもちろん過去の方が多い。わかりやすい言い方をすれば、過去に漢字で書かれた文献やブログや「つぶやき」なんかが全てこの世から消え去らない限り、漢字コードは無くならない。 とは言え、ここのTogetterで「議論」してる連中は、『文字符号の歴史 欧米と日本編』の「おわりに」なんか読んでないだろうし、IS
出版物のUnicode化推進セミナー 日本電子出版協会（JEPA）
2010年は、iPadの発売、Kindle3への日本語フォントの導入、年末のシャープのガラパゴス、ソニーのリーダーの発売など、まさに電子書籍元年にふさわしい話題が満載の年となりました。しかし、ハードウェアの話題ばかりが先行し、実際に読まれるコンテンツに関しては、コンテンツの充実という意味でも、流通経路の整備という意味でも、2011年が本格的普及に向けての正念場になることも明らかです。 こうした中で、出版社や印刷会社、編集プロダクションなど、コンテンツの制作を担う現場にとっては、各読書端末における縦組みやルビなどの日本語組版機能の実装状況とともに、外字や異体字など、日本語の文字表記の状況を正確に把握しておくことは、コンテンツ資産の電子書籍化、迅速かつ効率的な電子書籍の制作には不可欠です。 本セミナーは、電子書籍の制作と普及に欠かせない基礎技術である文字コードについて、最新の国際標準化状況
50年に1度!? IVSをめぐる熱いw討論
JEPAによる「出版物のUnicode化推進セミナー」をきっかけに、IVSについて熱く語り合った記録。思いがけず沢山の人が呼応してくれたので、まとめておきます。 IVSについては「UTS #37 UNICODE IDEOGRAPHIC VARIATION DATABASE」（http://unicode.org/reports/tr37/）、安岡孝一「漢字1文字が最大8バイト、Unicodeの「IVS」とは？」（http://itpro.nikkeibp.co.jp/article/COLUMN/20100126/343783/）、拙稿「包摂された字体を区別できる異体字シーケンス」（http://internet.watch.impress.co.jp/cda/jouyou/2008/09/09/20793.html）あたりをご参照ください。
IVSは文字コードではない - yanok.net
IVSを使うと、常用漢字体の「与」は以下の異なる符号化表現で表し得ます。 U+4E0E U+E0100 U+4E0E U+E0102 U+4E0E (※通常の日本語環境では上2つと同じように見える筈。中国語環境などでは異なる) これが何を意味するかというと、画面上で同じ「与」という漢字が見えていても、その背後にある符号化表現は上の3つのいずれでもあり得るわけです。これがどのような不都合をもたらすかはいうまでもないでしょう。 文字コードというものは、文字を一意に符号化するものです。しかしIVSでは一意に符号化することは最初から考えられていないようです。つまり、IVSは文字コードではありません。 文字コードでないものをUnicodeのレベルで扱うのが適切なのか、再考を要するかもしれません。たとえばルビタグや言語タグのような文字コードでないものがUnicodeにはあって、こういうのはXMLなどで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
近デジのテキスト化について、@aobekaさんのつぶやきまとめ
IBM Developer
BizPal - EPUB-2011.01.27 出版物のUnicode化推進セミナー
IVSと正規化について
