根据RFC 2109:
“VALUE对用户代理不透明,可以是源服务器选择发送的任何内容,可能采用服务器选择的可打印ASCII编码。‘不透明’意味着该内容仅对源服务器具有重要性和相关性。实际上,任何检查Set-Cookie头的人都可以阅读该内容。”
这听起来像“服务器是老板”,它决定了将应用哪种编码。这使得在从PHP后端设置Cookie并从Python或Java等其他语言中读取Cookie时,不编写任何手动编码/解码处理变得相当困难。
假设我们有一个需要编码的值。俄语
/"печенье (*} значения"/
表示带有一些额外的非字母数字字符的“cookie value”。
Python:
几乎所有的WSGI服务器都使用Python的SimpleCookie类进行编码/解码,即使许多人表示八进制字面量在ECMA-262严格模式下已被弃用。真是令人费解。因此,我们的原始cookie值变成了
"/\"\320\277\320\265\321\207\320\265\320\275\321\214\320\265 (*} \320\267\320\275\320\260\321\207\320\265\320\275\320\270\321\217\"/"
。
Node.js:
我完全没有测试,但我猜测使用本地的encodeURIComponent和decodeURIComponent函数的JavaScript后端可以完成它,这些函数使用十六进制转义/取消转义?
PHP:
PHP对cookie值应用urlencode,类似于encodeURIComponent但并不完全相同。
因此,原始值变为:%2F%22%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D1%8C%D0%B5+%28%2A%7D+%D0%B7%D0%BD%D0%B0%D1%87%D0%B5%D0%BD%D0%B8%D1%8F%22%2F
,甚至没有用双引号包装。
value
变量具有上述PHP编码值,则decodeURIComponent(value)
会给出 /“печенье+(*}+значения”/
,请注意+字符而不是空格。
Java、Ruby、Perl和.NET的情况如何?哪种语言遵循(或最接近)所需的行为。实际上,W3是否定义了任何标准?