根据过去使用的语言，我经历过相同字符串的不同 JSON 编码值。由于 API 是在封闭环境中使用的（不允许第 3 方），我们做出了妥协，我们所有的 Java 应用程序都是手动编码 Unicode 字符。LinkedIn 的 API 返回“损坏”的值，与我们的 Java 应用程序基本相同。我已经在他们的论坛上发布了一个问题，我在这里问的原因也很简单；分享是关怀 :) 因此，这个问题与 LinkedIn 有部分联系，但主要是试图找到下面描述的一般编码问题的答案。
如您所见，我的姓氏包含一个字母ž，应该是\u017eJava（或 LinkedIn 的 API）返回\u009eJSON 而没有返回 XML 响应。PHPjson_decode()忽略了它，我的姓变成了 Kurida。
U+009E 是一个通常不可见的控制字符，不是可接受的替代表示ž。
字节0x9E 表示 Windows 代码页 1252 中的字符。如果使用 ISO-8859-1 解码，该ž字节将变成 U+009E。
（混淆来自这样一个事实，如果你ž在 HTML 页面中编写，浏览器实际上并没有像你预期的那样给你字符 U+009E，而是将它转换为 U+017E。所有字符都是如此引用 0080–009F：它们被更改，就好像数字引用 cp1252 字节而不是 Unicode 字符。这是完全奇怪和错误的行为，但所有主要浏览器都这样做，所以我们现在坚持它。除了在正确的 XHTML 服务中作为 XML，因为它必须遵循更明智的 XML 规则。）
查看论坛页面，JSON 读取显然没有错：您的名字注册为“David Kurid[U+009E]a”。然而，这些数据已经进入他们的系统需要查看。