lke*_*e00 5 unicode rest encoding tomcat basic-authentication
在这个问题上,我一直在撞墙.我读过类似的帖子和文章; 大多数建议在Tomcat的server.xml文件中将URIEncoding设置为UTF-8,但这似乎没有区别.
我将一个ReSTful Web服务部署到托管在Tomcat 7上的测试环境中.Tomcat配置为使用Java 6,尽管Java 7也安装在计算机上.当针对托管在那里的服务运行基本身份验证测试时,登录失败,当原始凭据包含Unicode字符时,我收到HTTP状态401的响应.凭证仅包含ASCII时,基本身份验证工作正常.我也可以在不使用基本身份验证的情况下登录 - 我的服务支持自定义登录标头和RFC 2047.使用该方法,凭据是否包含Unicode无关紧要,登录不是问题.
具体来说,"问题"似乎是用户名是UTF-8编码两次.我的记录器(单独的问题)中存在一个错误,其中日志文件是ANSI编码的.将日志文件转换为UTF-8时,字符将正确显示.但在这种情况下,有问题的用户名比它应该的长得多,并且当文件转换为UTF-8时,它看起来就像它应该在第一个位置(在转换之前).例如:
这里真正的踢球者是我有自己的本地运行的Tomcat 7(Java 6)实例,我不能重现它的问题.我比较了两只雄猫的conf目录,它们看起来是一样的.我无法弄清楚为什么基本的auth在一个环境中而不是另一个环境中工作.我正在从我的机器上运行测试,所以它不能归因于我测试它的方式(JUnit/JSystem)的差异.
这就是我所知道的:
以下文章对我来说非常有趣,因为它们提出了将RFC 2047和基本身份验证结合在一起的可能性.我不认为这是必要的,因为基本的auth字符串本身只包含ASCII(因为它是base-64编码).即使如此,为什么在一个Tomcat服务器上需要这样的东西而不是另一个？我觉得追求这种组合方法并不是解决根本问题,这真是让我发疯的原因!
提前感谢您尝试或仔细检查的建议.测试环境在某种程度上仅限于我 - 我只能在非工作时间"玩它",所以如果我没有及时回复,我会提前道歉.
从您提供的数据来看，UTF-8 数据实际上似乎正在转换为 ASCII 编码，而不是双重 UTF-8 编码。
就实际问题而言，不幸的是基本身份验证没有提供任何方式来传输未解码的用户名和密码的字符集。因此，您的主要选项是假设并手动指定字符集，使用环境中的默认字符集，或确定提供字符集的自定义方式（例如另一个标头）。每个选项都取决于您对环境和通信的客户端/服务器端的控制程度，以及您是否希望所有调用都使用相同的字符集。
基于一台服务器行为正确而另一台服务器行为不正确，我假设解码当前使用环境中的默认字符集。您是对的，编码字符串仅包含 ASCII（因此您可能没有看到传输编码值的问题），因此数据可能在解码过程中（或之后）丢失。根据您选择的库，它可能会生成字节数组或字符串，因此请务必检查您在从字节数组创建字符串时是否提供了字符集（例如 new String(decodedData, someCharset)）或看看是否有办法将其提供给库（如果它生成一个字符串）。
| 归档时间： |
|
| 查看次数： |
1566 次 |
| 最近记录： |