urllib.request — URLを開くための拡張可能なライブラリ—Pythonドキュメント
urllib.request —URLを開くための拡張可能なライブラリ
ソースコード: :source: `Lib / urllib / request.py`
urllib.request モジュールは、基本認証とダイジェスト認証、リダイレクト、Cookieなどの複雑な世界でURL(主にHTTP)を開くのに役立つ関数とクラスを定義します。
urllib.request モジュールは、次の関数を定義します。
- urllib.request.urlopen(url, data=None, [timeout, ]*, cafile=None, capath=None, cadefault=False, context=None)
URL url を開きます。これは、文字列または Request オブジェクトのいずれかです。
data は、サーバーに送信する追加データを指定するオブジェクトである必要があります。そのようなデータが必要ない場合は、
None
である必要があります。 詳細については、リクエストを参照してください。urllib.requestモジュールはHTTP / 1.1を使用し、HTTPリクエストに
Connection:close
ヘッダーを含めます。オプションの timeout パラメーターは、接続試行などのブロック操作のタイムアウトを秒単位で指定します(指定されていない場合は、グローバルなデフォルトのタイムアウト設定が使用されます)。 これは実際にはHTTP、HTTPS、FTP接続でのみ機能します。
context を指定する場合は、さまざまなSSLオプションを記述する ssl.SSLContext インスタンスである必要があります。 詳細については、 HTTPSConnection を参照してください。
オプションの cafile および capath パラメーターは、HTTPS要求の信頼できるCA証明書のセットを指定します。 cafile は、CA証明書のバンドルを含む単一のファイルを指す必要がありますが、 capath は、ハッシュされた証明書ファイルのディレクトリを指す必要があります。 詳細については、 ssl.SSLContext.load_verify_locations()を参照してください。
cadefault パラメーターは無視されます。
この関数は常にコンテキストマネージャーとして機能し、次のようなメソッドを持つオブジェクトを返します。
geturl()
—取得したリソースのURLを返します。これは、リダイレクトが実行されたかどうかを判断するために一般的に使用されます。info()
—ヘッダーなどのページのメタ情報を email.message_from_string()インスタンスの形式で返します( HTTPヘッダーのクイックリファレンスを参照)。 )getcode()
–応答のHTTPステータスコードを返します。
HTTPおよびHTTPSURLの場合、この関数はわずかに変更された http.client.HTTPResponse オブジェクトを返します。 上記の3つの新しいメソッドに加えて、msg属性には、のドキュメントで指定されている応答ヘッダーの代わりに、 reason 属性(サーバーから返される理由句)と同じ情報が含まれます。 HTTPResponse 。
従来の URLopener および FancyURLopener クラスによって明示的に処理されるFTP、ファイル、およびデータのURLと要求の場合、この関数は
urllib.response.addinfourl
オブジェクトを返します。プロトコルエラーで URLError を発生させます。
ハンドラーが要求を処理しない場合、
None
が返される場合があることに注意してください(ただし、デフォルトでインストールされているグローバル OpenerDirector は、 UnknownHandler を使用して、これが発生しないようにします)。また、プロキシ設定が検出された場合(たとえば、
http_proxy
などの*_proxy
環境変数が設定されている場合)、 ProxyHandler がデフォルトでインストールされ、リクエストがプロキシを介して処理されることを確認します。Python2.6以前のレガシー
urllib.urlopen
関数は廃止されました。 urllib.request.urlopen()は、古いurllib2.urlopen
に対応します。 辞書パラメータをurllib.urlopen
に渡すことによって行われたプロキシ処理は、 ProxyHandler オブジェクトを使用して取得できます。バージョン3.2で変更: cafile および capath が追加されました。
バージョン3.2での変更: HTTPS仮想ホストが可能であればサポートされるようになりました(つまり、 ssl.HAS_SNI がtrueの場合)。
バージョン3.2の新機能: data は反復可能なオブジェクトにすることができます。
バージョン3.3で変更: cadefault が追加されました。
バージョン3.4.3で変更: context が追加されました。
バージョン3.6以降非推奨: cafile 、 capath 、 cadefault は非推奨になり、 context が優先されます。 代わりに ssl.SSLContext.load_cert_chain()を使用するか、 ssl.create_default_context()にシステムの信頼できるCA証明書を選択させてください。
- urllib.request.install_opener(opener)
- OpenerDirector インスタンスをデフォルトのグローバルオープナーとしてインストールします。 オープナーのインストールは、urlopenでそのオープナーを使用する場合にのみ必要です。 それ以外の場合は、 urlopen()の代わりに OpenerDirector.open()を呼び出すだけです。 コードは実際の OpenerDirector をチェックせず、適切なインターフェイスを持つ任意のクラスが機能します。
- urllib.request.build_opener([handler, ...])
OpenerDirector インスタンスを返します。これは、指定された順序でハンドラーをチェーンします。 handler は、 BaseHandler のインスタンス、または BaseHandler のサブクラスのいずれかです(この場合、パラメーターなしでコンストラクターを呼び出すことができる必要があります)。 次のクラスのインスタンスは、ハンドラーに含まれていない限り、ハンドラーの前にあります。ただし、それらのインスタンスまたはサブクラス: ProxyHandler (ifプロキシ設定が検出されました)、 UnknownHandler 、 HTTPHandler 、 HTTPDefaultErrorHandler 、 HTTPRedirectHandler 、 FTPHandler 、 FileHandler 、 HTTPErrorProcessor 。
PythonインストールでSSLがサポートされている場合(つまり、 ssl モジュールをインポートできる場合)、 HTTPSHandler も追加されます。
BaseHandler サブクラスは、
handler_order
属性を変更して、ハンドラーリスト内の位置を変更することもできます。
- urllib.request.pathname2url(path)
- パス名 path を、パスのローカル構文からURLのパスコンポーネントで使用される形式に変換します。 これは完全なURLを生成しません。 戻り値は、 quote()関数を使用してすでに引用されています。
- urllib.request.url2pathname(path)
- パスコンポーネント path をパーセントエンコードされたURLからパスのローカル構文に変換します。 これは完全なURLを受け入れません。 この関数は、 unquote()を使用してパスをデコードします。
- urllib.request.getproxies()
このヘルパー関数は、スキームのディクショナリをプロキシサーバーのURLマッピングに返します。 大文字と小文字を区別しないアプローチで、最初にすべてのオペレーティングシステムについて、
<scheme>_proxy
という名前の変数について環境をスキャンし、見つからない場合は、Mac OSXおよびWindowsシステムレジストリのMacOSXシステム構成からプロキシ情報を探します。 Windows用。 小文字と大文字の両方の環境変数が存在する(そして同意しない)場合は、小文字が優先されます。ノート
環境変数
REQUEST_METHOD
が設定されている場合、これは通常、スクリプトがCGI環境で実行されていることを示し、環境変数HTTP_PROXY
(大文字の_PROXY
)は無視されます。 これは、その変数が「Proxy:」HTTPヘッダーを使用してクライアントによって挿入できるためです。 CGI環境でHTTPプロキシを使用する必要がある場合は、ProxyHandler
を明示的に使用するか、変数名が小文字(または少なくとも_proxy
サフィックス)であることを確認してください。
次のクラスが提供されています。
- class urllib.request.Request(url, data=None, headers={}, origin_req_host=None, unverifiable=False, method=None)
このクラスは、URLリクエストを抽象化したものです。
url は、有効なURLを含む文字列である必要があります。
data は、サーバーに送信する追加データを指定するオブジェクトである必要があります。そのようなデータが必要ない場合は、
None
である必要があります。 現在、データを使用するのはHTTPリクエストのみです。 サポートされているオブジェクトタイプには、バイト、ファイルのようなオブジェクト、およびバイトのようなオブジェクトの反復可能オブジェクトが含まれます。Content-Length
またはTransfer-Encoding
ヘッダーフィールドが指定されていない場合、 HTTPHandler はデータのタイプに従ってこれらのヘッダーを設定します。Content-Length
はバイトオブジェクトの送信に使用され、 RFC 7230 、セクション3.3.1で指定されているTransfer-Encoding: chunked
はファイルの送信に使用されます。他の反復可能。HTTP POSTリクエストメソッドの場合、 data は標準の application / x-www-form-urlencoded 形式のバッファーである必要があります。 urllib.parse.urlencode()関数は、2タプルのマッピングまたはシーケンスを受け取り、この形式のASCII文字列を返します。 data パラメータとして使用する前に、バイトにエンコードする必要があります。
headers は辞書である必要があり、 add_header()が各キーと値を引数として呼び出されたかのように扱われます。 これは、ブラウザが自身を識別するために使用する
User-Agent
ヘッダー値を「スプーフィング」するためによく使用されます。一部のHTTPサーバーは、スクリプトではなく、一般的なブラウザからのリクエストのみを許可します。 たとえば、MozillaFirefoxは自分自身を"Mozilla/5.0 (X11; U; Linux i686) Gecko/20071127 Firefox/2.0.0.11"
として識別しますが、 urllib のデフォルトのユーザーエージェント文字列は"Python-urllib/2.6"
(Python 2.6の場合)です。data 引数が存在する場合は、適切な
Content-Type
ヘッダーを含める必要があります。 このヘッダーが提供されておらず、 data がNoneでない場合、Content-Type: application/x-www-form-urlencoded
がデフォルトとして追加されます。次の2つの引数は、サードパーティのHTTPCookieを正しく処理するためにのみ重要です。
origin_req_host は、 RFC 2965 で定義されているように、オリジントランザクションのリクエストホストである必要があります。 デフォルトは
http.cookiejar.request_host(self)
です。 これは、ユーザーによって開始された元の要求のホスト名またはIPアドレスです。 たとえば、リクエストがHTMLドキュメント内の画像に対するものである場合、これは画像を含むページに対するリクエストのリクエストホストである必要があります。unverizable は、 RFC 2965 で定義されているように、リクエストが検証不可能かどうかを示す必要があります。 デフォルトは
False
です。 検証不可能なリクエストとは、ユーザーが承認するオプションがなかったURLのリクエストです。 たとえば、リクエストがHTMLドキュメント内の画像に対するものであり、ユーザーが画像の自動フェッチを承認するオプションがなかった場合、これは当てはまるはずです。method は、使用されるHTTPリクエストメソッドを示す文字列である必要があります(例:
'HEAD'
)。 指定されている場合、その値は method 属性に格納され、 get_method()によって使用されます。 data がNone
の場合、デフォルトは'GET'
、それ以外の場合は'POST'
です。 サブクラスは、クラス自体に method 属性を設定することにより、異なるデフォルトメソッドを示す場合があります。ノート
データオブジェクトがコンテンツを複数回配信できない場合、リクエストは期待どおりに機能しません(例: コンテンツを1回だけ生成できるファイルまたはイテラブル)およびHTTPリダイレクトまたは認証のために要求が再試行されます。 data は、ヘッダーの直後にHTTPサーバーに送信されます。 ライブラリでは、100継続の期待値はサポートされていません。
バージョン3.3で変更: Request.method 引数がRequestクラスに追加されました。
バージョン3.4で変更:デフォルト Request.method はクラスレベルで示される場合があります。
バージョン3.6で変更:
Content-Length
が提供されておらず、 data がNone
でもbytesオブジェクトでもない場合でもエラーは発生しません。 代わりにチャンク転送エンコーディングを使用するようにフォールバックします。
- class urllib.request.OpenerDirector
- OpenerDirector クラスは、チェーンされた BaseHandler を介してURLを開きます。 ハンドラーのチェーンとエラーからの回復を管理します。
- class urllib.request.BaseHandler
- これは、登録されているすべてのハンドラーの基本クラスであり、登録の単純なメカニズムのみを処理します。
- class urllib.request.HTTPDefaultErrorHandler
- HTTPエラー応答のデフォルトハンドラーを定義するクラス。 すべての応答は HTTPError 例外に変換されます。
- class urllib.request.HTTPRedirectHandler
- リダイレクトを処理するクラス。
- class urllib.request.HTTPCookieProcessor(cookiejar=None)
- HTTPCookieを処理するクラス。
- class urllib.request.ProxyHandler(proxies=None)
リクエストにプロキシを経由させます。 プロキシを指定する場合は、プロトコル名をプロキシのURLにマッピングする辞書である必要があります。 デフォルトでは、環境変数
<protocol>_proxy
からプロキシのリストを読み取ります。 プロキシ環境変数が設定されていない場合、Windows環境では、プロキシ設定はレジストリの[インターネット設定]セクションから取得され、Mac OS X環境では、プロキシ情報はOSXシステム構成フレームワークから取得されます。自動検出されたプロキシを無効にするには、空の辞書を渡します。
no_proxy
環境変数を使用して、プロキシ経由で到達してはならないホストを指定できます。 設定する場合は、ホスト名サフィックスのコンマ区切りリストにする必要があります。オプションで、:port
を追加します(例:cern.ch,ncsa.uiuc.edu,some.host:8080
)。ノート
変数
REQUEST_METHOD
が設定されている場合、HTTP_PROXY
は無視されます。 getproxies()のドキュメントを参照してください。
- class urllib.request.HTTPPasswordMgr
(realm, uri) -> (user, password)
マッピングのデータベースを保持します。
- class urllib.request.HTTPPasswordMgrWithDefaultRealm
(realm, uri) -> (user, password)
マッピングのデータベースを保持します。None
のレルムは、キャッチオールレルムと見なされ、他のレルムが適合しない場合に検索されます。
- class urllib.request.HTTPPasswordMgrWithPriorAuth
HTTPPasswordMgrWithDefaultRealm のバリアントで、
uri -> is_authenticated
マッピングのデータベースもあります。 BasicAuthハンドラーで使用して、最初に401
応答を待つのではなく、認証資格情報をすぐに送信するタイミングを決定できます。バージョン3.5の新機能。
- class urllib.request.AbstractBasicAuthHandler(password_mgr=None)
これは、リモートホストとプロキシの両方に対するHTTP認証を支援するミックスインクラスです。 password_mgr は、指定されている場合、 HTTPPasswordMgr と互換性のあるものである必要があります。 サポートする必要のあるインターフェイスについては、セクション HTTPPasswordMgrオブジェクトを参照してください。 passwd_mgr が
is_authenticated
およびupdate_authenticated
メソッドも提供する場合( HTTPPasswordMgrWithPriorAuthオブジェクトを参照)、ハンドラーはis_authenticated
の結果を次のように使用します。リクエストとともに認証クレデンシャルを送信するかどうかを決定するための特定のURI。is_authenticated
がURIに対してTrue
を返す場合、資格情報が送信されます。is_authenticated
がFalse
の場合、資格情報は送信されず、401
応答が受信されると、要求は認証資格情報とともに再送信されます。 認証が成功すると、update_authenticated
が呼び出され、URIにis_authenticated
True
が設定されます。これにより、URIまたはそのスーパーURIへの後続の要求には、認証資格情報が自動的に含まれます。 。バージョン3.5の新機能:
is_authenticated
のサポートが追加されました。
- class urllib.request.HTTPBasicAuthHandler(password_mgr=None)
- リモートホストで認証を処理します。 password_mgr は、指定されている場合、 HTTPPasswordMgr と互換性のあるものである必要があります。 サポートする必要のあるインターフェイスについては、セクション HTTPPasswordMgrオブジェクトを参照してください。 HTTPBasicAuthHandlerは、間違った認証スキームが提示されると、 ValueError を発生させます。
- class urllib.request.ProxyBasicAuthHandler(password_mgr=None)
- プロキシで認証を処理します。 password_mgr は、指定されている場合、 HTTPPasswordMgr と互換性のあるものである必要があります。 サポートする必要のあるインターフェイスについては、セクション HTTPPasswordMgrオブジェクトを参照してください。
- class urllib.request.AbstractDigestAuthHandler(password_mgr=None)
- これは、リモートホストとプロキシの両方に対するHTTP認証を支援するミックスインクラスです。 password_mgr は、指定されている場合、 HTTPPasswordMgr と互換性のあるものである必要があります。 サポートする必要のあるインターフェイスについては、セクション HTTPPasswordMgrオブジェクトを参照してください。
- class urllib.request.HTTPDigestAuthHandler(password_mgr=None)
リモートホストで認証を処理します。 password_mgr は、指定されている場合、 HTTPPasswordMgr と互換性のあるものである必要があります。 サポートする必要のあるインターフェイスについては、セクション HTTPPasswordMgrオブジェクトを参照してください。 ダイジェスト認証ハンドラーと基本認証ハンドラーの両方が追加されている場合、ダイジェスト認証が常に最初に試行されます。 ダイジェスト認証が再び40x応答を返す場合、それは処理するために基本認証ハンドラーに送信されます。 このHandlerメソッドは、DigestまたはBasic以外の認証スキームで提示されると、 ValueError を発生させます。
バージョン3.3で変更:サポートされていない認証スキームで ValueError を発生させます。
- class urllib.request.ProxyDigestAuthHandler(password_mgr=None)
- プロキシで認証を処理します。 password_mgr は、指定されている場合、 HTTPPasswordMgr と互換性のあるものである必要があります。 サポートする必要のあるインターフェイスについては、セクション HTTPPasswordMgrオブジェクトを参照してください。
- class urllib.request.HTTPHandler
- HTTPURLのオープンを処理するクラス。
- class urllib.request.HTTPSHandler(debuglevel=0, context=None, check_hostname=None)
HTTPSURLのオープンを処理するクラス。 context および check_hostname は、 http.client.HTTPSConnection と同じ意味です。
バージョン3.2で変更: context および check_hostname が追加されました。
- class urllib.request.FileHandler
- ローカルファイルを開きます。
- class urllib.request.DataHandler
オープンデータのURL。
バージョン3.4の新機能。
- class urllib.request.FTPHandler
- FTPURLを開きます。
- class urllib.request.CacheFTPHandler
- FTP URLを開き、開いているFTP接続のキャッシュを保持して、遅延を最小限に抑えます。
- class urllib.request.UnknownHandler
- 不明なURLを処理するためのキャッチオールクラス。
- class urllib.request.HTTPErrorProcessor
- HTTPエラー応答を処理します。
リクエストオブジェクト
次のメソッドは Request のパブリックインターフェイスを記述しているため、すべてがサブクラスでオーバーライドされる可能性があります。 また、クライアントが解析された要求を検査するために使用できるいくつかのパブリック属性も定義します。
- Request.full_url
コンストラクターに渡された元のURL。
バージョン3.4で変更されました。
Request.full_urlは、setter、getter、およびdeleterを持つプロパティです。 full_url を取得すると、フラグメントが存在する場合は、フラグメントを含む元のリクエストURLが返されます。
- Request.type
- URIスキーム。
- Request.host
- URI権限(通常はホスト)ですが、コロンで区切られたポートが含まれる場合もあります。
- Request.origin_req_host
- ポートなしの、リクエストの元のホスト。
- Request.selector
- URIパス。 Request がプロキシを使用する場合、セレクターはプロキシに渡される完全なURLになります。
- Request.data
リクエストのエンティティ本体、または指定されていない場合は
None
。バージョン3.4で変更: Request.data の値を変更すると、「Content-Length」ヘッダーが以前に設定または計算されていた場合に削除されるようになりました。
- Request.unverifiable
- booleanは、 RFC 2965 で定義されているように要求が検証できないかどうかを示します。
- Request.method
使用するHTTPリクエストメソッド。 デフォルトでは、その値は None です。これは、 get_method()が使用されるメソッドの通常の計算を実行することを意味します。 その値は、 Request サブクラスのクラスレベルで設定してデフォルト値を指定するか、 get_method()のデフォルト計算をオーバーライドする)で設定できます。 method 引数を介して Request コンストラクターに値を入力します。
バージョン3.3の新機能。
バージョン3.4で変更:デフォルト値をサブクラスに設定できるようになりました。 以前は、コンストラクター引数を介してのみ設定できました。
- Request.get_method()
HTTPリクエストメソッドを示す文字列を返します。 Request.method が
None
でない場合はその値を返し、 Request.data がNone
の場合は'GET'
を返します。そうでない場合は'POST'
。 これは、HTTPリクエストに対してのみ意味があります。バージョン3.3で変更: get_methodは Request.method の値を参照するようになりました。
- Request.add_header(key, val)
- リクエストに別のヘッダーを追加します。 ヘッダーは現在、サーバーに送信されるヘッダーのリストに追加されるHTTPハンドラーを除くすべてのハンドラーによって無視されます。 同じ名前のヘッダーが複数存在することはできません。キーが衝突した場合、後の呼び出しで前の呼び出しが上書きされることに注意してください。 現在、これはHTTP機能の損失ではありません。これは、複数回使用されたときに意味を持つすべてのヘッダーには、1つのヘッダーのみを使用して同じ機能を取得する(ヘッダー固有の)方法があるためです。
- Request.add_unredirected_header(key, header)
- リダイレクトされたリクエストに追加されないヘッダーを追加します。
- Request.has_header(header)
- インスタンスに名前付きヘッダーがあるかどうかを返します(通常とリダイレクトなしの両方をチェックします)。
- Request.remove_header(header)
名前付きヘッダーをリクエストインスタンスから削除します(通常のヘッダーとリダイレクトされていないヘッダーの両方から)。
バージョン3.4の新機能。
- Request.get_full_url()
コンストラクターで指定されたURLを返します。
バージョン3.4で変更されました。
Request.full_url を返します
- Request.set_proxy(host, type)
- プロキシサーバーに接続してリクエストを準備します。 host と type はインスタンスのものを置き換え、インスタンスのセレクターはコンストラクターで指定された元のURLになります。
- Request.get_header(header_name, default=None)
- 指定されたヘッダーの値を返します。 ヘッダーが存在しない場合は、デフォルト値を返します。
- Request.header_items()
- リクエストヘッダーのタプル(header_name、header_value)のリストを返します。
バージョン3.4で変更: 3.3以降非推奨となったリクエストメソッドadd_data、has_data、get_data、get_type、get_host、get_selector、get_origin_req_host、is_unverizableは削除されました。
OpenerDirectorオブジェクト
OpenerDirector インスタンスには次のメソッドがあります。
- OpenerDirector.add_handler(handler)
handler は BaseHandler のインスタンスである必要があります。 次のメソッドが検索され、可能なチェーンに追加されます(HTTPエラーは特殊なケースであることに注意してください)。 以下では、 protocol を実際に処理するプロトコルに置き換える必要があることに注意してください。たとえば、
http_response()
はHTTPプロトコル応答ハンドラーになります。 また、 type は実際のHTTPコードに置き換える必要があります。たとえば、http_error_404()
はHTTP404エラーを処理します。<protocol>_open()
—ハンドラーがプロトコル URLを開く方法を知っていることを通知します。見る BaseHandler。 _開いた() 詳細については。
http_error_<type>()
—ハンドラーがHTTPエラーコード type でHTTPエラーを処理する方法を知っていることを通知します。見る BaseHandler.http_error_ () 詳細については。
<protocol>_error()
—ハンドラーが(http
以外)プロトコルからのエラーを処理する方法を知っていることを通知します。<protocol>_request()
—ハンドラーがプロトコル要求を前処理する方法を知っていることを通知します。見る BaseHandler。 _リクエスト() 詳細については。
<protocol>_response()
—ハンドラーがプロトコル応答を後処理する方法を知っていることを通知します。見る BaseHandler。 _応答() 詳細については。
- OpenerDirector.open(url, data=None[, timeout])
- 指定された url (リクエストオブジェクトまたは文字列の場合があります)を開き、オプションで指定された data を渡します。 発生する引数、戻り値、および例外は、 urlopen()(現在インストールされているグローバル OpenerDirector で open()メソッドを呼び出すだけです)と同じです。 。 オプションの timeout パラメーターは、接続試行などのブロック操作のタイムアウトを秒単位で指定します(指定されていない場合は、グローバルなデフォルトのタイムアウト設定が使用されます)。 タイムアウト機能は、実際にはHTTP、HTTPS、およびFTP接続でのみ機能します)。
- OpenerDirector.error(proto, *args)
指定されたプロトコルのエラーを処理します。 これにより、指定された引数(プロトコル固有)を使用して、指定されたプロトコルの登録済みエラーハンドラーが呼び出されます。 HTTPプロトコルは、HTTP応答コードを使用して特定のエラーハンドラーを判別する特殊なケースです。 ハンドラークラスの
http_error_<type>()
メソッドを参照してください。発生する戻り値と例外は、 urlopen()と同じです。
OpenerDirectorオブジェクトは、次の3つの段階でURLを開きます。
これらのメソッドが各ステージ内で呼び出される順序は、ハンドラーインスタンスを並べ替えることによって決定されます。
<protocol>_request()
のような名前のメソッドを持つすべてのハンドラーには、リクエストを前処理するために呼び出されるそのメソッドがあります。<protocol>_open()
のような名前のメソッドを持つハンドラーは、要求を処理するために呼び出されます。 この段階は、ハンドラーが None 以外の値を返すと終了します(つまり、 応答)、または例外を発生させます(通常は URLError )。 例外は伝播できます。実際、上記のアルゴリズムは、
default_open()
という名前のメソッドに対して最初に試行されます。 そのようなすべてのメソッドが None を返す場合、<protocol>_open()
のような名前のメソッドに対してアルゴリズムが繰り返されます。 そのようなすべてのメソッドが None を返す場合、unknown_open()
という名前のメソッドに対してアルゴリズムが繰り返されます。これらのメソッドの実装には、親 OpenerDirector インスタンスの open()および error()メソッドの呼び出しが含まれる場合があることに注意してください。
<protocol>_response()
のような名前のメソッドを持つすべてのハンドラーには、応答を後処理するために呼び出されるそのメソッドがあります。
BaseHandlerオブジェクト
BaseHandler オブジェクトは、直接役立つメソッドと、派生クラスで使用されることを意図したメソッドをいくつか提供します。 これらは直接使用することを目的としています。
- BaseHandler.add_parent(director)
- 親としてディレクターを追加します。
- BaseHandler.close()
- 親を削除します。
次の属性とメソッドは、 BaseHandler から派生したクラスでのみ使用する必要があります。
ノート
<protocol>_request()
または<protocol>_response()
メソッドを定義するサブクラスには*Processor
という名前が付けられるという規則が採用されています。 他のすべての名前は*Handler
です。
- BaseHandler.parent
- 有効な OpenerDirector 。これを使用して、別のプロトコルを使用して開いたり、エラーを処理したりできます。
- BaseHandler.default_open(req)
このメソッドは BaseHandler で定義されているではなくですが、すべてのURLをキャッチする場合は、サブクラスで定義する必要があります。
このメソッドが実装されている場合、親 OpenerDirector によって呼び出されます。 OpenerDirector または
None
の open()の戻り値で説明されているように、ファイルのようなオブジェクトを返す必要があります。 本当に例外的なことが起こらない限り、 URLError を発生させる必要があります(たとえば、 MemoryError をURLError
にマップしないでください)。このメソッドは、プロトコル固有のopenメソッドの前に呼び出されます。
- BaseHandler.<protocol>_open(req)
このメソッドは BaseHandler で定義されたではなくですが、指定されたプロトコルでURLを処理する場合は、サブクラスで定義する必要があります。
このメソッドは、定義されている場合、親 OpenerDirector によって呼び出されます。 戻り値は
default_open()
と同じである必要があります。
- BaseHandler.unknown_open(req)
このメソッドは BaseHandler で定義されている not ですが、特定の登録済みハンドラーがないすべてのURLをキャッチして開く場合は、サブクラスで定義する必要があります。
このメソッドが実装されている場合、親 OpenerDirector によって呼び出されます。 戻り値は、 default_open()の場合と同じである必要があります。
- BaseHandler.http_error_default(req, fp, code, msg, hdrs)
このメソッドは BaseHandler で定義されている not ですが、サブクラスは、他の方法で処理されないHTTPエラーのキャッチオールを提供する場合は、このメソッドをオーバーライドする必要があります。 OpenerDirector がエラーを取得すると自動的に呼び出されますが、他の状況では通常は呼び出されません。
req は Request オブジェクト、 fp はHTTPエラー本体を持つファイルのようなオブジェクト、 code は3つになります-エラーの数字コード。 msg はユーザーに表示されるコードの説明であり、 hdrs はエラーのヘッダーを持つマッピングオブジェクトです。
発生する戻り値と例外は、 urlopen()のものと同じである必要があります。
- BaseHandler.http_error_<nnn>(req, fp, code, msg, hdrs)
nnn は3桁のHTTPエラーコードである必要があります。 このメソッドも BaseHandler で定義されていませんが、存在する場合は、コード nnn のHTTPエラーが発生すると、サブクラスのインスタンスで呼び出されます。
サブクラスは、特定のHTTPエラーを処理するために、このメソッドをオーバーライドする必要があります。
発生する引数、戻り値、および例外は、
http_error_default()
の場合と同じである必要があります。
- BaseHandler.<protocol>_request(req)
このメソッドは BaseHandler で定義されたではなくですが、サブクラスは、指定されたプロトコルの要求を前処理する場合に定義する必要があります。
このメソッドは、定義されている場合、親 OpenerDirector によって呼び出されます。 req は Request オブジェクトになります。 戻り値は Request オブジェクトである必要があります。
- BaseHandler.<protocol>_response(req, response)
このメソッドは、 BaseHandler で定義されたではなくですが、サブクラスは、指定されたプロトコルの応答を後処理する場合に定義する必要があります。
このメソッドは、定義されている場合、親 OpenerDirector によって呼び出されます。 req は Request オブジェクトになります。 response は、 urlopen()の戻り値と同じインターフェイスを実装するオブジェクトになります。 戻り値は、 urlopen()の戻り値と同じインターフェイスを実装する必要があります。
HTTPRedirectHandlerオブジェクト
ノート
一部のHTTPリダイレクトでは、このモジュールのクライアントコードからのアクションが必要です。 この場合、 HTTPError が発生します。 さまざまなリダイレクトコードの正確な意味の詳細については、 RFC 2616 を参照してください。
HTTPError
例外は、HTTPRedirectHandlerがHTTP、HTTPS、またはFTPURLではないリダイレクトされたURLで提示された場合にセキュリティ上の考慮事項として発生します。
- HTTPRedirectHandler.redirect_request(req, fp, code, msg, hdrs, newurl)
リダイレクトに応答して、 Request または
None
を返します。 これは、サーバーからリダイレクトを受信したときに、http_error_30*()
メソッドのデフォルトの実装によって呼び出されます。 リダイレクトが必要な場合は、新しい Request を返して、http_error_30*()
が newurl へのリダイレクトを実行できるようにします。 それ以外の場合、他のハンドラーがこのURLを処理しようとしない場合は、 HTTPError を発生させ、他のハンドラーが処理できない場合はNone
を返します。ノート
このメソッドのデフォルトの実装は、 RFC 2616 に厳密には準拠していません。つまり、
POST
要求に対する301および302応答は、ユーザーの確認なしに自動的にリダイレクトされてはなりません。 。 実際には、ブラウザはこれらの応答の自動リダイレクトを許可し、POSTをGET
に変更し、デフォルトの実装はこの動作を再現します。
- HTTPRedirectHandler.http_error_301(req, fp, code, msg, hdrs)
Location:
またはURI:
のURLにリダイレクトします。 このメソッドは、HTTPの「永続的に移動」応答を取得するときに親 OpenerDirector によって呼び出されます。
- HTTPRedirectHandler.http_error_302(req, fp, code, msg, hdrs)
- http_error_301()と同じですが、「見つかった」応答が必要です。
- HTTPRedirectHandler.http_error_303(req, fp, code, msg, hdrs)
- http_error_301()と同じですが、「他を参照」応答が必要です。
- HTTPRedirectHandler.http_error_307(req, fp, code, msg, hdrs)
- http_error_301()と同じですが、「一時的なリダイレクト」応答が必要です。
ProxyHandlerオブジェクト
- ProxyHandler.<protocol>_open(request)
- ProxyHandler には、コンストラクターで指定された proxys ディクショナリにプロキシがあるすべての protocol に対してメソッド
<protocol>_open()
があります。 このメソッドは、request.set_proxy()
を呼び出すことによってプロキシを通過するように要求を変更し、チェーン内の次のハンドラーを呼び出して実際にプロトコルを実行します。
HTTPPasswordMgrオブジェクト
これらのメソッドは、 HTTPPasswordMgr および HTTPPasswordMgrWithDefaultRealm オブジェクトで使用できます。
- HTTPPasswordMgr.add_password(realm, uri, user, passwd)
- uri は、単一のURIまたは一連のURIのいずれかです。 realm 、 user 、および passwd は文字列である必要があります。 これにより、レルムの認証および指定されたURIのいずれかのスーパーURIが指定されたときに、
(user, passwd)
が認証トークンとして使用されます。
- HTTPPasswordMgr.find_user_password(realm, authuri)
指定されたレルムとURIがある場合は、そのユーザー/パスワードを取得します。 一致するユーザー/パスワードがない場合、このメソッドは
(None, None)
を返します。HTTPPasswordMgrWithDefaultRealm オブジェクトの場合、指定されたレルムに一致するユーザー/パスワードがない場合、レルム
None
が検索されます。
HTTPPasswordMgrWithPriorAuthオブジェクト
このパスワードマネージャーは、 HTTPPasswordMgrWithDefaultRealm を拡張して、認証資格情報を常に送信する必要があるURIの追跡をサポートします。
- HTTPPasswordMgrWithPriorAuth.add_password(realm, uri, user, passwd, is_authenticated=False)
- realm 、 uri 、 user 、 passwd は、 HTTPPasswordMgr.add_password()と同じです。 is_authenticated は、指定されたURIまたはURIのリストの
is_authenticated
フラグの初期値を設定します。 is_authenticated がTrue
として指定されている場合、レルムは無視されます。
- HTTPPasswordMgrWithPriorAuth.find_user_password(realm, authuri)
- HTTPPasswordMgrWithDefaultRealm オブジェクトの場合と同じ
- HTTPPasswordMgrWithPriorAuth.update_authenticated(self, uri, is_authenticated=False)
- 指定された uri またはURIのリストの
is_authenticated
フラグを更新します。
- HTTPPasswordMgrWithPriorAuth.is_authenticated(self, authuri)
- 指定されたURIの
is_authenticated
フラグの現在の状態を返します。
AbstractBasicAuthHandlerオブジェクト
- AbstractBasicAuthHandler.http_error_auth_reqed(authreq, host, req, headers)
ユーザーとパスワードのペアを取得し、要求を再試行することにより、認証要求を処理します。 authreq は、レルムに関する情報がリクエストに含まれているヘッダーの名前である必要があります。 host は、認証するURLとパスを指定し、 req は認証する必要があります。 (失敗した) Request オブジェクトであり、 headers はエラーヘッダーである必要があります。
host はいずれかの機関です(例:
"python.org"
)または権限コンポーネントを含むURL(例:"http://python.org/%22
)。 いずれの場合も、権限にuserinfoコンポーネントを含めることはできません(したがって、"python.org"
および"python.org:80"
は問題ありませんが、"joe:[email protected]"
は問題ありません)。
HTTPBasicAuthHandlerオブジェクト
- HTTPBasicAuthHandler.http_error_401(req, fp, code, msg, hdrs)
- 可能な場合は、認証情報を使用して要求を再試行してください。
ProxyBasicAuthHandlerオブジェクト
- ProxyBasicAuthHandler.http_error_407(req, fp, code, msg, hdrs)
- 可能な場合は、認証情報を使用して要求を再試行してください。
AbstractDigestAuthHandlerオブジェクト
- AbstractDigestAuthHandler.http_error_auth_reqed(authreq, host, req, headers)
- authreq は、レルムに関する情報がリクエストに含まれているヘッダーの名前である必要があります。 host は、認証先のホストである必要があります。 req は、 (失敗した) Request オブジェクト、および headers はエラーヘッダーである必要があります。
HTTPDigestAuthHandlerオブジェクト
- HTTPDigestAuthHandler.http_error_401(req, fp, code, msg, hdrs)
- 可能な場合は、認証情報を使用して要求を再試行してください。
ProxyDigestAuthHandlerオブジェクト
- ProxyDigestAuthHandler.http_error_407(req, fp, code, msg, hdrs)
- 可能な場合は、認証情報を使用して要求を再試行してください。
HTTPHandlerオブジェクト
- HTTPHandler.http_open(req)
req.has_data()
に応じて、GETまたはPOSTのいずれかのHTTPリクエストを送信します。
HTTPSHandlerオブジェクト
- HTTPSHandler.https_open(req)
req.has_data()
に応じて、GETまたはPOSTのいずれかのHTTPSリクエストを送信します。
FileHandlerオブジェクト
- FileHandler.file_open(req)
ホスト名がない場合、またはホスト名が
'localhost'
の場合は、ファイルをローカルで開きます。バージョン3.2で変更:この方法は、ローカルホスト名にのみ適用できます。 リモートホスト名を指定すると、 URLError が発生します。
DataHandlerオブジェクト
- DataHandler.data_open(req)
- データURLを読み取ります。 この種類のURLには、URL自体にエンコードされたコンテンツが含まれています。 データURL構文は、 RFC 2397 で指定されています。 この実装では、base64でエンコードされたデータURLの空白が無視されるため、URLは元のソースファイルにラップされる可能性があります。 ただし、一部のブラウザは、base64でエンコードされたデータURLの末尾にパディングがないことを気にしませんが、この実装では、その場合に ValueError が発生します。
FTPHandlerオブジェクト
- FTPHandler.ftp_open(req)
- req で示されるFTPファイルを開きます。 ログインは常に空のユーザー名とパスワードで行われます。
CacheFTPHandlerオブジェクト
CacheFTPHandler オブジェクトは、次の追加メソッドを持つ FTPHandler オブジェクトです。
- CacheFTPHandler.setTimeout(t)
- 接続のタイムアウトを t 秒に設定します。
- CacheFTPHandler.setMaxConns(m)
- キャッシュ接続の最大数を m に設定します。
HTTPErrorProcessorオブジェクト
- HTTPErrorProcessor.http_response(request, response)
HTTPエラー応答を処理します。
200のエラーコードの場合、応答オブジェクトはすぐに返されます。
200以外のエラーコードの場合、これは OpenerDirector.error()を介して
http_error_<type>()
ハンドラーメソッドにジョブを渡すだけです。 最終的に、他のハンドラーがエラーを処理しない場合、 HTTPDefaultErrorHandler は HTTPError を発生させます。
- HTTPErrorProcessor.https_response(request, response)
HTTPSエラー応答を処理します。
動作は http_response()と同じです。
例
以下の例に加えて、 HOWTOでurllibパッケージを使用してインターネットリソースを取得するにさらに多くの例が示されています。
この例では、python.orgのメインページを取得し、その最初の300バイトを表示します。
>>> import urllib.request
>>> with urllib.request.urlopen('http://www.python.org/') as f:
... print(f.read(300))
...
b'<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">\n\n\n<html
xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">\n\n<head>\n
<meta http-equiv="content-type" content="text/html; charset=utf-8" />\n
<title>Python Programming '
urlopenはbytesオブジェクトを返すことに注意してください。 これは、urlopenがHTTPサーバーから受信するバイトストリームのエンコーディングを自動的に決定する方法がないためです。 一般に、プログラムは、適切なエンコーディングを決定または推測すると、返されたバイトオブジェクトを文字列にデコードします。
次のW3Cドキュメント https://www.w3.org/International/O-charset には、(X)HTMLまたはXMLドキュメントでエンコード情報を指定するさまざまな方法がリストされています。
python.org Webサイトは、メタタグで指定されている utf-8 エンコーディングを使用しているため、bytesオブジェクトのデコードにも同じものを使用します。
>>> with urllib.request.urlopen('http://www.python.org/') as f:
... print(f.read(100).decode('utf-8'))
...
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtm
コンテキストマネージャーアプローチを使用せずに同じ結果を達成することも可能です。
>>> import urllib.request
>>> f = urllib.request.urlopen('http://www.python.org/')
>>> print(f.read(100).decode('utf-8'))
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtm
次の例では、CGIのstdinにデータストリームを送信し、それが返すデータを読み取ります。 この例は、PythonインストールがSSLをサポートしている場合にのみ機能することに注意してください。
>>> import urllib.request
>>> req = urllib.request.Request(url='https://localhost/cgi-bin/test.cgi',
... data=b'This data is passed to stdin of the CGI')
>>> with urllib.request.urlopen(req) as f:
... print(f.read().decode('utf-8'))
...
Got Data: "This data is passed to stdin of the CGI"
上記の例で使用されているサンプルCGIのコードは次のとおりです。
#!/usr/bin/env python
import sys
data = sys.stdin.read()
print('Content-type: text/plain\n\nGot Data: "%s"' % data)
Request を使用してPUT
リクエストを実行する例を次に示します。
import urllib.request
DATA = b'some data'
req = urllib.request.Request(url='http://localhost:8080', data=DATA,method='PUT')
with urllib.request.urlopen(req) as f:
pass
print(f.status)
print(f.reason)
基本HTTP認証の使用:
import urllib.request
# Create an OpenerDirector with support for Basic HTTP Authentication...
auth_handler = urllib.request.HTTPBasicAuthHandler()
auth_handler.add_password(realm='PDQ Application',
uri='https://mahler:8092/site-updates.py',
user='klem',
passwd='kadidd!ehopper')
opener = urllib.request.build_opener(auth_handler)
# ...and install it globally so it can be used with urlopen.
urllib.request.install_opener(opener)
urllib.request.urlopen('http://www.example.com/login.html')
build_opener()は、 ProxyHandler を含む、多くのハンドラーをデフォルトで提供します。 デフォルトでは、 ProxyHandler は<scheme>_proxy
という名前の環境変数を使用します。ここで、<scheme>
は関連するURLスキームです。 たとえば、 http_proxy
環境変数が読み取られ、HTTPプロキシのURLが取得されます。
この例では、デフォルトの ProxyHandler を、プログラムで提供されたプロキシURLを使用するものに置き換え、 ProxyBasicAuthHandler でプロキシ認証サポートを追加します。
proxy_handler = urllib.request.ProxyHandler({'http': 'http://www.example.com:3128/'})
proxy_auth_handler = urllib.request.ProxyBasicAuthHandler()
proxy_auth_handler.add_password('realm', 'host', 'username', 'password')
opener = urllib.request.build_opener(proxy_handler, proxy_auth_handler)
# This time, rather than install the OpenerDirector, we use it directly:
opener.open('http://www.example.com/login.html')
HTTPヘッダーの追加:
headers 引数を Request コンストラクターに使用するか、次のようにします。
import urllib.request
req = urllib.request.Request('http://www.example.com/')
req.add_header('Referer', 'http://www.python.org/')
# Customize the default User-Agent header value:
req.add_header('User-Agent', 'urllib-example/0.1 (Contact: . . .)')
r = urllib.request.urlopen(req)
OpenerDirector は、すべての Request に User-Agent ヘッダーを自動的に追加します。 これを変更するには:
import urllib.request
opener = urllib.request.build_opener()
opener.addheaders = [('User-agent', 'Mozilla/5.0')]
opener.open('http://www.example.com/')
また、 Request が渡されると、いくつかの標準ヘッダー( Content-Length 、 Content-Type 、 Host )が追加されることに注意してください。 urlopen()(または OpenerDirector.open())へ。
GET
メソッドを使用してパラメーターを含むURLを取得するセッションの例を次に示します。
>>> import urllib.request
>>> import urllib.parse
>>> params = urllib.parse.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0})
>>> url = "http://www.musi-cal.com/cgi-bin/query?%s" % params
>>> with urllib.request.urlopen(url) as f:
... print(f.read().decode('utf-8'))
...
次の例では、代わりにPOST
メソッドを使用しています。 urlencodeから出力されたparamsは、データとしてurlopenに送信される前にバイトにエンコードされることに注意してください。
>>> import urllib.request
>>> import urllib.parse
>>> data = urllib.parse.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0})
>>> data = data.encode('ascii')
>>> with urllib.request.urlopen("http://requestb.in/xrbl82xr", data) as f:
... print(f.read().decode('utf-8'))
...
次の例では、明示的に指定されたHTTPプロキシを使用して、環境設定をオーバーライドします。
>>> import urllib.request
>>> proxies = {'http': 'http://proxy.example.com:8080/'}
>>> opener = urllib.request.FancyURLopener(proxies)
>>> with opener.open("http://www.python.org") as f:
... f.read().decode('utf-8')
...
次の例では、プロキシをまったく使用せず、環境設定をオーバーライドしています。
>>> import urllib.request
>>> opener = urllib.request.FancyURLopener({})
>>> with opener.open("http://www.python.org/") as f:
... f.read().decode('utf-8')
...
レガシーインターフェース
次の関数とクラスは、Python2モジュールurllib
から移植されています(urllib2
ではありません)。 それらは将来のある時点で非推奨になる可能性があります。
- urllib.request.urlretrieve(url, filename=None, reporthook=None, data=None)
URLで示されるネットワークオブジェクトをローカルファイルにコピーします。 URLがローカルファイルを指している場合、ファイル名が指定されない限り、オブジェクトはコピーされません。 タプル
(filename, headers)
を返します。ここで、 filename はオブジェクトを見つけることができるローカルファイル名であり、 headers はinfo()
メソッドのいずれかです。 urlopen()によって返されたオブジェクトが返されました(リモートオブジェクトの場合)。 例外は urlopen()の場合と同じです。2番目の引数は、存在する場合、コピー先のファイルの場所を指定します(存在しない場合、場所は生成された名前の一時ファイルになります)。 3番目の引数は、存在する場合、ネットワーク接続の確立時に1回呼び出され、その後各ブロックが読み取られた後に1回呼び出される呼び出し可能オブジェクトです。 呼び出し可能オブジェクトには3つの引数が渡されます。 これまでに転送されたブロックの数、バイト単位のブロックサイズ、およびファイルの合計サイズ。 3番目の引数は、取得要求に応答してファイルサイズを返さない古いFTPサーバーでは
-1
である可能性があります。次の例は、最も一般的な使用シナリオを示しています。
>>> import urllib.request >>> local_filename, headers = urllib.request.urlretrieve('http://python.org/') >>> html = open(local_filename) >>> html.close()
url が
http:
スキーム識別子を使用する場合、オプションの data 引数を指定して、POST
リクエストを指定できます(通常、リクエストタイプは[ X168X] )。 data 引数は、標準の application / x-www-form-urlencoded 形式のバイトオブジェクトである必要があります。 urllib.parse.urlencode()関数を参照してください。urlretrieve()は、使用可能なデータの量が予想量( Content-Length ヘッダーによって報告されるサイズ)より少ないことを検出すると、
ContentTooShortError
を発生させます。 )。 これは、たとえば、ダウンロードが中断された場合に発生する可能性があります。Content-Length は下限として扱われます。読み取るデータが多い場合、urlretrieveはより多くのデータを読み取りますが、使用可能なデータが少ない場合は例外が発生します。
この場合でも、ダウンロードしたデータを取得できます。データは、例外インスタンスの
content
属性に保存されます。Content-Length ヘッダーが指定されていない場合、urlretrieveはダウンロードしたデータのサイズを確認できず、単にデータを返します。 この場合、ダウンロードが成功したと想定する必要があります。
- urllib.request.urlcleanup()
- urlretrieve()への以前の呼び出しによって取り残された可能性のある一時ファイルをクリーンアップします。
- class urllib.request.URLopener(proxies=None, **x509)
バージョン3.3以降非推奨。
URLを開いて読み取るための基本クラス。
http:
、ftp:
、またはfile:
以外のスキームを使用したオブジェクトのオープンをサポートする必要がない限り、おそらく FancyURLopener を使用することをお勧めします。デフォルトでは、 URLopener クラスは
urllib/VVV
の User-Agent ヘッダーを送信します。ここで、 VVV は urllib バージョンです。番号。 アプリケーションは、 URLopener または FancyURLopener をサブクラス化し、クラス属性 version を適切な文字列値に設定することにより、独自の User-Agent ヘッダーを定義できます。サブクラスの定義。オプションの proxies パラメーターは、スキーム名をプロキシURLにマッピングするディクショナリである必要があります。この場合、空のディクショナリはプロキシを完全にオフにします。 デフォルト値は
None
です。この場合、上記の urlopen()の定義で説明されているように、環境プロキシ設定が存在する場合はそれが使用されます。x509 で収集された追加のキーワードパラメータは、
https:
スキームを使用する場合のクライアントの認証に使用できます。 キーワード key_file および cert_file は、SSLキーと証明書を提供するためにサポートされています。 クライアント認証をサポートするには、両方が必要です。URLopener オブジェクトは、サーバーがエラーコードを返した場合、 OSError 例外を発生させます。
- open(fullurl, data=None)
適切なプロトコルを使用して fullurl を開きます。 このメソッドは、キャッシュとプロキシの情報を設定し、入力引数を使用して適切なopenメソッドを呼び出します。 スキームが認識されない場合、 open_unknown()が呼び出されます。 data 引数は、 urlopen()の data 引数と同じ意味です。
このメソッドは常に quote()を使用して fullurl を引用します。
- open_unknown(fullurl, data=None)
不明なURLタイプを開くためのオーバーライド可能なインターフェース。
- retrieve(url, filename=None, reporthook=None, data=None)
url の内容を取得し、ファイル名に配置します。 戻り値は、ローカルファイル名と、応答ヘッダー(リモートURLの場合)または
None
(ローカルURLの場合)を含む email.message.Message オブジェクトのいずれかで構成されるタプルです。 次に、呼び出し元はファイル名の内容を開いて読み取る必要があります。 filename が指定されておらず、URLがローカルファイルを参照している場合、入力ファイル名が返されます。 URLが非ローカルで、 filename が指定されていない場合、ファイル名は tempfile.mktemp()の出力であり、サフィックスはの最後のパスコンポーネントのサフィックスと一致します。入力URL。 reporthook を指定する場合は、チャンク番号、読み込まれるチャンクの最大サイズ、ダウンロードの合計サイズ(不明な場合は-1)の3つの数値パラメーターを受け入れる関数である必要があります。 これは、開始時とデータの各チャンクがネットワークから読み取られた後に1回呼び出されます。 reporthook はローカルURLでは無視されます。url が
http:
スキーム識別子を使用する場合、オプションの data 引数を指定して、POST
リクエストを指定できます(通常、リクエストタイプは[ X168X] )。 data 引数は、標準の application / x-www-form-urlencoded 形式である必要があります。 urllib.parse.urlencode()関数を参照してください。
- version
オープナーオブジェクトのユーザーエージェントを指定する変数。 urllib を取得して、サーバーに特定のユーザーエージェントであることを通知するには、基本コンストラクターを呼び出す前に、これをクラス変数としてサブクラスまたはコンストラクターに設定します。
- class urllib.request.FancyURLopener(...)
バージョン3.3以降非推奨。
FancyURLopener サブクラス URLopener は、次のHTTP応答コードのデフォルト処理を提供します:301、302、303、307、および401。 上記の30x応答コードの場合、 Location ヘッダーを使用して実際のURLを取得します。 401応答コード(認証が必要)の場合、基本HTTP認証が実行されます。 30x応答コードの場合、再帰は maxtries 属性の値によって制限されます。デフォルトは10です。
他のすべての応答コードについては、メソッド
http_error_default()
が呼び出されます。このメソッドをサブクラスでオーバーライドして、エラーを適切に処理できます。ノート
RFC 2616 の書簡によると、POST要求に対する301および302の応答は、ユーザーの確認なしに自動的にリダイレクトされてはなりません。 実際には、ブラウザはこれらの応答の自動リダイレクトを許可し、POSTをGETに変更し、 urllib はこの動作を再現します。
コンストラクターのパラメーターは、 URLopener のパラメーターと同じです。
ノート
基本認証を実行する場合、 FancyURLopener インスタンスはその prompt_user_passwd()メソッドを呼び出します。 デフォルトの実装では、制御端末で必要な情報をユーザーに要求します。 サブクラスは、必要に応じて、より適切な動作をサポートするためにこのメソッドをオーバーライドできます。
FancyURLopener クラスは、適切な動作を提供するためにオーバーロードする必要がある1つの追加メソッドを提供します。
- prompt_user_passwd(host, realm)
指定されたセキュリティレルム内の指定されたホストでユーザーを認証するために必要な情報を返します。 戻り値は、基本認証に使用できるタプル
(user, password)
である必要があります。実装は、端末でこの情報の入力を求めます。 アプリケーションは、ローカル環境で適切な相互作用モデルを使用するために、このメソッドをオーバーライドする必要があります。
urllib.request 制限
現在、サポートされているプロトコルは、HTTP(バージョン0.9および1.0)、FTP、ローカルファイル、およびデータURLのみです。
バージョン3.4で変更:データURLのサポートが追加されました。
urlretrieve()のキャッシュ機能は、有効期限の時間ヘッダーの適切な処理をハックする時間を誰かが見つけるまで無効になっています。
特定のURLがキャッシュにあるかどうかを照会する関数が必要です。
下位互換性のために、URLがローカルファイルを指しているように見えてもファイルを開くことができない場合、URLはFTPプロトコルを使用して再解釈されます。 これにより、紛らわしいエラーメッセージが表示される場合があります。
urlopen()および urlretrieve()関数は、ネットワーク接続がセットアップされるのを待つ間、任意に長い遅延を引き起こす可能性があります。 これは、スレッドを使用せずにこれらの関数を使用してインタラクティブなWebクライアントを構築することは困難であることを意味します。
urlopen()または urlretrieve()によって返されるデータは、サーバーによって返される生データです。 これは、バイナリデータ(画像など)、プレーンテキスト、または(たとえば)HTMLの場合があります。 HTTPプロトコルは、応答ヘッダーでタイプ情報を提供します。これは、 Content-Type ヘッダーを調べることで調べることができます。 返されるデータがHTMLの場合は、モジュール html.parser を使用して解析できます。
FTPプロトコルを処理するコードは、ファイルとディレクトリを区別できません。 これにより、アクセスできないファイルを指すURLを読み取ろうとすると、予期しない動作が発生する可能性があります。 URLが
/
で終わる場合、それはディレクトリを参照していると見なされ、それに応じて処理されます。 ただし、ファイルを読み取ろうとすると550エラーが発生する場合(多くの場合、アクセス許可の理由でURLが見つからないかアクセスできないことを意味します)、ディレクトリが指定されている場合を処理するために、パスはディレクトリとして扱われます。 URLによるものですが、末尾の/
は省略されています。 これにより、読み取り権限によってアクセスできないファイルをフェッチしようとすると、誤解を招く結果が生じる可能性があります。 FTPコードはそれを読み取ろうとし、550エラーで失敗し、読み取り不可能なファイルのディレクトリリストを実行します。 きめ細かい制御が必要な場合は、 ftplib モジュールの使用、 FancyURLopener のサブクラス化、または _urlopener の変更を検討してください。
urllib.response —urllibによって使用される応答クラス
urllib.response モジュールは、read()
やreadline()
など、インターフェイスのような最小限のファイルを定義する関数とクラスを定義します。 典型的な応答オブジェクトは、ヘッダーを返すinfo()
メソッドと、URLを返すgeturl()
メソッドを定義するaddinfourlインスタンスです。 このモジュールで定義された関数は、 urllib.request モジュールによって内部的に使用されます。