電書時代の文字コードを考える(ための資料)
自家製資料いろいろ 文字コード体系(サマリ) 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のマップ。表示できるグリフはフォントに依存しま
『Unicode IVS/IVD入門』へのツッコミ・第4章編 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
『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
スマートフォンと文字コード
1. はじめに 内閣府によれば，2012年3月時点における携帯電話の世帯普及率はじつに94.5％にのぼる[1]．携帯電話はほとんど全ての国民が1台ずつ持つ，他に例を見ない製品に育った．その中で近年台頭著しいのがスマートフォンである． コムスコア社の調査によると，今年6月時点におけるスマートフォンユーザは全携帯電話ユーザの23.5%であり，この数字は前年同月から43%の増加にあたる[2]．つまり，最近になって普及率が急カーブで上昇している．こうした傾向は出荷台数を見るとより顕著になる．MM総研によると，今年4月～9月の国内携帯電話端末の総出荷台数に占めるスマートフォンの比率は69.4％にのぼる[3]． さて，スマートフォンは不特定多数との情報交換を目的とするものだ．したがって文字コードの実装は，重要なポイントとなる．では，その実態はどんなものか，いささか調べた結果をお伝えしたい． 2. レパ
Unicodeがこの10年で普及して…
漢字の話とアラビア文字／インド系文字の話が混在してすみません。 現在Unicodeは実用されている文字をほとんど符号化して、新規の追加文字は昔の文字が大きな比重を占めています。複雑な用字系の表示環境も整って特殊絵文字で皆遊んでいる。しかし10年ほど前には全然状況は違っていたわけで……。
旧えびめも(2012-06-05)
■ SHIFT-JIS使用禁止な話 最近facebookやtwitterに書き込んでいるのでこちらのblogは放置状態でした。久々に書くネタを見つけたので更新します。 基本的な話ですが最近似た話があったので書き残しておくことにします。 次のようなC言語プログラムがあったとします。 #include <stdio.h> int main(){ int x=0; int table[]={0,10,20,30,40,50,60,70,80,90,100}; // 点数表 x=2; printf("TENSU=%d\n",table[x]); } これ実行すると TENSU= いくつになります？ 20ですか？実際にやってみましょう。 $ gcc tensu.c $ ./a.out TENSU=0 TENSU=0 になります。そんな馬鹿な？？ 実はこれソースコードをSHIFT-JISで保存した場合
絵文字が開いてしまった「パンドラの箱」第4回--絵文字が引き起こしたUnicode-MLの“祭り”
普通では考えられない優遇策--「Google提案」を振り返る 皆さんこんにちは、毎度おなじみ（？）文字コード漫談の時間がやってまいりました。前回が3月の掲載ですから3カ月ぶりですか。今まで3回にわたって絵文字をUnicode及びISO/IEC 10646（国際符号化文字集合）に収録しようという提案の動きについてご説明してきましたが、今回から2回に分けて完結編をお届けします。どうぞよろしくお付き合いください。 ひさしぶりですから、ここまでのポイントを整理しておきましょう。前述した「提案」とは、もともとはUnicodeに収録するためにGoogleがAppleと共同で作成したものです。以下、主唱者の名前をとり「Google提案」と呼ぶことにします。これはこの2月に開かれた最高議決機関、UTC会議で承認されてUnicodeコンソーシアムの総意となりました。ついでGoogle提案はISO/IEC 1
絵文字が開いてしまった「パンドラの箱」第3回--Unicode提案の限界とメリット
前回までを振り返る--Unicodeコンソーシアムの影響力 前回はどこまでお話ししましたっけ。世界中の文字の収録を目的とした文字コード規格、Unicodeは、米国のIT企業を中心に結成されたUnicodeコンソーシアムが制定するデファクト規格に過ぎないこと。しかし公的な国際機関が定めるデジュール規格ISO/IEC 10646と同期することで、WTO/TBT協定にもとづき世界中の国々に普及させられるメリットを得たこと。 また、Unicodeコンソーシアム自体はオープンな組織だけれど、意志決定を行うUTC（Unicode Technical Committee/Unicode技術委員会）で一票を投じる権利を持つのは一握りの団体に限られること。そしてUTCはISO/IEC 10646のアメリカ・ナショナルボディであるL2委員会と合同でしか開催されておらず、同時にL2委員会とUnicodeコンソー
絵文字が開いてしまった「パンドラの箱」第2回--Googleの開けてしまった箱の中味
じつはコメントを送っていたNTTドコモ 最初に前回のおさらいをしておきましょう。スタート当初の携帯電話の絵文字には、キャリア間でメールのやり取りの中で文字化けしてしまう欠点があったこと、それを解決する仕組みをキャリア各社が作ったものの、その場しのぎの欠点の多いものであったこと、そして絵文字のUnicode符号化というのはそうした欠点を一挙に解決するはずであること。ついでにGoogleが絵文字のUnicode符号化を進めることで、キャリア各社は今まで自分たちが育ててきた絵文字の主導権を奪われてしまうということも。 それから前回の最後では、キャリア各社に対してGoogleの提案についてどう思うか、パブリックレビューに参加する意向があるかを聞いてみました。そこでの回答は、各社そろって消極的と受け取れるものでした。 ところが前回の掲載後に、NTTドコモがGoogleの絵文字メーリングリストに投稿し
絵文字が開いてしまった「パンドラの箱」第1回--日本の携帯電話キャリアが選んだ道
Unicodeが携帯電話の絵文字を収録へ 絵文字ってなに？そう聞かれても多くの人は、ああ、それはと答えられるはず。そう言えばちょっと前に『メールのハートマークにだまされるな！ 8割の女性は「恋人以外にも使う」』（RBB NAVI）なんていうニュースもありました。携帯電話の個人普及率が9割を上回る（平成20年内閣府消費動向調査）この国において、絵文字はごくありふれたものになっている現実があります。 2008年の11月27日、Googleが携帯電話で使われる絵文字を国際的な文字コード規格、Unicodeに収録しようというプロジェクト進行中であることを発表しました。では、このニュースは何を意味するのでしょう。そして私たちに何をもたらすのでしょう。今回から3回に分けて考えてみようと思います。 まず歴史を振り返ってみましょう。じつは絵文字を使ったのは携帯電話が最初というわけでありません。先行するもの
日本語のe-mail、ISO-2022-JP以外のcharsetを使うのは是か非か | スラド IT
問題をよく考えましょう． 単独で動作するアプリケーションの話ではなく，不特定多数の相手との通信アプリケーション 直接に相手の(文字コードなどの)能力仕様を確認する手順を踏まずに， 仮定(相手が ISO-2022-JP 等を処理できると決めうち)の上でいきなり送りつける (SMTPによる MTA 間のやり取りはEHLO 等で仕様確認して調整する余地があるが， MUA間のやり取りは RFC822,RFC2822,RFC5322 などの仕様で書かれたものを，完全一方通行で送る) (とりあえず 8bit through かどうかはまた別の問題ということで置いておく) さてここで，歴史的に考えるとこんな感じになります． 原始時代: 英語? ローマ字?(私はよく知らない) pre-MIME時代: メッセージには JIS(≒ISO-2022-JP)を使うという プロトコル外の「共通の了解事項」を設定する
Safariでの意味不明な文字化け解消 - 駄目日記っぽぃ。
XOOPSで運営してるサイトで、EUC-JPの文字コードを指定してちゃんとHTTP Headerも出ているにも関わらず、Safariが認識してくれなくて悩んでた(ずっと放置してた)んやが、ようやく納得のいく形で解決した。というか相当前に解決はしてたようやが、原因がまとまった記事が見あたらなかったのでまとめておく。問題は複数あったようだ。 Safariの問題 実装を読んだわけではないんで確信はないが、なんか文字コード判定に2段階あるらしい。 第1段階が多分HTTP Headerで指定されたContent-Typeのcharset指定で、ここで指定されたものが第2段階でのデフォルト値になる。指定がなければ恐らくデフォルトエンコーディングの値。 第2段階が実際のHTMLを読む段階での自動判定で、通常エディタなどで行われるような、文字コードを特定できるような文字が出てきた時点で確定とするタイプのア
Winnyネットワークはやっぱり真っ黒，NTTコミュニケーションズの小山氏に聞く：ITpro
ボットネット研究で知られるNTTコミュニケーションズの小山覚氏。小山氏の新しい研究対象は「Winnyネットワークの実態」だ。小山氏は「悪意のある人物がワームを撒き散らしているWinnyネットワークは『真っ黒』としか言いようがない」と指摘する。小山氏にWinnyネットワークに関する最新事情を聞いた（聞き手は中田 敦＝ITpro）。 小山さんは最近，Winnyネットワークの調査を始められているそうですね。 これは，4月25日の「RSA Conference 2007」で話そうと思っていた内容なのですが，私が出るセッションは，ラックの新井悠さん，JPCERTの伊藤友里恵さん，マイクロソフトの奥天陽司さんというセキュリティ界の論客が揃ったパネル・ディスカッションなので（モデレータは日経パソコン副編集長の勝村幸博），私だけが長い時間発表するのは無理そうです（笑）。そこで，今回のインタビューで全部お話
tonan's blog: 「わ」と「れ」の左側は同じ形ではない
トナン・大熊肇の（ほぼ文字についての）覚え書きです。 充分に検証していないこともありますので、眉につばをつけてご覧ください。 連絡先：hajimeアットマークtonan.jp（「アットマーク」を「@」に変えてください） 『文字の骨組み』2刷の間違いとご指摘 『文字の骨組み』初刷の間違いとご指摘 『文字の組み方』訂正箇所 『組版／タイポグラフィの廻廊』（白順社）に、「秘」は本来は「祕」で「秘」は誤字であり、単なる誤字が由緒ある誤字になったのは王羲之が誤字である「秘」を書いたからだ、と書いた。 このように「のぎへん」と「しめすへん」は古来たびたび間違われている。 ひらがなも同様で、たとえば「わ」は「和」をくずしたものであり、「れ」は「礼」をくずしたものだから、左側の偏の部分は本来は違うかたちになるべきだ。 上の図版は「元永本古今集」の「われ」だ。 （丸1）が「わ・和」の基本形で、（丸2）が「の
Python の unicodedata モジュール - bkブログ
Python の unicodedata モジュール Unicode のちょっとしたテキスト処理をしようと思い、 Python の unicodedata モジュールを使ってみました。これは非常に便利です。 unicodedata は Python に標準で付属するため、別途のインストールは不要です。次のようなことができます。 文字の名前を取得する 文字の名前を取得することができます。Unicode の文字にはすべて一意の名前がつけられています。ソースコード内で Unicode のコードポイントを使うときは U+20AC (EURO SIGN) などとコメントをつけておくと便利でしょう。 >>> unicodedata.name(u'A') 'LATIN CAPITAL LETTER A' >>> unicodedata.name(u'あ') 'HIRAGANA LETTER A' 文字の
Unicodeメモ
最も短い文字名 (Unicode 3.2.0) 3字 U+22BB (XOR) U+22BD (NOR) U+2312 (ARC) U+2609 (SUN) U+264C (LEO) 最も長い文字名 (Unicode 3.2.0) 83字 U+FBF9 (ARABIC LIGATURE UIGHUR KIRGHIZ YEH WITH HAMZA ABOVE WITH ALEF MAKSURA ISOLATED FORM) 四種の正規形 (NFD, NFC, NFKD, NFKC) がすべて異なる文字 (Unicode 3.2.0) 以下の通り。 U+03D3 (GREEK UPSILON WITH ACUTE AND HOOK SYMBOL): NFD <U+03D2, U+0301>, NFC <U+03D3>, NFKD <U+03A5, U+0301>, NFKC <U+038E>
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【電子書籍の夜明け】第6回 電子書籍時代の外字問題を探る（1）～文字コード規格とフォントの関係 
文字とXSSの関係