UA 文字列を Javascript から得るにあたり検索をかけてみたのだけど、UA 文字列にある文字列 (eg. “MSIE”) があるか調べるときに String.prototype.indexOf の結果が -1 であるかを調べているのが多かった。これはやっぱ String.prototype.match だと遅いとかそういう問題があるからなのだろうか……なんかダサいので今回自分は String.prototype.match を使ったけど、どうなんだろ。

if (navigator.userAgent.indexOf("MSIE") != -1)
    // do something for MSIE

if (navigator.userAgent.match(/MSIE/))
    // do something for MSIE

さらに && とか使おうとすると演算子の優先順位 (よく忘れる) とか考えることになって面倒臭い……

pre に現れるコードを Javascript で着色 (Javascript でやってるのはマークアップ) してみる。重い？

少し前からこれがやってみたかったので class 属性に使用してる言語を書いていたりした。言語ごとにトークンを使いわけたようと思ってたわけだけど、実際そこまでやるのってどうなのよ、とか思い始めた。そのうちやってみて、いけそうだったら採用してみよう。

現状でもかなり重い気が……長くとれるトークンを増やせば (ループ量が減って) 軽くなるかもしれないけど微妙。実際一文字ずつループまわしてるからなぁ。やりすぎか。

Ruby と ECMAScript は別のトークンテーブル使うようにしてみた。別にパースしてるわけじゃない (スキャンだけ) なので微妙にアレな状況が既にいくつか思いつくわけですが……例えば式展開の引数で括ってるクオーテーションつかっちゃうとかが絶対おかしくなる。

それとループ回数を減らすために /[a-z][a-z0-9]*/i は identifer ってことにしてスキップしてる。

Lisp と XML もすっごい適当に加えた。

サンプル 重いので移した。

正規表現はブラウザ毎の違いが殆どない気もする。気付いてないだけかもしれないけど。

FF で右クリックから View Selection Source すると内部 DOM の内容もソースとして出てくるのが役に立った……

そもそもスキャナの実装が激しく間違ってたので修正。根本的な部分を変えたのでバグがあるかもしれない。