代码之家 › 专栏 › 技术社区 › Sklivvz

在C中处理编码的cookie值#

single-sign-on cross-platform cookies c#

Sklivvz · 技术社区 · 16 年前

根据 RFC 2109 ,cookie的值“对用户代理是不透明的,可能是源服务器选择发送的任何内容,可能是服务器选择的可打印的ASCII编码。”

因此,即使原始值相同,不同的语言/平台/服务器也会发送不同的cookie值。

例如,c/asp.net按原样发送文本;经典的asp urlencodes和urldecodes文本;perl/apache urlencodes/decodes文本(但不同于asp!).php提供了选项。

我正在编写一个单一的登录系统,需要与各种各样的应用程序共享cookie。特别是,我有.NET,Java,Perl,CaldFube,需要被支持。

我存储在cookie中的文本始终是有效的 ASCII-7 字符串。然而,例如,Perl喜欢对一些7位的ASCII字符进行编码。

我看到了两个主要的替代方案:

只接受非编码值。毕竟,没有必要对它们进行编码。这就是目前的情况。显然,所有集成系统都必须能够支持非编码值。
接受编码值和非编码值。这将允许最大限度地实现开箱即用的兼容性,但我需要确定是否对特定值进行了编码(听起来很不可能:文本“%20”是字符串还是空格?)

你建议哪种解决方案?为什么?如果是2,如何检测URLENCODED文本?

cookie示例(我添加了换行符以使其适合)

A5A2794D694241AD92F9B22F288EFAA1|8428DCCC|20090821142732|20090821142832|
10.100.107.40|955098D50AB4982D4E247EFA53F4E23B32A05ED0131E096709BE1D8CCC
8A3CA18252D376473C244FD71C462AB42CF54C

2 回复 | 直到 16 年前

Jon Skeet 16 年前

你为什么不能用纯字母数字值?如果您有一些不透明的二进制数据试图持久化,那么您可以使用十六进制或使用“web-safe”base64。

你越不可能让别人乱搞你的饼干完全我觉得更好。

paracycle 16 年前

是的,这不是一个小问题。从根本上讲,我更倾向于解决方案2,因为它是最具互操作性的。但是,正如您所说,检测哪些cookie是URL编码的,哪些不是URL编码的,这是一个非常重要的问题。

我想到的一件事是,您可以使用一些特殊的字符填充cookie值的开头,这样您就可以检测cookie是否被编码。当然,这可能不包括所有客户机,但例如,如果您的普通cookie值是 CookieValue1234 然后你可以把它改成 head :CookieValue1234 并检查其中的空间是否会返回已编码的URL(即返回为 %20 “或”作为“”。