Pick up the 9th-gen iPad with two years of AppleCare+ for only $298
これまで何度かUTR50(Unicode縦書きの文字の向き仕様)を話題にしてきましたが、2013年8月31日に正式版が出て、CSS3 Writing Modes仕様(現在最終草案)でも、このUTR50仕様が縦書きの文字の向きのデフォルトになることが確定しました。 今後はEPUBリーダーなどでの縦書きの文字の向きのデフォルトとして、これが標準になっていくものと思われますが、現在はそれぞれ独自であったりドラフト版のUTR50ベースであったりして、実装によって向きがまちまちです(それを解決しようとしたのがUTR50なのですが)。新しい標準に切り替わるまでのあいだ、電子書籍制作側ではいろいろ注意が必要です。 これについて、「電書魂」の次のブログ記事など参考になるかと思います: InDesignとEPUBの縦書き時の文字の向きの差について/電書魂 また、UTR50とCSS3 Writing Mode
日本が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の未定義領域の文字」として
この項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に
RLOのトリックを使ったMacの署名済みマルウェア 2013年07月15日19:48 ツイート fsecure_corporation クアラルンプール発 by:ブロデリック・アキリノ RLO(Right-to-left override)とは、双方向のテキストエンコードシステムで使われる特殊文字で、テキストを右から左への表示に切り替える場所を指示するものだ。実行可能ファイルの本当の拡張子を隠蔽する目的で、昨年来Bredolabや高度なトロイの木馬MahdiといったWindowsマルウェアで一般的に使われている。トリックの詳細については、Krebs on Securityのこの投稿を確認してほしい。 我々はあるMac用のマルウェアがRLOのトリックを用いていることに気付いた。そして先週の金曜日にVirusTotalに投稿した。 ここでの目的は、Krebの投稿で触れられていたものほど複雑で
小形克宏 @ogwata 相変わらずシフトJISについて調べているわけだが、先日の文字の学校で狩野さんから「『CJKV』第2版ではシフトJIS関連がばっさり削られているんですよね」との情報を得て、ひょっとしたらと一番最初の版『日本語情報処理』(1995年、ソフトバンク)を見てみたら、これが一番詳しい! 2013-05-23 22:08:51 小形克宏 @ogwata さすが1995年の本だけあって、ベンダーごとの実装差は必要不可欠。新しい版が出たらかといって、古い版を捨てなくてよかった…と書いたところで、Facebook経由で安岡さん曰く「でもミスも多い!」だそうです。しょぼん。 2013-05-23 22:12:38 小形克宏 @ogwata そうか、EPSONの98互換機は単純にJIS83だと思っていたけど、符号化文字集合としては78JISにJIS83の追加分を加え、レパートリにJIS
皆さんこんにちは、片づけコンサルタントのこんまり先生です。 いきなりの個人名詐称……。 今日は、Windows 8のIVS実装について説明するわよ。 「わよ」? 最初に結論を言っちゃうと、Windows 8のMS明朝・MSゴシックがIVSでサポートしているのは、MS122から「筵」を引いて「濹」を足した122文字ね。 ん? 以前のエントリでも言ったように、Windows Vistaで変更された文字のうち、jp90タグやJIS90互換フォントパッケージによって昔のグリフに戻せる122字を、MS122と呼ぶんだけどね。 MS122はいいんですけど、そこからまた引いたり足したりするんですか? うん。 じぁあまず、マイナス分の「筵」は、何なんですか? MS122のうち「喩」と「筵」については、XPグリフがJIS90の例示と一致しないんだよね。 ホントだー。 だから「喩」と「筵」のXPグリフ(JIS
自家製資料いろいろ 文字コード体系(サマリ) JIS文字コード表 JIS X 0213全漢字一覧(1-4水準 10050文字) UTF文字コード表 部首別漢字コード表 Adobe-Japan1のJIS外Unicodeマッピング文字一覧 文字テストEPUB Adobe-Japan1 IVS異体字一覧 Source Han Sansフォント特設ページ 漢字これくしょん 康熙字典EPUB版 Google Notoフォントグリフ一覧(CJK以外) macOS Sierra で最初から入ってる日本語フォント一覧 Unicode変体仮名フォント **new** 実験ツール 文字コードチェッカー 青空UTF IVS異体字メーカー 顔文字デコーダ Unicodeデコーダ (文字列からUnicodeコードポイントを表示) Unicodeマップ (全Unicodeのマップ。表示できるグリフはフォントに依存しま
tomo.(むにゃむにゃ) @MnjaMnia (ISO/IEC 10646 の弁護をするなら、Unicode って自分で勝手に決めた領域だけを面倒見れば良いのに対して、ISO や JIS 等の公的標準は引用関係の網の目の中で矛盾を来さないよう他の規格に悪影響をもたらさないようにいじらないといけないので難易度が違う気が) 2013-04-04 01:46:33 tomo.(むにゃむにゃ) @MnjaMnia (あと、歴史的には結合文字という概念は ISO/IEC 10646 より前からあって、結合文字を使った文字符号から precomposed なのにしようという流れの中で 8859 シリーズが生まれ、その延長上で 10646 作ろうって話が出てきたみたいだし…) 2013-04-04 01:53:21 tomo.(むにゃむにゃ) @MnjaMnia (あと、伝統的には文字符号の標準って受
2013年3月26日から発生していた住民基本台帳ネットワークシステム(住基ネット)の障害の原因が、データベース(DB)に情報を書き込む際の文字コードの誤り(文字化け)にあったことや、障害が影響した市町村の合計が231に及んでいたことなどが分かった。総務省が4月2日に発表した(関連記事:全国200の自治体で住基ネットが利用不可能になる障害が発生)。 今回の障害は、自治体にある住民基本台帳システムと住基ネットを接続する「コミュニケーションサーバー」のハードウエアとOSを231の自治体で更新し、それに伴い、コミュニケーションサーバーのアプリケーションに対して、新OSに対応させる修正プログラムを適用することで発生した。 コミュニケーションサーバーのアプリケーションは、氏名・住所・生年月日・性別という4つの「本人確認情報」を、DBサーバーである「Oracle Database」に保存する際に、住基ネ
榎並利博の『電子行政における外字問題の解決に向けて』(富士通総研経済研究所研究レポート, No.400, 2013年2月)を読んでほしい、とアチコチから連絡をいただいた。読んでみたのだが、2010年の『常用漢字表』改定にまつわる議論を全くフォローしておらず、そのために、正直かなり頓珍漢な内容となっている。それを端的に示しているのが、【追補2】の以下の文章だろう(p.41)。 時代に即して合理的に物事を考え、外字問題を解決していくのは、本来国語審議会の役割ではないだろうか。国語審議会の存在意義が問われていると言っても良いだろう。 存在意義も何も、国語審議会は2000年12月に、『表外漢字字体表』の答申をもって解散した。いまさら存在意義とか言われても、読者は困惑するばかりだろう。こういう調子なので、文化審議会国語分科会が答申した『改定常用漢字表』も全く理解しておらず、その結果、以下のようなわけ
1. はじめに 内閣府によれば,2012年3月時点における携帯電話の世帯普及率はじつに94.5%にのぼる[1].携帯電話はほとんど全ての国民が1台ずつ持つ,他に例を見ない製品に育った.その中で近年台頭著しいのがスマートフォンである. コムスコア社の調査によると,今年6月時点におけるスマートフォンユーザは全携帯電話ユーザの23.5%であり,この数字は前年同月から43%の増加にあたる[2].つまり,最近になって普及率が急カーブで上昇している.こうした傾向は出荷台数を見るとより顕著になる.MM総研によると,今年4月~9月の国内携帯電話端末の総出荷台数に占めるスマートフォンの比率は69.4%にのぼる[3]. さて,スマートフォンは不特定多数との情報交換を目的とするものだ.したがって文字コードの実装は,重要なポイントとなる.では,その実態はどんなものか,いささか調べた結果をお伝えしたい. 2. レパ
世の中には姓名にちょっとでも違う字を使うとうるさく言う奴がいて、そんなこんなでUnicodeに字形切り替えの仕組みが備わった。これをIVSという。特に「ナベ」さんはうるさかったらしく、字形も沢山登録された。 上の図はUnicodeに登録されている異体字リスト(IVD:http://unicode.org/ivd/data/2007-12-14/IVD_Charts.pdf*1)から引っ張ってきた。実は上に挙げたのは一部である。日本人しか使わない、日本人のための表である。ああ素晴らしい( ´∀`)。 こういう規格が何で出てきたのかとか、以下のサイトが詳しかった。 IVSとフォントの関係 - ちくちく日記 IVSとGSUBはどう違うのか - Mac OS Xの文字コード問題に関するメモ ともかく、私も日曜フォントプログラマーとして、フォント内部のIVS構造がどうなっているのかを話したい。 仕様
マイクロソフトがOfficeドキュメントでIVSを使用できるようにするアドイン「Unicode IVS Add-in for Microsoft Office」の無償提供を開始しました。 これを使えばOfficeソフトの「Word」「Excel」「PowerPoint」でIVSでの表示、印刷、編集が行えます。「Access」や「Outlook」には対応しません。 ああああーーー、ついにきたかーーーー。 と、いうことで、OfficeソフトのIVS対応でDTP作業にどんな影響があるのかを簡単にあくまで簡単に説明してみる。 そもそもIVSって何? まずは基礎知識から。 今DTPでいわゆる異体字を使おうと思うと、例えばInDesignや、Illustratorなどのアプリケーションに入力された文字に対して字形切り替えパレットから字形の切り替えを行うといった方法があります。 ▲InDesignの字形
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く