歴史的背景としてArrayBufferが標準化される前からreadAsBinaryStringは実装されているが、readAsArrayBufferの登場によりその利用価値はほぼ皆無となり、File APIの仕様から削除されたとかいう噂が飛び交っている。
しかし後方互換の為に再び仲間として生暖かく迎えられたとかいう噂が飛び交っている。そんな理由で仲間入りした所で、果たして最後まで冒険を共にする事ができるだろうか? 2度死ぬ未来が訪れないとも言い切れない。
使い所さん
などといった下らない前置きはこのくらいにして、本題に話をすり替えていこう。個人的にはこの役に立たない便利なreadAsBinaryStringはまだ使い所さんがあると思い込んでいる。例えば以下のような処理である。
<input type=file oninput="with(new FileReader)readAsBinaryString(files[0]),onload=b=>a.href=self.URL.createObjectURL(new Blob([btoa(result)]))"><a download id=a>DL</a>
上記の処理をreadAsArrayBufferでやろうとするとクソ面倒な事になる。btoaは文字列しか受け入れやがらない体質だからだ。代替しようとするとbtoaへの渡し方は以下のようになる。
btoa(String.fromCharCode.apply(0,result))
ただしこれだと引数の個数の限界に引っ掛かると動作しなくなる。applyに代わりspread構文にしても同じ事である(現時点では)。限界突破したいなら以下のような処理になる。
btoa(Array.from(new Uint8Array(result),a=>String.fromCharCode(a)).join(""))
言うまでもなく低速化は免れられない。Unicode番号127以下の文字しか含まれない文字列であれば以下のようにできる。
btoa(new TextDecoder().decode(result))
余談
さて、他にも使い所は山盛りてんこ盛りであるが、そんな事はもはやどうでも良い。atobといいbtoaといい、その変態的な仕様にはうんざりだ。atob = ascii to binary、btoa = binary to asciiという解釈ではないのか。
それにもかかわらずatobの返り値は文字列、btoaの引数は文字列、これでは両方ともascii to asciiだろうと突っ込まざるを得ない