「プログラマのための文字コード技術入門」書評 - はてなるせだいあり
珍しく書評です。まだ書きかけなんですが、完成を待つと忘れそうなのでとりあえず。 断片的に見た感じとして、現在ある文字コード本では最高峰なんじゃないでしょうか。人に勧める文字コード本としては*1、長らく文字コード超研究がベストだったと思うのですが、今後はこれでしょう。 Ruby 1.8/1.9 ざっと見た限りでは誤りを見つけられませんでした。と、いうわけでこれはよい記述だと思います。 UCS-2 下記で引用を交えつつ紹介していますが、UCS-2は「文字集合」ではなく「文字符号化方式」でしょう。ISOの文書自身でもUCS-2を文字集合であるかのように扱っている記述があるのがアレなんですが、定義を見ればISO/IEC 10646を見てもUnicodeを見ても文字符号化方式だと解釈するのが妥当です。 http://d.hatena.ne.jp/nurse/20090325 http://d.hat
Cookie 今昔物語 - はてなるせだいあり
概要 Cookie の不幸な歴史と現状、そして将来についてまとめた。 仕様はどこにあるか Web 上の様々な規格は、誰かが定め、それに皆が合わせるという形で動いている。しかし、Cookie の仕様は誰が決め、どこで規定されているか知っている人は、意外と少ないのではないかと思う。W3C や IETF だと思っている人が多いのではなかろうか。 正解を言ってしまうと、定めたのは 1994 年、Netscape Communications 社であり、文書は http://wp.netscape.com/newsref/std/cookie_spec.html で公開されていた。アクセスしてみればわかる通り、このページはもう存在しないし、Netscape 社自体が AOL に買収されており、今は Mozilla になったというか、消えてなくなっていることを知っている人は多いだろう。当時の文書は例に
Validating Strings :: 2009-09-12 - はてなるせだいあり
文字エンコーディングバリデーション を受けて。 この辺の話ははせがわさんがお詳しいので、ご存じでない方はまず「本当は怖い文字コードの話」をお読みください。 不正なバイト列を用いた攻撃について さて、大垣さんの記事は 不正なバイト列をWebブラウザに送ると攻撃が可能となる場合があるので、Webアプリケーション側で対策が必要 不正なバイト列のチェックには文字エンコーディング変換を用いる まだ対策が不十分な事が多いので、みんな対策しようね HTTP charset パラメタの勧め *1 というお話。「validation」や「不正な」の対象が「文字エンコーディング」になっているのが気になります。不正なのはバイト列ですよね。invalid byte sequence を用いた攻撃の話です。 変換による検査 さて、これらの記事では「文字エンコーディング変換を利用したバリデーションをする方法」が不正な
講習会「文字集合と文字エンコーディング」について - はてなるせだいあり
なかなか豪快な記事(講習会「文字集合と文字エンコーディング」を開催しました — ディノオープンラボラトリ)を見つけたので、ツッコミを書いてみることにしました。ツッコミどころはかなり多いんですが、まぁ世の中の文字コードがらみの記事なんて大半がこんなものです。 「文字コード」という語は「正しい」か スライドの5ページ目は、「文字コード」という言い方は間違いという趣旨に見えますが、そうでもありません。 というのも、文字コードの世界は難しい世界です。複数のレイヤー、複数の国、複数のベンダーにまたがっているものが簡単になるはずがありません。しかし必須要素であるために、十分な知識を持たないまま、または必要性に駆られて十分な知見が集まる前に実装を行ってしまうこともしばしばあります。このことがさらに「歴史的経緯」としてさらに文字コードを難しくしています。例えばHTTPのcharsetパラメータは、char
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
