【发布时间】：2019-02-13 18:51:56
【问题描述】：
我有一个返回 json 的存储过程。 proc 工作正常，当我在 SSMS 中调用它时，它返回一个 json 对象，我可以单击该对象并将其视为有效的 json。当我通过 Visual Studio 调用它时，它会执行相同的操作，然后单击它并按回车很好地格式化它，因此它是可读的（而不是全部在一行上）。如果我把字符串传回 sql 函数 IsJson，它也会返回 true，所以我 100% 确信从 proc 出来的 json 是有效的。
但是，我的前端开发人员无法解析它，它似乎归结为试图在某处转换它的东西。
json（作为 proc 的输出）是：
{"APIResult":[{"ID":200,"Status_Message":"Success","Developer_Message":"D56D10AC-3A74-42FC-8BB5-F783A6C0C556 33E4F907-F1E5-4F1B-8CA5-5521291E683A 登录成功(AppID: (null)).","User_Message":"登录成功","User":[{"ID":"D56D10AC-3A74-42FC-8BB5-F783A6C0C556"}]}]}
使用 Postman 访问实时 API（或 localhost）我得到了我期望的数据（如上）但是，它将整个内容用双引号括起来并转义每个元素周围的所有双引号，所以我得到：
"{\"APIResult\":[{\"ID\":200,\"Status_Message\":\"Success\",\"Developer_Message\":\"D56D10AC-3A74-42FC-登录成功8BB5-F783A6C0C556 33E4F907-F1E5-4F1B-8CA5-5521291E683A (AppID: (null)).\",\"User_Message\":\"登录成功\",\"User\":[{\"ID\": \"D56D10AC-3A74-42FC-8BB5-F783A6C0C556\"}]}]}"
当我尝试在 sql 中解析这个（使用 isjson）时，它返回 false。但是，通过 jsonlint.com 解析相同的代码会将其解释为有效。通过我的开发人员使用 http://json.parser.online.fr 的解析器尝试它也会将其作为错误抛出。
我可以告诉我的开发人员去掉第一个和最后一个字符并将每个 \" 替换为 " 但这似乎有点古怪。
对json有不同的解释吗？我读过这通常是由于调用应用程序需要一个它需要 json-ify 的字符串，并且因为它正在获取一个 json 对象，所以它是 json-ifying json，但即使我强制 sql server 将字符串输出为字符串而不是 json，它看起来仍然一样。 SQL 肯定会正确地将其推出，但无论我的开发人员通过什么方式调用 api，都会返回与邮递员相同的格式，并且不喜欢它。如何确保调用代码得到的是 SQL 给出的而不是一些奇怪的解释？
【问题讨论】：
-
那么您有返回结果的 REST API 吗？问题可能就在那里。此外，如果您直接返回 FOR JSON 的结果，它可能会在结果集中的多行中被打破。
-
是的，我没有编写 API，但是是的。如果我直接在浏览器中调用 API，我会得到未经编辑的格式：
schemas.microsoft.com/2003/10/Serialization">{"APIResult ":[{"ID":200,"Status_Message":"Success","Developer_Message":"登录成功（ID: D56D10AC-3A74-42FC-8BB5-F783A6C0C556）。","User_Message":"登录成功", "用户":[{"ID":"D56D10AC-3A74-42FC-8BB5-F783A6C0C556"}]}]} -
听起来 API 返回的是字符串而不是原始 JSON。那是API的错。如何正确执行此操作取决于 API 使用的框架。
-
如果错误在 api 代码中，我应该从哪里开始查看？它以原始格式出现在浏览器中的事实是否表明它不存在，或者我错过了重点？
-
它不应该像这样被包装在 XML 中。并且还取决于客户端发送的
accept标头。但是对于 .NET API，请找到控制器并确保将内容类型设置为application/json并将 json 写入请求正文或使用适当的响应格式化程序。
标签： json sql-server parsing