インターセプターは、スプリングMVCでよく使用されます。傍受する必要があるパスを構成する場合、<MVC：マッピング/>サブラベルがよく使用されます。パス属性があり、インターセプトする必要があるパスを指定するために使用されます。例えば：
<MVC：Interceptor> <MVC：Mapping Path = "/**"/> <Bean/> </MVC：Interceptor> </MVC：Interceptor>
上記の構成によれば、このインターセプターはすべてのリクエストをインターセプトします。
Spring MVCのパスマッチングは、標準のWeb.xmlよりもはるかに柔軟です。デフォルトのポリシーは、org.springframework.util.antpathmatcherを実装します。名前が示すように、パスパターンはApache Antスタイルのパスを使用します。 Apache Antスタイルのパスには3つのワイルドカードマッチング方法があります（下の表にリストされています）。これらは、多くの柔軟なパスパターンを組み合わせることができます。
テーブルアリワイルドカード文字
ワイルドカード | 説明 |
| ？ | 単一の文字を一致させます |
| * | 0または任意の数の文字を一致させます |
| ** | 0以上のディレクトリを一致させます |
テーブルの例アリスタイルのパスパターン
| パス | 説明 |
| /app/*.x | アプリパスの下ですべての.xファイルを一致させます |
| /app/p？ttern | 一致 /アプリ /パターンおよび /app /pxtternではありませんが、 /app /ptternではありません |
| /**/例 | 一致 /app /example、 /app /foo /example、および /example |
| /app/**/dir/ファイル。 | Matches /app/dir/file.jsp、/app/foo/dir/file.html、/app/foo/bar/dir/file.pdf、および/app/dir/file.java |
| /**/*.jsp | 任意の.jspファイルに一致します |
ハンドライング
Webアプリケーションは基本的にURLとリクエストプロセッサの間のマッピングに依存し、Spring MVCにも同じことが言えますが、Spring MVCはSpringのすべてのものと同じです（翻訳者：柔軟性、あらゆる種類のものを構成できますが、多くの複雑さを生み出します）。確かに、URLとコントローラーの関係をマッピングする1つの方法だけでなく、実際には、URLマッピングに依存するのではなく、マッピングルールと実装を自分で作成できます。
SpringはURLマッピング処理を提供し、パスパターンの処理の順序と方法は、どのインターフェースに限定されません。 Spring MVCのデフォルト実装org.springframework.web.servlet.handler。 abstracturllhandlermappingは、パスを最も長いパスパターンと一致させます。
たとえば、リクエストが/app/dir/file.jspであり、2つのパスマッチングパターン/**/*.jspと/app/dir/*.jspがあります。最後のパターン/app/dir/*.jspは、/**/*.jspよりも多くの文字を持つ最も長い文字の原理と一致します。この原則は、高レベルのインターフェイスでは指定されていませんが、実装の詳細であることに注意してください。
beannameurlhandlermapping
デフォルトのマッピング戦略の実装は、org.springframework.web.servlet.handler.beannameurlhandlermappingクラスです。このクラスでは、リクエストを処理できる豆には、バックスラッシュ（/）文字から始まる名前またはエイリアスが必要です。この名前またはエイリアスは、URLパスマッチング原理に準拠する任意の名前にすることができます。
Bean名でマッピングされたコントローラーのリスト
XMLコード
<bean name = "/home"> <プロパティname = "flightservice" ref = "flightservice"/> </bean>
■注：ID属性を使用してURLパスを指定することはできません。これは、XML仕様で（/）文字がXMLのIDを指定するために禁止されているためですが、Bean定義にID属性と名前属性の両方を持つことができます。
非常に使いやすく、いくつかの欠点があります。プロトタイプの豆を暗示することはできません。言い換えれば、beannameurlhandlermappingを使用する場合、すべての要求処理クラスはシングルトンのみになります。一般的に言えば、コントローラーはシングルトンに従って確立されているため、これはそれほど深刻な問題ではありません。また、次の章でコントローラーを紹介しますが、プロトタイプである必要があるコントローラーの種類はほとんどありません。
■注：プロトタイプBeanは非シングルトンビーンです。 getBean（）ApplicationContextの方法が呼び出されると、新しいBeanインスタンスが返されます。
BeannameurlhandLermappingのもう1つの問題は、アプリケーションにインターセプターが適用されることです。要求されたマップと豆のイマッピングマップは結び付けられており、分離されていないため、コントローラーとインターセプターの間に複雑な関係を作成することは不可能です。複雑なリクエストマッピング要件がある場合は、BeanNameurlhandLermappの代わりにSimpleUrlhandLermappを使用できます。 SimpleRlhandLermappingは、BeannameurlhandLermappingのもう1つのオプションです。 SimpleRlhandLermappingは、BeannameurlhandLermappの2つの主要な弱点を直接指しています。プロトタイプタイプのリクエストプロセッサをマッピングでき、ハンドラーとインターセプターの間に複雑で柔軟なマッピングパスを作成できます。マッピングアルゴリズムは、BeannameurlhandLermappsと同じ基本コンポーネントを使用するため、このパターンはまだURLをマップしてハンドラー（リクエストハンドラー）を要求するため、ApplicationContextで宣言してSimpleUrlhandLermappを使用できます。 DispatcherServletはタイプに従って見つかり、デフォルトのマッパー（BeanNameurlhandLermapping）は作成されません。これは、両方を使用したい場合、ApplicationContextですべてを宣言する必要があることを意味します。
■プロンプトディスパッチャーサーブレットは、チェーン内のリクエストを処理します（翻訳者：プロセスリクエストが順番に、フィルターとGOFSの責任モードのチェーンモードを参照できます）。これにより、要件に応じてマッピングを処理できます。マッピングプロセッサ（ハンドラーマッピング）は、Orderedrインターフェイスを実装します。
上記は、Spring MVC Path Matchingの原則の詳細な説明に関するこの記事のすべての内容です。誰にとっても役立つことを願っています。興味のある友人は、このサイトの他の関連トピックを引き続き参照できます。欠点がある場合は、それを指摘するためにメッセージを残してください。このサイトへのご支援をありがとうございました！