-
-
kernel32.CopyFileA不调用kernel32.CopyFileExA，而是调用kernel32.CopyFileExW。但如果直接调用kernel32.CopyFileExA, 还是可用的，会转kernel32.CopyFileExW
-
发表于: 2024-7-4 10:49
-
kernel32.CopyFileA不调用kernel32.CopyFileExA，而是调用kernel32.CopyFileExW。但如果直接调用kernel32.CopyFileExA, 还是可用的，会转kernel32.CopyFileExW
2024-7-4 10:49
|
|
|---|---|
|
|
“CopyFileA试验不能拷贝中文名的文件，也可认为过时了” 能说出这种话，你对编码的认知太片面了，你不懂A和W的区别 我直接调用 API 试过了（并非语言里包装好的函数），并不存在你说的问题
|
|
|
①你的文件没写路径②开发工具帮你做了转换。你如果直接在内存里以二进制填上“C:\Users\Hp\Desktop\原文件.txt”，拷贝到“C:\Users\Hp\Desktop\新文件.txt”，就不行。
最后于 2024-7-4 14:22
被ＰＥＤＩＹ编辑
，原因：
|
|
|
|
|
|
我很谦虚的，是试了不行，用CopyFileW就成功了，用CopyFileA就失败了。
最后于 2024-7-4 16:50
被ＰＥＤＩＹ编辑
，原因：
|
|
|
新鲜测试，WIN10 19044， 完全没问题 ！ 你成功浪费我2分钟。 auto a = GetProcAddress(GetModuleHandleA("kernel32.dll"), "CopyFileA"); ((decltype (&CopyFileA))a)("o:\\放我就芬兰的个人.txt", "o:\\放我就芬兰的个人222222.txt", FALSE); |
|
|
２分钟算啥，以上总结耗费我２０小时劳动成果呢
最后于 2024-7-4 16:52
被ＰＥＤＩＹ编辑
，原因：
|
|
|
有啥成功，x64dbg附加上去，一分钟就知道结果了。 你自己得出错误结论还出来误导人 |
|
|
好吧，态度不错，但你把这个当经验发在这里会误导别人的 CopyFileA 是针对 ANSI 字符集的，对于中文来说，处理 GBK 编码是没有问题的，所以文件名得用 GBK 编码，这跟带不带路径没有关系，你拿它来处理 UniCode 字符集的中文肯定是不会成功的 |
|
|
我用的工具的锅，我用它的功能直接在内存中输入ASCII版字符串，参数1是C:\Users\Hp\Desktop\原文件.txt，参数2是C:\Users\Hp\Desktop\新文件.txt，输入完显示正常，但转到内存视图看，无论用ASCII格式显示，还是用UTF-16显示，还是用UTF-8显示，前面的英文都正确，但到了“原文件”这个中文词就乱码了，push参数时用这两个地址调用CopyFileA就是失败。但是如果用这个工具输入Unicode版的参数1和参数2，push参数时用这两个地址调用CopyFileW，就是成功。这导致我结论错误，我这就把帖子“CopyFileA试验不能拷贝中文名的文件”删除
最后于 2024-7-4 17:41
被ＰＥＤＩＹ编辑
，原因：
|
|
|
我用的工具的锅，我用它的功能直接在内存中输入ASCII版字符串，参数1是C:\Users\Hp\Desktop\原文件.txt，参数2是C:\Users\Hp\Desktop\新文件.txt，输入完显示正常，但转到内存视图看，无论用ASCII格式显示，还是用UTF-16显示，还是用UTF-8显示，前面的英文都正确，但到了“原文件”这个中文词就乱码了，push参数时用这两个地址调用CopyFileA就是失败。但是如果用这个工具输入Unicode版的参数1和参数2，push参数时用这两个地址调用CopyFileW，就是成功。这导致我结论错误，我这就把帖子“CopyFileA试验不能拷贝中文名的文件”删除
最后于 2024-7-4 17:41
被ＰＥＤＩＹ编辑
，原因：
|
|
|
根本就是你自己的问题， 你怀疑CopyFileA有问题，那就应该单独写个代码来测试，像我那样，就2句核心代码， 而不是基于你乱七八糟的工程项目，谁知道你里面多了什么东西。 |
|
|
你看错了，是“工具”，不是“工程项目”
最后于 2024-7-5 06:56
被ＰＥＤＩＹ编辑
，原因：
|
|
|
|
