问题描述
我正在将一些JSON文件导入到我的Parse.com项目中，并且不断收到错误无效键:值对".
I'm importing some JSON files into my Parse.com project, and I keep getting the error "invalid key:value pair".
它指出存在意外的"8".
It states that there is an unexpected "8".
这是我的JSON的示例:
Here's an example of my JSON:
}
"Manufacturer":"Manufacturer",
"Model":"THIS IS A STRING",
"Description":"",
"ItemNumber":"Number12345",
"UPC":083456789012,
"Cost":"$0.00",
"DealerPrice":" $0.00 ",
"MSRP":" $0.00 ",
}
如果我通过从"UPC":083456789012,中删除0或将其转换为"UPC":"083456789012",来更新JSON，则它变为有效.
If I update the JSON by either removing the 0 from "UPC":083456789012, or converting it to "UPC":"083456789012", it becomes valid.
JSON是否真的不接受以0开头的整数，还是有办法解决这个问题?
Can JSON really not accept an integer that begins with 0, or is there a way around the problem?
推荐答案
前导0表示JavaScript中的八进制数.八进制数字不能包含8；因此，该数字无效.而且，JSON不(正式地)支持八进制数字，因此，即使该数字不包含8，JSON还是正式无效.尽管如此，某些解析器确实支持它，这可能会引起一些混乱.其他解析器会将其识别为无效序列，并会引发错误，尽管他们给出的确切解释可能有所不同.
A leading 0 indicates an octal number in JavaScript. An octal number cannot contain an 8; therefore, that number is invalid.Moreover, JSON doesn't (officially) support octal numbers, so formally the JSON is invalid, even if the number would not contain an 8. Some parsers do support it though, which may lead to some confusion. Other parsers will recognize it as an invalid sequence and will throw an error, although the exact explanation they give may differ.
解决方案::如果您有数字，请不要将其与前导零一起存储.如果您的值需要以零开头，则不要将其视为数字，而应视为字符串.用引号将其存储.
Solution: If you have a number, don't ever store it with leading zeroes. If you have a value that needs to have a leading zero, don't treat it as a number, but as a string. Store it with quotes around it.
在这种情况下，您拥有一个长度为12位数字的UPC ，并且可能包含前导零.我认为最好的存储方式是字符串.
In this case, you've got a UPC which needs to be 12 digits long and may contain leading zeroes. I think the best way to store it is as a string.
但是，这值得商bat.如果将其视为条形码，则将前导0视为其不可或缺的一部分，那么字符串就有意义.其他类型的条形码甚至可以包含字母字符.
It is debatable, though. If you treat it as a barcode, seeing the leading 0 as an integral part of it, then string makes sense. Other types of barcodes can even contain alphabetic characters.
另一方面. UPC是一个数字，并且用0到12位数字左填充它的事实可以看作是显示属性.实际上，如果您通过添加一个额外的0将其左键填充到13位数字，则您将获得EAN代码，因为EAN是UPC的超集.
On the other hand. A UPC is a number, and the fact that it's left-padded with zeroes to 12 digits could be seen as a display property. Actually, if you left-pad it to 13 digits by adding an extra 0, you've got an EAN code, because EAN is a superset of UPC.
如果您有金额，则可以将其显示为€ 7.30，而将其存储为7.3，因此也可以将产品代码存储为数字.
If you have a monetary amount, you might display it as € 7.30, while you store it as 7.3, so it could also make sense to store a product code as a number.
但是，该决定取决于您.我只能建议您使用字符串，这是我个人对这些代码的偏爱，如果选择数字，则必须删除0才能使其正常工作.
But that decision is up to you. I can only advice you to use a string, which is my personal preference for these codes, and if you choose a number, then you'll have to remove the 0 to make it work.
这篇关于如果整数以前导零开头，为什么JSON无效?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！