blocks|key|358183|text|JSON本身并不关心实现限制。你的问题是JS不能处理你的数据，而不是协议。换句话说，您的JS客户端代码必须使用这两个不完美的选项中的任何一个。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|358184|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

JSON itself doesn't care about implementation limits.
your problem is that JS can't handle your data, not the protocol.
In other words, your JS client code has to use either of those non-perfect options.

blocks|key|3360948|text|这似乎不是JSON的问题，而是Javascript本身的问题。你打算用这些数字做什么？如果它只是一个神奇的令牌，您需要稍后将其传递回网站，那么一定要使用包含该值的字符串。如果您实际上必须对值进行算术运算，则可以编写自己的64位算术Javascript例程。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3360949|在Javascript+(以及JSON)中表示值的一种方法是将数字拆分为两个32位的值，例如。|3360950|++[+12345678,+12345678+]|code-block|syntax|javascript|3360951|要将一个64位值拆分为两个32位值，请执行以下操作：|3360952|++output_values[0]+=+(input_value+>>+32)+&+0xffffffff;
++output_values[1]+=+input_value+&+0xffffffff;|3360953|然后将两个32位值重新组合为64位值：|3360954|++input_value+=+((int64_t)+output_values[0])+<<+32)+%7C+output_values[1];|3360955|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|Y|8|@]|9|@]|A|$G|H]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

This seems to be less a problem with JSON and more a problem with Javascript itself. What are you planning to do with these numbers? If it's just a magic token that you need to pass back to the website later on, by all means simply use a string containing the value. If you actually have to do arithmetic on the value, you could possibly write your own Javascript routines for 64-bit arithmetic. 

One way that you could represent values in Javascript (and hence JSON) would be by splitting the numbers into two 32-bit values, eg.

<pre><code> [ 12345678, 12345678 ]
</code></pre>

To split a 64-bit value into two 32-bit values, do something like this:

<pre><code> output_values[0] = (input_value &gt;&gt; 32) &amp; 0xffffffff;
 output_values[1] = input_value &amp; 0xffffffff;
</code></pre>

Then to recombine two 32-bit values to a 64-bit value:

<pre><code> input_value = ((int64_t) output_values[0]) &lt;&lt; 32) | output_values[1];
</code></pre>

blocks|key|358208|text|JS数字表示是标准的ieee+double，因此不能表示64位整数。iirc在双精度运算中，您可能会获得48位的实际int精度，但所有JS位运算都会减少到32位精度(这是规范所要求的。耶！)因此，如果你真的需要在js中使用64位int，你需要实现你自己的64位int逻辑库。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|358209|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The JS number representation is a standard ieee double, so you can't represent a 64 bit integer. iirc you get maybe 48 bits of actual int precision in a double, but all JS bitops reduce to 32bit precision (that's what the spec requires. yay!) so if you really need a 64bit int in js you'll need to implement your own 64 bit int logic library.

blocks|key|3361025|text|Javascript的Number类型(64位IEEE754)只有大约53位的精度。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3361026|但是，如果您不需要做任何加法或乘法，那么您可以将64位的值保留为4个字符的字符串，因为JavaScript使用UTF-16。|3361027|例如，1可以编码为“\u0000\u0001”。这样做的好处是，值比较(==，>，<)可以在字符串上按预期工作。写比特操作似乎也很简单：|3361028|function+and64(a,b)+{
++++var+r+=+"";
++++for+(var+i+=+0;+i+<+4;+i%2B%2B)
++++++++r+%2B=+String.fromCharCode(a.charCodeAt(i)+&+b.charCodeAt(i));
++++return+r;
}|code-block|syntax|javascript|3361029|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|O|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|P|8|@]|9|@]|A|$I|J]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Javascript's Number type (64 bit IEEE 754) only has about 53 bits of precision.

But, if you don't need to do any addition or multiplication, then you could keep 64-bit value as 4-character strings as JavaScript uses UTF-16.

For example, 1 could be encoded as "\u0000\u0000\u0000\u0001". This has the advantage that value comparison (==, >, &lt;) works on strings as expected. It also seems straightforward to write bit operations:

<pre><code>function and64(a,b) {
 var r = "";
 for (var i = 0; i &lt; 4; i++)
 r += String.fromCharCode(a.charCodeAt(i) &amp; b.charCodeAt(i));
 return r;
}
</code></pre>

blocks|key|360342|text|事实上，JavaScript/ECMAScript级别的精度限制为53位整数(它们存储在“双精度”8字节内存缓冲区的尾数中)。因此，将大数字作为JSON传输并不会像JavaScript客户端预期的那样进行反序列化，这会将它们截断为53位分辨率。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|360343|>+parseInt("10765432100123456789")
10765432100123458000|code-block|syntax|javascript|360344|请参见Number.MAX_SAFE_INTEGER+constant和Number.isSafeInteger()函数：|offset|length|style|CODE|360345|360346|+MAX_SAFE_INTEGER常量的值为9007199254740991。这个数字背后的原因是，JavaScript使用IEEE754中指定的双精度浮点格式的数字，并且只能安全地表示-(2%5E53+-+1)和2%5E53+-+1之间的数字。|blockquote|360347|360348|本文中的安全是指准确表示整数并正确比较它们的能力。例如，Number.MAX_SAFE_INTEGER+%2B+1+===+Number.MAX_SAFE_INTEGER+%2B+2将计算为true，这在数学上是不正确的。有关详细信息，请参阅Number.isSafeInteger()。|360349|360350|由于JavaScript中浮点数的分辨率，使用您建议的“64位浮点数”将受到完全相同的限制。|360351|我想最好的选择是像文本一样传递这样的值。它仍然是完全可读的JSON内容，并且很容易在JavaScript级别进行操作。|360352|“纯字符串”表示就是OData+specifies,+for+its+Edm.Int64+or+Edm.Decimal+types。|360353|在本例中，Twitter+API所做的是在JSON中添加一个特定的".._str":字段，如下所示：|360354|{
+++"id":+10765432100123456789,+++++++++++//+for+JSON+compliant+clients
+++"id_str":+"10765432100123456789",+++++//+for+JavaScript
++++...
}|360355|我非常喜欢这个选项，因为它仍然与支持int64的客户端兼容。在实践中，如果在HTTP级别压缩/压缩JSON中的重复内容，则不会造成太大伤害。|360356|作为字符串传输后，您可以使用诸如strint+–+a+JavaScript+library+for+string-encoded+integers之类的库来处理这些值。|360357|更新：较新版本的JavaScript引擎包括一个BigInt对象类，它能够处理超过53位的数据。事实上，它可以用于任意大的整数，因此非常适合64位整数值。但是当序列化为JSON时，BigInt的值是will+be+serialized+as+a+JSON+string+-很奇怪，但是出于兼容性的目的，我猜。|BOLD|360358|entityMap|0|LINK|mutability|MUTABLE|url|https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER|1|https://stackoverflow.com/a/16549441/458259|2|https://github.com/rauschma/strint|3|https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt|4|https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt#use_within_json^0|0|0|3|N|10|M|3|W|0|0|0|1|G|M|G|2L|B|2X|8|0|0|S|1N|2J|4|39|M|0|0|0|0|Z|9|1C|B|A|1J|1|0|X|9|0|0|0|G|1L|2|0|0|3|O|6|3|2R|Z|4|0^^$0|@$1|2|3|4|5|6|7|1R|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1S|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|1T|8|@$I|1U|J|1V|K|L]|$I|1W|J|1X|K|L]]|9|@$I|1Y|J|1Z|1|20]]|A|$]]|$1|M|3|-4|5|6|7|21|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|22|8|@$I|23|J|24|K|L]|$I|25|J|26|K|L]|$I|27|J|28|K|L]|$I|29|J|2A|K|L]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|2B|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|2C|8|@$I|2D|J|2E|K|L]|$I|2F|J|2G|K|L]|$I|2H|J|2I|K|L]]|9|@]|A|$]]|$1|T|3|-4|5|6|7|2J|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|2K|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|2L|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|2M|8|@$I|2N|J|2O|K|L]|$I|2P|J|2Q|K|L]]|9|@$I|2R|J|2S|1|2T]]|A|$]]|$1|10|3|11|5|6|7|2U|8|@$I|2V|J|2W|K|L]]|9|@]|A|$]]|$1|12|3|13|5|D|7|2X|8|@]|9|@]|A|$E|F]]|$1|14|3|15|5|6|7|2Y|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|2Z|8|@]|9|@$I|30|J|31|1|32]]|A|$]]|$1|18|3|19|5|6|7|33|8|@$I|34|J|35|K|1A]]|9|@$I|36|J|37|1|38]|$I|39|J|3A|1|3B]]|A|$]]|$1|1B|3|-4|5|6|7|3C|8|@]|9|@]|A|$]]]|1C|$1D|$5|1E|1F|1G|A|$1H|1I]]|1J|$5|1E|1F|1G|A|$1H|1K]]|1L|$5|1E|1F|1G|A|$1H|1M]]|1N|$5|1E|1F|1G|A|$1H|1O]]|1P|$5|1E|1F|1G|A|$1H|1Q]]]]

There is in fact a limitation at JavaScript/ECMAScript level of precision to 53-bit for integers (they are stored in the mantissa of a &quot;double-like&quot; 8 bytes memory buffer). So transmitting big numbers as JSON won't be unserialized as expected by the JavaScript client, which would truncate them to its 53-bit resolution.
<pre><code>&gt; parseInt(&quot;10765432100123456789&quot;)
10765432100123458000
</code></pre>
See the <a href="https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER" rel="nofollow noreferrer"><code>Number.MAX_SAFE_INTEGER</code> constant</a> and <code>Number.isSafeInteger()</code> function:
<blockquote>
The <code>MAX_SAFE_INTEGER</code> constant has a value of <code>9007199254740991</code>. The
reasoning behind that number is that JavaScript uses double-precision
floating-point format numbers as specified in IEEE 754 and can only
safely represent numbers between <code>-(2^53 - 1)</code> and <code>2^53 - 1</code>.
Safe in this context refers to the ability to represent integers
exactly and to correctly compare them. For example,
<code>Number.MAX_SAFE_INTEGER + 1 === Number.MAX_SAFE_INTEGER + 2</code> will
evaluate to <code>true</code>, which is mathematically incorrect. See
<code>Number.isSafeInteger()</code> for more information.
</blockquote>
Due to the resolution of floats in JavaScript, using &quot;64-bit floating point numbers&quot; as you proposed would suffer from the very same restriction.
IMHO the best option is to transmit such values as text. It would be still perfectly readable JSON content, and would be easy do work with at JavaScript level.
A &quot;pure string&quot; representation is what <a href="https://stackoverflow.com/a/16549441/458259">OData specifies, for its <code>Edm.Int64</code> or <code>Edm.Decimal</code> types</a>.
What the Twitter API does in this case, is to add a specific <code>&quot;.._str&quot;:</code> field in the JSON, as such:
<pre><code>{
 &quot;id&quot;: 10765432100123456789, // for JSON compliant clients
 &quot;id_str&quot;: &quot;10765432100123456789&quot;, // for JavaScript
 ...
}
</code></pre>
I like this option very much, since it would be still compatible with int64 capable clients. In practice, such duplicated content in the JSON won't hurt much, if it is deflated/gzipped at HTTP level.
Once transmitted as string, you may use libraries like <a href="https://github.com/rauschma/strint" rel="nofollow noreferrer">strint – a JavaScript library for string-encoded integers</a> to handle such values.
Update: Newer versions of JavaScript engines include a <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt" rel="nofollow noreferrer">BigInt</a> object class, which is able to handle more than 53-bit. In fact, it can be used for arbitrarily large integers, so a good fit for 64-bit integer values. But when serializing as JSON, the BigInt value <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt#use_within_json" rel="nofollow noreferrer">will be serialized as a JSON string</a> - weirdly enough, but for compatibility purposes I guess.

blocks|key|359639|text|这件事发生在我身上。当通过json将大整数发送到JSON.parse时，所有的地狱都爆发了。我花了几天的时间尝试调试。当我将值作为字符串传输时，问题立即得到了解决。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|359640|使用{+"the_sequence_number":+"20200707105904535"+}而不是{+"the_sequence_number":+20200707105904535+}|offset|length|style|CODE|359641|更糟糕的是，似乎每个JSON.parse都实现了火狐、Chrome和Opera之间的共享库，因为它们的行为都完全相同。Opera错误消息中有Chrome+URL引用，几乎就像浏览器共享的WebKit。|359642|console.log('event_listen['+%2B+global_weird_counter+%2B+']:+to+be+sure,+server+responded+with+['+%2B+aresponsetxt+%2B+']');
var+response+=+JSON.parse(aresponsetxt);
console.log('event_listen['+%2B+global_weird_counter+%2B+']:+after+json+parse:+'+%2B+JSON.stringify(response));|code-block|syntax|javascript|359643|我得到的行为是指针数学变得非常糟糕的那种东西。幽灵从我的工作站飞出来，在我的睡梦中肆意扰乱。现在我换成了string，它们都被驱散了。|359644|entityMap^0|0|2|1A|1F|18|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@$D|U|E|V|F|G]|$D|W|E|X|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|Y|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|Z|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|R|$]]

This thing happened to me. All hell broke loose when sending large integers via json into JSON.parse. I spent days trying to debug. Problem immediately solved when i transmitted the values as strings.
Use
<code>
<code>{ &quot;the_sequence_number&quot;: &quot;20200707105904535&quot; }</code>
</code>
instead of
<code>
<code>{ &quot;the_sequence_number&quot;: 20200707105904535 }</code>
</code>
To make it worse, it would seem that where every JSON.parse is implemented, is some shared lib between Firefox, Chrome and Opera because they all behaved exactly the same. Opera error messages have Chrome URL references in it, almost like WebKit shared by browsers.
<code>
<pre><code>console.log('event_listen[' + global_weird_counter + ']: to be sure, server responded with [' + aresponsetxt + ']');
var response = JSON.parse(aresponsetxt);
console.log('event_listen[' + global_weird_counter + ']: after json parse: ' + JSON.stringify(response));
</code></pre>
</code>
The behaviour i got was the sort of stuff where pointer math went horribly bad. Ghosts were flying out of my workstation wreaking havoc in my sleep. They are all exorcised now that i switched to string.

Some of my data are 64-bit integers. I would like to send these to a JavaScript program running on a page.

However, as far as I can tell, integers in most JavaScript implementations are 32-bit signed quantities.

My two options seem to be:

<ol>
<li>Send the values as strings</li>
<li>Send the values as 64-bit floating point numbers</li>
</ol>

Option (1) isn't perfect, but option (2) seems far less perfect (loss of data).

How have you handled this situation?

What is the accepted way to send 64-bit values over JSON?

数据丢失

JSON

我的一些数据是64位整数。我想把这些发送给一个在页面上运行的JavaScript程序。但是，据我所知，大多数JavaScript实现中的整数都是32位有符号数量。我的两个选择似乎是：将值作为字符串发送将值作为64位浮点数发送选项(1)并不完美，但选项(2)似乎远没有那么完美(数据丢失)。你是如何处理这种情况的？

问通过JSON发送64位值的公认方式是什么？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问通过JSON发送64位值的公认方式是什么？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问通过JSON发送64位值的公认方式是什么？
EN