Kanasan.JS CodeReading #3: Days on the Moon

Kanasan.JS の Prototype.js CodeReading #3 (参加者のブログ記事一覧) に行ってきた。今回は告知が開催間際だったせいか人数はやや少なめだったけど、内容的にはこれまでと変わらぬ濃さ。範囲としては Prototype.js 1.6.0.2 の 1352 行目から 1650 行目付近まで。

コードリーディング

無線ネットワークが提供されているはずが私のマシンでは利用できず。LAN ケーブルをお借りして有線で接続。それにしても私がこれまでに参加した Kanasan.JS でネットワーク関係の不備に陥ること 4 回中 4 回。何か呪いでもかけられているのかと疑いたくなる。

例外処理の有無

Ajax.Response#getStatusText などは try 文による例外処理を行っているのに、Ajax.Response#getResponseHeader および Ajax.Response#getAllResponseHeaders に例外処理がないのはなぜかという話題 (例外処理の範囲はできるだけ小さくしたほうがいいだろうに)。例外が起きたときの処理を場合によって変えやすくするためではといった意見が。後から見直すと、XMLHttpRequest オブジェクトの同名のメソッドをそのまま呼び出すときだけ例外処理がないような気がする。XMLHttpRequest オブジェクトの処理を、例外も含めて透過的に扱えるようにするためか?

ちなみに、JavaScript では try 文が複数の catch 節を持てないという話が出たが、JavaScript 1.5 以降では可能だし、シンタックスは違うものの ECMAScript 4 でも可能になる予定だ。

// JavaScript 1.5 conditional catch clauses
try {
  [].length = -1;
} catch (e if e instanceof TypeError) {
  print("invalid type");
} catch (e if e instanceof RangeError) {
  print("invalid index");
}
// => invalid index

// ECMAScript 4 multiple catch clauses
try {
  [].length = -1;
} catch (e : TypeError) {
  print("invalid type");
} catch (e : RangeError) {
  print("invalid index");
}
// => invalid index

Ajax.Response#_getHeaderJSON

X-JSON ヘッダの値を変数 json に代入し、その後 json = decodeURIComponent(escape(json)) としている。これは、変数 json の値が UTF-8 バイト列だった場合、それを UTF-16 文字列に直す働きがある。まず escape 関数によって 0x80 - 0xFF の範囲の文字が %XX という文字列に置き換えられ、次に decodeURIComponent 関数によって %XX%XX%XX といった UTF-8 の URI エスケープ表現が元の文字に置き換えられる。

// 「日本語」のバイト表現は:
// UTF-8:    E6 97 A5 E6 9C AC E8 AA 9E
// UTF-16BE: 65 E5 67 2C 8A 9E
var str = String.fromCharCode(0xE6, 0x97, 0xA5,
                              0xE6, 0x9C, 0xAC,
                              0xE8, 0xAA, 0x9E);
str.length; // => 9
str.charCodeAt(0).toString(16); // => e6
str = escape(str); // => %E6%97%A5%E6%9C%AC%E8%AA%9E
str = decodeURIComponent(str); // => 日本語
str.length; // => 3
str.charCodeAt(0).toString(16); // => 65e5

RFC 2616 によれば、RFC 2047 に従った形で符号化されない限り、HTTP ヘッダフィールドの値の文字符号化方式は ISO-8859-1 であるとみなされるようなので、UTF-8 オクテット列をそのまま送られたのなら、このような処理を挟む必要があるのだろう。実際のブラウザの実装がどうなっているかは知らないが。