关于使用httpclient的问题

Posted 2023-05-17

BufferedReader br = new BufferedReader(new InputStreamReader(entity.getContent(), "utf-8"))
读出的内容都是
usercard=\"name=\u738b\u658c_ICTIR\" >@\u738b\u658c_ICTIR<\/a>:\u9a6c\u8bfe\/\/<a href=\"\/n\/%E5%BC%A0%E4%BF%8A%E6%9E%97
普通字符和unicode编码混合的 有没有什么方法能直接转换

先转换unicode再转换url
没有直接转换的方法。

在源码里unicode被表示为
\\u9a6c多了一层，没办法 参考技术A new String(s.getBytes("iso-8859-1") ,"UTF-8")

apache HttpClient关于digest的一个大坑

一个简单的http请求，花了我将近一天的时间，只因为HttpClient的一个实现与规范有些不一致。

服务器使用了digest认证，使用的是nginx，我们用iOS,js写的程序都可以顺利访问，浏览器、curl自然也都不在话下，但java程序访问总是报401或者400的错误。

抓包分析，自己写程序比对程序生成的response值，都没有问题，打开nginx的日志，只看到报错，也没有说明报错原因。

后来仔细比较正常请求和java程序发出的请求，发现java发出的请求中qop和algorithm两个字段的值没有带双引号。

尝试升级HttpClient到最新版，还是一样。

尝试使用OKHttp，发现不支持digest认证，安装了一个第三方的扩展okhttp-digest，这个也是从HttpClient中扣出来的，所以也有相同的问题。

最后没有办法，重写了相关方法，把qop和algorithm两个字段加上引号，重新运行，返回http 200了。

这肯定是httpclient和nginx不兼容，两者都是工业级的成熟工具，怎么能出这种低级错误呢？我得给他们做个裁判。

看了标准规范RFC2617，发现对这一块也没有非常明确的要求，但有要求auth-req中这两个值是带引号的，auth-resp没有明确，但理论上讲nginx更有道理些，所以板子打到httpclient上面。

最终实现代码（略）