VB6内存中生成Bitmap并转Byte数组：GDI+DIB完整实现与避坑指南

1. 项目背景与核心需求拆解

1.1 为什么会有"内存中生成Bitmap再转byte数组"这种需求

VB6 这门语言到今天还在不少工业控制、医疗设备、老旧MIS系统里跑着，这不是情怀，是现实。很多产线工控机、票据打印机、老式扫描枪配套软件，底层就是VB6写的，换不掉也不敢换。而这类场景里，一个绕不开的需求就是：程序需要动态画一张图，然后把这图以二进制形式丢给别的模块用。

什么叫"丢给别的模块用"？举几个我实际碰到的场景你就懂了：

• 一台老式热敏打印机，驱动只认原始字节流，你得自己把文字、条码、二维码画成位图，再按打印机的指令格式把位图数据拼进去；
• 一个和C++写的DLL对接的接口，对方函数签名是ProcessImage(byte* pData, long size)，你VB6这边必须给出一个Byte()数组；
• 一个网络传输模块，要把截图或生成的图形压缩后发出去，中间层只接受字节数组；
• 数据库里要存缩略图，但不想落地成临时文件再读回来，嫌慢又嫌脏。

这些场景的共同点是：图像只在内存里存在，不需要（也不应该）先存成文件再读回来。存文件再读，多一次磁盘IO不说，还得处理临时文件清理、权限、并发冲突一堆破事。所以"内存中生成Bitmap，直接转成byte数组"就成了一个非常实用的基本功。

1.2 VB6在这件事上的先天短板

VB6自带的图像能力其实很弱。PictureBox、Image控件能显示图，但你要"凭空生成"一张图，标准控件是做不到的。VB6也没有原生的Bitmap类，更没有System.Drawing这种现成库。

那VB6靠什么画图？靠GDI（Graphics Device Interface），也就是Windows系统底层那套绘图API。VB6通过Declare语句声明API函数，就能调用CreateCompatibleDC、CreateCompatibleBitmap、SelectObject、BitBlt、GetDIBits这一整套东西。这套东西威力很大，但坑也很多——句柄泄漏、DC释放顺序、位图格式对齐，任何一个没处理好，程序跑一会儿就崩或者内存暴涨。

所以这个项目的核心，本质上是：用GDI在内存里创建一张位图，画上内容，然后把这张位图的像素数据按DIB格式提取出来，塞进一个Byte()数组。听起来简单，但每一步都有讲究。

1.3 适合谁来参考

这篇内容适合三类人：

第一类是被迫维护VB6老系统的开发者，需要给老代码加个"生成图片"的功能，又不想引入外部控件；第二类是想理解GDI位图内存布局的人，因为这套知识在C++、C#、Delphi里是相通的，只是调用方式不同；第三类是做嵌入式或工控上位机的，经常要和"原始字节流"打交道。

哪怕你用的是VB.NET或C#，理解DIB的内存结构、行对齐规则、BGR排列顺序，对你处理图像二进制也是实打实有用的。下面我会从设计思路讲到具体实现，再到踩坑排查，尽量把每个"为什么"都讲透。

2. 整体方案设计与技术选型思路

2.1 两条技术路线的取舍

在VB6里把Bitmap转成byte数组，主流有两条路：

路线A：GDI + GetDIBits。自己创建内存DC和位图，画完之后用GetDIBits把像素数据提取到一个字节缓冲区里。这条路完全依赖系统API，不依赖任何外部组件，兼容性最好，从Windows 98到Windows 11都能跑。

路线B：借助第三方库或控件。比如某些图像处理控件自带SaveToByteArray之类的方法，或者用IPicture、StdPicture配合流对象转换。这条路代码短，但引入了依赖，部署时可能缺DLL，而且老控件在新系统上未必稳定。

我选路线A。原因很直接：工控和老系统最怕的就是依赖。你多带一个DLL，客户现场就可能因为注册失败、版本冲突、位数不匹配（32位/64位）而跑不起来。纯API方案虽然代码长一点，但它是自包含的，拷过去就能用。而且理解了API方案，你以后遇到任何"内存图像"的需求都能自己改。

2.2 为什么最终要的是DIB而不是DDB

这里有个关键概念必须分清：DDB（设备相关位图）和DIB（设备无关位图）。

你用CreateCompatibleBitmap创建出来的，是DDB。DDB的像素数据存储格式依赖具体设备，你没法直接读它的内存——它的位是"设备相关"的，可能和显卡、显示器配置有关。而GetDIBits这个函数的作用，就是把DDB转换成DIB格式，并复制到你提供的缓冲区里。

DIB的格式是标准化的，由BITMAPINFO结构描述，包含：

• 位图宽度、高度（像素）
• 每个像素的位数（1、4、8、16、24、32）
• 调色板信息（8位及以下需要）
• 压缩方式（通常用BI_RGB不压缩）

我们最终要的byte数组，就是DIB的像素数据部分（有时候也把文件头一起拼上，做成完整的BMP文件字节流）。理解这一点，后面所有参数设置就都有依据了。

2.3 24位还是32位：一个必须提前定的决策

像素位深的选择直接影响后面所有代码，得先定下来。

我一般默认用24位。理由是：兼容性最好，几乎所有消费方都认；不需要处理Alpha通道；体积适中。只有明确需要透明度时才上32位。8位和1位除非是特定硬件要求，否则不碰，调色板处理太容易出错。

提示：24位DIB有一个非常容易被忽略的规则——每一行的字节数必须是4的倍数。如果宽度是奇数，比如宽100像素，100×3=300字节，300不是4的倍数，系统会自动补到304字节。这个填充字节不算像素，但占位置。算缓冲区大小时如果忘了它，GetDIBits就会写越界，直接崩。

2.4 整体流程鸟瞰

把整个流程串起来，大概是这么几步：

1. 用GetDC(0)或CreateCompatibleDC拿到一个参考DC；
2. CreateCompatibleBitmap创建一张指定宽高的DDB；
3. SelectObject把位图选进内存DC，之后所有绘图都画在这张位图上；
4. 用GDI绘图函数（TextOut、Rectangle、BitBlt等）在位图上作画；
5. 准备BITMAPINFO结构，描述目标DIB格式；
6. 计算缓冲区大小（含行对齐）；
7. 调用GetDIBits把像素数据提取到Byte()数组；
8. 按需拼上BMP文件头，或直接返回纯像素数据；
9. 清理：SelectObject还原、DeleteObject删位图、DeleteDC/ReleaseDC释放DC。

这九步里，第6步和第9步是最容易翻车的。后面会重点讲。

3. 核心API与数据结构详解

3.1 必须声明的几个GDI函数

VB6调用API全靠Declare。下面这几个是核心，我按用途分组说明。

' 设备上下文相关 Private Declare Function CreateCompatibleDC Lib "gdi32" (ByVal hdc As Long) As Long Private Declare Function CreateCompatibleBitmap Lib "gdi32" (ByVal hdc As Long, ByVal nWidth As Long, ByVal nHeight As Long) As Long Private Declare Function DeleteDC Lib "gdi32" (ByVal hdc As Long) As Long Private Declare Function DeleteObject Lib "gdi32" (ByVal hObject As Long) As Long Private Declare Function SelectObject Lib "gdi32" (ByVal hdc As Long, ByVal hObject As Long) As Long ' 像素数据提取 Private Declare Function GetDIBits Lib "gdi32" (ByVal hdc As Long, ByVal hBitmap As Long, ByVal nStartScan As Long, ByVal nNumScans As Long, lpBits As Any, lpBI As BITMAPINFO, ByVal wUsage As Long) As Long ' 获取屏幕DC（作为参考） Private Declare Function GetDC Lib "user32" (ByVal hwnd As Long) As Long Private Declare Function ReleaseDC Lib "user32" (ByVal hwnd As Long, ByVal hdc As Long) As Long

这里有几个细节值得说：

GetDIBits的lpBits参数声明为As Any，是为了能传Byte()数组的首元素（bits(0)）。VB6里传数组给API，标准做法是传第一个元素，配合ByRef语义，API就能拿到数组起始地址。

lpBI参数是BITMAPINFO结构，必须ByRef传递（VB6默认就是ByRef，所以不用写）。这个结构里既有格式描述，又有调色板数组，24位时调色板用不上，但结构定义里得留位置。

3.2 BITMAPINFO 结构怎么定义

这是整个项目里最容易定义错的结构。它由两部分组成：BITMAPINFOHEADER和调色板数组。

Private Type BITMAPINFOHEADER biSize As Long biWidth As Long biHeight As Long biPlanes As Integer biBitCount As Integer biCompression As Long biSizeImage As Long biXPelsPerMeter As Long biYPelsPerMeter As Long biClrUsed As Long biClrImportant As Long End Type Private Type RGBQUAD rgbBlue As Byte rgbGreen As Byte rgbRed As Byte rgbReserved As Byte End Type Private Type BITMAPINFO bmiHeader As BITMAPINFOHEADER bmiColors(0 To 255) As RGBQUAD End Type

关键字段解释：

• biSize：固定填Len(bmiHeader)，也就是40。填错系统直接返回失败。
• biWidth/biHeight：位图宽高。高度为正数表示自下而上存储（bottom-up），这是BMP的传统格式；负数表示自上而下（top-down）。这个方向问题后面单独讲。
• biPlanes：固定填1，历史遗留字段。
• biBitCount：24或32，按前面决策填。
• biCompression：填BI_RGB（值为0），表示不压缩。
• biSizeImage：图像数据大小。填0时系统会自动算，但为了保险我一般手动算好填上。

注意：BITMAPINFO里我留了256个RGBQUAD，虽然24位用不上，但这样定义能兼容8位场景，而且结构大小足够，不会因为缓冲区太小被API写越界。这是老手常用的"防御性定义"。

3.3 行对齐：那个让无数人栽跟头的4字节规则

前面提过，DIB每行字节数必须是4的倍数。公式是：

每行字节数 = ((宽度 × 位深 + 31) \ 32) × 4

拆开理解：宽度 × 位深是每行实际需要的位数，+31再\32是向上取整到32位（4字节）的整数倍，最后×4转成字节数。

举个具体例子，宽100像素、24位：

• 实际位数：100 × 24 = 2400 位
• 2400 + 31 = 2431
• 2431 \ 32 = 75（整除，向下取整）
• 75 × 4 = 300 字节

300正好是4的倍数，不用补。再看宽101像素、24位：

• 101 × 24 = 2424
• 2424 + 31 = 2455
• 2455 \ 32 = 76
• 76 × 4 = 304 字节

实际需要 101×3=303 字节，补到304，多了1个填充字节。

缓冲区总大小 = 每行字节数 × 高度。这个值必须算准，传给GetDIBits的缓冲区如果小于这个值，API会写越界，轻则数据错乱，重则程序崩溃。

Dim lngStride As Long Dim lngBufSize As Long lngStride = ((lngWidth * 24 + 31) \ 32) * 4 lngBufSize = lngStride * lngHeight ReDim bytBuffer(0 To lngBufSize - 1) As Byte

这段代码我建议直接背下来，改位深时把24换成32即可。

3.4 自下而上还是自上而下：图像倒置的根源

BMP格式默认是自下而上存储的，也就是说，缓冲区里的第一行数据，其实是图像的最后一行（底部）。如果你直接把这段数据按顺序当成图像显示，图就是上下颠倒的。

处理方式有两种：

方式一：接受倒置，在消费端翻转。如果消费方是打印机或某个知道BMP规则的模块，它自己会处理，你不用管。

方式二：把biHeight设为负数，告诉系统用自上而下格式。这样缓冲区第一行就是图像顶部，符合直觉。但不是所有消费方都支持top-down格式，用之前要确认。

我一般默认用正数高度（标准bottom-up），因为兼容性最好。如果最终要拼成完整BMP文件，文件头里也会标明方向，看图软件能正确显示。只有在明确知道消费方需要top-down时才用负数。

实操心得：调试阶段如果发现图上下颠倒，先别急着改代码逻辑，先确认是不是这个方向问题。我见过有人花半天查绘图代码，最后发现只是没理解BMP的存储顺序。

4. 完整实操流程与代码实现

4.1 第一步：创建内存DC和位图

先拿到参考DC，再创建兼容位图。参考DC用屏幕DC最省事。

Dim hdcScreen As Long Dim hdcMem As Long Dim hBmp As Long Dim hBmpOld As Long hdcScreen = GetDC(0) hdcMem = CreateCompatibleDC(hdcScreen) hBmp = CreateCompatibleBitmap(hdcScreen, lngWidth, lngHeight) hBmpOld = SelectObject(hdcMem, hBmp)

这里hBmpOld保存的是被替换出来的默认位图句柄，最后清理时必须SelectObject还原回去，否则位图删不掉，造成句柄泄漏。这是GDI编程的铁律：谁选进去，谁负责选出来。

4.2 第二步：在位图上绘图

位图选进内存DC后，所有GDI绘图操作都作用在它上面。比如填充背景、画矩形、写字：

' 填充白色背景 Dim lngBrush As Long lngBrush = CreateSolidBrush(RGB(255, 255, 255)) Dim lngRect As RECT lngRect.Left = 0: lngRect.Top = 0 lngRect.Right = lngWidth: lngRect.Bottom = lngHeight FillRect hdcMem, lngRect, lngBrush DeleteObject lngBrush ' 设置文字颜色和背景透明 SetBkMode hdcMem, TRANSPARENT SetTextColor hdcMem, RGB(0, 0, 0) TextOut hdcMem, 10, 10, "测试文字", Len("测试文字")

绘图这块没什么特别的，就是标准GDI操作。要注意的是用完的GDI对象（画刷、画笔、字体）都要DeleteObject，不然一样泄漏。VB6不像.NET有GC帮你兜底，这里全靠手动。

4.3 第三步：准备BITMAPINFO并计算缓冲区

这一步是核心，参数填错全盘皆输。

Dim tBI As BITMAPINFO With tBI.bmiHeader .biSize = Len(tBI.bmiHeader) .biWidth = lngWidth .biHeight = lngHeight ' 正数=bottom-up .biPlanes = 1 .biBitCount = 24 .biCompression = 0 ' BI_RGB .biSizeImage = lngBufSize .biXPelsPerMeter = 0 .biYPelsPerMeter = 0 .biClrUsed = 0 .biClrImportant = 0 End With

biSizeImage填我们算好的lngBufSize。虽然填0系统也能算，但显式填上更稳妥，某些老系统对0的处理不一致。

4.4 第四步：调用GetDIBits提取像素

Dim lngRet As Long lngRet = GetDIBits(hdcMem, hBmp, 0, lngHeight, bytBuffer(0), tBI, 0) If lngRet = 0 Then ' 失败处理 End If

参数说明：hdcMem是内存DC，hBmp是位图句柄，0是起始扫描行，lngHeight是要提取的行数，bytBuffer(0)是目标缓冲区首元素，tBI是格式描述，最后的0表示DIB_RGB_COLORS。

返回值是成功复制的扫描行数，正常应该等于lngHeight。如果返回0，说明调用失败，常见原因是缓冲区太小或结构定义错误。

4.5 第五步：清理资源（顺序不能错）

SelectObject hdcMem, hBmpOld ' 先还原 DeleteObject hBmp ' 再删位图 DeleteDC hdcMem ' 删内存DC ReleaseDC 0, hdcScreen ' 释放屏幕DC

顺序很重要：必须先SelectObject还原，才能DeleteObject位图。如果位图还选在DC里就删，删除会失败，句柄泄漏。这个顺序我踩过坑，当年程序跑几小时后句柄数爆表，查了半天才发现是这里。

4.6 完整函数封装

把上面串起来，封装成一个函数，输入宽高和绘图回调，输出byte数组：

Public Function GenerateBitmapBytes(ByVal lngWidth As Long, _ ByVal lngHeight As Long, _ ByRef bytOut() As Byte) As Boolean Dim hdcScreen As Long, hdcMem As Long Dim hBmp As Long, hBmpOld As Long Dim tBI As BITMAPINFO Dim lngStride As Long, lngBufSize As Long Dim lngRet As Long On Error GoTo CleanUp ' 计算缓冲区 lngStride = ((lngWidth * 24 + 31) \ 32) * 4 lngBufSize = lngStride * lngHeight ReDim bytOut(0 To lngBufSize - 1) ' 创建DC和位图 hdcScreen = GetDC(0) hdcMem = CreateCompatibleDC(hdcScreen) hBmp = CreateCompatibleBitmap(hdcScreen, lngWidth, lngHeight) hBmpOld = SelectObject(hdcMem, hBmp) ' 这里调用你的绘图逻辑 DrawContent hdcMem, lngWidth, lngHeight ' 准备BITMAPINFO With tBI.bmiHeader .biSize = 40 .biWidth = lngWidth .biHeight = lngHeight .biPlanes = 1 .biBitCount = 24 .biCompression = 0 .biSizeImage = lngBufSize End With ' 提取像素 lngRet = GetDIBits(hdcMem, hBmp, 0, lngHeight, bytOut(0), tBI, 0) GenerateBitmapBytes = (lngRet = lngHeight) CleanUp: If hBmpOld <> 0 Then SelectObject hdcMem, hBmpOld If hBmp <> 0 Then DeleteObject hBmp If hdcMem <> 0 Then DeleteDC hdcMem If hdcScreen <> 0 Then ReleaseDC 0, hdcScreen End Function

这个封装的好处是：资源清理放在CleanUp标签里，无论中途哪里出错都能正确释放。On Error GoTo CleanUp保证异常时也走清理流程。这是VB6里写API代码的标准防御姿势。

4.7 如果需要完整BMP文件字节流

有时候消费方要的不是纯像素，而是完整的BMP文件格式（带文件头）。那就需要在像素数据前面拼上14字节的BITMAPFILEHEADER和40字节的BITMAPINFOHEADER。

Private Type BITMAPFILEHEADER bfType As Integer ' "BM" = &H4D42 bfSize As Long ' 文件总大小 bfReserved1 As Integer bfReserved2 As Integer bfOffBits As Long ' 像素数据偏移 = 14 + 40 = 54 End Type

拼装时注意bfType要填&H4D42（也就是字符"BM"按小端序的整数值），bfSize是文件头+信息头+像素数据的总和，bfOffBits固定54（24位无调色板时）。

提示：拼文件头时字节序要小心。x86是小端序，bfType填&H4D42后，内存里低字节是&H42（'B'），高字节是&H4D（'M'），正好是"BM"。如果你手动按字节拼，顺序是 'B' 在前 'M' 在后。

5. 常见问题与排查技巧实录

5.1 图像上下颠倒

这是最高频的问题。原因前面讲过，BMP默认bottom-up。解决方案二选一：要么把biHeight设为负数用top-down，要么在消费端翻转。我一般先确认消费方期望的格式，再决定。如果只是自己调试看效果，把biHeight设负数最快。

5.2 图像颜色不对（红蓝互换）

24位DIB的像素排列是BGR，不是RGB。也就是说，每个像素三个字节依次是蓝、绿、红。如果你按RGB顺序去解析，红色和蓝色就反了。这不是bug，是BMP格式的规定。消费端解析时按BGR读，或者你在生成后手动交换R和B通道。

5.3 图像右侧有杂色或错位

几乎可以肯定是行对齐没处理对。宽度不是4的倍数对应关系时，每行末尾有填充字节。如果你在消费端按宽度×3去读每行，就会把填充字节当成像素，导致逐行错位，图像看起来像斜的。正确做法是按stride跳行，跳过填充字节。

5.4 GetDIBits返回0

排查顺序：

1. 缓冲区大小是否够（最常见）；
2. biSize是否填了40；
3. biBitCount和缓冲区计算是否匹配；
4. 位图句柄是否有效（有没有提前被删）；
5. biCompression是否填了0。

我遇到过biSize填成Len(tBI)（整个结构含调色板的大小）而不是Len(tBI.bmiHeader)，结果一直返回0。这个细节很容易错。

5.5 程序运行一段时间后崩溃或变慢

典型的GDI句柄泄漏。检查清单：

• 位图有没有DeleteObject；
• 画刷、画笔、字体有没有DeleteObject；
• 内存DC有没有DeleteDC；
• 屏幕DC有没有ReleaseDC；
• SelectObject有没有还原。

可以在任务管理器里加一列"GDI对象"观察，如果数字只涨不跌，就是泄漏了。VB6程序GDI对象上限默认是10000，超了就崩。

5.6 常见问题速查表

5.7 几个独家避坑技巧

技巧一：调试时把byte数组存成文件验证。生成完byte数组后，手动拼上BMP文件头写成一个.bmp文件，用看图软件打开。如果文件能正常显示，说明像素数据没问题，问题在消费端；如果文件都打不开，说明生成环节有错。这个二分法能快速定位问题在哪一侧。

技巧二：宽高用偶数。虽然奇数也能处理，但偶数宽高能避开行对齐的填充问题，调试阶段能少一类干扰。等逻辑跑通了再测奇数。

技巧三：先画纯色再画内容。调试时先只填充一个纯色（比如纯红），确认byte数组里每个像素都是00 00 FF（BGR的纯红），再往上加复杂内容。这样能把"生成流程"和"绘图内容"两个问题分开排查。

技巧四：句柄用完立即置0。清理代码里删完句柄后把它设为0，防止重复删除。重复DeleteObject一个已删除的句柄行为未定义，可能误删别的对象。

技巧五：大图分块处理。如果要生成很大的图（比如几千像素宽），一次性分配大缓冲区可能失败。可以按扫描行分块调用GetDIBits，每次提取若干行，降低内存峰值。

6. 性能优化与扩展思路

6.1 减少不必要的DC创建

如果程序需要频繁生成图像（比如每秒几十张），每次都GetDC/CreateCompatibleDC开销不小。可以创建一个长期存在的内存DC，复用它，只在尺寸变化时重建位图。屏幕DC也可以创建一次长期持有，程序退出时再释放。

6.2 复用缓冲区

ReDim一个大的byte数组也有开销。如果尺寸固定，可以把缓冲区做成模块级变量，只分配一次，每次生成时复用。注意每次生成前要清零，否则残留上一张图的数据。

6.3 32位带Alpha的场景

如果消费方需要透明度，把biBitCount改成32，缓冲区大小按4字节每像素算。注意32位DIB的Alpha通道在GetDIBits提取时不一定被正确填充——GDI对Alpha的支持不完整，很多时候Alpha位是0。如果需要真正的Alpha，得手动填充Alpha字节，或者用AlphaBlend相关API。这是个进阶话题，普通场景用24位就够了。

6.4 和现代接口对接

如果消费方是C#或C++写的现代模块，它可能期望的是标准的32位BGRA或24位BGR。VB6生成的DIB数据可以直接通过CopyMemory传给这些模块的字节数组参数。跨语言传递时注意调用约定（stdcall还是cdecl）和参数类型匹配，这是另一个容易出问题的地方。

6.5 保存为PNG/JPG的延伸

纯GDI只能生成BMP格式的原始数据。如果要保存成PNG或JPG（压缩格式），VB6原生做不到，需要借助GDI+的GdipSaveImageToStream系列API，或者调用系统的WIA组件。这是另一个项目了，但理解了DIB内存布局，迁移到GDI+会顺很多，因为GDI+的Bitmap也能从字节数组构造。

我在实际项目里最深的体会是：这套东西的价值不在于代码本身，而在于它逼你把图像的内存表示彻底搞明白。一旦你理解了DIB的行对齐、BGR排列、bottom-up存储这些底层规则，再去看任何图像库的文档，都会觉得豁然开朗。那些看似神秘的参数，其实都是这些基础规则的不同表达方式。VB6虽然老，但用它来学这些底层知识，反而比用高级库更直接，因为高级库把这些细节都藏起来了，你永远不知道它背后发生了什么。