6

Referencing https://www.rfc-editor.org/rfc/rfc6902#appendix-A.14:

A.14. ~ Escape Ordering

An example target JSON document:

{
  "/": 9,
  "~1": 10
}

A JSON Patch document:

[
  {"op": "test", "path": "/~01", "value": 10}
]

The resulting JSON document:

{
  "/": 9,
  "~1": 10
}

I'm writing an implementation of this RFC, and I'm stuck on this. What is this trying to achieve, and how is it supposed to work?

Assuming the answer to the first part is "Allowing json key names containing /s to be referenced," how would you do that?

4

3 回答 3

6

该~字符是 JSON 指针中的关键字。因此，我们需要将其“编码”为~0. 引用jsonpatch.com，

如果您需要在其名称中引用带有 ~ 或 / 的键，则必须分别使用 ~0 和 ~1 转义字符。例如，要从 { "foo/bar~": "baz" } 获取 "baz"，您可以使用指针 /foo~1bar~0

所以本质上，

[
  {"op": "test", "path": "/~01", "value": 10}
]

当解码产生

[
  {"op": "test", "path": "/~1", "value": 10}
]
于 2019-02-22T04:43:20.833 回答
2

~0扩大到~所以/~01扩大到/~1

我猜他们的意思是你不应该“双重展开”，这样展开/~1后就不应该再次展开//，因此不能与文档"/"键匹配（如果你双重展开就会发生这种情况）。您也不应该在源文档中扩展文字，因此"~1"关键就是字面上的意思，而不等同于扩展的"/". 但我再说一遍，这是我对这个例子意图的猜测，真正的意图可能不同。

这个例子确实很糟糕，特别是因为它使用了一个"test"操作并且没有指定该操作的结果。其他示例，例如 A.15 的下一个示例，至少说明其测试操作必须失败，A.14 并没有告诉您操作是否应该成功。我认为他们的意思是操作应该成功，所以这意味着/~01应该匹配"~1"密钥。这可能就是那个例子的全部内容。

如果我要编写一个实现，我可能不会太担心这个例子，只需看看其他实现做了什么——检查我是否与它们兼容。寻找其他项目的测试套件也是一个好主意，例如我从http://jsonpatch.com/在https://github.com/json-patch/json-patch-tests找到了一个

于 2014-06-26T15:54:43.410 回答
1

我认为 RFC 中提供的示例并不是经过深思熟虑的，尤其是它试图仅通过示例来记录功能，这充其量是模糊的 - 没有提供任何类型的评论。

您可能对以下文档中的解释感兴趣：

这些看起来非常相似，我认为这是由于 Rackspace 和 OpenStack 之间的关系性质：

OpenStack 始于 2010 年，是 Rackspace Hosting 和 NASA (...) 的联合项目

它实际上提供了一些有用的细节，包括它接受的语法和引入这些标记背后的基本原理，而不是 RFC 本身。

编辑：似乎 JSON 指针有单独的 RFC 6901，可在此处获得，并且上面的 OpenStack 和 Rackspace 规范与之一致。

于 2014-06-26T06:34:12.563 回答