• 关于CMD/DOS中的短文件名规则


    最近在制作一个批处理的过程中发现一个很郁闷的问题,就是有些时候搜索到的结果不是我们想要的

    比如上图,我要搜索的文件时?ec*.*,也就是说我要搜索第二个字母是e,第三个字母是c的所有文件
    而搜索到的结果前两个都正确,但是后面两个就错了,很不理解,最初以为是bat写的问题
    后来发现直接在DOS写命令也是一样的,有很多完全不符合的文件,遂百度,才知道怎么回事

    星号通配符总是使用短文件名映射,因此,您可能会得到意外的结果

     也就是说当使用*通配符后只按照短文件名搜索,而不按照原始长文件名来搜索
    我输出了下短文件名后发现果然是这样的:



    如图所示可以看到?ec*.*确实匹配的短文件名,看了命令没有执行错误。
    但是又一个问题出现了,为什么短文件名是VEXXXX~1这种形式?
    接着百度,得到以下结果:

    当创建一个长文件名文件时,系统会自动加上对应的短文件名,其一般有的原则:
    (1)、取长文件名的前 6 个字符加上"~1"形成短文件名,扩展名不变。
    (2)、如果已存在这个文件名,则符号"~"后的数字递增,直到 5。
    (3)、如果文件名中"~"后面的数字达到 5,则短文件名只使用长文件名的前两个字母。通过数学操纵长文件名的剩余字母生成短文件名的后四个字母,然后加后缀"~1"直到最后(如果有必要,或是其他数字以避免重复的文件名)。
    (4)、如果存在老 OS 或程序无法读取的字符,换以"_"


    很明显目前的状况属于第三种情况,但是后面的4位16进制数据是怎么计算得到的还是不太清楚

    网上对此解释也有很多,这里也就不再讨论,只是希望在使用过程中了解有这么个机制

    会发生结果与预期不符,而不是程序设计错误即可

    —— 原文发表于2012-3-11 08:57

  • 相关阅读:
    平台调用中的数据封送处理
    JavaScript 中的事件流
    Jquery插件 表格固定表头
    ASP.NET MVC Action Filter与内置的Filter实现
    getCurrentScript的改进
    analyze spring framework source
    Windows Azure: Service Bus Brokered Messaging DeadLetterQueue 使用详解
    C#截图
    权限系统
    音乐播放器
  • 原文地址:https://www.cnblogs.com/xxcanghai/p/4584100.html
Copyright © 2020-2023  润新知