JSON补丁RFC中的tilde转义应该如何操作？

参考：

A.14.~逃逸命令

一个示例目标JSON文档：

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

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

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

JSON修补程序文档：

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

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

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

生成的JSON文档：

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

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

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

我正在写一个RFC的实现，我被困在这上面了。这是为了达到什么目的，它应该如何工作

---

假设第一部分的答案是“允许引用包含/s的json键名”，您会怎么做？

我认为RFC中提供的示例并不是经过深思熟虑的，尤其是它试图仅通过示例来记录一个功能，这最多是模糊的，没有提供任何注释

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

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

OpenStack开始于2010年，是Rackspace Hosting和NASA的一个联合项目（…）

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

---

编辑：JSON指针似乎有单独的RFC 6901，这是可用的，上面的OpenStack和Rackspace规范与之一致。

~0

扩展到

~

所以

/~01

扩展到

/~1

我猜他们的意思是，您不应该“双重展开”，这样展开的

/~1

就不应该再次展开为

/

，因此必须与文档

“/”

键不匹配（如果双重展开就会发生这种情况）。您也不应该在源文档中展开文本，因此

“~1”

键实际上就是这样，并且不等同于展开的

“/”

。但是我重复一下这是我对这个例子的意图的猜测，真正的意图可能不同

这个例子确实很糟糕，特别是因为它使用了一个

“test”

操作，并且没有指定该操作的结果。其他例子，比如A.15的下一个例子，至少说它的测试操作必须失败，A.14没有告诉你操作是否应该成功。我想他们的意思是操作应该成功，因此这意味着

/~01

应该匹配

“~1”

键。这可能就是那个例子的全部内容

---

如果我要写一个实现，我可能不会太担心这个例子，只要看看其他实现都做了些什么——检查我是否与它们兼容。查找其他项目的测试套件也是一个好主意，例如，我在

中找到了一个，

~

字符是JSON指针中的关键字。因此，我们需要将其“编码”为

~0

。引用

如果需要引用名称中带有~或/的键，则必须分别使用~0和~1对字符进行转义。例如，要从{“foo/bar~”：“baz”}获取“baz”，您需要使用指针/foo~1bar~0

所以本质上,

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

解码时产生

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

---

我必须说，jsonpatch.com上的措辞非常不准确。它说“你必须逃跑”，而它与“逃跑”无关。这实际上是一种替代，而不是逃避。必须将

~

替换为

~0

，将

/

替换为

~1

。