今天18：30收到一个异常警报，一下子暴涨了300+的次数，我老大一下就不淡定了（我还没吃饭呢！！！），于是我这边和服务端一起开始查问题了，问题是服务端的一个轮询的接口异常了，导致android异常了（我就纳闷了，ios怎么就没有问题呢？）

于是，在解决线上问题时候还是决定对这个bug一探究竟。下面是异常信息：

# Thread-8284(8284)
java.lang.IllegalArgumentException
Unexpected code point: d8ec
  a.e.a(SourceFile:922)
  okhttp3.HttpUrl.a(SourceFile:1851)
  okhttp3.HttpUrl.a(SourceFile:1820)
  okhttp3.HttpUrl.a(SourceFile:1867)
  okhttp3.FormBody$Builder.add(SourceFile:110)
  xh.basic.internet.k.run(SourceFile:313)

就这么多，唯一比较明白的代码就是okhttp3.FormBody$Builder.add(SourceFile:110)这句，那就从这里开始追查。在 Github 上找到现在使用的 okhttp Tag 3.6.0 版本的代码，就可以对应到使这个方法。

题外话，这里为了在 GitHub 上方便查看源码，我在 Chrome 上安装了 Sourcegraph for GitHub 插件，查看源码需要跳转时，就像在 ide 中一样，ctrl + 鼠标左键 就可以跳转到目标代码很方便。
还有 octotree 插件值得推荐，是可以将 GitHub 的项目目录结构化，查看目录是不用每次跳转到新的页面了。

根据收集到的错误log可以很顺利的一步步定位到下图中 3 的位置，跳过去发现是 okio 的 Buffer.java 文件。由于 okio 的 jar 也是有版本的，只能再去 GitHub 找对应的 tag 查看代码了。

项目中所使用的 okio 1.9.0 版本

一看代码，行数和异常输出的信息都对上了。

再按照上面的代码顺序看看逻辑，这是在对 POST 请求的参数进行 encode 的时候，出现了一部分字符会不接新的情况，并且直接就抛出异常了，描述的 codePoint 为 d8ec 也确实符合 0xd800~0xdfff 这个区间。

这我就更加好奇了，这个神奇的符号到底是个什么鬼，害得我差点背锅了要。最后是了一些方法转换出来是这个字符“ރ”，第一反应这 (ri) 是 (le) 什 (gou) 么 (le)，度娘一下十个货币符号，这种符号用户也会输入？？？

BUG 的追查也告一段落了，这个符号的来源没有细究，来源于服务端的可能较大，毕竟这个 bug 是在服务器异常的情况下暴增的嘛！但是这个隐患可不能留，于是看看 okio 更高版本的 jar 有没有处理这个问题，直接看1.13.0版本的代码

可以看到，之前的抛出异常代码已经被替换成了输出 ? ，好吧没有根治至少不会在异常了，这说明这个区间的字符是不应该被解析么？

赶紧更新 okio 的 jar，完事提交代码，下班回家。。。