モジュール java.base
パッケージ java.net

クラスURL

java.lang.Object
java.net.URL
すべての実装されたインタフェース:
Serializable
public final class URL extends Object implements Serializable
URLクラスは、Uniform Resource Locator (ユニフォーム・リソース・ロケータ)、つまりWorld Wide Web上の「リソース」へのポインタを表します。 リソースは、ファイルやディレクトリのような単純なものであることも、データベースや検索エンジンに対するクエリーなど、より複雑なオブジェクトへの参照であることもあります。 URLの種類や形式の詳細については、次を参照してください。 Types of URL

一般に、URLはいくつかの部分に分解できます。 次の例を検討してください: 

     http://www.example.com/docs/resource1.html

上記のURLは、使用すべきプロトコルがhttp (HyperText Transfer Protocol)であることと、www.example.comという名前のホスト・マシン上に情報が存在していることを示しています。 そのホスト・マシン上の情報には、/docs/resource1.htmlという名前が付けられています。 ホスト・マシン上におけるこの名前の正確な意味は、プロトコルとホストの両方に依存します。 一般的には情報はファイル内に保存されていますが、動的に生成される場合もあります。 URLのこうした部分はパス・コンポーネントと呼ばれます。

URLにはオプションで「ポート」を指定できます。これは、TCP接続の確立先となる、リモート・ホスト・マシン上のポート番号です。 ポートを指定しなかった場合は、代わりにプロトコルのデフォルト・ポートが使用されます。 たとえば、httpのデフォルト・ポートは80です。 次のように別のポートを指定することもできます。 

     http://www.example.com:1080/docs/resource1.html

URLの構文は、「RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax」で定義され、「RFC 2732: Format for Literal IPv6 Addresses in URLs」で修正されています。 リテラルIPv6アドレス形式ではスコープIDもサポートされます。 スコープIDの構文や使用方法については、ここを参照してください。

URLには「フラグメント」(「ref」または「参照(reference)」とも呼ぶ)を追加できます。 フラグメントは、シャープ記号文字「#」とそれに続くいくつかの文字によって示されます。 たとえば、 

     http://www.example.com/index.html#chapter1

本来は、このフラグメントはURLの一部ではありません。 たとえば、上に示したフラグメントは、指定されたリソースを取得したあと、そのドキュメントの中でchapter1というタグが付いている部分をアプリケーションによる処理の対象とすることを示します。 タグの意味はリソースによって異なります。

アプリケーションは「相対URL」を指定することもできます。このURLには、別のURLを基準としてリソースを検索するのに必要な情報しか含まれていません。 相対URLはHTMLページ内でよく使用されます。 たとえば、次のURLがあるとします。 

     http://www.example.com/index.html
このHTMLページの中に次の相対URLが含まれているとします。 
     FAQ.html
これは次の短縮形とみなされます。 
     http://www.example.com/FAQ.html

相対URLでは、URLのすべてのコンポーネントを指定する必要はありません。 プロトコルやホスト名、ポート番号を省略した場合には、すべてのコンポーネントが指定されているURLから値が継承されます。 ファイル・コンポーネントは指定しなければいけません。 オプション指定のフラグメントは継承されません。

URLのインスタンスの作成

java.net.URLコンストラクタは非推奨です。 開発者は、java.net.URIを使用してURLを解析または構築することをお薦めします。 接続を開くために java.net.URLのインスタンスが必要な場合、URIを使用してURL文字列を構築または解析できます。URI.parseServerAuthority()をコールして、権限コンポーネントをサーバー・ベースの権限として解析できることを確認し、URI.toURL()をコールしてURLインスタンスを作成できます。

URLコンストラクタはMalformedURLExceptionをスローするように指定されていますが、実行される実際の解析/検証は実装によって異なります。 一部の解析/検証は、基礎となる「ストリーム・ハンドラの実装」がコールされるまで遅延する場合があります。 URLのインスタンスを構築できるようにしても、URL構文仕様への準拠は保証されません。

URLクラス自体がRFC2396に定義されたエスケープ・メカニズムに従ってURLコンポーネントのエンコードやデコードを行うことはありません。 URLの呼出し前にエスケープの必要なすべてのフィールドをエンコードしておくことは、呼出し元の責任です。URLから返されたすべてのエスケープ済みフィールドをデコードすることも、同様です。 さらに、URLは、URLエスケープの知識を持たないため、同じURLのエンコードされた形式とデコードされた形式の等価性を判断できません。 たとえば、次の2つのURLがあるとします。
 

    http://foo.com/hello world/ and http://foo.com/hello%20world
これらは、互いに等しくないと見なされます。

URIクラスは特定の状況において、そのコンポーネント・フィールドに対してエスケープ処理を実行することに注意してください。 URLのエンコードとデコードを管理する際の推奨の方法は、URIを使用して、これら2つのクラス間の変換をtoURI()とURI.toURL()を使って行うことです。

URLEncoderクラスとURLDecoderクラスを使用することもできますが、これらはHTML形式のエンコーディング専用です。また、このエンコーディングは、RFC2396で定義されているエンコーディング方式と同じものではありません。

APIのノート:
ファイル・パスおよびファイルURIを操作するアプリケーションは、2つの間で変換する適切なメソッドを使用することを検討する必要があります。 Path.of(URI)ファクトリ・メソッドおよびFile(URI)コンストラクタを使用して、ファイルURIからPathまたはFileオブジェクトを作成できます。 Path.toUri()およびFile.toURI()を使用して、URI.toURL()を使用してURLに変換できるファイル・パスからURIを作成できます。 アプリケーションは、FileまたはPathインスタンスの直接文字列表現からURLをconstructまたはparseしないでください。

URIからURLを構築する前に、関連するプロトコルに応じて、アプリケーションはURI権限「サーバー・ベースとして解析できます」の検証を検討する必要があります。

URLまたはURIの一部のコンポーネント(userinfoなど)は、先行するURLまたはURIの構築に不正に使用される可能性があります。 Urlまたはuriを処理するアプリケーションは、「RFC3986,セクション7,セキュリティに関する考慮事項」で推奨される推奨事項を考慮してください。

すべてのURLコンストラクタは、MalformedURLExceptionをスローできます。 特に、基礎となるURLStreamHandler実装が拒否するか、拒否することがわかっている場合は、パラメータMalformedURLExceptionがスローされます。 通常、ストリーム・ハンドラの「parseURLメソッド」をコールするコンストラクタは、そのメソッドの基礎となるストリーム・ハンドラ実装がIllegalArgumentExceptionをスローする場合、MalformedURLExceptionをスローすることがあります。 ただし、ストリーム・ハンドラによってどのチェックが実行されるかは実装に依存するため、呼出し元は、完全なURL検証についてそのようなチェックに依存しないでください。

導入されたバージョン:
1.0
外部仕様
関連項目: