问题描述:官方手册阅读:
8.3命名格式:8.3格式通常指较旧的Windows操作系统或DOS的文件命名格式 “8”是指文件名或目录名的主体部分小于等于8个字节; “3”是指文件名的扩展名部分小于等于3个字节; 8.3文件名的有效字符不包括空格等特殊字符 若不符合以上限制则会以"~"作延长名称如"ProgramFiles"会变成"Progra~1" 若同一文件夹有相似的名称,末端的数值则会自动递增 8.3短文件名格式规范是DOS+FAT12/FAT16时代遗留下的老规矩 自从Windows95开始(其实据说从Windowsfor Groups 3.11开始), Windows就已经能支持长文件名,但是为了向前兼容,特别是文件系统兼容性, FAT文件系统均强制执行“为长文件名提供8.3兼容格式的短文件名”的特性。 因此你会看到,在FAT16/32文件系统上: 目录"programfiles"同时还拥有一个8.3规范的"PROGRA~1"短名称; 而文件"元素周期表.exe"也同时拥有一个"元素周~1.exe"的短名称。 [这有一点像类UNIX系统下的hardlink,一个对象拥有两个引用方式。] 结合filex官方手册、8.3命名格式的说明以及问题的现象,可以确定问题是因为8.3命名所造成的! 如何获取长文件名: 根据上述可知,我们获取到的中文名称是8.3格式的短文件名,而我们实际要使用的是完整的长文件名,那么如何获取到长文件名呢? 仿真: 根据经验,这种问题一般在仿真时查看关键变量或者内存数据变化,能够找到线索。 在触发filex+usbx查找U盘中指定目录存在的文件时,逐步仿真,发现对于有中文名字的文件和纯英文名字的文件,在名字信息上有所差异: 可以看到包含中文的文件名要比纯英文的文件名信息多了2行,除了包含1行短文件名之外,还有2行信息。 资料查找与对比: 这多出来的2行数据,结合“007@缝纫测试图”的unicode码和filex 的unicode格式分析来看,两者是对应的: 获取长文件名API: 在filex官方手册pdf中全局搜索“unicode”,找到可能适合的API函数: API实际测试: 在获取到文件名称后,使用fx_unicode_name_get 获取长文件名,仿真查看在获取到的具体内容(以007@缝纫侧视图.JED为测试目标): 其中file_name中存放短文件名,unicode_name中存放长文件名: 可以看到此API可以正确读出文件的长文件名!!! 总结: 遇到此类问题要先阅读官方手册,找到线索后可以辅助仿真进一步排查。
|