从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解析器，现在可以检测到重复的键。
试一试：点击参考链接
现在，使用lossless-json有一个缺点：它比原生内置的JSON.parse慢得多。这只是大的JSON对象或数组的问题，对于大于10MB的文件，它可能会很明显。为了仍能顺利地处理大文件，JSON Editor Online允许你选择你想使用的解析器，默认情况下，它会自动为你选择最合适的解析器。
到此这篇关于为什么JSON.parse会损坏大数字，如何解决这个问题？的文章就介绍到这了,更多相关JSON.parse损坏大数字内容请搜索本站以前的文章或继续浏览下面的相关文章希望大家以后多多支持本站！