けど騒ぐことではなかった。

でも JS との相互運用考えると \u 形式の escape してた方がいいっぽい。待て続報。

RFC に may って書いてあったので問題解決というか問題は存在しなかった

Twitter / mala: 実装依存(できる、してもよい、しなくてもいい)でしょ …

なるほど。

http://tools.ietf.org/html/rfc4627

Any character may be escaped. If the character is in the Basic Multilingual Plane (U+0000 through U+FFFF), then it may be represented as a six-character sequence: a reverse solidus, followed by the lowercase letter u, followed by four hexadecimal digits that encode the character's code point. The hexadecimal letters A though F can be upper or lowercase. So, for example, a string containing only a single reverse solidus character may be represented as "\u005C".

ということで、escape されるとは限りませんよ、で何の問題もないのであった。

背景とまとめ

REE ( Ruby 1.8.7 ) + json 1.4.6 の環境で Hash#to_json を使っていくらシリアライズしてやっても日本語がエスケープされずに出力されてしまう。最初のうちはあまりに自然で気づかなかったけど、いやいや、JSON は生で読めないはずだと思い出してからはそれが再現できずにずいぶんと悩んでしまった。※ 思い出したというか思い込んだっつーことでした。

json のバージョンを戻せば直るかと思ってやったら確かに期待する動作になったけれど、これもしかして Ruby 1.9 を期待して内部をいじって失敗したクチじゃねーのと思い直して実験してみた。

結果、Ruby のバージョンによらず全部同じ動作をした。

実験に利用したRuby

$ rvm list

rvm rubies

   rbx-1.0.1-20100603 [ ]
   ruby-1.8.7-p299 [ i386 ]
   ruby-1.9.2-head [ i386 ]

実験に利用したgem

• json 1.2.4
• json 1.4.6

実験結果 json 1.4.6

$ rvm ruby json14.rb

info: rbx-1.0.1-20100603: rubinius 1.0.1 (1.8.7 release 2010-06-03 JI) [i686-apple-darwin9.8.0]

{
  "key1": "あいう",
  "key2": "漢字"
}

info: ruby-1.8.7-p299: ruby 1.8.7 (2010-06-23 patchlevel 299) [i686-darwin9.8.0]

{
  "key1": "あいう",
  "key2": "漢字"
}

info: ruby-1.9.2-head: ruby 1.9.2p14 (2010-10-02 revision 29393) [i386-darwin9.8.0]

{
  "key1": "あいう",
  "key2": "漢字"
}

実験結果 json 1.2.4

$ rvm ruby json12.rb

info: rbx-1.0.1-20100603: rubinius 1.0.1 (1.8.7 release 2010-06-03 JI) [i686-apple-darwin9.8.0]

{
  "key1": "\u3042\u3044\u3046",
  "key2": "\u6f22\u5b57"
}

info: ruby-1.8.7-p299: ruby 1.8.7 (2010-06-23 patchlevel 299) [i686-darwin9.8.0]

{
  "key1": "\u3042\u3044\u3046",
  "key2": "\u6f22\u5b57"
}

info: ruby-1.9.2-head: ruby 1.9.2p14 (2010-10-02 revision 29393) [i386-darwin9.8.0]

{
  "key1": "\u3042\u3044\u3046",
  "key2": "\u6f22\u5b57"
}

ね？ やっぱ変じゃない？変じゃないよ！

RFC のバージョンが上がって日本語もエスケープしなくてよくなったの？最初からescapeする「必要」はありませんでした。

また当たり前ですが parse はどちらの形式できても問題なくできました。

実験に使ったコード

json12.rb

#! /usr/bin/env ruby
# -*- coding: utf-8 -*-

require 'rubygems' unless defined? ::Gem
gem 'json', '< 1.4'
require 'json'

require File.dirname( __FILE__ ) + '/body'

json14.rb

#! /usr/bin/env ruby
# -*- coding: utf-8 -*-

require 'rubygems' unless defined? ::Gem
gem 'json', '>= 1.4'
require 'json'

require File.dirname( __FILE__ ) + '/body'

body.rb

# -*- coding: utf-8 -*-

jj ( { 'key1' => 'あいう',
       'key2' => '漢字'
     } )

余談

rvm list の platform の情報と実際に実行したときに出てくる情報が食い違ってるなぁ。

別に何か作ったわけじゃないけど。恐らくいちばん新しい Ruby 用の iCal ライブラリ。

RiCal

とりあえず情報の出力。

RiCal.parse( open( ICS_FILE ) ).first.events.map { |e|
  puts e.summary
}

で summary 一覧を出力できる。map を each にしちゃダメなんだけど、どういうポリシーでこうなっているのかはよく分かってない。

組み立ての方は DSL で書ける。個人的にはこの DSL っていうのが聞き飽きたというかあまり便利に感じられることが言うほど多くないと思っていたんだけど、RiCal の DSL はいいと思う。

README に書かれているサンプルをそのままコピペするとこんな感じ。

 RiCal.Calendar do
   event do
     description "MA-6 First US Manned Spaceflight"
     dtstart     DateTime.parse("2/20/1962 14:47:39")
     dtend       DateTime.parse("2/20/1962 19:43:02")
     location    "Cape Canaveral"
     add_attendee "john.glenn@nasa.gov"
     alarm do
       description "Segment 51"
     end
   end
 end

こういうのを真面目にオブジェクト指向で組み立てさせるとえらいややこしい記述が必要になったりするんだけど、これは実に自然に書けていると思う。

「将来の人間はコンピュータウイルスに感染する」、英教授が警告 (CNET Japan)

某所の会話。

「感染したらどうなるんでしょう？ みんなにメールばらまいたりするんですか？」

「違いますよ。あることないことみんなに喋るんですよ。」

「それってもう、結構感染してる人いるんじゃないすか？」

Apache module mod_rewrite

完全に見落としてました。

もうひとつ注意事項: クエリー文字列部分を付加した置換文字列で URL を生成することもできます。 単に、置換文字列の中にクエスチョンマークを入れるだけで、それ以降は QUERY_STRING に入れるべきことを示します。 既存のクエリー文字列を消去したい場合は、 置換文字列をクエスチョンマークだけで終わらせるようにします。

ちゅーことで

RewriteRule Regex 新URI?

重要なのは最後の ? なんだそうだ。

こんなこと言うのは今さらなのかもしれないけど、「ダメ人間」という言葉は「テスト勉強全然してない」と同じくらいの意味なんじゃないかなぁ。

例えばダメ人間スカウターを例にとっても、あれだけの知識、スキル全部を手に入れるにはそれなりの努力が必要である。例え社会的にダメでもその頑張りは評価されてよいと思う。問題はそこにリソースを注ぎ込むべきかどうかの判断やスキルの活かし方だけ。ダメではあるがダメではない。

同じようにほんとにダメな人間は真面目に毎日 blog 書いたりネタ考えたりはしない。例え社会的にダメでも、（受け手も居るし）それは創作活動として立派に成り立っていると言える。¹つまり何年も続いている日記を書いている人がダメ人間ですと表明することは「テスト勉強してないんだー」と同じような謙遜と軽いいやみを発しているように見えるのだ。

なられたようなので pkgsrc を使うように薦めておく。もちろんこれはノウハウをあとで自分が教えてもらうためだ。Unison もそうだったけど、「誰かに新しいツールを紹介して使ってもらってノウハウをあとでいただく」という作戦は成功率が低いのが難点だ。しかしめげてはいけない。誰かが試行錯誤している時間は自分の時間じゃないのだ。有効利用しなければ(マテ

ちなみに自分は ThinkPad + PowerBook 使いなのでたださんとはモバイルな好みはまったく合わないようだ。

−インターネトダメ人間度 (2004年11月15日12時1分9秒現在)− あなたのインターネットダメ人間力は771000です。

−結果からのコメント−

正真正銘真性のネット人間です。 ネットでの罪の意識が希薄な状態になりかけています。 ファイルがダウソできるところがあれば とりあえず落としていますね？ 迅速な意識改革が必要そうです。 今ならギリギリ間に合・・・わないです。タイーホ(゜∀゜)！ とりあえずフロには入りましょう。

※再プレイする時は必ずこのウィンドウを閉じてください！

知識、スキルがあることとダメかどうかは別問題です。このチェックではセキュリティ技術者はみんなダメってことになります。

なんてマジレスしてみるテスト。まぁネット人間であることに異論はねーです。ダメ人間であることも否定しません。両方同時に成り立つことにされたくないだけさ。

しかしこの数字って大きいんだか小さいんだかよく分からないなぁ。どれくらいのキャラに相当するのか教えてくれるといいかもしんない。それ以前に、いまどきスカウターネタはどの程度通用するのかという疑問もあるんだけど。

もともと Emacs キーバインドな xyzzy 使いだったが、最近色分けの仕方が Emacs の方が見やすいと感じるようになってきた。もちろんこんなものはカスタマイズ可能だってことは百も承知だけれど、基本的な部分で色分けの精度が高い印象を受ける。

分かりやすく言うと表現力が高い。xyzzy の場合はもとの設定が非常にシックというかどぎつくない設定になっているので、これの印象に引きずられているのかもしれないが、それほど詳細には色分けしていない印象を受ける。また、Emacs Lisp による Emacs 拡張と Common Lisp による xyzzy 拡張ではどうしても開発者の数が違う。Emacs Lisp の方がどっちかというとパワフルなものが多い。例えば Emacs の perl-mode では変数をハイライトしてくれるし、POD の部分を解釈してちゃんと色分けしてくれるが、xyzzy の perl-mode では両方未対応とか、そういった具合だ。

もちろんそれだけで xyzzy や CommonLisp の評価が下がるわけではないが、Lisp を知らない人間にとってより便利なのはどっちかということなのだ。

うーん、ホイールでのスクロールができるかもしれないし、Meadow とか入れてみようかな。カスタマイズが激しく面倒くさそうだし、きっとけっこう重いんだろうけど。（xyzzy は今にして思えば十分軽い。Windows 用のエディタの中では動作は重い方だろうけど。）

• 2002年11月 〜 2004年4月まで説教講座の方で PukiWiki を使って
• 2003年6月 〜 2004年8月まで自宅サーバで tDiary を使って¹
• 2004年8月 〜 AAA! CAFE で tDiary を使って
• 2005年6月 〜 aligach.net ドメインで tDiary を使って

書いてます。²そのときどきで

• Web 用のツールばかりに興味があったり
• ニュースサイト的なものにしてみようとしていたり
• ほんとに日記的な内容だけを書いていたり
• 自分の考えを練ったり、思いを中心に書いたり

していて、日記サイトとしての統一感はありません。ツールとサイトの違いで書きやすさなどが変化し、それに影響されて内容が変化しています。

それ以前は手で HTML を書いていた時期もありましたが、さすがに内容が稚拙＆個人的すぎるのでここには持ってきていません。