2010-02-14 - 未来のいつか/hyoshiokの日記
例えば、次の言葉の意味を知りたい、聞いたことがあるけどよく分かっていないプログラマにとって、お勧めの書籍だ。Unicode/UTF-8/UTF-16/USC-2/JIS X0208/JIS X0212/JIS X0213/SJIS/EUC-JP/CP932/ISO-2022-JP/ASCII/Latin-1/ISO 10646/ISO 8859-1/サロゲートペア/文字化け/機種依存文字/半角カナ/絵文字… JIS X0208やJIS X0213の解説などは圧巻である。書籍にはWebにない利点がある。Webには即時性があるが、文字コードの解説においては、即時性はそれほど求められない。字体ないし字形の差異についてWebではその字体ないし字形がなければ表現しようがないが、書籍であれば細部までこだわって表現できる。 例えば、包摂された「辻」という字の一点しんにょうと二点しんにょうの字体の差はWe
漢字1文字が最大8バイト、Unicodeの「IVS」とは？
「漢字1文字は2バイト」という常識が、大きく変わろうとしている。現在改正中の「常用漢字表」に対応するためには、Unicodeの4バイト文字を使用する必要があるが、それだけでは済まない恐れがある。今後、戸籍や住民基本台帳で使われている文字がUnicodeに追加されると、漢字1文字が最大8バイトになるかもしれない。文字コードに詳しい京都大学人文科学研究所附属東アジア人文情報学研究センターの安岡孝一准教授が、問題の核心を解説する。（日経コンピュータ） 先日公開した『新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能』の読者から、「今後のシステムでは漢字1文字を最大4バイトで処理すればいいのか」という質問を頂いた。実は、UTF-8あるいはUTF-16で漢字を表す場合、最新のUnicodeにおけるIVS（Ideographic Variation Sequence）を考慮すると、漢
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
UTF-8の冗長なエンコードとは何で、なんでそれがセキュリティ的に危ないのか？を文字コード知識レヴェル3くらいの凡プログラマが考えてみる - tohokuaikiのチラシの裏
何故かあたり前にならない文字エンコーディングバリデーション | yohgaki's blog ってあるように、いまいち文字コードの不正な判定による危険性ってのが分かってない。 SJISの問題は、（2/3）SQLインジェクションを根絶！セキュア開発の極意 - 第5回■注目される文字コードのセキュリティ問題：ITproの記事がわかりやすかった。 というか、やっぱりPHP使ってると誰でも一度は「なんじゃこの『￥』は？」って思うもんなんで。 なるほど、確かに↓の図のように「あるバイト」が2つの意味を持つっていう文字コード形態はやばいんだなと。 EUC-JPはそんなことはしないで、1つのバイトには1つの意味しか取らせない。 だけど、これでも文字化けが起こることがある。経験的には、「マルチバイトをXX文字で切り落としたい」とかやった場合。ちゃんと文字コードを判定してくれるPHPでいえばmb_subst
携帯電話の絵文字のUnicode登録をめぐる議論の動向 - moroshigeki's blog
「第2回ワークショップ: 文字 ―文字の規範―」において、「携帯電話の絵文字のUnicode登録をめぐる議論の動向」という題でしゃべってきた。その時スライドに書いたりしゃべったことを、以下にメモしておく。 はじめに 問題の所在 2008年12月、Googleが日本の携帯電話の絵文字をUnicodeに登録するための提案を発表したところ、Unicodeのメーリングリスト上で激論が発生した（1ヶ月で600通超）。この議論の中で、しばしば反対意見の中で「規範」を持ち出した意見が出ていた。したがって、本ワークショップのテーマである「文字の規範」を考えるネタとして、おもしろいのではないかと思う。 おことわり 以下の議論の概観は、メーリングリスト（Unicode Public Email List、Google グループ）をもとにしているが、細かい議論を端折ったり、時間が離れた議論をくっつけたりしている
絵文字が開いてしまった「パンドラの箱」第4回--絵文字が引き起こしたUnicode-MLの“祭り”
普通では考えられない優遇策--「Google提案」を振り返る 皆さんこんにちは、毎度おなじみ（？）文字コード漫談の時間がやってまいりました。前回が3月の掲載ですから3カ月ぶりですか。今まで3回にわたって絵文字をUnicode及びISO/IEC 10646（国際符号化文字集合）に収録しようという提案の動きについてご説明してきましたが、今回から2回に分けて完結編をお届けします。どうぞよろしくお付き合いください。 ひさしぶりですから、ここまでのポイントを整理しておきましょう。前述した「提案」とは、もともとはUnicodeに収録するためにGoogleがAppleと共同で作成したものです。以下、主唱者の名前をとり「Google提案」と呼ぶことにします。これはこの2月に開かれた最高議決機関、UTC会議で承認されてUnicodeコンソーシアムの総意となりました。ついでGoogle提案はISO/IEC 1
そろそろUnicodeについて一言いっておくか - 未来のいつか/hyoshiokの日記
文字コードの標準化について日記を書いたのだが、内容がいまいちだったのでボツにして気を取り直してUnicodeについて一言いっておくことにする。先日、といっても昨年(２００８年)の10月なんだけど、その中でちょと文字コードの標準化について話をしている。*1 もう1つ自分の経験としてあるのが、漢字の文字コードがあるんですけど、番号で言うとJIS X 0208とか0212とか規格の番号で皆言うわけなんですけど、実は1988年にその日本語の文字コードの改正の委員会にいたんですね。 その当時、私は 30歳ぐらいなんですけど、「富士通」とか「日立」とか「NEC」の部長さんぐらいの偉い人たちが来てて、私なんか外資系で且つ30前後のぺーぺーだから、全然格下なんですよ。 そういうところで議論の主軸を担ってるのは、「富士通」「日立」「NEC」「日本IBM」「東芝」「沖」、外資でいえば「ユニシス」とかの錚々たる
絵文字が開いてしまった「パンドラの箱」第3回--Unicode提案の限界とメリット
前回までを振り返る--Unicodeコンソーシアムの影響力 前回はどこまでお話ししましたっけ。世界中の文字の収録を目的とした文字コード規格、Unicodeは、米国のIT企業を中心に結成されたUnicodeコンソーシアムが制定するデファクト規格に過ぎないこと。しかし公的な国際機関が定めるデジュール規格ISO/IEC 10646と同期することで、WTO/TBT協定にもとづき世界中の国々に普及させられるメリットを得たこと。 また、Unicodeコンソーシアム自体はオープンな組織だけれど、意志決定を行うUTC（Unicode Technical Committee/Unicode技術委員会）で一票を投じる権利を持つのは一握りの団体に限られること。そしてUTCはISO/IEC 10646のアメリカ・ナショナルボディであるL2委員会と合同でしか開催されておらず、同時にL2委員会とUnicodeコンソー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
