XmlHttpRequest でのデータ受信時に NULL 文字が含まれていると、そこでデータが切れてしまいます。

Question

以下の現象はIE(6,7,8)の仕様でしょうか。

WEBサーバ上のHTMLにNULL(ヌル文字）が含まれている場合、
XmlHttpRequest オブジェクトからHTMLを取得すると、
NULL までのテキストしか取得できません。（NULLのところで切れます。）
（ブラウザ画面上やtelnetによるアクセスでは、何の問題も起きず、NULLを含めた
全てのHTMLが取得できます。）

WEBアプリに対して、NULL文字を登録（送信）することは、容易であり、
となると、アプリ側での対策（入力チェック、出力エスケープ）が必須になりそうですが、
皆様はどのように対策されておりますでしょうか？

Answer 1

サービス内容によるんでしょうけど、入力チェック、出力エスケープは必須かな。
項目単位で文字コードの範囲を決めています。特定の制御コードやコード表にないものはすべてエラー。
それによる工数増大(1.1-1.2倍とか？）は当然のトレードオフ。軽量サービスには向かないかも。

社内向けサービスなら、バイナリデータが得られるらしいresponseBodyをADODB.Streamに食わせたらどうにかなるかもと思ったり思わなかったり。
http://www.google.co.jp/search?hl=ja&lr=lang_ja&tbs=lr:lang_1ja&q=responseBody　ADODB.Stream　Microsoft.XMLHTTP　charset&aq=f&aqi=&aql=&oq=&gs_rfai=

Answer 2

アドバイスありがとうございます。

XHR.responseBody で対応できないか、検証してみたいと思います。

Answer 3

おかげさまで、responseBodyを調査してみましたが、vbScriptかADODB.Streamを使うあたりで、シンプルではないと思いました。

（無理に実装してWEBアプリに組み込んだとしても、将来的に時限爆弾になる可能性もありそうかなと。）

出力エスケープについては、HTMLエスケープやURLエスケープ、Unicodeエスケープ等、

いろいろな仕様がありますが、どれも「NULL（ヌル文字）」はエスケープ対象でないのが残念です。

よって、アドバイスどおり、「入力チェックにて特定の文字コード以外は受け付けないようにする」のが、

もっともスマートな方法なのでは、と考えております。

入力チェックといっても、2段階で防ぐのはどうでしょう？

ユーザビリティ(またはRIA)と考えると、JavaScript等を使い、データ入力画面上で”入力チェック”し、即座にエラーを表示するのが良いでしょうか。（第1段階）

データベースへの登録やファイル生成時には、共通処理（フレームワーク等）で”入力チェック”し、安全なデータのみ受け付けるようにするなど。（第2段階）

この方法なら、不正なアクセスで第1段階を潜り抜けたとしても、第2段階で完全防御できます。

しかし、"入力チェック"を最初からWEBサーバ側で行えば、1段階で防げるのでは？と思いましたが、

近年は、クライアント側（入力画面）に対して、ハイレベルな要求を受けるため、2段階防御にせざるを得ないかと。

（結局、もとどおりの一般的な設計に落ち着いたような・・・。）

以上、長文にお付き合いいただき、ありがとうございました。

Answer 4

dyamanak さん、

こんにちは。
フォーラム オペレーターの服部 清次です。

今回、1つの情報として、（´・ω・｀） さんのアドバイスが参考になったのではないかと思いましたので、
勝手ながら、ひとまず私の方で [回答としてマーク] させていただきました。

また何か疑問や質問がありましたら、ぜひ MSDN/TechNet フォーラムをご利用ください。
今後とも、よろしくお願いします。
それでは、また。

__________________________________________________
マイクロソフト株式会社　フォーラム オペレーター　服部 清次