我正在使用Google Apps脚本按我的云端硬盘帐户中的名称查找文件。我在查找名称包含下划线的文件时遇到问题。
例如,我有一个文件名为FB_51.pdf
此代码不会检索文件
folder.searchFiles('title contains "51"');
此代码不会检索文件
folder.searchFiles('title contains "_51"');
但是此代码检索文件
folder.searchFiles('title contains "FB_51"');
我只想检索两位数字为“ 51”的文件。
答案 0 :(得分:2)
不幸的是,我相信从Google的角度来看,您实际上认为的是“设计错误”。 Apps Script doc on searching和page that doc links to都没有提到这一点,但是我在API docs page for search syntax的脚注下找到了答案:
contains运算符仅对名称执行前缀匹配。例如,名称“ HelloWorld”将与名称包含“ Hello”但名称不包含“ World”匹配。
对我来说,这似乎是很确定的,但是可以肯定的是,我对您的示例进行了测试:
在这种情况下,Google将下划线视为普通字符,而不是定界符或单词边界,因此“ FB_51”被视为一个单词,而不是“ FB”和“ 51”,因此只能与一个完全匹配的单词或一个前缀匹配(根据我上面的警告)。
除了将文件强制为适合搜索语法的格式(例如,交换为51_FB.pdf
)之外,或者如果文件始终与该语法匹配,则始终以FB_
作为搜索词的前缀,非常有限。最好的选择是将搜索的开始范围限制在尽可能小的位置,例如特定的Drive文件夹,然后获取所有文件,遍历它们,然后使用Regex匹配文件名。示例脚本:
function findNumberedPdf(folderId, number) {
var folder = DriveApp.getFolderById(folderId);
var files = folder.searchFiles("mimeType contains 'pdf'");
while (files.hasNext()) {
var file = files.next();
var regPattern = new RegExp(number);
if (regPattern.test(file.getName())) {
return file;
}
}
return false;
}
/**
* Test:
* Logger.log(findNumberedPdf('0CdI2-...', 51).getName());
* >> "FB_51.pdf"
*/
当然,如果您的文件确实确实总是以FB_
开头,那么您也可以只创建一个包装函数,以始终在搜索前添加该字符串。
之所以这么做是因为“设计”,而Google似乎关心单词边界和标记化是因为字符串匹配是如何工作的。通常,当我们搜索某些内容时,我们希望搜索查询中的每个标记都匹配一个完整的单词(或类似单词)。如果搜索无法通过这种方式进行,则搜索“ 51”可能会拉出“ fileA-v5251989.jpg”之类的文件,或者搜索“ cat”将匹配“乘法”和“修改”。
答案 1 :(得分:0)
Google的“设计使然”结果是,如果您或任何人在文件名中添加下划线,则会为您和其他用户“难以搜索”该文件(例如在GSuite中)。
依赖Google云端硬盘功能存储与法规遵从性相关的文档并且希望审计人员搜索文件(可能有时使用文件名)的企业因此陷入“不太可能遵从”的情况。员工可以通过添加下划线来意外或有意破坏业务流程。只需将下划线添加到文件名,用户就可以破坏/执行与GDrive API集成并且依赖单个完全匹配的文件名搜索的应用系统。由于Google持续不愿更新庞然大物代码存储库的旧部分而导致的一系列问题(注意:改写在Google Drive平台上工作的Google员工)。
这也许是世界各国政府认为Google不适合其云服务需求的原因之一吗?
审计员的解决方案是在搜索字符串中用空格或连字符替换任何下划线,然后也许从结果列表中找出正确的匹配项。