このページの2つのバージョン間の差分を表示します。
両方とも前のリビジョン 前のリビジョン 次のリビジョン | 前のリビジョン 次のリビジョン 両方とも次のリビジョン | ||
psr:psr7 [2020/06/16 17:53] y2sunlight |
psr:psr7 [2020/07/28 11:06] tanaka [PSR-7: HTTP message interfaces] |
||
---|---|---|---|
行 5: | 行 5: | ||
本章は、若干の補足を加筆してはいるものの単に[[https:// | 本章は、若干の補足を加筆してはいるものの単に[[https:// | ||
- | ==== 目次 ==== | + | 関連記事 |
* [[psr: | * [[psr: | ||
* [[psr: | * [[psr: | ||
行 14: | 行 15: | ||
* PSR-7: HTTP Message Interface - HTTPメッセージインターフェイス | * PSR-7: HTTP Message Interface - HTTPメッセージインターフェイス | ||
* [[psr: | * [[psr: | ||
+ | * [[psr: | ||
+ | * [[psr: | ||
+ | * [[psr: | ||
+ | * [[psr: | ||
----- | ----- | ||
行 155: | 行 160: | ||
==== 1.3 ストリーム ==== | ==== 1.3 ストリーム ==== | ||
- | messages consist of a start-line, headers, and a body. The body of an HTTP message can be very small or extremely large. Attempting to represent the body of a message as a string can easily consume more memory than intended because the body must be stored completely in memory. Attempting to store the body of a request or response in memory would preclude the use of that implementation from being able to work with large message bodies. | + | HTTPメッセージは、開始行、ヘッダー、および本文で構成されます。HTTPメッセージの本文は、非常に小さい場合と非常に大きい場合があります。メッセージの本文を完全にメモリに格納する必要があるため、メッセージの本文を文字列として表現しようとすると、意図したよりも多くのメモリが消費されます。リクエストまたはレスポンスの本文をメモリに保存しようとすると、その実装を使用して大きなメッセージ本文を処理できなくなります。'' |
- | HTTPメッセージは、開始行、ヘッダー、および本文で構成されます。 HTTPメッセージの本文は、非常に小さい場合と非常に大きい場合があります。 メッセージの本文を完全にメモリに格納する必要があるため、メッセージの本文を文字列として表現しようとすると、意図したよりも多くのメモリが消費されます。 リクエストまたはレスポンスの本文をメモリに保存しようとすると、その実装を使用して大きなメッセージ本文を処理できなくなります。 | + | '' |
- | StreamInterface exposes several methods that enable streams to be read from, written to, and traversed effectively. | + | ストリームは、'' |
- | StreamInterfaceは、ストリームの読み取り、書き込み、および効率的なトラバース(横断)を可能にするいくつかのメソッドを公開しています。 | + | 各ストリームのインスタンスには様々な機能があります。読み取り専用、書き込み専用、または読み書き可能です。 また、任意のランダムアクセス(任意の場所への前方または後方へのシーク)またはシーケンシャルアクセス(たとえば、ソケット、パイプ、またはコールバックベースのストリームの場合)のみを許可することもできます。 |
- | Streams expose their capabilities using three methods: isReadable(), isWritable(), | + | 最後に、'' |
- | ストリームは、isReadable()、isWritable()、isSeekable() の3つのメソッドを使用してその機能を公開します。ストリームの共同制作者はこれらのメソッドを使用して、ストリームが要件を満たしているかどうかを判断できます。 | + | リクエストおよびレスポンスインターフェイスとは異なり、'' |
- | + | ||
- | Each stream instance will have various capabilities: | + | |
- | + | ||
- | 各ストリームインスタンスにはさまざまな機能があります。読み取り専用、書き込み専用、または読み書き可能です。 また、任意のランダムアクセス(任意の場所への前方または後方へのシーク)またはシーケンシャルアクセス(たとえば、ソケット、パイプ、またはコールバックベースのストリームの場合)のみを許可することもできます。 | + | |
- | + | ||
- | Finally, StreamInterface defines a __toString() method to simplify retrieving or emitting the entire body contents at once. | + | |
- | + | ||
- | 最後に、StreamInterfaceは__toString() メソッドを定義して、ボディコンテンツ全体を一度に取得(読み込み)または放出(書き込み)することを簡素化します。 | + | |
- | + | ||
- | Unlike the request and response interfaces, StreamInterface does not model immutability. In situations where an actual PHP stream is wrapped, immutability is impossible to enforce, as any code that interacts with the resource can potentially change its state (including cursor position, contents, and more). Our recommendation is that implementations use read-only streams for server-side requests and client-side responses. Consumers should be aware of the fact that the stream instance may be mutable, and, as such, could alter the state of the message; when in doubt, create a new stream instance and attach it to a message to enforce state. | + | |
- | + | ||
- | リクエストおよびレスポンスインターフェイスとは異なり、StreamInterfaceは不変性(immutability)をモデル化していません。 実際のPHPストリームがラップされている状況では、リソースとやり取りするコードがその状態(カーソルの位置、内容など)を変更する可能性があるため、不変性を強制することは不可能です。 実装では、サーバー側の(HTTP)要求とクライアント側の(HTTP)応答に読み取り専用ストリームを使用することをお勧めします。 コンシューマーは、ストリームインスタンスが変更可能であり、メッセージの状態を変更する可能性があることを認識しておく必要があります。 | + | |
\\ | \\ | ||
==== 1.4 リクエストターゲットとリクエストURI ==== | ==== 1.4 リクエストターゲットとリクエストURI ==== | ||
- | |||
- | Per RFC 7230, request messages contain a “request-target” as the second segment of the request line. The request target can be one of the following forms: | ||
RFC 7230に従い、リクエストメッセージには、リクエストラインの2番目のセグメントとして「リクエストターゲット」が含まれています。 リクエストターゲットは、次のいずれかの形式になります。 | RFC 7230に従い、リクエストメッセージには、リクエストラインの2番目のセグメントとして「リクエストターゲット」が含まれています。 リクエストターゲットは、次のいずれかの形式になります。 | ||
- | * origin-form, which consists of the path, and, if present, the query string; this is often referred to as a relative | + | |
- | * origin-form: パスと、クエリ文字列(存在する場合)で構成されます。 これは多くの場合、相対URLと呼ばれます。 TCPを介して送信されるメッセージは、通常はorigin-formです。 | + | * **absolute-form** (絶対形式): スキーム、権限(「[user-info@]host[: |
- | * absolute-form, which consists of the scheme, authority | + | * **authority-form** (権限形式): 権限のみで構成されます。これは通常、HTTPクライアントとプロキシサーバー間の接続を確立するために、CONNECTリクエストでのみ使用されます。 |
- | * absolute-form: スキーム、権限(「[user-info@]host[:port]」、角括弧内の項目はオプション)、パス(存在する場合)、クエリ文字列(存在する場合)、およびフラグメント(存在する場合)で構成されます。 | + | * **asterisk-form** (アスタリスク形式): 単独の '' |
- | * authority-form, | + | これらのリクエストターゲットとは別に、リクエストターゲットとは異なる「有効なURL」が存在することがよくあります。有効なURLはHTTPメッセージ内では送信されませんが、リクエストを行うためにプロトコル (http/ |
- | * authority-form: | + | 有効なURLは '' |
- | * asterisk-form, which consists solely of the string *, and which is used with the OPTIONS method to determine the general capabilities of a web server. | + | '' |
- | * asterisk-form: 単独の*文字で構成されます。OPTIONSメソッドで使われ、Webサーバーの一般的な機能を判断します。 | + | エンドユーザーが他の3つの形式(origin-form以外)のいずれかを使用したい場合、またはユーザーがリクエストターゲットを明示的にオーバーライドしたい場合は、'' |
- | Aside from these request-targets, | + | このメソッドを呼び出しは、'' |
- | これらのリクエストターゲットとは別に、リクエストターゲットとは異なる「有効なURL」がよくあります。 有効なURLはHTTPメッセージ内では送信されませんが、リクエストを行うためにプロトコル (http/ | + | たとえば、ユーザーがサーバーに asterisk-form のリクエストを行う場合があります: |
- | The effective URL is represented by UriInterface. UriInterface models HTTP and HTTPS URIs as specified in RFC 3986 (the primary use case). The interface provides methods for interacting with the various URI parts, which will obviate the need for repeated parsing of the URI. It also specifies a < | + | <code php> |
- | + | ||
- | 有効なURLはUriInterfaceで表されます。 UriInterfaceは、RFC 3986(主な使用例)で指定されているHTTPおよびHTTPS URIをモデル化します。 このインターフェースは、さまざまなURI部分と対話するためのメソッドを提供します。これにより、URIを繰り返し解析する必要がなくなります。 また、モデル化されたURIをその文字列表現にキャストするための< | + | |
- | + | ||
- | When retrieving the request-target with getRequestTarget(), | + | |
- | + | ||
- | getRequestTarget() を使用してリクエストターゲットを取得する場合、デフォルトでは、このメソッドはURIオブジェクトを使用し、必要なすべてのコンポーネントを抽出してorigin-formを構築します。 origin-formは、最も一般的なリクエストターゲットです。 | + | |
- | + | ||
- | If it’s desired by an end-user to use one of the other three forms, or if the user wants to explicitly override the request-target, | + | |
- | + | ||
- | エンドユーザーが他の3つの形式(origin-form以外)のいずれかを使用したい場合、またはユーザーがリクエストターゲットを明示的にオーバーライドしたい場合は、withRequestTarget() を使用してこれを行うことができます。 | + | |
- | + | ||
- | Calling this method does not affect the URI, as it is returned from getUri(). | + | |
- | + | ||
- | このメソッドはgetUri() から返されるため、このメソッドを呼び出してもURIには影響しません。 | + | |
- | + | ||
- | For example, a user may want to make an asterisk-form request to a server: | + | |
- | + | ||
- | たとえば、ユーザーがサーバーにasterisk-formのリクエストを行う場合があります。 | + | |
- | + | ||
- | <code php> | + | |
$request = $request | $request = $request | ||
-> | -> | ||
-> | -> | ||
-> | -> | ||
- | |||
</ | </ | ||
- | This example may ultimately result in an HTTP request that looks like this: | ||
- | この例では、最終的に次のようなHTTPリクエストになります。 | + | この例では、最終的に次のようなHTTPリクエストになります: |
< | < | ||
行 242: | 行 211: | ||
</ | </ | ||
- | But the HTTP client will be able to use the effective URL (from getUri()), to determine the protocol, hostname and TCP port. | + | しかし、HTTPクライアントは、( '' |
- | しかし、プロトコル、ホスト名、およびTCPポートを決定する為に、HTTPクライアントは、(getUri() からの)有効なURLを使用することができます。 | + | HTTPクライアントは、'' |
- | An HTTP client | + | 4つのリクエストターゲット形式の1つ以上を実装しないことを選択したクライアントは、引き続き '' |
- | HTTPクライアントは、Uri:: | + | >'' |
- | Clients that choose to not implement 1 or more of the 4 request-target forms, MUST still use getRequestTarget(). These clients MUST reject request-targets they do not support, and MUST NOT fall back on the values from getUri(). | + | '' |
- | 4つのリクエストターゲット形式の1つ以上を実装しないことを選択したクライアントは、引き続きgetRequestTarget() を使用する必要があります (MUST)。これらのクライアントは、サポートしていないリクエストターゲットを拒否する必要があり (MUST)、getUri() からの値に依存してはなりません (MUST NOT)。 | + | '' |
- | + | ||
- | RequestInterface provides methods for retrieving the request-target or creating a new instance with the provided request-target. By default, if no request-target is specifically composed in the instance, getRequestTarget() will return the origin-form of the composed URI (or “/” if no URI is composed). | + | |
- | + | ||
- | RequestInterfaceは、リクエストターゲットを取得するメソッド、または指定されたリクエストターゲットを使用して新しいインスタンスを作成するメソッドを提供します。デフォルトでは、リクエストターゲットがインスタンスで具体的に構成されていない場合、getRequestTarget() は、構成されたURIのorigin-form(または構成されていない場合は「/ | + | |
- | + | ||
- | withRequestTarget($requestTarget) creates a new instance with the specified request target, and thus allows developers to create request messages that represent the other three request-target forms (absolute-form, | + | |
- | + | ||
- | withRequestTarget($requestTarget) は、指定されたリクエストターゲットを使用して新しいインスタンスを作成するため、開発者は他の3つのリクエストターゲット形式(absolute-form、authority-form、およびasterisk-form)を表すリクエストメッセージを作成できます。それが使用された場合、構成されたURIインスタンスは、特にクライアントで、サーバーへの接続を作成するために使用される可能性があるため、引き続き使用できます。 | + | |
\\ | \\ | ||
==== 1.5 サーバーサイドリクエスト ==== | ==== 1.5 サーバーサイドリクエスト ==== | ||
- | RequestInterface provides the general representation of an HTTP request message. However, server-side requests need additional treatment, due to the nature of the server-side environment. Server-side processing needs to take into account Common Gateway Interface (CGI), and, more specifically, | ||
- | RequestInterfaceは、HTTPリクエストメッセージの一般的な表現を提供します。 ただし、サーバー側の環境の性質上、サーバー側のリクエストには追加の処理が必要です。 サーバー側の処理では、Common Gateway Interface(CGI)、PHP(さらに具体的には、サーバーAPI(SAPI)を介したCGIの抽象化)と拡張を考慮する必要があります。 PHPは、次のようなスーパーグローバル変数を介して入力のマーシャリングを簡素化しました。 | + | '' |
- | * $_COOKIE, which deserializes and provides simplified access to HTTP cookies. | + | |
- | * $_GET, which deserializes and provides simplified access to query string arguments. | + | |
- | * $_POST, which deserializes and provides simplified access for urlencoded parameters submitted via HTTP POST; generically, | + | |
- | * $_FILES, which provides serialized metadata around file uploads. | + | |
- | * $_SERVER, which provides access to CGI/ | + | |
- | * $_COOKIE: HTTPCookieへのデシリアル化と簡略化されたアクセスを提供します。 | + | '' |
- | * $_GET: クエリ文字列引数へのデシリアル化と簡略化されたアクセスを提供します。 | + | |
- | * $_POST: HTTP POST経由で送信されたURLエンコードされたパラメーターへのデシリアル化と簡略化されたアクセスを提供します。 | + | |
- | * $_FILES: ファイルのアップロードに関するシリアル化されたメタデータを提供します。 | + | |
- | * $_SERVER: CGI / SAPI環境変数へのアクセスを提供します。これには、通常、リクエストメソッド、リクエストスキーム、リクエストURI、およびヘッダーが含まれます。 | + | |
- | ServerRequestInterface extends RequestInterface to provide an abstraction around these various superglobals. This practice helps reduce coupling to the superglobals by consumers, and encourages and promotes the ability to test request consumers. | + | サーバーリクエストは、「attributes」という1つの追加プロパティを提供して、コンシューマーがアプリケーション固有のルール(パスマッチング、スキームマッチング、ホストマッチングなど)に対してリクエストを内省(introspect)、分解(decompose)、および照合(match)できるようにします。従って、サーバーリクエストは、複数のリクエストコンシューマー間のメッセージングを提供することもできます。 |
- | + | ||
- | ServerRequestInterfaceはRequestInterfaceを拡張して、これらのさまざまなスーパーグローバル変数に関する抽象化を提供します。 このプラクティスは、コンシューマーによるスーパーグローバル変数への結合を減らすのに役立ち、リクエストコンシューマーをテストする機能を奨励および促進します。 | + | |
- | + | ||
- | The server request provides one additional property, “attributes”, | + | |
- | + | ||
- | サーバーリクエストは、「attributes」という1つの追加プロパティを提供して、コンシューマーがアプリケーション固有のルール(パスマッチング、スキームマッチング、ホストマッチングなど)に対してリクエストを内省(introspect)、分解(decompose)、および照合(match)できるようにします。 | + | |
\\ | \\ | ||
行 293: | 行 243: | ||
==== 1.6 アップロードファイル ==== | ==== 1.6 アップロードファイル ==== | ||
- | ServerRequestInterface | + | '' |
- | ServerRequestInterfaceは、正規化された構造でアップロードファイルのツリーを取得するメソッドを規定します。そのツリーの各リーフにはUploadedFileInterfaceのインスタンスがあります。 | + | '' |
- | + | ||
- | The $_FILES superglobal has some well-known problems when dealing with arrays of file inputs. As an example, if you have a form that submits an array of files — e.g., the input name “files”, | + | |
- | + | ||
- | $_FILESスーパーグローバル変数には、ファイル入力の配列を処理するときによく知られた問題がいくつかあります。 例として、ファイルの配列を送信するフォームがある場合(例えば入力名を「files」とする)、files[0] とfiles[1] を送信すると、PHPはこれを次のように表します: | + | |
<code php> | <code php> | ||
行 316: | 行 262: | ||
) | ) | ||
</ | </ | ||
- | |||
- | instead of the expected: | ||
期待されるのは次のようです: | 期待されるのは次のようです: | ||
行 337: | 行 281: | ||
) | ) | ||
</ | </ | ||
- | |||
- | The result is that consumers need to know this language implementation detail, and write code for gathering the data for a given upload. | ||
その結果、コンシューマーはこの言語実装(PHP)の詳細を知って、与えられたアップロードのデータを収集するためのコードを書く必要があります。 | その結果、コンシューマーはこの言語実装(PHP)の詳細を知って、与えられたアップロードのデータを収集するためのコードを書く必要があります。 | ||
- | Additionally, | + | さらに、ファイルのアップロードが発生したときに '' |
- | さらに、ファイルのアップロードが発生したときに$_FILESが入力されない状況があります: | + | * HTTPメソッドが |
+ | * ユニットテストの時 | ||
+ | * [[https:// | ||
- | * When the HTTP method is not POST. | + | そのような場合、データを別の方法でシード(特別な処理)する必要があります。例としては: |
- | * When unit testing. | + | |
- | * When operating under a non-SAPI environment, | + | |
- | + | ||
- | * HTTPメソッドがPOSTでない場合 | + | |
- | * ユニットテスト時 | + | |
- | * ReactPHPのように非SAPI環境下で操作する場合 | + | |
- | + | ||
- | In such cases, the data will need to be seeded differently. As examples: | + | |
- | + | ||
- | そのような場合、データを別の方法でシード(特別な処理)する必要があります。 例としては: | + | |
- | + | ||
- | * A process might parse the message body to discover the file uploads. In such cases, the implementation may choose not to write the file uploads to the file system, but instead wrap them in a stream in order to reduce memory, I/O, and storage overhead. | + | |
* プロセスがメッセージ本文を解析して、ファイルのアップロードを検出する場合があります。 このような場合、実装では、ファイルアップロードをファイルシステムに書き込まず、代わりにストリームにラップして、メモリ、I/ | * プロセスがメッセージ本文を解析して、ファイルのアップロードを検出する場合があります。 このような場合、実装では、ファイルアップロードをファイルシステムに書き込まず、代わりにストリームにラップして、メモリ、I/ | ||
- | |||
- | * In unit testing scenarios, developers need to be able to stub and/or mock the file upload metadata in order to validate and verify different scenarios. | ||
* ユニットテストのシナリオでは、さまざまなシナリオを検証および検査するために、開発者はファイルアップロードのメタデータをスタブ化および/ | * ユニットテストのシナリオでは、さまざまなシナリオを検証および検査するために、開発者はファイルアップロードのメタデータをスタブ化および/ | ||
- | getUploadedFiles() | + | '' |
- | getUploadedFiles() は、コンシューマに正規化された構造を提供します。 実装では、次のことが期待されます: | + | * 与えられたファイルアップロードのすべての情報を集約し、それを使用して '' |
- | | + | * 送信されたツリー構造を再作成します。その時各リーフは、ツリー内の与えられた場所に対して適切な'' |
- | * Re-create the submitted tree structure, with each leaf being the appropriate Psr\Http\Message\UploadedFileInterface instance for the given location in the tree. | + | |
- | + | ||
- | * 与えられたファイルアップロードのすべての情報を集約し、それを使用してPsr\Http\Message\UploadedFileInterfaceインスタンスに入力します。 | + | |
- | | + | |
- | + | ||
- | The tree structure referenced should mimic the naming structure in which files were submitted. | + | |
参照されるツリー構造は、ファイルが送信されたときのネーミング構造を模倣する必要があります。 | 参照されるツリー構造は、ファイルが送信されたときのネーミング構造を模倣する必要があります。 | ||
- | |||
- | In the simplest example, this might be a single named form element submitted as: | ||
最も単純な例では、これは次のように送信された単一の名前付きフォーム要素でしょう: | 最も単純な例では、これは次のように送信された単一の名前付きフォーム要素でしょう: | ||
行 388: | 行 310: | ||
</ | </ | ||
- | In this case, the structure in $_FILES would look like: | + | この場合、'' |
- | + | ||
- | この場合、$_FILESの構造は次のようになります: | + | |
<code php> | <code php> | ||
行 404: | 行 324: | ||
</ | </ | ||
- | The normalized form returned by getUploadedFiles() would be: | + | '' |
- | + | ||
- | getUploadedFiles() によって返される正規化された形式は次のようになります: | + | |
<code php> | <code php> | ||
行 413: | 行 331: | ||
) | ) | ||
</ | </ | ||
- | |||
- | In the case of an input using array notation for the name: | ||
名前に配列表記を使用した入力の場合: | 名前に配列表記を使用した入力の場合: | ||
行 421: | 行 337: | ||
<input type=" | <input type=" | ||
</ | </ | ||
- | |||
- | $_FILES ends up looking like this: | ||
$_FILESは次のようになります: | $_FILESは次のようになります: | ||
行 459: | 行 373: | ||
</ | </ | ||
- | And the corresponding tree returned by getUploadedFiles() should be: | + | そして、'' |
- | + | ||
- | そして、getUploadedFiles() によって返される対応するツリーは次のようになります: | + | |
<code php> | <code php> | ||
行 472: | 行 384: | ||
) | ) | ||
</ | </ | ||
- | |||
- | In some cases, you may specify an array of files: | ||
場合によっては、ファイルの配列を指定できます: | 場合によっては、ファイルの配列を指定できます: | ||
行 481: | 行 391: | ||
Upload an avatar: <input type=" | Upload an avatar: <input type=" | ||
</ | </ | ||
- | |||
- | (As an example, JavaScript controls might spawn additional file upload inputs to allow uploading multiple files at once.) | ||
(例として、JavaScriptコントロールは、複数のファイルを一度にアップロードできるように、追加のファイルアップロード入力を生成する場合があります。) | (例として、JavaScriptコントロールは、複数のファイルを一度にアップロードできるように、追加のファイルアップロード入力を生成する場合があります。) | ||
- | In such a case, the specification implementation must aggregate all information related to the file at the given index. The reason is because $_FILES deviates from its normal structure in such cases: | + | このような場合、仕様の実装では、指定されたインデックスにあるファイルに関連するすべての情報を集約する必要があります。その理由は、'' |
- | + | ||
- | このような場合、仕様の実装では、指定されたインデックスにあるファイルに関連するすべての情報を集約する必要があります。 その理由は、$_FILESは通常の構造から逸脱しているためです。それは、次のような場合です: | + | |
<code php> | <code php> | ||
行 542: | 行 448: | ||
</ | </ | ||
- | The above $_FILES array would correspond to the following structure as returned by getUploadedFiles(): | + | 上記の |
- | + | ||
- | 上記の$_FILES配列は、getUploadedFiles() によって返される次の構造に対応します: | + | |
<code php> | <code php> | ||
行 559: | 行 463: | ||
) | ) | ||
</ | </ | ||
- | |||
- | Consumers would access index 1 of the nested array using: | ||
コンシューマーは、ネストされた配列のインデックス1に次のようにしてアクセスします: | コンシューマーは、ネストされた配列のインデックス1に次のようにしてアクセスします: | ||
行 568: | 行 470: | ||
</ | </ | ||
- | Because the uploaded files data is derivative (derived from $_FILES or the request body), a mutator method, withUploadedFiles(), | + | アップロードされたファイルデータは派生型('' |
- | + | ||
- | アップロードされたファイルデータは派生物($_FILESまたはリクエストボディからの派生)であるため、インターフェイスにはミューテーターメソッド(mutator method) としてwithUploadedFiles() も存在し、正規化を別のプロセスに委譲できます。 | + | |
- | + | ||
- | In the case of the original examples, consumption resembles the following: | + | |
冒頭の例の場合、使用方法は次のようになります: | 冒頭の例の場合、使用方法は次のようになります: | ||
行 589: | 行 487: | ||
</ | </ | ||
- | This proposal also recognizes that implementations may operate in non-SAPI environments. As such, UploadedFileInterface | + | この提案は、実装が非SAPI環境で動作する可能性があることも認識しています。従って、'' |
- | この提案は、実装が非SAPI環境で動作する可能性があることも認識しています。 したがって、UploadedFileInterfaceは、環境に関係なく操作が確実に機能するためのメソッドを提供します。 特に: | + | |
- | + | ||
- | + | ||
- | * moveTo($targetPath) is provided as a safe and recommended alternative to calling move_uploaded_file() directly on the temporary upload file. Implementations will detect the correct operation to use based on environment. | + | |
- | + | ||
- | | + | |
- | + | ||
- | * getStream() will return a StreamInterface instance. In non-SAPI environments, | + | |
- | + | ||
- | * getStream() はStreamInterfaceインスタンスを返します。 非SAPIの環境下では、個々のアップロードファイルを解析して直接ファイルにではなくphp:// | + | |
- | As examples: | + | * '' |
例として: | 例として: | ||
行 609: | 行 498: | ||
// Move a file to an upload directory | // Move a file to an upload directory | ||
// ファイルをアップロードディレクトリに移動する | // ファイルをアップロードディレクトリに移動する | ||
+ | |||
$filename = sprintf( | $filename = sprintf( | ||
' | ' | ||
行 620: | 行 510: | ||
// Psr7StreamWrapper is a class that will decorate a StreamInterface as a PHP | // Psr7StreamWrapper is a class that will decorate a StreamInterface as a PHP | ||
// StreamWrapper. | // StreamWrapper. | ||
- | // ファイルをAmazon S3にストリーミングします。 | + | // |
- | // $s3wrapperがS3に書き込むPHPストリームであり、Psr7StreamWrapperがStreamInterfaceを | + | // ファイルを Amazon S3 にストリーミングします。 |
- | // PHP StreamWrapperとして装飾するクラスであると想定します。 | + | // $s3wrapper が S3 に書き込むPHPストリームであり、 |
+ | // Psr7StreamWrapper が StreamInterface を | ||
+ | // PHP StreamWrapper として装飾するクラスであると仮定します。 | ||
$stream = new Psr7StreamWrapper($file1-> | $stream = new Psr7StreamWrapper($file1-> | ||
stream_copy_to_stream($stream, | stream_copy_to_stream($stream, |