json_decode到数组或对象

Latly I came upon a question where someone asked me, why I turn the output of json_decode into an assoc array.

Latly我遇到了一个问题,有人问我,为什么我将json_decode的输出变成一个assoc数组。

For me it's easier to use assoc arrays than stdClasses and there are already many array_* functions which support data handling after I decode the json string.

对我来说,使用关联数组比使用stdClasses更容易,并且在解码json字符串后,已经有许多array_ *函数支持数据处理。

After a short performance test it turns out, that the conversion to an assoc array is about 20% faster than the conversion to stdClass.

经过短暂的性能测试后,转换为assoc数组的转换速度比转换为stdClass快约20%。

Nevertheless, the default behavior is $assoc = false. So I wonder, were are the benefits of using stdClasses when dealing with json data. Are there any json types which can't be represented in assoc arrays, but in stdClasses?

然而,默认行为是$ assoc = false。所以我想知道,在处理json数据时使用stdClasses的好处是什么。是否有任何json类型无法在assoc数组中表示,但在stdClasses中?

2 个解决方案

#1

This might get closed as opinion based, but for me, I would typically decode to whatever data structure makes the most sense for the use case.

这可能会基于意见而被关闭,但对我来说,我通常会解码为对用例最有意义的数据结构。

For example, say the JSON described a single item like a book and looked something like this:

例如,假设JSON描述的单个项目就像一本书,看起来像这样:

{
    "title": "Cool Book",
    "author": "Amazing Author",
    "publisher": "Evil Corporation",
    ...
}

To me that is an object, in that it is a single item with different properties. I would be likely to want to treat it like an object in my subsequent code, so I would decode it as an object.

对我来说,这是一个对象,因为它是一个具有不同属性的单个项目。我可能希望将它视为后续代码中的对象,因此我将其解码为对象。

Now if the JSON contained the sort of data that may represent a dictionary, map, hash table, etc. sort of structure, where all the key-value pairs were, in essence, similar items, just with different lookups and mapped values, I might consider decoding to an associative array. Maybe a good example of that would be a country code to country name map like this:

现在,如果JSON包含可能代表字典,映射,散列表等结构的数据类型,其中所有键值对本质上是相似的项目,只是具有不同的查找和映射值,I可能会考虑解码为关联数组。也许一个很好的例子是国家/地区名称映射的国家/地区代码,如下所示:

{
    "AF": "Afghanistan",
    "AX": "Aland Islands",
    "AL": "Albania",
    "DZ": "Algeria",
    ...
}

I might be inclined to decode this to an associative array, because I don't need any object-oriented representation of this information, since I am just using this for key-value lookups.

我可能倾向于将其解码为关联数组,因为我不需要任何面向对象的此信息表示,因为我只是将其用于键值查找。

To answer your question about other data structures that can be represented in JSON, officially there are only two data structures supported in JSON - objects and numerically-indexed arrays. This is because of the javascript-based roots of the serialization format, where, for example, the concept of an "out-of-the-box" associative array doesn't exist.

要回答有关可以用JSON表示的其他数据结构的问题,正式情况下,JSON中只支持两种数据结构 - 对象和数字索引数组。这是因为序列化格式的基于javascript的根,例如,“开箱即用”关联数组的概念不存在。

You will however find that a number of JSON encoding/decoding libraries across languages do add support for other data structures or types, typically adding handling behavior around primitive data types, but I would not rely on this unless you fully understand the data structures that are going to be passed and how they are going to be encoded/decoded across all applications that might pass the data around.

然而,您会发现跨语言的许多JSON编码/解码库确实增加了对其他数据结构或类型的支持,通常会在原始数据类型周围添加处理行为,但除非您完全理解数据结构,否则我不会依赖它。将要传递以及如何在可能传递数据的所有应用程序中对它们进行编码/解码。

For example, PHP provides support for certain primitives as shown in this note from the json_encode() documentation:

例如,PHP提供了对某些原语的支持,如json_encode()文档中的本说明所示:

Note: Like the reference JSON encoder, json_encode() will generate JSON that is a simple value (that is, neither an object nor an array) if given a string, integer, float or boolean as an input value. While most decoders will accept these values as valid JSON, some may not, as the specification is ambiguous on this point. To summarise, always test that your JSON decoder can handle the output you generate from json_encode().

注意:与引用JSON编码器一样,如果给定字符串,整数,浮点或布尔值作为输入值,json_encode()将生成一个简单值(即,既不是对象也不是数组)的JSON。虽然大多数解码器都会接受这些值作为有效的JSON,但有些可能不会,因为规范在这一点上是模棱两可的。总而言之,始终测试您的JSON解码器可以处理您从json_encode()生成的输出。

Finally, with regards to performance, if you get to the point in your application development where the number one concern is optimizing performance for execution time, memory utilization, etc. and you have reason to believe that relatively substantial gains can be made by optimizing the JSON deserialization (and subsequent data access) logic, then you should ultimately test your application with representative data and see what works best for you. My guess is that this would be along the lines of a micro-optimization for most applications.

最后,关于性能,如果你在应用程序开发中达到了重点,那么首要关注的是优化执行时间,内存利用率等性能,你有理由相信通过优化它可以获得相对可观的收益。 JSON反序列化(以及后续数据访问)逻辑,那么您应该最终使用代表性数据测试您的应用程序,看看什么最适合您。我的猜测是,这将是大多数应用程序的微优化。

#2

I think the reason is, that JSON is "JavaScript Object Notation" and therefore people expect an object. If you look at json.org the an object is defined as an unordered set of name/value pairs and an array is for ordered collections of values, like people are used to it in javascript. This can also be found in the RFC 4627:

我认为原因是,JSON是“JavaScript Object Notation”,因此人们期待一个对象。如果你看一下json.org,一个对象被定义为一组无序的名称/值对,一个数组用于有序的值集合,就像人们在javascript中习惯它一样。这也可以在RFC 4627中找到:

The terms "object" and "array" come from the conventions of JavaScript.

术语“对象”和“数组”来自JavaScript的约定。

#1