我对MongoDB有一个特殊的问题,当我尝试对数据库进行查询时,例如db.departments.find({"key": "MEL 301"
}),没有找到结果。
我目前正在使用mLab来托管我的MongoDB数据库,因此有一种方法可以直观地查看集合中的文档。当我找到具有密钥MEL 301
的文档时,我将MEL 301
复制并粘贴到上面查询中的相应位置,然后查询成功并找到该文档。为了澄清,只有当我将数据库中的键值复制/粘贴到查询中而不是将其键入时,查询才会起作用。
您可以使用此shell命令测试数据库(用户名为stack
,密码为overflow
):mongo ds015335.mlab.com:15335/utcourses -u stack -p overflow
在测试了一些关键值后,不仅仅是MEL 301
,您可能会发现类似这样的内容 - 第一个查询是我输入MEL 301
的位置,第二个查询是我复制/粘贴值的位置来自数据库本身。
答案 0 :(得分:0)
正如评论中所指出的那样,当你将每个转换为十六进制时,这里是输出:
复制和粘贴:4d 45 4c a0 33 30 31
(关注a0
此处,这是问题所在)
无需复制和粘贴:4d 45 4c 20 33 30 31
(每当您点击键盘上的空格键时都会20
)
20
是您点击计算机空格键时获得的实际空白字符(您可以从this table看到20
十六进制值解析为符号{{1} })。
space
很棘手。它实际上是non-breaking space,不与a0
符号相同,实际上并没有ASCII代码。 这就是为什么当您输入space
时,您正在点击键盘上的空格键并输入解析为空格的MEL 301
十六进制,但&#34 ;空间"文档内部存储为不间断的空间。
问题是您的值为20
+非空格字符+ MEL
。
这是301
的编码表(来自上述非破坏性空间链接):
当数据导入数据库时,数据的原始编码似乎存在问题。
答案 1 :(得分:0)
感谢所有评论过的人 - 它确实是一个编码错误。我决定制作一个小实用程序函数来解决这个问题。不间断的空间将转换为常规空间,并在MongoDB和mLab上进行测试和处理。
exports.fixSpace = function(string) {
var fixed = '';
for (var i = 0; i < string.length; i++) {
string.charCodeAt(i) === 160 ? fixed += ' ' : fixed += string[i];
}
return fixed;
}