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種類のパターンが扱えることになるので、文字列を圧縮データ格納に使いたい人(そんな人他にいないかもしれませんが)はもう少し圧縮率を稼ぐことができそうです。