我有一个JSON文件，其中包含来自Clojure的data.json库的JSON。数据来自Twitter，那里的人们似乎经常微笑。
$ cat /tmp/myfile | jq .字符串
我明白了：
parse error: Invalid \uXXXX\uXXXX surrogate pair escape at line 1, column 14862268型
违规部分是：
$ cut -c 14862258-14862269 /tmp/2017-02-23-2
79-7\ud83d",型
所以，这个转义码是在一个真实的JSON文件中找到的，JQ无法读取它。
echo '"\ud83d"' | jq .型
Fileformat.info seems to suggest它应该成对出现：
SMILING FACE WITH OPEN MOUTH
"\uD83D\uDE03"型
1.这真的是一个在JSON文件中找到的无效字符吗？我的JSON技术上无效吗？
1.有没有一个简单的实用程序可以让我在JQ之前把这些字符去掉？或者我可以让JQ放松它的解释吗？
3条答案
按热度按时间goucqfw61#
JSON specification说道：
字符串是零个或多个Unicode字符的序列[UNICODE]。
从这个意义上说，字符串“\ud83d”不是有效的JSON（"+UD83D is not a valid Unicode character"），即使它符合JSON ABNF。正如标准文档继续所说，字符串规范和ABNF之间存在差异：
本规范中的ABNF允许成员名和字符串值包含不能编码Unicode字符的位序列;例如，“\uDEAD”（单个未配对的UTF-16代理）。已经观察到了其中的许多，例如，当一个库截断一个UTF-16字符串而不检查截断是否拆分了代理项对。接收包含此类值的JSON文本的软件的行为是不可预测
所以可以这样说：
1.“\uD83D”不是严格有效的JSON，即使它符合ABNF;
“......去掉这些字符”
参见例如How to remove non UTF-8 characters from text file
p3rjfoxz2#
json绝对是有效的，但是代码单元
D83D本身是无效的。记住，jq不仅仅是解释json，它还试图获取它的值。所以一旦被jq使用，它就不再只是存储在json中的字符流，而是一个有明确值的字符串。这个值是一个高代理，它必须成对出现，而你的输入显然没有。所以在文件中编码的字符串，虽然是有效的json，但并不代表jq试图解析成的有效的unicode字符串。
如果你想使用jq解析它，你需要检查你的json并完成对。
如果你至少可以确保它是有效的json，你可能可以使用正则表达式来扫描数据以搜索不匹配的代理。类似于这样：
字符串
你要么把它们剥下来要么就能猜出失踪的代孕妈妈。
hrirmatl3#
使用yq（https://github.com/mikefarah/yq）代替，它在jq失败的大型数据集上没有解析错误。