不快感を与えるテキストデータの入力を排除する

テキストエディタとコンパイラによる複合コントロールの作成

ディスカッションフォーラムなどのWebアプリケーションで、不快感を与えるテキストを受け付けないようにするには、さまざまな対策が考えられます。本稿では、テキストボックスとボタン、ラベルを合わせた複合コントロールを作成することで、この機能を実装します。

はじめに

　例えば、ユーザーからテキスト入力を受け取り、データベースへの保存とWebサイトへの表示を行うWebアプリケーションを作成しているとします。このようなアプリケーションの代表例はディスカッションフォーラムです。

　このアプリケーションを多様なユーザーに公開する場合には、不快感を与えるテキストを受け付けない（あるいはWebサイトに表示しない）ようにする必要があるかもしれません。

　そのためには、さまざまな対策が考えられます。

• アプリケーションのユーザーグループを限定する
つまり、アプリケーションの使用前にユーザーにログイン／登録を求めます。このようなシステムにすると、入力されたテキストを特定の登録ユーザーに結び付けることができるため、無責任なルール違反をするユーザーが減少します。仮に問題行動があったとしても、正しい情報でユーザー登録されていれば、そのユーザーを追跡することができます。未登録ユーザーを追跡することも不可能ではありませんが、確実性は劣ります。
• 管理者が調整を行う
管理者がテキストを承認してからサイトに発行するという方法です。この方法は管理者の負担が大きくなるため、あまり現実的ではありません。
• 不快感を与えるテキスト入力を受け付けない
これは、問題を根本から絶つ効果的な方法です。本稿ではこの方法を取り上げます。

　これから紹介するソリューションでは、不快感を与える言葉のリストをXMLファイルとして定義し、このリストに基づいてテキスト入力を制限する独自の複合コントロールを作成します。実装言語としてはVB .NETを使用し、テキストエディタとコマンドラインコンパイラ（vbc）を使ってコードの記述とコンパイルを行います。

コントロールについての復習

　まず、ASP.NETで使用できるコントロールの種類について簡単に復習しておきましょう。

　私たちが目にするコントロールはすべてサーバーコントロールです。これらはサーバー上で動作し、クライアントに対してHTMLをレンダリングします。サーバーコントロールは、Webフォームページに組み込まれているか（そのためオンデマンドでコンパイルされる）、プリコンパイルの状態で存在するかで大きく2つに分類されます。

　Microsoftは、次の種類のコントロールをASP.NETサーバーコントロールとして分類および区別しており、これらは前者のカテゴリに属します。

• HTMLサーバーコントロール
• Webサーバーコントロール
• 検証コントロール
• ユーザーコントロール

　おそらく最初の3つはおなじみだと思います。これらは（少なくともプログラマにとっては）最も単純な種類のコントロールであり、ASP.NET内であらかじめプログラミングされています。しかし、4つ目のユーザーコントロールはちょっと違います。

　ユーザーコントロールは.aspxページを.ascxという形にしたものであり、.aspxページから登録とインスタンス化を行うことでアクセスできます。これは、さまざまな付加機能を備えたサーバーサイドインクルードであり、完全にオブジェクト指向準拠のプログラミング言語を使用しているASP／ASP.NET開発者にとっては非常に有意義な手法です。ここで、私自身の言葉を交えながら、ASP.NETユーザーコントロールとは何かを定義しておきたいと思います。

　ASP.NETユーザーコントロールとは、一連の機能をカプセル化している複数のサーバーコントロールまたは静的HTML要素の集まりです（場合によってはコードも含まれています）。既存のサーバーコントロールの機能を拡張しただけのものもあれば（回転できるイメージコントロールや、日付をテキストボックスに格納するカレンダコントロールなど）、いくつかの要素を連携させて一連の決まった機能を実行させるものもあります。ユーザーコントロールの大きな特徴は、分離コードを通じて（またはHTML内で）自身のプロパティを公開でき、そのプロパティを他の要素から簡単に利用できることです。

　前述の4種類のコントロールは、拡張子.aspxおよび.ascxを持つWebフォームページの機能セットの一部としてJITコンパイルされるという点に注意してください。これらのクラスはページクラス階層から派生したものであり、所定のプロパティ、メソッド、イベントを継承しています。しかし、本稿で作成するカスタムコントロールは、ページクラスを継承する必要はありません。つまり、プリコンパイルコンポーネントとしてASP.NETのページフレームワークから切り離すことが可能です。ただし、それによってページフレームワークのサポートを受けられなくなるため、一部の機能を自分の手で実装する必要があります。

　MicrosoftはWebユーザーコントロールとWebカスタムコントロールを区別していますが、ユーザーコントロールもある程度はカスタマイズできるため、この区別はあまり適切でないように思います。いずれにしても、カスタムコントロールがユーザーコントロールと大きく違うのは、プリコンパイルされることと、ユーザーコントロールよりも作成が難しいことです。もう1つの大きな違いは、カスタムコントロールは、グローバルアセンブリキャッシュ（GAC）に登録できるため、再利用しやすいと考えられることです（それに対してユーザーコントロールは、IIS上のアプリケーションごとに別々のコピーが必要です）。IDEとデザイン時のサポートにも違いがあります。

　ユーザーコントロールとは対照的に、カスタムコントロールはクラスの形にコンパイルされます。さらに、HTML、JavaScriptなどのインターフェイス部分は、標準ページクラスのユーザーインターフェイス部分を使用するのではなく、コードとして記述します。そのため、プログラマは.NETプログラミングモデルの豊富な機能と独自の複雑なインターフェイスを柔軟に融合させることができます。カスタムコントロールはクラス内に含まれるため、.NET Frameworkのすべての機能を利用できます。つまり、プロパティを定義し、関数を実装することができます。実際、ASP.NETおよびVisual Studio .NETに用意されているサーバーコントロールは、実質的には、少々複雑なカスタムコントロールです。これらはコンパイル済みクラスであり、ページ上に配置されると、相互にやり取りし、OnLoadなどのイベントを利用してページとやり取りし、HTMLおよびスクリプトを発行して、ASP.NETテクノロジの機能を提供します。

　カスタムコントロールを作成するにはいくつかの方法があります。

• 2つ以上の既存のコントロールの機能を結合したコントロールをコンパイルする
例えば、ボタンとテキストボックスをカプセル化したコントロールが必要な場合は、既存のコントロールを一緒にコンパイルすることで、これを実現します。このようなコントロールのことを「複合コントロール」と呼びます。
• 既存のコントロールをカスタマイズする
要件のほとんどは既存のサーバーコントロールで満たされているが、必要な機能がいくつか不足している場合は、そのコントロールクラスから派生クラスを作成し、プロパティ、メソッド、イベントをオーバーライドします。
• 基本のコントロールクラスからカスタムコントロールを作成する
要件を満たす既存のWebサーバーコントロール（またはその組み合わせ）がない場合は、基本のコントロールクラスの1つから派生クラスを作成します。基本のコントロールクラスはWebサーバーコントロールの基本的な機能をすべて備えているため、必要な機能だけをプログラミングすれば済みます。

　既にお気付きかもしれませんが、ここでは1番目の方法に焦点を当てます。つまり、必要な機能を提供する単純な複合コントロールを作成します。通常、このように複雑な問題を扱う場合には、前述のユーザーコントロールとカスタムコントロールのメリット／デメリットを考えて、必要な機能をユーザーコントロールとして実装します。しかし本稿では、複合コントロールの作成に関するいくつかの問題を紹介するために、あえてカスタムコントロールに取り組むことにします。本稿のコードを出発点として、あれこれ研究してみてください。同じアプリケーションのユーザーコントロール版の実装に興味がある人は、自分自身で試してみるか、aspalliance.comに掲載されている私のコラムを参照してください。