Ground Sunlight

Windowsで作る - PHPプログラミングの開発環境

ユーザ用ツール

サイト用ツール


psr:psr7

差分

このページの2つのバージョン間の差分を表示します。

この比較画面にリンクする

両方とも前のリビジョン 前のリビジョン
次のリビジョン
前のリビジョン
psr:psr7 [2020/06/16 18:02]
y2sunlight [1.3 ストリーム]
psr:psr7 [2020/09/01 11:53] (現在)
tanaka [PSR-7: HTTP message interfaces]
行 3: 行 3:
  --- //[[http://www.y2sunlight.com|y2sunlight]] 2020-05-25//  --- //[[http://www.y2sunlight.com|y2sunlight]] 2020-05-25//
  
-本章は、若干の補足を加筆してはいるものの単に[[https://www.php-fig.org/psr/|PSRのサイト]]を翻訳したものに過ぎません。英語が堪能な方は原文をご参照下さい。翻訳に当たっては、基本的に機械翻訳を使い、理解できない部分は独断で意訳しております。拙い訳では御座いますが恥を忍んで投稿しておりますので、ご指摘など御座いましたらコメントを頂ければ幸いです。+本章は、若干の補足を加筆してはいるものの単に[[https://www.php-fig.org/psr/|PSRのサイト]]を日本語に翻訳したものに過ぎません。英語が堪能な方は原文をご参照下さい。翻訳に当たっては、基本的に機械翻訳を使い、理解できない部分は独断で意訳しております。拙い訳では御座いますが恥を忍んで投稿しておりますので、ご指摘など御座いましたらコメントを頂ければ幸いです。 
 + 
 +関連記事
  
-==== 目次 ==== 
   * [[psr:top|PSR - PHP標準勧告]]   * [[psr:top|PSR - PHP標準勧告]]
   * [[psr:psr1|PSR-1: Basic Coding Standard - 基本コーディング規約]]   * [[psr:psr1|PSR-1: Basic Coding Standard - 基本コーディング規約]]
行 14: 行 15:
   * PSR-7: HTTP Message Interface - HTTPメッセージインターフェイス   * PSR-7: HTTP Message Interface - HTTPメッセージインターフェイス
   * [[psr:psr11|PSR-11: Container Interface - コンテナインターフェイス]]    * [[psr:psr11|PSR-11: Container Interface - コンテナインターフェイス]] 
 +  * [[psr:psr12|PSR-12: Extended Coding Style - 拡張コーディングスタイル]] 
 +  * [[psr:psr13|PSR-13: Link definition interfaces - リンク定義インターフェース]]
 +  * [[psr:psr14|PSR-14: Event Dispatcher - イベントディスパッチャー]] 
 +  * [[psr:psr15|PSR-15: HTTP Server Request Handlers - HTTPサーバーリクエストハンドラー]] 
 +  * [[psr:psr16|PSR-16: Common Interface for Caching Libraries - キャッシングライブラリのための共通インターフェース]] 
 +  * [[psr:psr17|PSR-17: HTTP Factories - HTTPファクトリー]] 
 +  * [[psr:psr18|PSR-18: HTTP Client - HTTPクライアント]] 
 +  * [[psr:psr19|PSR-19: PHPDoc tags(Draft) - PHPDocタグ]] 
  
 ----- -----
行 159: 行 168:
 ''StreamInterface'' は、ストリームの読み取り、書き込み、および効率的なトラバース(通過)を可能にするいくつかのメソッドを公開しています。 ''StreamInterface'' は、ストリームの読み取り、書き込み、および効率的なトラバース(通過)を可能にするいくつかのメソッドを公開しています。
  
------+ストリームは、''isReadable()''、''isWritable()''、''isSeekable()'' の3つのメソッドを使用してその機能を公開します。ストリームの共同作業者はこれらのメソッドを使用して、ストリームが要件を満たしているかどうかを判断できます。
  
->TODO: こから+各ストリームのインスタンスには様々な機能があります。読み取り専用、書き込み専用、または読み書き可能です。 また、任意のランダムアクセス(任意の場所への前方または後方へのシーク)またはシーケンシャルアクセス(たとえば、ソケット、パイプ、またはコールバックベースのストリームの場合)のみを許可するともできます。
  
-Streams expose their capabilities using three methods: isReadable(), isWritable(), and isSeekable(). These methods can be used by stream collaborators to determine if a stream is capable of their requirements.+最後に、''StreamInterface'' は ''<nowiki>__</nowiki>toString()'' メソッドを定義して、ボディコンテンツ全体を一度に取得(読み込み)または送出(書き込み)することを簡素化します。
  
-ストリームは、isReadable()、isWritable()、isSeekable() の3つのメソッドを使用してその機能を公開します。ストリームの共同制作者はこれらのメソッドを使用して、ストリームが要件を満たしているかどうかを判断できます。 +リクエストおよびレスポンスインターフェイスとは異なり、''StreamInterface'' は不変性(immutability)をモデル化していません。 実際のPHPストリームがラップされている状況では、リソースとやり取りするコードがその状態(カーソルの位置、内容など)を変更する可能性があるため、不変性を強制することは不可能です。実装では、サーバー側の(HTTP)要求とクライアント側の(HTTP)応答に読み取り専用ストリームを使用することをお勧めします。コンシューマーは、ストリームインスタンスが変更可能であり、メッセージの状態を変更する可能性があることを認識しておく必要があります。不確かな場合は、新しいストリームインスタンスを作成し、それをメッセージにアタッチして状態を強制します。
- +
-Each stream instance will have various capabilities: it can be read-only, write-only, or read-write. It can also allow arbitrary random access (seeking forwards or backwards to any location), or only sequential access (for example in the case of a socket, pipe, or callback-based stream). +
- +
-各ストリームインスタンスにはさまざまな機能があります。読み取り専用、書き込み専用、または読み書き可能です。 また、任意のランダムアクセス(任意の場所への前方または後方へのシーク)またはシーケンシャルアクセス(たとえば、ソケット、パイプ、またはコールバックベースのストリームの場合)のみを許可することもできます。 +
- +
-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 URL. Messages as transmitted over TCP typically are of origin-form; scheme and authority data are usually only present via CGI variables.+  * **origin-form** (基本形式): パスと、クエリ文字列(存在する場合)で構成されます。これは多くの場合、相対URLと呼ばれます。TCPを介して送信されるメッセージは、通常は origin-form です。スキームと権限データは通常、CGI変数を介してのみ提供されます。
  
-  * origin-form: パス、クエリ文字列(存在する場合)で構成されます。 これは多くの場合、URLと呼ばれます。 TCPを介して送信されるメッセジは、通常はorigin-formです。 スキームと権限データ通常CGI変数を介してみ提供されます。+  * **absolute-form** (絶対形式)スキーム、権限(「[user-info@]host[:port]」、角括弧内の項目はオプション)、パス(存在する場合)、クエリ文字列(存在する場合)、およびフラグメント(存在する場合)で構成されます。これは多くの場合、URIと呼ばれ、RFC 3986で詳述されていようにURIを指定する唯一のフォです。このフォームは一般的にHTTPプロキシへリクエストを行うときに使用されます。
  
-  * absolute-form, which consists of the scheme, authority (“[user-info@]host[:port]”, where items in brackets are optional), path (if present), query string (if present), and fragment (if present). This is often referred to as an absolute URI, and is the only form to specify a URI as detailed in RFC 3986. This form is commonly used when making requests to HTTP proxies.+  * **authority-form** (権限形式)権限のみで構成されます。これは通常、HTTPクライアントとプロキシサーバー間の接続を確立するために、CONNECTリクエストでのみ使用されます。
  
-  * absolute-formキーム、権限(「[user-info@]host[:port]」、角括弧内項目はオプション)、パス(存在する場合)、クエリ文字列(存在する場合)、およびフラグメント(存在する場合)で構成されます。 多くの場合、絶対URIと呼ばれ、RFC 3986で詳述されているようにURIを指定する唯一のフォムです。こフォームは一般的に、HTTPプロキシへのリクエスト行うときに使用されます。+  * **asterisk-form** (アタリスク形式)単独の ''*'' 文字のみで構成されます。OPTIONSメソッドで使われ、Webサーバーの一般的な機能判断します。
  
-  * authority-form, which consists of the authority only. This is typically used in CONNECT requests only, to establish a connection between an HTTP client and a proxy server.+これらのリクエストターゲットとは別に、リクエストターゲットとは異なる「有効なURL」が存在することがよくあります。有効なURLはHTTPメッセージ内では送信されませんが、リクエストを行うためにプロトコル (http/https)、ポート、およびホスト名を決定するために使用されます。
  
-  * authority-form: 権限のみ構成されます。 これ通常、HTTPクラトとプロキシサ間の接続を確立するために、CONNECTリクエストみ使用されます。+有効なURLは ''UriInterface'' されます。''UriInterface'' は、RFC 3986(the primary use case)で指定されているHTTPおよびHTTPS URIをモデル化します。このインフェスは、さまざまなURI部分と対話するためのメソッドを提供します。これよりURIを繰り返し解析する必要がなくなります。また、モデル化されたURIをその文字列表現にキャストするため<nowiki>__</nowiki>toString() メソッドも仕様に含んでいます。
  
-  * 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.+''getRequestTarget()'' を使用してリクエストターゲットを取得する場合、デフォルトでは、このメソッドはURIオブジェクトを使用し、必要なすべてのコンポーネントを抽出して origin-form を構築します。origin-form は、最も一般的なリクエストターゲットです。
  
-  * asterisk-form: 単独*文字で構成さます。OPTIONSメソッドで使われWebサの一般な機能判断します。+エンドユーザーが他の3つの形式(origin-form以外)いずかを使用したい場合またはユがリクエストターゲットを明示にオーバーライドしたい場合は、''withRequestTarget()'' 使用てこれを行うことができます。
  
-Aside from these request-targets, there is often an ‘effective URL’ which is separate from the request target. The effective URL is not transmitted within an HTTP message, but it is used to determine the protocol (http/https), port and hostname for making the request.+このメソッドを呼び出しは、''getUri()'' から返されるURIには影響しません。
  
-これらのリクエストターゲットは別にリクエストタゲットとは異なる「有効なURL」よくあります。 有効なURLはHTTPメッセジ内では送信されませんが、リクエストを行うためにプロトコル (http/https)、ポート、およびホスト名を決定するために使用されます+えばユーザーがサーバに 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 <nowiki>__</nowiki>toString() method for casting the modeled URI to its string representation. +<code php>
- +
-有効なURLはUriInterfaceで表されます。 UriInterfaceは、RFC 3986(主な使用例)で指定されているHTTPおよびHTTPS URIをモデル化します。 このインターフェースは、さまざまなURI部分と対話するためのメソッドを提供します。これにより、URIを繰り返し解析する必要がなくなります。 また、モデル化されたURIをその文字列表現にキャストするための<nowiki>__</nowiki>toString() メソッドも仕様に含んでいます。 +
- +
-When retrieving the request-target with getRequestTarget(), by default this method will use the URI object and extract all the necessary components to construct the origin-form. The origin-form is by far the most common request-target. +
- +
-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, it is possible to do so with withRequestTarget(). +
- +
-エンドユーザーが他の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
     ->withMethod('OPTIONS')     ->withMethod('OPTIONS')
     ->withRequestTarget('*')     ->withRequestTarget('*')
     ->withUri(new Uri('https://example.org/'));     ->withUri(new Uri('https://example.org/'));
- 
 </code> </code>
-This example may ultimately result in an HTTP request that looks like this: 
  
-この例では、最終的に次のようなHTTPリクエストになります+この例では、最終的に次のようなHTTPリクエストになります
  
 <code> <code>
行 242: 行 215:
 </code> </code>
  
-But the HTTP client will be able to use the effective URL (from getUri()), to determine the protocol, hostname and TCP port.+しかし、HTTPクライアントは、''getUri()'' からの 有効なURLを使用して、プロトコル、ホスト名、およびTCPポートを決定することができます。
  
-しかし、プロトコル、ホスト名、およびTCPポートを決定する為に、HTTPクライアントは、(getUri() から)有効なURLを使用することがでます。+HTTPクライアントは、''Uri::getPath()'' および ''Uri::getQuery()'' 値を無視し、代わりに ''getRequestTarget()'' によって返される値を使用する必要あります ( ''MUST'' )。''getRequestTarget()'' はデフォルトは、これら2つの値が連結されます。
  
-An HTTP client MUST ignore the values of Uri::getPath() and Uri::getQuery(), and instead use the value returned by getRequestTarget(), which defaults to concatenating these two values.+4つのリクエストターゲット形式の1つ以上を実装しないことを選択したクライアントは、引き続き ''getRequestTarget()'' を使用する必要があります ( ''MUST'' )。これらのクライアントは、サポートしていないリクエストターゲットを拒否する必要があり''MUST'' )、''getUri()'' からの値にフォールバックしてはなりません ''MUST NOT'' )
  
-HTTPクライアントは、Uri::getPath() およびUri::getQuery() 値を無視し、代わりにgetRequestTarget() によって返される値を使用する必要があります (MUST)。getRequestTarget()はデフォルトでは、これら2つの値を連結します。+>''上記原文'' \\ 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().
  
-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().+''RequestInterface'' は、リクエストターゲットを取得するメソッド、または指定されたリクエストターゲットを使用して新しいインスタンスを作成するメソッドを提供します。デフォルトでは、リクエストターゲットがインスタンス内で具体的に構成されていない場合、''getRequestTarget()'' は、構成されたURIの origin-form(または構成されていない場合は「/」)を返します。 
  
-4つのリクエストターゲット形式の1つ以上を実装しないことを選択したクライアントは、引き続きgetRequestTarget() を使用する必要があります (MUST)。これらのクライアントは、サポートしていないリクエストターゲットを拒否する必要があり (MUST)、getUri() からの値に依存してはなりません (MUST NOT)。 +''withRequestTarget($requestTarget)'' は、指定されたリクエストターゲットを使用して新しいインスタンスを作成するので、開発者は他の3つのリクエストターゲット形式 absolute-form、authority-form、およびasterisk-form を表すリクエストメッセージを作成できます。れが使用された場合、構成されたURIインスタンスは、特にクライアント引き続き使用、サーバーへの接続を作成するために使用できます。
- +
-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, authority-form, and asterisk-form). When used, the composed URI instance can still be of use, particularly in clients, where it may be used to create the connection to the server. +
- +
-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, PHP’s abstraction and extension of CGI via its Server APIs (SAPI). PHP has provided simplification around input marshaling via superglobals such as: 
  
-RequestInterfaceは、HTTPリクエストメッセージの一般的な表現を提供します。 ただし、サーバー側の環境の性質上、サーバー側のリクエストには追加の処理が必要です。 サーバー側の処理では、Common Gateway Interface(CGI)、PHP(さらに具体的には、サーバーAPI(SAPI)を介したCGIの抽象化と拡張を考慮する必要があります。 PHPは、次のようなスーパーグローバル変数をして入力のマーシャリングを簡素化しました。+''RequestInterface'' は、HTTPリクエストメッセージの一般的な表現を提供します。ただし、サーバー側の環境の性質上、サーバー側のリクエストには追加の処理が必要です。サーバー側の処理では、Common Gateway Interface(CGI)、さらに具体的には、PHPのサーバーAPI(SAPI)を介したCGIの抽象化と拡張を考慮する必要があります。PHPは、次のようなスーパーグローバル変数を経由して入力のマーシャリングを簡素化しました。
  
-  * $_COOKIE, which deserializes and provides simplified access to HTTP cookies. +  * **$_COOKIE**: HTTPCookieへのデシリアル化と簡略化されたアクセスを提供します。 
-  * $_GET, which deserializes and provides simplified access to query string arguments. +  * **$_GET**: クエリ文字列引数へのデシリアル化と簡略化されたアクセスを提供します。 
-  * $_POST, which deserializes and provides simplified access for urlencoded parameters submitted via HTTP POST; generically, it can be considered the results of parsing the message body. +  * **$_POST**: HTTP POST経由で送信されたURLエンコードされたパラメーターへのデシリアル化と簡略化されたアクセスを提供します。 一般的には、メッセージ本文の解析結果と考えることができます。 
-  * $_FILES, which provides serialized metadata around file uploads. +  * **$_FILES**: ファイルのアップロードに関するシリアル化されたメタデータを提供します。 
-  * $_SERVER, which provides access to CGI/SAPI environment variables, which commonly include the request method, the request scheme, the request URI, and headers.+  * **$_SERVER**: CGI / SAPI環境変数へのアクセスを提供します。これには、通常、リクエストメソッド、リクエストスキーム、リクエストURI、およびヘッダーが含まれます。
  
-  * $_COOKIE: HTTPCookieへのデシリアル化と簡略化されたアクセス提供ます。 +''ServerRequestInterface'' は ''RequestInterface'' 拡張て、これらのさまざまなスーパーグロ変数に関する抽象化を提供します。このプラクティスは、コンシュマーによスーパーグロール変数への結合減ら役立ち、リクエストコンシュマーをテストする為の能力を奨励し促進します。
-  * $_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”, to allow consumers the ability to introspect, decompose, and match the request against application-specific rules (such as path matching, scheme matching, host matching, etc.). As such, the server request can also provide messaging between multiple request consumers. +
- +
-サーバーリクエストは、「attributes」という1つの追加プロパティを提供して、コンシューマーがアプリケーション固有のルール(パスマッチング、スキームマッチング、ホストマッチングなど)に対してリクエストを内省(introspect)、分解(decompose)、および照合(match)できるようにします。 したがって、サーバーリクエストは、複数のリクエストコンシューマー間のメッセージングにも提供できます。+
  
 \\ \\
行 293: 行 247:
 ==== 1.6 アップロードファイル ==== ==== 1.6 アップロードファイル ====
  
-ServerRequestInterface specifies a method for retrieving a tree of upload files in a normalized structure, with each leaf an instance of UploadedFileInterface.+''ServerRequestInterface'' は、正規化された構造でアップロードファイルのツリーを取得するメソッドを規定します。そのツリーの各リーフには ''UploadedFileInterface'' のインスタンスがあります。
  
-ServerRequestInterfaceは、正規化された構造でアップロードファイルのツリーを取得するメソッドを規定します。そのツリーの各リーフにはUploadedFileInterfaceのインスタンスがあります。 +''$_FILES'' スーパーグローバル変数には、ファイル入力の配列を処理するときによく知られた問題がいくつかあります。例として、ファイルの配列を送信するフォームがある場合(例えば入力名を「files」とする)、''files[0]'' と ''files[1]'' を送信すると、PHPはこれを次のように表します:
- +
-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”, submitting files[0] and files[1] — PHP will represent this as: +
- +
-$_FILESスーパーグローバル変数には、ファイル入力の配列を処理するときによく知られた問題がいくつかあります。 例として、ファイルの配列を送信するフォームがある場合(例えば入力名を「files」とする)、files[0] とfiles[1] を送信すると、PHPはこれを次のように表します:+
  
 <code php> <code php>
行 316: 行 266:
 ) )
 </code> </code>
- 
-instead of the expected: 
  
 期待されるのは次のようです: 期待されるのは次のようです:
行 337: 行 285:
 ) )
 </code> </code>
- 
-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, scenarios exist where $_FILES is not populated when file uploads occur:+さらに、ファイルのアップロードが発生したときに ''$_FILES'' が設定されない状況があります:
  
-さらに、ファイルのアプロードが発生したときに$_FILESが入力されない状況がありま+  * HTTPメソッドが ''POST''ない場合 
 +  * ユニットテストの時 
 +  * [[https://reactphp.org/|ReactPHP]]のように非SAPI環境下で操作る場合
  
-  * When the HTTP method is not POST. +そのような場合、データを別の方法でシード(特別な処理)する必要があります。例としては:
-  * When unit testing. +
-  * When operating under a non-SAPI environment, such as ReactPHP. +
- +
-  * 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/O、ストレージのオーバーヘッドを削減します。   * プロセスがメッセージ本文を解析して、ファイルのアップロードを検出する場合があります。 このような場合、実装では、ファイルアップロードをファイルシステムに書き込まず、代わりにストリームにラップして、メモリ、I/O、ストレージのオーバーヘッドを削減します。
- 
-  * 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() provides the normalized structure for consumers. Implementations are expected to:+''getUploadedFiles()'' は、コンシューマに正規化された構造を提供します。実装では、次のことが期待されます:
  
-getUploadedFiles() は、コンシューマに正規化された構造提供ます。 実装では次のことが期待されます+  * 与えられたファイルアップロードのすべての情報集約し、を使用して ''Psr\Http\Message\UploadedFileInterface'' インスタンスに設定します
  
-  * Aggregate all information for a given file upload, and use it to populate a Psr\Http\Message\UploadedFileInterface instance. +  * 送信されたツリー構造を再作成します。その時各リーフは、ツリー内の与えられた場所に対して適切な''Psr\Http\Message\UploadedFileInterface'' のインスタンスになります。
-  * 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インスタンスに入力します。 +
-  * 送信されたツリー構造を再作成します。その時各リーフは、ツリー内の与えられた場所に対して適切な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: 行 314:
 </code> </code>
  
-In this case, the structure in $_FILES would look like: +この場合、''$_FILES'' の構造は次のようになります:
- +
-この場合、$_FILESの構造は次のようになります:+
  
 <code php> <code php>
行 404: 行 328:
 </code> </code>
  
-The normalized form returned by getUploadedFiles() would be: +''getUploadedFiles()'' によって返される正規化された形式は次のようになります:
- +
-getUploadedFiles() によって返される正規化された形式は次のようになります:+
  
 <code php> <code php>
行 413: 行 335:
 ) )
 </code> </code>
- 
-In the case of an input using array notation for the name: 
  
 名前に配列表記を使用した入力の場合: 名前に配列表記を使用した入力の場合:
行 421: 行 341:
 <input type="file" name="my-form[details][avatar]" /> <input type="file" name="my-form[details][avatar]" />
 </code> </code>
- 
-$_FILES ends up looking like this: 
  
 $_FILESは次のようになります: $_FILESは次のようになります:
行 459: 行 377:
 </code> </code>
  
-And the corresponding tree returned by getUploadedFiles() should be: +そして、''getUploadedFiles()'' によって返される対応するツリーは次のようになります:
- +
-そして、getUploadedFiles() によって返される対応するツリーは次のようになります:+
  
 <code php> <code php>
行 472: 行 388:
 ) )
 </code> </code>
- 
-In some cases, you may specify an array of files: 
  
 場合によっては、ファイルの配列を指定できます: 場合によっては、ファイルの配列を指定できます:
行 481: 行 395:
 Upload an avatar: <input type="file" name="my-form[details][avatars][]" /> Upload an avatar: <input type="file" name="my-form[details][avatars][]" />
 </code> </code>
- 
-(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'' は通常の構造から逸脱しているためです。それは、次のような場合です:
- +
-このような場合、仕様の実装では、指定されたインデックスにあるファイルに関連するすべての情報を集約する必要があります。 その理由は、$_FILESは通常の構造から逸脱しているためです。それは、次のような場合です:+
  
 <code php> <code php>
行 542: 行 452:
 </code> </code>
  
-The above $_FILES array would correspond to the following structure as returned by getUploadedFiles(): +上記の ''$_FILES'' 配列は、''getUploadedFiles()'' によって返される次の構造に対応します:
- +
-上記の$_FILES配列は、getUploadedFiles() によって返される次の構造に対応します:+
  
 <code php> <code php>
行 559: 行 467:
 ) )
 </code> </code>
- 
-Consumers would access index 1 of the nested array using: 
  
 コンシューマーは、ネストされた配列のインデックス1に次のようにしてアクセスします: コンシューマーは、ネストされた配列のインデックス1に次のようにしてアクセスします:
行 568: 行 474:
 </code> </code>
  
-Because the uploaded files data is derivative (derived from $_FILES or the request body), a mutator method, withUploadedFiles(), is also present in the interface, allowing delegation of the normalization to another process. +アップロードされたファイルデータは派生''$_FILES'' またはリクエストボディからの派生)であるため、インターフェイスにはミューテーターメソッド(mutator method) として ''withUploadedFiles()'' も存在し、正規化を別のプロセスに委譲できます。
- +
-アップロードされたファイルデータは派生($_FILESまたはリクエストボディからの派生)であるため、インターフェイスにはミューテーターメソッド(mutator method) としてwithUploadedFiles() も存在し、正規化を別のプロセスに委譲できます。 +
- +
-In the case of the original examples, consumption resembles the following:+
  
 冒頭の例の場合、使用方法は次のようになります: 冒頭の例の場合、使用方法は次のようになります:
行 589: 行 491:
 </code> </code>
  
-This proposal also recognizes that implementations may operate in non-SAPI environments. As such, UploadedFileInterface provides methods for ensuring operations will work regardless of environment. In particular:+この提案は、実装が非SAPI環境で動作する可能性があることも認識しています。従って、''UploadedFileInterface'' は、環境に関係なく操作が確実に機能するためのメソッドを提供します。 特に:
  
-この提案は、実装が非SAPI環境で動作する可能性があることも認識しています。 したがって、UploadedFileInterfaceは、環境に関係なく操作が確実に機能するためのメソッドを提供します。 特に: +  ''moveTo($targetPath)'' は、一時的なアップロードファイルで直接 ''move_uploaded_file()'' を呼び出すより安全で推奨される代替手段として提供されています。実装は、環境に基づいて使用する正しい操作を検出します。
-  +
- +
-  * 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. +
- +
-  * moveTo($targetPath) は、一時アップロードファイルでmove_uploaded_file() を直接呼び出すより安全で推奨される代替手段として提供されています。 実装は、環境に基づいて使用する正しい操作を検出します。 +
- +
-  * getStream() will return a StreamInterface instance. In non-SAPI environments, one proposed possibility is to parse individual upload files into php://temp streams instead of directly to files; in such cases, no upload file is present. getStream() is therefore guaranteed to work regardless of environment. +
- +
-  * getStream() はStreamInterfaceインスタンスを返します。 非SAPIの環境下では、個々のアップロードファイルを解析して直接ファイルにではなくphp://tempストリームにすることが提案されています。 このような場合、アップロードファイルは存在しないことになり、 したがって、getStream() は環境に関係なく動作することが保証されています。+
  
-As examples:+  * ''getStream()'' は ''StreamInterface'' インスタンスを返します。非SAPIの環境下では、個々のアップロードファイルを解析して直接ファイルにではなく ''php:<nowiki>//</nowiki>temp'' ストリームにすることが提案されています。このような場合、アップロードファイルは存在しないことになり、従って、''getStream()'' は環境に関係なく動作することが保証されています。
  
 例として: 例として:
行 609: 行 502:
 // Move a file to an upload directory // Move a file to an upload directory
 // ファイルをアップロードディレクトリに移動する // ファイルをアップロードディレクトリに移動する
 +
 $filename = sprintf( $filename = sprintf(
     '%s.%s',     '%s.%s',
行 620: 行 514:
 // 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->getStream()); $stream = new Psr7StreamWrapper($file1->getStream());
 stream_copy_to_stream($stream, $s3wrapper); stream_copy_to_stream($stream, $s3wrapper);
psr/psr7.1592298155.txt.gz · 最終更新: 2020/06/16 18:02 by y2sunlight