Python3调用win32clipboard读取剪贴板内容的格式问题咨询

1. 剪贴板格式编号的含义 #

剪贴板的格式编号分两大类：

• 系统预定义标准格式：编号小于0xC000（即十进制49152），是Windows内核定义的通用格式，你测试中出现的这类编号对应含义如下：
  • 1：CF_TEXT，ANSI编码纯文本
  • 2：CF_BITMAP，GDI位图对象句柄
  • 7：CF_OEMTEXT，OEM字符集编码纯文本，为老系统兼容保留
  • 8：CF_DIB，设备无关位图内存块，存储完整位图信息头+像素数据
  • 13：CF_UNICODETEXT，UTF-16LE编码的Unicode文本，pywin32会自动解析为Python字符串类型
  • 14：CF_ENHMETAFILE，增强型图元文件GDI句柄
  • 15：CF_HDROP，文件拖放格式，pywin32会自动解析为文件路径元组
  • 16：CF_LOCALE，剪贴板文本对应的区域设置ID，你复制文本时拿到的b'\t\x04\x00\x00'就对应简体中文区域
  • 17：CF_DIBV5，支持Alpha通道的第五版设备无关位图格式
• 注册格式：编号大于等于0xC000，又分两种：一种是Windows Shell、系统组件、通用控件注册的公共格式，比如你复制文件时看到的49158/49159分别对应短路径文件描述、Unicode长路径文件描述格式，复制图片时看到的49155是OLE对象标识格式；另一种是第三方应用自行注册的私有格式，比如你测试中看到的49326、49672这类，只有注册它的应用自己知道具体结构。

2. 部分格式读取失败（出现LOSE FORMAT提示）的原因 #

常见原因有4种：

• 格式存储的是内核/GDI对象句柄，而非可直接读取的内存块：比如CF_BITMAP（编号2）、CF_METAFILEPICT（编号3，就是你复制图片时读失败的格式）这类，本质是指向系统内核对象的整数句柄，不是全局内存块，pywin32默认按内存块读取自然报错。
• 格式采用延迟渲染机制：很多应用复制时不会立刻把所有格式的数据写入剪贴板，仅登记自己支持的格式列表，等其他程序真的发起读取请求时才实时生成数据。如果读取时原复制程序已经退出、或者无响应，就会读失败。
• 格式需要专用接口读取：部分OLE格式、私有格式不通过全局内存块传递数据，需要调用对应的COM接口才能获取，直接用GetClipboardData读内存拿不到有效数据。
• pywin32的兼容限制：部分结构复杂的格式，pywin32没有做对应的自动解析逻辑，调用时会直接抛出异常。

3. 单次复制存储多份不同格式的设计逻辑 #

这是Windows剪贴板为了最大化跨程序兼容性做的核心设计：
不同程序支持的粘贴格式完全不同，比如你从浏览器复制一段带样式的文字，如果只存浏览器私有格式，粘到记事本里就拿不到内容；如果只存纯文本，粘到Word里就会丢失格式、图片、超链接。所以复制操作发生时，源程序会把同一份内容尽可能转换成所有它支持的格式，全部写入剪贴板，粘贴时目标程序只需要挑选自己能识别的、优先级最高的格式读取即可。
你自己的测试结果也能印证这个逻辑：复制记事本纯文本时，记事本同时写入了Unicode文本、ANSI文本、OEM文本、区域信息4种格式，老程序可以读ANSI/OEM编码的文本，新程序直接读Unicode文本，都能正常拿到内容；复制文件、图片时同理，多份格式分别对应不同程序的读取需求。

4. 剪贴板格式官方资料查询渠道 #

可以直接查阅微软官方发布的Win32开发文档中剪贴板相关章节：

• 预定义标准格式的说明在「Standard Clipboard Formats」章节下
• 资源管理器相关的文件操作公共格式说明在「Shell Clipboard Formats」章节下
• 系统公共注册格式都有对应的公开说明，第三方应用的私有格式需要查阅对应应用的开发文档。

内容的提问来源于stack exchange，提问作者CAMOBAP