macOS上のAPFSはUnicode Normalizationを行うのか? - なるせにっき
iOS 10.3がリリースされましたが、APFSへの移行が含まれていて話題です。特に文字コード界隈ではHFS+で搭載されていた暗黙のUnicode Normalizationがなくなっている点が指摘されています1。 ではmacOSではどうなのでしょうか。SierraならばすでにAPFSを扱うことが出来るので試してみましょう。 % hdiutil create -fs APFS -size 1GB foo.sparseimage WARNING: You are using a pre-release version of the Apple File System called APFS which is meant for evaluation and development purposes only. Files stored on this volume may not be ac
観察日記 2010-11-05 - なるせにっき
文字と 32bit int 文字をsigned intで扱おうとしている子がいるな GB18030がいるからunsigned 32bit必要だと何度！ ... ということは、裏を返すと、rubyは文字コードが32bit以内であることを仮定してる? rubyに限らずほとんどそうだな 一部のコードは31bit以内である事を仮定している その幻想をぶちこわさないと http://redmine.ruby-lang.org/wiki/ruby-19/AssumptionsJa {util_mput} Ruby 1.9 - AssumptionsJa - Ruby Issue Tracking System http://tinyurl.com/24cr3b5 こんなページがあるので 書いておくといいかもしれない たしかに GB18030ってmohta bitを使うの？ なんか嫌な名前のbitですね
観察日記 2010-05-14 - なるせにっき
間が開きましたがぼくは元気です。今回はスレッドネタとWindowsでのデバッグと、ライブラリデザインの相談風景(ext/etc?)です。RubyではWindows愛にあふれた方の参加を待っています！とかそんな Thread#priority いやー、本当にスレッドって素晴らしいですね。 [ruby-core:29586] 3 行で…… {util_mput} [ruby-core:29586] [Bug #1169] Thread#priority still doesn't work http://mla.n-z.jp/?ruby-core=29586 1.9 では Thread#priroity は効力を発揮しない場合がある、という仕様になりました と偉い人からコメントがあれば納得するのかな 笹田さんにそう書いてもらえばいいのかな Thread#priority を deprecate
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 を用いた攻撃の話です。 変換による検査 さて、これらの記事では「文字エンコーディング変換を利用したバリデーションをする方法」が不正な
Web上の日本語EUCデータに指定すべきエンコーディングは何か - なるせにっき
日本語EUCは当初、G0にUS-ASCII、G1にJIS X0208-1990、G2にHalf Width Katakana、G3にユーザ定義文字が定義されていました。その後、これを拡張しつつ多くの亜種が作られました。まずはこの亜種のうちの主要なものを挙げます。 まず、日本語EUCの国家標準は結局作られませんでしたが*1、IANA Character Set Registry*2に登録されているEUC-JP*3(以下、この仕様をeucJPと呼ぶ)は「標準」にかなり近いものということができるでしょう。これはG0にUS-ASCII、G1にJIS X0208-1990、G2にHalf Width Katakana、G3にJIS X0212-1990を指定しています。つまり、このエンコーディングはJIS X 0212を収録しているのが特徴です。 次に、eucJP-open系があります。このエンコー
講習会「文字集合と文字エンコーディング」について - はてなるせだいあり
なかなか豪快な記事(講習会「文字集合と文字エンコーディング」を開催しました — ディノオープンラボラトリ)を見つけたので、ツッコミを書いてみることにしました。ツッコミどころはかなり多いんですが、まぁ世の中の文字コードがらみの記事なんて大半がこんなものです。 「文字コード」という語は「正しい」か スライドの5ページ目は、「文字コード」という言い方は間違いという趣旨に見えますが、そうでもありません。 というのも、文字コードの世界は難しい世界です。複数のレイヤー、複数の国、複数のベンダーにまたがっているものが簡単になるはずがありません。しかし必須要素であるために、十分な知識を持たないまま、または必要性に駆られて十分な知見が集まる前に実装を行ってしまうこともしばしばあります。このことがさらに「歴史的経緯」としてさらに文字コードを難しくしています。例えばHTTPのcharsetパラメータは、char
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
