使用JSONObject时，你需要注意避免的一个问题

鲍协浩，小米MIUI部门， MIUI基础应用组通讯录开发负责人。

为政和等地区用户提供了全套网页设计制作服务，及政和网站建设行业解决方案。主营业务为成都网站设计、成都网站建设、外贸网站建设、政和网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！

问题现象

在 Android 业务同步的逻辑代码中，使用到了 JSONObject 来解析服务端的 JSON 数据。同时本地因为业务新增需求的缘故，在本地数据库中使用 JSONObject 缓存了包括水位等同步相关的信息，其中，水位值是 Long 型。但近期发现同步过程中下一次同步时，传递给服务器的水位并不是上一次服务器返回的新水位，而是相差一些。以 301028292893495297L 为例，服务器返回这个水位之后，下次客户端上传的水位是 301028292893495296L，差值为 -1。

问题排查

通过反复排查代码逻辑，发现水位从服务端返回到下次请求之间，只经过了以下转换：

认真阅读代码不难发现，Long 型的水位值保存在 JSON 对象中的时候被转成了 String 型，而在读取的时候又当作是 Long 型来处理。所以就会有精度缺失的问题吗?马上参考 JSONObject 的文档：

认真阅读代码不难发现，Long 型的水位值保存在 JSON 对象中的时候转成了 String 型，而在读取的时候又当作是 Long 型来处理。因此会有精度缺失的问题，参见如下 JSONObject 的文档：

由此可见，在读取 JSON 对象的某个值时，如果原先是 String 型，读取的时候当作是 Long 型，是会将 String 型通过 Double 进行解析的，所以在值超过 2^52 时会有精度缺失的问题。于是，遇到的问题就可以解释了。以下是 Double 的存储格式规范：

其中，Double 和 Long 的精度测试代码很简单(输入参数可以提供例如 301028292893495297L 这样超过 2^52 的 long 值，会发现其返回值不为 0)：

也就是说，在读取 JSON 对象的某个值时，如果原先是 String 型，读取的时候当作是 Long 型，是会将 String 型通过 Double 进行解析的，所以在值超过 2^52 时会有精度缺失的问题。

另外，关于 JSON 对象中的值是 Long 型还是 String 型，其实比较容易被忽略。如果JSON 对象在使用 String 表示的时候，该值对应处有引号就是 String 型，否则就是其他类型。看如下的 2 个测试用例就一目了然：

Double 和 Long 的精度测试代码很简单(输入参数可以提供例如 301028292893495297L 这样超过 2^52 的 long 值)：

知道了问题的根源，修复就一目了然了，在水位保存在 JSONObject 对象中时，应该当作 Long 型而不是 String 型来保存;亦或者在读取的时候也当作是 String 型，然后通过 Long.valueOf 等接口进行解析。

另外，关于 JSON 对象中的值是 Long 型还是 String 型，其实比较容易被忽略。如果JSON 对象在使用 String 表示的时候，该值对应处有引号就是 String 型。看如下的试用例就一目了然了：

类似的问题在网上随意一搜，其实有许多人遇坑了，比如这个。

所以，尽管不能说这个库的设计是很失败的，但肯定不算是一个设计良好的库。因为你无法直接从 API 名称看出其内在的潜在逻辑，容易导致使用者使用不当。因此，经验教训就是：使用第三方库的时候，能看 API 文档就看 API 文档，切不可望文生义。当然，这个问题可能也仅限在 Android 中较老的代码模块，毕竟新的代码都会使用 GSON 等类库进行 JSON 对象操作，也就不容易出现这样的不易发现的问题了。

当然，单就这个问题来看，其实是在新增业务逻辑的时候，没有正确使用 JSONObject 对象的接口，Long 型的值不应当看成是 String 型进行保存而又当成是 Long 型来读取，如果保存和读取的接口保持对应，也就不会出现问题了。不管怎么说，该问题的教训是在使用 JSONObject 相关接口时要倍加小心谨慎。

备注：Github 上***的 JSON-Java 库没有这个问题，可以放心使用。

问题解决

知道了问题的根源，修复就一目了然了，在水位保存在 JSON 对象中时，应该当作 Long 型而不是 String 型来保存;或者在读取的时候也当作是 String 型，然后通过 Long.valueOf 等接口进行解析。

问题后话

类似的问题在网上随意一搜，其实有许多人遇坑了，比如这个。所以，尽管不能说这个库的设计是很失败的，但肯定不算是一个设计良好的库。因为你无法直接从 API 名称看出内在的潜在逻辑，导致使用不当。因此，经验教训就是：使用第三方库的时候，能看 API 文档就看 API 文档，切不可望文生义。

当然，Github 上***的 JSON-Java 库是没有这个问题的。

网站题目：使用JSONObject时，你需要注意避免的一个问题
地址分享：http://www.hantingmc.com/qtweb/news26/175076.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联