【问题标题】:Validate a character as a file path?将字符验证为文件路径?
【发布时间】:2011-12-08 09:44:31
【问题描述】:

确定字符是否为有效文件路径的最佳方法是什么?所以CheckFilePath( "my*file.csv") 会返回FALSE(在windows * 是无效字符),而CheckFilePath( "c:\\users\\blabla\\desktop\\myfile.csv" ) 会返回TRUE

请注意,文件路径可以有效但不存在于磁盘上。

【问题讨论】:

  • 好吧,如果你能找到一个 Perl 兼容的正则表达式(参见 ?regexp,它只匹配有效的 Windows 路径,那么你可以使用 grepl(regular_exp, filename) 来测试 filename 的有效性。但是构建这样的正则表达式可能比您想象的要难。例如,请参阅此 SO 问题stackoverflow.com/questions/537772/… 的公认答案。
  • 是的...这是 DIY 答案 =) 希望有人已经解决了这个问题

标签: r


【解决方案1】:

我建议尝试checkmate 包提供的checkPathForOutput 功能。如链接文档中所述,功能:

检查[s]文件路径是否可以安全地用于创建文件并写入文件。

示例

checkmate::checkPathForOutput(x = tempfile(pattern = "sample_test_file", fileext = ".tmp"))
# [1] TRUE
checkmate::checkPathForOutput(x = "c:\\users\\blabla\\desktop\\myfile.csv")
# [1] TRUE

路径无效

\0 字符不应在 Linux 中使用1 文件名:

checkmate::check_path_for_output("my\0file.csv")
# Error: nul character not allowed (line 1)

1 未在 Windows 上测试,但查看 checkmate::check_path_for_output 的代码表明该功能也应在 MS Windows 系统上正常工作。

【讨论】:

    【解决方案2】:

    这是save 用来执行该功能的代码:

     ....
     else file(file, "wb")
                on.exit(close(con))
            }
            else if (inherits(file, "connection")) 
                con <- file
            else stop("bad file argument")
     ......
    

    【讨论】:

    • 酷!我可以将其重新用于检查有效文件路径的函数。谢谢!
    • ...在检查它不存在之后,也许?
    • 这正是我的想法。不幸的是,如果它不存在,那么 file(...) 调用将创建该文件,这不是本意。我没有看到任何解决方法??
    • 另外,如果路径中的目录不存在但实际上文件路径有效,则 file(...) 会引发错误。这是一个较小的问题,可以称为有效文件路径检查功能的“功能”
    • file.exists() 似乎适合测试。
    【解决方案3】:

    不,没有办法(可靠地)这样做。我在 Windows 和 Linux 中都没有看到操作系统接口来测试这个。您通常会尝试创建文件并获得失败消息,或者尝试读取文件并获得“不存在”类型的消息。

    因此,您应该依靠操作系统来告知您是否可以对文件执行您想要执行的操作(通常是读取和/或写入)。

    我想不出除了测验(“输入有效的完全限定的 Windows 文件路径:”)之外的其他原因。

    【讨论】:

    • 谢谢。预先检查函数参数并在参数格式错误时向用户提供友好的错误消息是一种很好的做法。想象一个带有 filePath 参数的函数,它执行一些文件写入操作。最好检测无效的文件路径和向用户发送的消息,而不是尝试捕获/解析操作系统消息或简单地让用户直接处理操作系统错误。操作系统错误很可能会很糟糕。
    • 另请注意,我的函数可能会调用另一个执行文件写入的函数。第二个函数可能不是直接写入文件(即 ODBC)。最好提前防止错误。
    • 我完全不同意。在 .Net 中对此进行谷歌搜索会引发大量争论,解决方案依赖于捕获异常等。如果您使用的“解决方案”有任何错误的 肯定 案例,您将阻止用户创建他们合法可以创建的东西,因此惹恼了他们。如果它有任何错误的否定情况,当你去读取或写入文件时,你仍然必须处理操作系统错误,这会让你很烦恼。
    • 那么我们同意不同意 =) .net 中的解决方案并不复杂(它就像 5-10 行代码)。它不会允许误报或误报(这就是您的单元测试的目的)。如果你确实遇到了,这意味着你的用户已经非常努力地破坏你的程序(比如反编译?)。我不相信针对解决极端情况进行优化的软件。我相信优化用户体验。最好的用户体验和减少挫折感的途径是通过尽可能地检测上游错误来帮助用户避免错误。
    • 由于长度限制或字符限制,某些文件路径仅在某些文件系统类型上有效。对纯字符串的任何测试都不会参考文件系统。 .net 解决方案是否需要路径和文件系统类型?
    【解决方案4】:

    也许file.exists() 是你所追求的?从帮助页面:

    file.exists returns a logical vector indicating whether the files named by its argument exist.
    (Here ‘exists’ is in the sense of the system's stat call: a file will be reported as existing only
    if you have the permissions needed by stat. Existence can also be checked by file.access, which
    might use different permissions and so obtain a different result. 
    

    还提供了一些其他用于访问计算机文件系统的功能,在帮助页面上也有参考。

    【讨论】:

    • 不完全。这确定文件是否存在。我正在寻找有效的文件路径。文件路径可以有效但不存在(即您打算写入文件)。更新了原始帖子以反映这一点
    • 为什么 CheckFilePath( "&&&(&(&" ) 会返回 FALSE?这是一个完全有效的文件路径。您可以使用该名称创建文件。我认为操作系统没有这样的接口但是测试有效性 - 通常你只是尝试创建它或阅读它然后得到一个错误。
    • Spacedman - 我将原始帖子更新为 Windows 上的无效文件路径。我不确定什么是“正常”,我认为平台有不同的处理方式。在 .net 中,您可以在尝试写入文件之前检查有效的文件路径
    • 那个 .Net API 调用的文档在哪里?
    猜你喜欢
    • 2012-10-08
    • 1970-01-01
    • 1970-01-01
    • 2021-12-25
    • 1970-01-01
    • 1970-01-01
    • 2020-04-14
    • 2021-09-07
    • 1970-01-01
    相关资源
    最近更新 更多