为什么JSON.parse会损坏大数字,如何解决这个问题?

开发 前端
JSON数据格式极其简单,而且它是JavaScript的一个子集。所以它与JavaScript完全可以互换。你可以将一个JSON文档粘贴到一个JavaScript文件中,这就是有效的JavaScript。

从10多年前JSON在线编辑器的早期开始,用户经常反映编辑器有时会破坏他们JSON文档中的大数字的问题。直到现在,我们也没能解决这个问题。在这篇文章中,我们深入解释了这个问题,并展示如何在JSON Editor Online中解决这个问题。

大数字的问题

大多数 Web 应用程序处理来自服务器的数据。这些数据以纯文本的JSON文档形式被接收,并被解析成一个JavaScript对象或数组,这样我们就可以读取属性并做一些事情。通常情况下,数据的解析是使用JSON.parse函数进行的,该函数内置于JavaScript中,非常快速和方便。

JSON数据格式极其简单,而且它是JavaScript的一个子集。所以它与JavaScript完全可以互换。你可以将一个JSON文档粘贴到一个JavaScript文件中,这就是有效的JavaScript。

在JavaScript中使用JSON应该不会出现任何问题,但有一种棘手的情况可能会破坏数据:大数字。这是一个有效的JSON字符串:

{"count": 9123372036854000123}

当我们将其解析为JavaScript并读取 "count" 键时,我们会得到:

9123372036854000000

解析后的数值被破坏了:最后三位数字被重置为零。这是否是一个问题,取决于这些最后的数字是否确实有意义,但一般来说,知道这种情况可能会发生,可能会给你一种不舒服的感觉。

为什么大数字会被JSON.parse破坏?

像 9123372036854000123​ 这样的长数字既是有效的 JSON 也是有效的 JavaScript。当JavaScript 将数值解析为数字时,事情就出错了。最初,JavaScript 只有一种数字类型。Number​。这是一个64位的浮点值,类似于C++、Java或C#中的Double值。这种浮点值可以存储大约16位数字。因此,它不能完全代表像9123372036854000123这样的数字,它有19位数字。在这种情况下,最后三位数字会丢失,破坏了该值。

在用浮点数存储分数时也会发生同样的情况:当你在 JavaScript 中计算 1/3时,结果是:

0.3333333333333333

在现实中,该值应该有无限的小数,但 JavaScript 的数字在大约 16位 之后就停止了。

那么,JSON文档中像9123372036854000123​这样的大数字是怎么来的呢?嗯,其他语言如Java或C#确实有其他数字数据类型,如Long。Long是一个64位的值,可以容纳最多20位的整数。它能容纳更多数字的原因是,它不需要像浮点值那样存储指数值。因此,在像Java这样的语言中,你可以有一个Long值,它不能在JavaScript的Number类型中正确表示,或者在其他语言中的Double类型中正确表示。

JavaScript 的 Number(或者更好:任何浮点数值)还有一些限制:数值可以溢出或下溢。例如,1e+500​会变成Infinity​,而1e-500​会变成0。不过,这些限制在实际应用程序中很少成为问题。

如何防止数字被 JSON.parse 破坏?

多年来,这个用 JavaScript 解析大数字的问题一直是https://jsoneditoronline.org/ 的用户反复要求的。像大多数基于网络的JSON编辑器一样,它也使用了本地的JSON.parse函数和常规的JavaScript数字,所以它受到了上述的限制。

第一个想法可能是:等等,但是 JSON.parse​ 有一个可选的reviver​参数,允许你用不同的方式来解析内容。但问题是,首先文本被解析成一个数字,接下来,它被传递给reviver。所以到那时,已经太晚了,值已经被破坏了。

为了解决这个问题,根本不能使用内置的JSON.parse,必须使用一个不同的JSON解析器。对此有各种优秀的解决方案:lossless-json、json-bigint、js-jon-bigint或json-source-map。

这些库中的大多数都采取了务实的方法,将长数字直接解析为JavaScript相对较新的BigInt数据类型。lossless-json库是专门为JSON Editor Online开发的。它采取了比JSON BigInt解决方案更加灵活和强大的方法。

默认情况下,lossless-json 将数字解析成一个轻量级的LosslessNumber​类,该类将数字值作为一个字符串持有。这保留了任何数值,甚至还保留了格式化,比如数值4.0​中的尾部零。当对其进行操作时,LosslessNumber​将被转换为Number​或BigInt,或者在不安全时抛出一个错误。

该库允许你传递你自己的数字解析器,所以你可以应用你自己的策略来处理数字值。也许你想把长的数字值转换成BigInt,或者把数值传给某个BigNumber库。你可以选择是否要在数字信息丢失时抛出一个异常,或者默默地忽略某些类别的信息丢失。

因此,比较本地JSON.parse​函数和lossless-json,会得到以下结果:

import { parse, stringify } from 'lossless-json'
const text = '{"decimal":2.370,"long":9123372036854000123,"big":2.3e+500}'
// JSON.parse will lose some digits and a whole number:
console.log(JSON.stringify(JSON.parse(text)))
// '{"decimal":2.37,"long":9123372036854000000,"big":null}'
// WHOOPS!!!
// LosslessJSON.parse will preserve all numbers and even the formatting:
console.log(stringify(parse(text)))
// '{"decimal":2.370,"long":9123372036854000123,"big":2.3e+500}'

使用LosslessJSON解析器是否能解决所有问题?

答案是并不能。这取决于你在解析数据后想做什么,但通常情况下,你想用它做一些事情。在屏幕上显示数据,验证它,比较它,排序它,等等。例如,在JSON Editor Online中,你可以编辑数值,转换文档(查询、过滤、排序等),比较两个文档,或者根据JSON模式验证一个文档。一旦你引入BigInt值或LosslessNumbers,你想执行的所有操作都需要支持这些类型的值。

拥有 BigInt 值或 LosslessNumbers 的数据很可能给不了解这些数据类型的第三方库带来问题。例如,JSON Editor Online支持将你的JSON数据导出到CSV,并使用优秀的json2csv库来实现。

这个库不知道BigInt​或LosslessNumber​类型,不会正确串联这些数据类型。为了使其正常工作,包含LosslessNumbers​或BigInt值的JSON数据必须首先被转换为该库所能理解的数据。

即使没有第三方库的参与,与BigInt值一起工作也会导致棘手的问题。当对大整数和普通数字的混合操作时,JavaScript可以默默地将一种数字类型强制转化为另一种,这可能会导致错误。下面的代码例子显示了这是如何出错的。

const a = 91111111111111e3 // a regular number
const b = 91111111111111000n // a bigint
console.log(a == b) // returns false (should be true)
console.log(a > b) // returns true (should be false)

在这个例子中,你看到两个常数​​a​​​和​​b​​​持有相同的数字值。但是一个是数字,另一个是BigInt,用这些东西和普通的操作符(如​​==​​​和​​>​​)一起使用会导致错误的结果。

结论:要让大数字在一个应用程序中工作,可能需要大量的努力。因此,最好的办法是尽量避免在一开始就处理这些问题。

如果你真的要处理大数值,你必须使用一个替代的JSON分析器,如​​lossless-json​​​。为了防止陷入与拥有​​BigInt​​​或​​LosslessNumber​​数据类型有关的难以调试的问题,使用TypeScript明确定义你的数据模型是很有帮助的。这样,你就可以事先知道哪些地方需要能够处理这些特殊的数据类型,你就可以采取行动,而不是让你的应用程序默默地失败。

在线JSON编辑器现在可以安全地处理大数字了

从今天起,JSON Editor Online已经完全支持大数字,所以你不必再担心损坏的数值。它已经集成了lossless-json库,并确保编辑器的所有功能都能处理大数字:从格式化、排序和查询到导出到CSV。作为一个副作用,它现在甚至保持了数字的格式化,而且由于新的LosslessJSON解析器,现在可以检测到重复的键。

试一试:https://jsoneditoronline.org/#left=json.%7B%20%22using%22:%20%22Lossless%20JSON%20Parser%22,%20%22formatted%20number%22:%204.0,%20%22long%22:%209123372036854000123,%20%22large%22:%201e500,%20%22small%22:1e-500%20%7D

现在,使用lossless-json有一个缺点:它比原生内置的JSON.parse慢得多。这只是大的JSON对象或数组的问题,对于大于10MB的文件,它可能会很明显。为了仍能顺利地处理大文件,JSON Editor Online允许你选择你想使用的解析器,默认情况下,它会自动为你选择最合适的解析器。

责任编辑:姜华 来源: 大迁世界
相关推荐

2013-08-01 10:05:54

大数据信息安全

2023-12-26 17:07:56

GenAICIO

2017-07-20 07:30:16

大数据数据互联网

2023-09-07 17:06:21

@Autowired报错原因分析

2022-07-14 14:27:34

Javascript数字精度二进制

2020-10-19 07:51:25

Linux软件

2020-03-16 10:56:06

大数据IT安全

2016-12-13 11:34:10

2012-09-05 11:09:15

SELinux操作系统

2021-01-18 14:34:59

幂等性接口客户端

2024-01-04 12:53:00

Unicode字符UTF-8

2010-04-29 17:46:31

Oracle死锁

2022-09-07 07:05:25

跨域问题安全架构

2013-05-21 10:49:59

Windows硬件冲突

2015-05-15 17:29:13

.Netxp系统如何解决

2023-04-19 14:20:49

2023-02-15 07:03:41

跨域问题面试安全

2020-09-24 09:29:34

人工智能

2011-08-29 10:34:00

网络安全云安全云计算

2011-03-23 14:42:47

CPU过度消耗
点赞
收藏

51CTO技术栈公众号