Interweb对这一点没有帮助。我们正在使用" serializeJSON"在ColdFusion中对数据进行编码，并尝试使用" json_decode"在PHP中对其进行解码。在大多数情况下，这可以正常工作，但在某些情况下，json_decode返回NULL。我们一直在寻找明显的罪魁祸首，但是serializeJSON似乎正在按预期方式格式化。还有什么可能是问题？

更新：几个人(明智地)要求我发布导致问题的输出。我会的，除了我们刚刚发现结果集就是我们所有的数据(列出2300多个租赁属性的信息，共565,135个ASCII字符)！这可能是个问题，尽管我在PHP文档中没有看到有关字符串最大大小的任何信息。那里的限制因素是什么？内存？

更新二：看起来问题在于我们的几个用户复制并粘贴了带有"智能"引号的Microsoft Word文本。那些讨厌的用户...

解决方案

我们可以可靠地复制此问题吗？如果可以，我们是否可以发布返回null的样本数据？我确定我们知道这一点，但是出于参考目的，RFC 4627描述了JSON，这是一个常见的错误，认为有效的JavaScript是有效的JSON。最好将JSON视为javascript的子集。

响应编辑：

我建议我们检查以确保在PHP脚本中填充了信息(在将其传递给json_decode之前)，并验证了该信息(尤其是如果我们可以可靠地重现该错误)。为了方便起见，我们可以尝试使用在线验证器。基于非常有限的信息，听起来好像正在超时并且没有获取所有数据？是否需要这么大的数据集？

我们可以尝试使用另一个解析器对其进行解析，然后查找错误-我知道Python的JSON解析器的质量很高。如果我们安装了Python，则可以很容易地通过demjson的语法检查器运行文本。如果它是一个非常大的数据集，则可以使用我的库jsonlib-内存使用量将高于demjson，但由于它是用C编写的，因此运行速度更快。

我们可以尝试在UTF-8中运行，也可以让PHP知道这一事实。

PHP的json_decode无法解码UTF-8 JSON字符串(除了卷曲引号以外，还有一些"奇怪"字符)，我遇到了问题。我的解决方案是通过在正在提交到PHP的HTML页面中插入Content-Type元标记来暗示PHP我正在UTF-8模式下工作。这样，提交数据的内容类型(即JSON字符串)也将为UTF-8：

<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>

之后，PHP的json_decode能够正确解码该字符串。

我遇到了这个确切的问题，事实证明这是由于ColdFusion没有将可打印的字符放到JSON数据包中(这些字符实际上确实存在于我们的数据中)，但它们无法进入JSON。

这个站点上有两个问题为我解决了这个问题，尽管我选择了PHP解决方案而不是ColdFusion解决方案，因为我认为这是两者中比较优雅的一种。

PHP解决方案

在将字符串传递给json_decode()之前先对其进行修复

$string = preg_replace('/[\x00-\x1F\x80-\xFF]/', '', $string);

ColdFusion解决方案

在使用serializeJSON()之后，在那个SO问题中使用cleanXmlString()函数