提出新标准：JSON ++ [英] proposed new standard: JSON++
问题描述
http://htmatters.net/htm /1 / 2005/07/evaling-JSON.cfm
这或多或少都是为了回应克罗克福德先生的劝告几句
个月前，如果你必须的话，叉子。具有讽刺意味的是，尽管在那个usenet
帖子中他称之为脆弱，他自己的Javascript JSON
解析器不是有效的JSON，而是符合我的提议变种
JSON上
!!将标识符预先添加到JSON块的前面，
和函数文字作为值：请参阅
http://www.crockford.com/JSON/json.js
出于对克罗克福德先生的尊重我的原创想法非常出色，我建议将这个新标准称为JSON ++。我的主要动机之一是
帮助基于JSON的技术获得更多的牵引力; XML已经确定为数据格式，所以我相信添加声明性功能可以使得
JSON更有价值。
G Matthew J写道：http://htmatters.net/htm/1/2005/07/evaling-JSON.cfm
这或多或少都是回应几个月前，克罗克福德先生的劝告，如果你必须的话，就岔开。具有讽刺意味的是，虽然在那个usenet
帖子中他称之为脆弱，他自己的Javascript JSON
解析器不是有效的JSON，而是符合我在JSON上提出的变体！ ！将标识符添加到JSON块的前面，
和函数文字作为值：请参阅
http://www.crockford.com/JSON/json.js
出于对Crockford先生杰出的原创想法的尊重，我建议将这个新标准称为JSON ++。我的主要动机之一是帮助基于JSON的技术获得更多的牵引力; XML已经成为一种数据格式，所以我相信添加声明性功能可以使JSON更有价值。
我明白你是什么说，但我不同意忽略标识符。
相当于数组容器的标准化标识符似乎是最有用的，因为最小的修改标识符很容易
被其他语言转换（或忽略，看起来合适），JSON
可以说总是评估为可预测的东西。
另一个选项可能是将它包装在一个函数调用中，以避免在加载多个JSON对象时命名
冲突。
ie
JSON（
// JSON文字
）
这看起来最便携，可重复使用，绕过eval （）
问题。它确实需要稍微远离JSON，但我认为它的纯度会带来回报的可用性。
< blockquote>
Matthew J写道：
http://htmatters.net/htm/1/2005/07/evaling-JSON.cfm
这或多或少都是回应几个月前，克罗克福德先生的劝告，如果你必须的话，就岔开。具有讽刺意味的是，虽然在那个usenet
帖子中他称之为脆弱，他自己的Javascript JSON
解析器不是有效的JSON，而是符合我在JSON上提出的变体！ ！将标识符添加到JSON块的前面，
和函数文字作为值：请参阅
http://www.crockford.com/JSON/json.js
现在你在提议这个功能可以用纯JSON ++声明吗？那点
，我们不是要离开数据交换的领域而是进入......语言特定的编程领域吗？
JS中有用的功能不适用于VBS，PERL，Python以及许多其他
语言。数据交换格式是一回事，但是如果你是在讨论实际传递函数的话，那么收件人
必须有一个完整的JS解析器+转换成原生的
语言，或者是一个解析器+编译器，它将提供
JS功能的接口。然后我们进入了安全问题，因为基本上，
你正在下载相当于任意代码的内容。
I只是觉得有趣的是，Crockford先生选择将一个
函数文字作为其JSON
解析器的对象文字中的值来分配，而这对于JSON本身来说是非法的。我同意
期望各种服务器端语言解析Javascript函数
文字是不现实的。
但是，大多数这样的语言已经处理了正则表达式，并且只需要很少的努力就可以将Javascript常规转换为通过JSON传递给自己的正则表达式的常规
表达式文字
格式。我认为它有巨大的力量。
***通过开发人员指南 http发送：//www.developersdex.com ***
http://htmatters.net/htm/1/2005/07/evaling-JSON.cfm
This is more or less in response to Mr Crockford''s admonition a few
months ago, "fork if you must". Ironically, although in that usenet
post he calls what I am suggesting "brittle", his own Javascript JSON
parser is not valid JSON, but rather conforms to my proposed variation
on JSON!! With an identifier prepended to the front of the JSON block,
and function literals as values: see
http://www.crockford.com/JSON/json.js
Out of deference to Mr Crockford''s outstanding original idea, I propose
this new standard be called JSON++. One of my key motivations is to
help a JSON-based technology to get more traction; XML is entrenched as
a data format so I believe adding declarative capabilities could make
JSON more valuable.
G Matthew J wrote:http://htmatters.net/htm/1/2005/07/evaling-JSON.cfm
This is more or less in response to Mr Crockford''s admonition a few
months ago, "fork if you must". Ironically, although in that usenet
post he calls what I am suggesting "brittle", his own Javascript JSON
parser is not valid JSON, but rather conforms to my proposed variation
on JSON!! With an identifier prepended to the front of the JSON block,
and function literals as values: see
http://www.crockford.com/JSON/json.js
Out of deference to Mr Crockford''s outstanding original idea, I propose
this new standard be called JSON++. One of my key motivations is to
help a JSON-based technology to get more traction; XML is entrenched as
a data format so I believe adding declarative capabilities could make
JSON more valuable.
I see what you''re saying, but I disagree about ignoring the identifier.
A standardized identifier amounting to an array container would seem
most useful, as with minimal modification the identifier could easily
be converted (or ignored, as seen fit) by other languages, and the JSON
could be said to always evaluate to a predictable thing.
Another option might be wrapping it in a function call to avoid naming
conflicts as multiple JSON objects are loaded.
i.e.
JSON(
// JSON literals
)
This seems most portable and reuseable, and gets around the eval()
issue. It does take a slight bit away from JSON, but I think what it
takes away in purity it gives back in useability.
Matthew J wrote:http://htmatters.net/htm/1/2005/07/evaling-JSON.cfm
This is more or less in response to Mr Crockford''s admonition a few
months ago, "fork if you must". Ironically, although in that usenet
post he calls what I am suggesting "brittle", his own Javascript JSON
parser is not valid JSON, but rather conforms to my proposed variation
on JSON!! With an identifier prepended to the front of the JSON block,
and function literals as values: see
http://www.crockford.com/JSON/json.js
Now are you proposing that functions be declarable by pure JSON++? At
that point, aren''t we leaving the realm of data interchange and
entering the realm of... well, language-specific programming?
What works in JS won''t work in VBS, PERL, Python, and many, many other
languages. A data interchange format is one thing, but if you''re
talking about actually passing functions around then the recipient
would have to have a full JS parser + translate into the native
language, or a parser + compiler that would provide an interface to the
JS functionality. Then we''re into security issues because essentially,
you''re downloading what amounts to arbitrary code.
I merely find it interesting that Mr Crockford chooses to assign a
function literal as a value within an object literal for his JSON
parser, whereas this is illegal with JSON itself. I agree that to
expect various server side languages to parse Javascript function
literals is unrealistic.
However, most such languages already process regular expressions, and
with little effort they may be able to convert a Javascript regular
expression literal, passed via JSON, to their own regular expression
format. I think there is tremendous power in that.
*** Sent via Developersdex http://www.developersdex.com ***
这篇关于提出新标准：JSON ++的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
