在Windows平台下用C++处理资源管理器中的文件复制操作时，很多初学者会误以为剪切板里直接保存了一段纯文本路径。实际上当用户在文件夹中选中若干文件并按下Ctrl+C，系统写入剪切板的是CF_HDROP类型的结构化数据，里面包含每一个被选中文件的完整磁盘路径。我们的任务就是打开剪切板、识别这种格式、提取路径，并最终写进一个txt文件。
理解剪切板中的CF_HDROP数据结构
Windows剪切板支持多种数据格式，每一种用一个整型格式ID标识。普通文本对应CF_TEXT或CF_UNICODETEXT，而资源管理器复制文件时使用CF_HDROP。该格式背后是一个内存句柄，指向一个DROPFILES结构体，紧接着存放所有文件路径的字符串。直接调用GetClipboardData(CF_TEXT)当然拿不到任何内容，因为格式不匹配。
为了读取文件列表，必须先调用OpenClipboard锁定剪切板，再用GetClipboardData(CF_HDROP)得到HDROP句柄。随后使用DragQueryFile这个API：第一次传入索引0xFFFFFFFF可获取文件总数，之后用从0开始的索引逐个取出路径。这种方式天然支持用户一次选中几十个文件，且能正确处理包含空格和中文的长路径。
需要注意的是，读取完毕后必须调用DragFinish释放HDROP相关资源，并调用CloseClipboard解除锁定。如果忘记关闭剪切板，其他进程（包括资源管理器自身）将无法再次写入剪切板，导致用户粘贴功能暂时失效。因此异常处理路径上也要保证关闭动作被执行。
实战代码：提取路径并保存为txt
下面给出一份完整可编译的示例，基于Win32 API与标准C++文件流。程序运行后会尝试读取剪切板中的文件列表，并将每个路径写在一行，输出到当前目录的selected_files.txt中。代码使用Unicode编码以兼容各种语言文件名。
#include <windows.h>
#include <shlobj.h>
#include <fstream>
#include <string>
int main() {
if (!OpenClipboard(NULL)) {
return 1;
}
HDROP hDrop = (HDROP)GetClipboardData(CF_HDROP);
if (hDrop == NULL) {
CloseClipboard();
return 2;
}
UINT fileCount = DragQueryFile(hDrop, 0xFFFFFFFF, NULL, 0);
std::wofstream outFile(L"selected_files.txt");
if (!outFile.is_open()) {
DragFinish(hDrop);
CloseClipboard();
return 3;
}
for (UINT i = 0; i < fileCount; ++i) {
UINT len = DragQueryFile(hDrop, i, NULL, 0);
std::wstring buf(len + 1, L' ');
DragQueryFile(hDrop, i, &buf[0], len + 1);
outFile << buf.c_str() << L"n";
}
outFile.close();
DragFinish(hDrop);
CloseClipboard();
return 0;
}
上述代码先判断剪切板能否打开，再取HDROP。通过两次调用DragQueryFile，第一次拿长度，第二次填字符串，避免缓冲区溢出。std::wofstream以宽字符写入，保证中文路径不会乱码。若希望追加而非覆盖，可将打开方式改为std::wofstream outFile(L"selected_files.txt", std::ios::app);。
编译时请链接必要的库，例如在Visual Studio中无需额外配置，但若是命令行 cl 编译，确保包含shell32.lib（DragQueryFile所在库）。如果是在MinGW环境，则需加-lshell32。运行前先打开资源管理器，选中几个文件复制，再启动程序即可看到txt生成。
常见错误与跨进程注意事项
一个典型误区是在没有OpenClipboard的情况下直接调用GetClipboardData，这会返回NULL且GetLastError提示权限问题。另一个误区是以为CF_HDROP里只有文件名，实际上DragQueryFile返回的是带盘符的完整绝对路径，如C:ASRtest.docx，无需自己拼接目录。
在跨进程场景里，如果自己的程序是后台服务或以不同用户权限运行，可能无法打开当前用户桌面的剪切板。此时需要调整为与用户同会话的普通桌面程序。此外，若用户复制的是“剪切”状态而非“复制”状态，CF_HDROP内容一致，但原文件在粘贴后会被移动；我们的只读提取逻辑不会影响原文件，仅生成txt清单，因此很安全。
最后，若想支持非资源管理器的其他软件复制的文件对象（例如压缩软件内部文件），它们可能不使用CF_HDROP，而用自定义格式。此时可枚举EnumClipboardFormats查看可用格式，但绝大多数系统级文件复制都遵循CF_HDROP约定，实战中优先处理该格式即可覆盖九成以上需求。