如何从Windows剪贴板正确读取复制图片的像素？现有实现遇异常

使用GetClipboardData(CF_DIB)获取剪贴板数据，并将其视为BITMAPINFOHEADER进行处理，已覆盖以下逻辑：

• 处理biWidth和biHeight参数
• 兼容biBitCount为24或32的情况
• 当biCompression为BI_BITFIELDS时，跳过像素数据前3*4字节的颜色掩码

多数场景下能正常获取像素数据，但从Telegram等特定应用复制图片时，频繁出现颜色错乱、图像变形异常，且检查BITMAPINFOHEADER未发现特殊异常。

• 行字节对齐处理：DIB要求每行像素数据的字节数必须是4的倍数，即使biWidth * biBitCount / 8的结果不是4的整数倍，也需要填充额外字节。如果直接按实际像素宽度计算行长度，会导致后续行的像素数据偏移错误，引发图像变形。正确的行字节数计算应为：((biWidth * biBitCount + 31) / 32) * 4。
• 颜色通道顺序混淆：DIB的像素数据默认是BGR/BGRA顺序，而非常见的RGB/RGBA。如果代码将数据按RGB顺序解析，会直接导致颜色错乱。Telegram复制的图片可能严格遵循DIB的通道顺序，而其他应用可能做了兼容转换，因此暴露了这个问题。
• BI_BITFIELDS的颜色掩码解析错误：当biCompression为BI_BITFIELDS时，虽然跳过了前3*4字节的掩码，但需要正确解析这三个掩码对应的颜色通道（蓝、绿、红），并按掩码提取对应通道的像素值。如果掩码顺序搞反（比如当成红、绿、蓝）或者掩码位提取逻辑错误，会导致颜色错乱。
• biHeight的正负含义处理：biHeight为正数时，DIB的像素数据是从下到上存储的（即第一行数据对应图像底部）；为负数时则是从上到下存储。如果代码未根据biHeight的正负调整像素行的读取顺序，会导致图像上下颠倒或变形。
• BITMAPINFO结构的完整解析：CF_DIB返回的是BITMAPINFO结构，而非单纯的BITMAPINFOHEADER。BITMAPINFO包含BITMAPINFOHEADER后跟颜色表（调色板），即使biBitCount为24位，若biClrUsed不为0，仍会存在颜色表数据。如果未正确计算颜色表的长度并跳过，会导致像素数据起始位置偏移，引发图像异常。
• 32位DIB的Alpha通道处理：32位DIB可能包含Alpha通道（BGRA），如果代码忽略Alpha通道或错误将其当作颜色通道处理，可能导致颜色显示异常。部分应用（如Telegram）可能会保留Alpha通道数据，而其他应用可能会去除或转换为24位。

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