fastfullstack.com

我这边对此专门抽取了出问题的数据和代码写了测试代码做测试，发现结果具有随机性，就是说，同样的数据和算法，调用bson.encode有时正常有时报错，我估计还是bson库本身有bug。这些encode的原数据是一个table，将table本身进行bson.encode是必然成功的，但将这个table用lua代码进行一些处理(非二进制处理)转换为字符串类型添加到一个空table里再bson.encode就会出现我上面说的随机性错误了。

这里例一下我的测试代码： ``` local t = { ["uid"] = 100040, ["msg"] = { [1] = { ["uid_from"] = 100040, ["msg"] = "#24#", ["service_time"] = 1666687149, }, [2] = { ["uid_from"] =...

大概类似这样的转换格式： ``` { ["name"] = "gate:to_client.rsp_get_last_private_msg", ["param_float"] = 1789, ["param_varchar"] = "{ [\"uid\"] = 100040, [\"msg\"] = { [1] = { [\"uid_from\"] = 100040, [\"msg\"] = \"#24#\", [\"service_time\"] = 1666687149,...

另外把另一个报错的数据的二进制格式显示出来了 

初步判断应该是我在转换函数里调用了string.sub函数进行拼接，导致完整的utf8格式被破坏了导致。

非常感谢云大的大力支持，目前问题已经解决，问题原因已经基本确定是string.sub后字节重新拼接导致打破了正常的utf8字节序。 为解决此问题重新实现了两个函数，这里列出，方便有碰到同类问题的同学参考： ``` -- 以字符为单位获取子串(区别于string.sub按字节为单位) function nnstring.sub_chat(s, i, j) i = i or 1 local ii = utf8.offset(s, i) local jj = j and (utf8.offset(s, j + 1) - 1)...

另外还有个小问题是，为啥被打破的字符串字调用for utf8.codes时不会报错，按lua官方文档说应该要报错的： ``` utf8.codes (s [, lax]) Returns values so that the construction for p, c in utf8.codes(s) do body end will iterate over all UTF-8 characters in string s,...