英文:
Debug Inspector showing strange characters?
问题
我第一次接触Go语言，并且终于在我的Win10机器上成功运行了。在IntelliJ IDEA中，我终于让断点正常工作了，但是在我的调试器窗口中看到了这样的内容。那些一团乱码的字符实际上应该是来自MongoDB的一个由24个字符组成的十六进制ID。
我猜测这可能是mgo没有正确地反序列化ObjectId对象的问题，但是这似乎对于运行Linux或macOS的开发人员来说并不是一个问题，所以也许这只是一个Windows的问题？
如果有任何意见，我将不胜感激！
英文:
I'm just getting into Go for the first time and finally got things running on my Win10 machine. Finally got breakpoints working inside of IntelliJ IDEA, and I'm seeing stuff like this in my debugger window. Those messes of unicode chars should actually be a 24-char HEX id that's coming from MongoDB.
My best guess is that this is a problem with mgo not properly unmarshalling ObjectId objects, but this doesn't seem to be a problem for any of the devs running linux or macOS, so maybe it's just a Windows thing?
Any input would be appreciated!
答案1
得分: 1
这里没有错误。bson.ObjectId 的底层类型是 string：
type ObjectId string
但它用于存储12个“任意”的字节（“任意”意味着它不是用符文解释的，也不是有效的UTF-8编码序列）。通常使用其字节的十六进制表示来显示给人类。
调试器不会使用这种便利性。它们看到它是一个 string，所以尝试将其显示为 string（尽管它不是用来这样做的）。这不仅仅是 Windows 的问题，Atom 编辑器与 delve 调试器在 Linux 上也是如此。不用担心。
如果你打印一个 ObjectId，通常会使用 fmt 包的 String() 方法来获取要显示的 string 值。调试器不一定这样做。
英文:
No error here. bson.ObjectId has an underlying type of string:
type ObjectId string
But it is used to store 12 "arbitrary" bytes ("arbitrary" means it is not meant to be interpreted by runes, and it's not a valid UTF-8 encoded sequence). It is usually displayed using the hex representation of its bytes, for humans.
Debuggers don't take that convenience. They see it's a string, so they attempt to display it as a string (even though it's not meant to). This is not a Windows-only thing, the Atom editor with the delve debugger does the same on Linux too. Nothing to worry about.
If you print an ObjectId, it's usually the fmt package's "thing" to use its String() method to acquire the string value to be displayed. Debuggers do not necessarily do that.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论