kamo from scratch

Flash Lite 1.xのアクションスクリプトでは、文字列に使用できない文字があります。

まず、\x00はSWFの中でデリミタとして使われているので使えません。

そのほかにも、正しいShift-JISの並びでないとFlashの開発環境(今使っているのは、Flash Pro 8 です)が望むようにコンパイルしてくれません。

たとえば、

s = "abcdefghij";

のとき、
length(s) と ord(substring(s,4,1)) と ord(substring(s,5,1)) の値はそれぞれ10,100,101ですが、

s = "abc\xffefghij";

の場合は先ほどの3つの値は、(9,101,102)となります。

つまり、Shift-JISとして無効な(\xff)が無視されてしまうのです。
本来なら、(10,255,101)になってほしいつもりでした。

バイナリ2.0カンファレンスのときの発表では、無効な文字より後がカットされてしまう(上の例なら3,0,0 となるはず)と話したのですが、年が明けて改めて試してみたら違う挙動になっていました。
試用期限が切れて製品版を購入してインストールしなおしたりしたので、そのあたりが関係しているのかもしれません。

また、2番目の例と等価なはずの

s = "abc\xff\x65fghij";

の場合は、(8,102,103)になるし、

s = "abc\377efghij";

の場合は、(10,121,101)となります。

121ってなんだろう。ちょっとだけ試してみましたが、\376は116、\375では同じ121になります。
これはあまり深追いしませんが、とにかく正しいShift-JISの並びを与える必要があるということです。

で、これはFlash Proのコンパイラのところの癖みたいなので、SWFを直接いじればたぶん大丈夫だろうということ(を口では言ってましたが試していなかったの)で試してみました。

最初の例の、s="abcdefghij"でSWFファイルを生成して、

perl -ipe 's/abcdefg/abc\xff\x65fg/' test.swf

という変換をかけてから実行してみたところ、望みどおりの値(10,255,101)になりました。

というわけで、Flash Pro以外のツールを使ったり、Flash Proが生成したSWFをさらに変換したりすれば1バイトで255種類のパターンが扱えることになるので、文字列を圧縮データ格納に使いたい人(そんな人他にいないかもしれませんが)はもう少し圧縮率を稼ぐことができそうです。