問題タブ [rfc1738]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
php - SagePay フォーム - RFC1738 にエンコードすると成功/失敗の URL が失敗する
フォーム v3.0 にアップグレードし、その間にコードをリファクタリングしています。
そうしているうちに、 which を使用http_build_queryして連想配列を受け取り、それを RFC1738 の有効な URL に変換すると、SagePay が次のエラーで失敗することに気付きました。
SagePay エンドポイントに送信するフォームの enctype はapplication/x-www-form-urlencodedです。
ただし...次のようにして、暗号化する文字列を手動で作成すると:
できます...
RFC1738 を理解しているので、URL 内に URL が存在する場合は、エンコードする必要があります。
RFC1738:
SagePay:
SagePay が RFC1738 に従っている場合、URL のエンコードは機能するはずですか? それとも、文字列が暗号化されているため、実際には問題にならないのでしょうか?
何かご意見は？
ありがとう
ギャビン
url - URLの疑問符はクエリ文字列の一部ですか?
TL;TR: URL の (最初の) クエスチョン マークはクエリの一部ですか、それとも区切り記号の後にクエリが続くだけですか?
RFC 1738のセクション 3.3 では、「?」(疑問符) はクエリ文字列の一部ではなく、パスから分離するだけです。
RFC 3986の付録 A に示されている文法も、「?」を示しています。実際のクエリ文字列の一部ではありません:
ここで、2 つの URL を考えてみましょう。
http://server.com/api/item.jsonhttp://server.com/api/item.json?
それらは同等ですか、それとも異なりますか？
それらを区別して、2 つの異なるリソースを識別するために使用することは有効ですか?
url - URL の最初のスラッシュは必須ですか?
今日、それが有効な URL であるかどうかについて同僚と議論しましたhttp://domain.com?some_param=1。URL 構造を定義する RFC は、それが無効な構造であることを明示的に述べていません。RFC 1738のパート 3.3によると
ただし、同じドキュメントのパート 3.1 の最後に、
curl を調べてみると、興味深いことがわかりました
それで、質問は
これは有効な URL ですか?http://domain.com?some_param=1
r - RFC1738 の R を使用した URL デコード (PHP デフォルト)
RFC 1738 を使用して URL エンコードされた R文字列でデコードする必要があります。
これらの文字列は PHP リクエストから取得され、デフォルトで RFC1738 を使用http_build_queryする PHP 関数でエンコードされます。
たとえば、 にHello, World!なりHello%2C+world%21ます。
次の PHP コードを使用して、オンラインで簡単に試すことができます。
残念ながら、R ベースの URL エンコーディングは RFC 3986を使用しますが、これは異なります!
戻りたい"Hello, world!"！Rでそれを行うにはどうすればよいですか？
記号をスペースに置き換えるだけ
+でよろしいのですが、これがあなたの答えである場合は、なぜこれが正しいのかを正当化してください. これまでの私の調査では、RFC 1738 が正確にRFC 3986 にプラス記号が付いていることを示していませんでした。奇妙なエッジ ケースは必要ありません...