dimastr.com 暂未发现付费内容

CDO 的全称是 Collaboration Data Objects（协作数据对象），是微软提供的一套 COM 组件，用来在代码里访问 MAPI 消息、邮箱、通讯簿和协作数据。它适合“程序里要读写邮件/通讯簿，但不想或不能依赖已安装的 Outlook”这类场景；如果你只是想在已装 Outlook 的机器上操作当前用户的邮件，Outlook 对象模型通常更直接。CDO 不是 MAPI 的替代品，而是架在 MAPI 之上的一层封装。

CDO 的定位：MAPI 之上的一层 COM 封装

MAPI（Messaging Application Programming Interface）是底层的消息接口，能力最全，但调用复杂，涉及大量指针、表和属性操作。CDO 把这些能力包装成 COM 对象，让 VB、VBScript、Delphi、C++ 等支持 COM 的语言用属性、方法就能操作消息和文件夹。

关键关系可以这样理解：

• MAPI：底层接口，功能最完整，直接面向消息存储、通讯簿、传输。
• CDO：MAPI 之上的 COM 封装，用对象模型暴露 MAPI 能力，降低调用门槛。
• Outlook 对象模型：面向 Outlook 应用本身的对象模型，依赖已安装并运行的 Outlook。

所以 CDO 和 MAPI 是“封装与被封装”的关系，不是二选一。需要 MAPI 级别能力又不想直接写 MAPI 时，CDO 是中间选项。

CDO 和 Outlook 对象模型的区别

两者都能操作邮件，但运行前提和适用面不同：

选择条件很明确：代码跑在没有 Outlook 的服务器上，或需要脱离 Outlook 进程操作邮箱，用 CDO 更合适；代码是 Outlook 插件、要跟用户当前界面交互，用 Outlook 对象模型。

CDO、CDONTS、CDOEX 不要混为一谈

这三个名字相近，用途和时代不同：

• CDONTS（Collaboration Data Objects for Windows NT Server）：旧版 SMTP 发信组件，主要用于早期 Windows 服务器上发送邮件，功能集中在“发信”，不涉及完整邮箱/通讯簿操作。
• CDOEX：面向 Exchange 2000 及之后版本的 CDO 版本，用于访问 Exchange 存储中的邮件、日历、联系人等协作数据。
• CDO（1.x / 1.21 等）：更早的通用 CDO 组件，通过 MAPI 配置文件访问消息与通讯簿。

简单说，CDONTS 偏“发信”，CDOEX 偏“Exchange 数据访问”，通用 CDO 偏“MAPI 封装”。它们不是同一个组件的不同叫法，迁移或排错时要先确认代码用的是哪一个。

典型用途与限制

CDO 常见用途包括：

• 在服务端脚本或程序里发送邮件；
• 访问邮箱文件夹、读取或创建消息；
• 查询通讯簿、解析收件人信息。

需要注意的限制：

• 它依赖 MAPI 配置文件和底层消息系统，环境配置不对会直接报错；
• 在现代 Exchange/Outlook 环境里，旧版 CDO 的兼容性有限，很多场景已被更现代的接口替代；
• 具体支持哪些接口、在哪些系统上可用，取决于你使用的 CDO 版本和目标 Exchange/Outlook 版本，不能一概而论。

和这个站点上的工具怎么配合

dimastr.com（Advanced Messaging Systems）提供的是 Outlook/MAPI 方向的开发与生产力工具，其中 OutlookSpy 可以直接在经典 Outlook 里检查 Outlook 对象模型、Extended MAPI、EWS 和 Microsoft Graph 数据；Outlook Redemption 定位是“用任意语言获得 Extended MAPI 的能力”，作为 Outlook 对象模型缺失或受限功能的实用替代。如果你在用 CDO 或 MAPI 排查问题，这类工具的价值在于能直接查看底层对象和属性，而不是靠猜。

一句话选择建议

要在无 Outlook 的服务端环境里通过 COM 访问 MAPI 消息与通讯簿，选 CDO；要在已装 Outlook 的客户端操作当前用户邮件，选 Outlook 对象模型；只发 SMTP 邮件且是旧环境，才考虑 CDONTS；访问 Exchange 2000 及之后的存储数据，看 CDOEX。现代项目里，先确认目标环境支持哪个版本，再决定是否用 CDO 或转向更现代的接口。

Outlook 是微软的桌面个人信息管理器，核心用途是收发邮件、管理日历、联系人和任务。它本身是客户端，邮箱数据通常存放在服务端（企业环境里最常见的是 Exchange），而开发者想用代码读写这些数据时，会碰到三层不同的接口：Outlook 对象模型、MAPI、以及 Exchange 提供的服务端接口。理解这三者的分工，就能判断自己该用哪一层、以及什么时候需要借助第三方库。

Outlook 的定位：客户端，不是邮箱本身

Outlook 装在 Windows 上，负责把服务端的邮件、日历、联系人呈现给用户，并允许离线缓存、撰写、搜索。它连接的邮箱可以是：

• Exchange / Microsoft 365 邮箱：企业主流方案，服务端负责存储、同步、策略。
• POP / IMAP 账户：Outlook 作为普通邮件客户端使用。
• 本地 PST 文件：数据存在本机，不依赖服务端。

所以“Outlook 出问题”和“邮箱出问题”是两件事：前者是客户端，后者是服务端。排查时先分清是哪一侧。

Outlook 对象模型：给普通开发者用的高层接口

Outlook 对象模型（Outlook Object Model，OOM）是 Outlook 暴露给外部程序的一套 COM 接口，用 VBA、VBScript、C#、Delphi 等语言都能调用。典型能力包括：

• 遍历收件箱、发件箱、日历文件夹
• 读取和设置邮件主题、正文、收件人
• 创建、发送、回复、转发邮件
• 读取约会、联系人和任务

它的限制很关键，也是很多开发需求卡住的地方：

• 受 Outlook 安全策略限制，某些属性访问会弹安全提示或被阻止。
• 部分底层属性（如某些 MAPI 属性、传输头信息）在对象模型里根本没有暴露。
• 依赖 Outlook 进程运行，不适合服务端无人值守场景。

一句话：对象模型适合“在 Outlook 里做点自动化”，不适合“绕开 Outlook 直接操作邮箱数据”。

MAPI：更底层、更强大的消息接口

MAPI（Messaging Application Programming Interface）是 Windows 上访问消息系统的底层接口。Outlook 自己就是构建在 MAPI 之上的。相比对象模型，MAPI 能访问：

• 完整的属性集合（包括对象模型没暴露的）
• 附件、地址簿、文件夹层级
• 更细粒度的存储和传输控制

代价是复杂度高：C/C++ 直接写 MAPI 代码冗长，需要处理大量指针、属性和内存管理。因此实际开发中常见两种做法：

1. 用封装库：把 MAPI 包装成更易用的接口，在任意语言里调用。
2. 用检查工具：直接查看 MAPI 属性和对象结构，辅助调试。

dimastr.com（Advanced Messaging Systems）提供的工具正是围绕这个生态：

其中 OutlookSpy 和 Redemption 直接对应“对象模型不够用”这个痛点：前者帮你看清数据，后者帮你绕过限制。

Exchange：服务端，和客户端是两回事

Exchange 是微软的邮件与协作服务端，负责邮箱存储、同步、日历共享、策略下发。Outlook 通过 MAPI/HTTP、EWS 等协议与它通信。

对开发者来说，这意味着：

• 想操作服务端邮箱（不依赖某台机器上的 Outlook），通常走 EWS 或 Microsoft Graph。
• 想操作本机 Outlook 里的数据，走对象模型或 MAPI。
• 两者不是替代关系，而是不同层面的入口。

怎么选：按场景对号入座

• 只是写个宏或小脚本，在 Outlook 里自动处理邮件 → Outlook 对象模型。
• 对象模型访问不到某个属性，或总被安全策略拦住 → Extended MAPI，或直接用 Redemption 这类封装库。
• 要调试、搞不清某个数据藏在哪 → 用 OutlookSpy 在 Outlook 内直接查看对象模型、MAPI、EWS、Graph 数据。
• 要操作服务端邮箱、做无人值守的服务 → EWS 或 Microsoft Graph，而不是 Outlook 对象模型。
• 想让 AI 帮忙总结邮件、起草回复 → 可了解 Skipper Agent 这类面向 Outlook 的助手工具。

常见卡点

• 把 Outlook 当成邮箱：客户端和服务端混为一谈，排查方向就错了。
• 以为对象模型能做一切：安全限制和属性缺失是硬约束，遇到就得换 MAPI 层。
• 直接手写 MAPI：除非必要，用封装库能省大量调试时间。
• 忽略运行环境：对象模型和 MAPI 方案通常依赖 Outlook 进程，服务端场景要另选接口。

判断顺序可以简化为：先问“数据在客户端还是服务端”，再问“对象模型够不够用”，最后才决定是否下沉到 MAPI 或改用 EWS/Graph。

Delphi 是 Embarcadero 旗下的快速应用开发（RAD）工具，核心语言是 Object Pascal，主要用于开发原生 Windows 应用，也支持跨平台。它和 C++Builder 共用同一个 IDE 与组件框架，两者打包在一起就是 RAD Studio。Delphi 源自 Borland，但 Borland 早已不负责它的开发，目前由 Embarcadero 持续维护并发布新版本。如果你关心的是“它是否还活着”，答案是：仍在更新，而且有可免费使用的 Community Edition 版本。

Delphi、C++Builder、RAD Studio 三者的关系

理解这三者的关键，是分清“语言”和“套件”两个层面。

也就是说，Delphi 和 C++Builder 是同一套 IDE 下、面向不同语言的两种开发工具，它们共享 VCL 和 FMX 组件框架。RAD Studio 则是把这两个工具合在一起的完整套件。你选 Delphi 还是 C++Builder，主要取决于团队熟悉 Object Pascal 还是 C++，而不是功能上的根本差异。

从 Borland 到 Embarcadero：归属怎么变的

Delphi 最早由 Borland 推出，这是它常被和“Borland”一起提及的原因。后来 Borland 将开发工具业务剥离为 CodeGear，CodeGear 又被 Embarcadero 收购，Delphi 由此转入 Embarcadero 旗下。

所以现在的情况是：

• Borland 已不再负责 Delphi 的开发，它更多是历史渊源和商标归属层面的存在。
• 当前 Delphi、C++Builder、RAD Studio 的开发和发布都由 Embarcadero 负责。
• 在 X-Files Components 这类第三方组件站点的页面上，仍能看到“Borland 及 Borland 标志是 Borland Software Corporation 的注册商标”这类声明，这属于商标标注，不代表 Borland 仍在维护产品。

现在还在更新吗

在更新。以第三方 VCL 组件库 X-Files Components 的页面为例，可以看到它跟随 RAD Studio 的版本节奏持续重建：

• 2025/09/09：Package X-Files Components 8.5 对应 RAD Studio 13
• 2026/03/20：8.6 用 RAD Studio 13.1 重建
• 2026/09/19：8.7 用 RAD Studio 13.2 重建

第三方组件库会跟着 IDE 版本走，这本身就说明 RAD Studio（含 Delphi）在持续发布新版本。页面还标注了“Ready for using with free Delphi - Community Edition”，即该组件可用于免费的 Delphi Community Edition。

常见用途和生态

Delphi 的典型场景集中在数据密集型桌面应用和企业内部工具：

• 数据库桌面应用：配合 dbgrid、tdbgrid 这类数据网格组件做数据展示与编辑。
• VCL 组件开发：VCL 是 Delphi 的原生 Windows 组件框架，生态里有大量第三方组件库，比如上面提到的 X-Files Components，就提供 X-DBGrid、X-DBData 等数据库相关组件。
• 企业内部工具：因为 RAD 特性，适合快速搭建带界面的业务系统。

现在是否还值得学或用

这取决于你的目标：

• 如果你要维护或接手已有的 Delphi 项目，那基本没有替代选项，学它是必要的。
• 如果你要做原生 Windows 桌面应用、尤其是数据库类工具，Delphi 的 RAD 效率和 VCL 生态仍有实际价值。
• 如果你只是想入门编程或做 Web/移动为主的项目，Delphi 未必是首选，可以先用 Community Edition 试水再决定。

需要注意的是，具体版本的功能、授权条款和 Community Edition 的适用条件，应以 Embarcadero 官方说明为准，第三方组件页面的信息只能作为版本节奏的旁证。

CDONTS 是 Windows NT 4.0 和早期 IIS 时代随系统提供的一个 SMTP 发信组件，全称 Collaboration Data Objects for Windows NT Server。它只做一件事：让 ASP 或 VB 脚本通过本机 SMTP 服务把邮件投递出去。如果你现在还在维护 2000 年代前后的老代码，看到 CreateObject("CDONTS.NewMail") 就属于它；如果是在新项目里选型，直接用 System.Net.Mail 或 CDO.Message，不要再用 CDONTS。

CDONTS 到底能做什么

CDONTS 的接口非常窄，核心就是创建一个 NewMail 对象，设置几个属性，然后调用 Send。

Set mail = CreateObject("CDONTS.NewMail")
mail.From = "[email protected]"
mail.To = "[email protected]"
mail.Subject = "测试"
mail.Body = "正文"
mail.Send

输入是收件人、发件人、主题、正文，动作是 Send，预期结果是邮件被交给本机 SMTP 服务并排队投递。它不支持附件以外的复杂 MIME 结构，不支持现代认证，也不直接操作邮箱里的邮件——它只负责“发出去”。

失败排查通常集中在两处：

• SMTP 服务未启动或未安装：CDONTS 依赖本机 SMTP 虚拟服务器，服务停了就会报错。
• 权限不足：运行脚本的账户（如 IIS 匿名账户 IUSR）需要对 SMTP 投递目录有写权限，否则邮件进不了队列。

CDONTS 和 CDO 不是同一套库

这是最容易混淆的地方。名字里都有 “CDO”，但面向的场景完全不同。

简单说：CDONTS 是“发信工具”，CDO 1.21 是“协作数据访问库”。两者可以都用来发邮件，但 CDO 的能力范围大得多，也更贴近 MAPI。

和 MAPI、Outlook 对象模型的分工

把这几层放在一起看，关系会清楚很多：

• MAPI：底层消息接口，是 Outlook、Exchange 客户端和 CDO 共同依赖的基础。
• Outlook 对象模型：在 MAPI 之上做的一层自动化接口，通过 Outlook.Application 操作，必须装有 Outlook 客户端。
• CDO 1.21：直接基于 MAPI，可以不启动 Outlook 就访问 Exchange 数据。
• CDONTS：完全不走 MAPI，也不依赖 Outlook，只对接本机 SMTP。

所以 CDONTS 的定位很特殊：它是这几者里唯一“不碰邮箱、只发信”的组件。这也是它在纯发信场景下曾经流行的原因——不需要装 Outlook，也不需要连 Exchange。

现在还能用吗，该换成什么

CDONTS 从 Windows Server 2003 之后就不再随系统提供了，新系统上 CreateObject("CDONTS.NewMail") 通常会直接失败。迁移时按需求选替代：

• 只是发简单邮件：用 .NET 的 System.Net.Mail.SmtpClient，或脚本里用 CDO.Message（CDO for Windows 2000/2003 的 SMTP 版本，注意和 CDO 1.21 区分）。
• 需要访问 Exchange 邮箱、日历、联系人：用 CDO 1.21，或更现代的 Exchange Web Services（EWS）、Microsoft Graph。
• 需要在 Outlook 内自动化，且要绕开 Outlook 对象模型的限制：可考虑第三方 MAPI 库，例如 dimastr.com 上列出的 Outlook Redemption，它定位为“用任意语言调用 Extended MAPI”，作为 Outlook 对象模型缺失功能的实用替代。

迁移时最需要注意的是：CDONTS 的 Send 是同步投递到本机 SMTP，而新方案大多需要显式配置 SMTP 服务器地址、端口和认证。老代码里那些默认本机投递的假设，换库后往往要补上配置才能跑通。

MAPI（Messaging Application Programming Interface）是 Windows 上用于访问和发送邮件、通讯录、日历等消息数据的编程接口。它最典型的用途是让程序绕过 Outlook 界面，直接读写邮箱里的数据。如果你要开发与 Outlook 或 Exchange 深度集成的功能，MAPI 往往是能力最强、也最底层的一条路；如果只是做常规的邮件收发和简单字段读取，Outlook 对象模型通常更省事。

MAPI 在 Windows 消息体系中的位置

MAPI 由两部分组成：

• 客户端接口：程序通过它请求发送消息、打开文件夹、读取通讯录。
• 服务提供者接口：邮件存储、通讯录、传输等后端（如 Exchange、PST 文件）通过它接入 MAPI 体系。

所以 MAPI 更像一层“消息总线”，程序不直接跟 Exchange 或 SMTP 打交道，而是通过 MAPI 统一访问。Exchange 是常见的后端存储与传输系统，SMTP 负责邮件在服务器之间的投递，而 MAPI 负责客户端这一侧的数据访问。

Simple MAPI 与 Extended MAPI

这是最容易混淆的一组概念，能力差距很大。

Simple MAPI 适合“帮我把这封邮件发出去”这类简单需求。一旦涉及读取已有邮件、批量处理文件夹、操作附件或通讯录，就需要 Extended MAPI。

MAPI 与 Outlook 对象模型怎么选

两者都能操作 Outlook 数据，但定位不同：

• Outlook 对象模型：面向 Outlook 应用本身，语言支持广（VBA、C#、VB.NET 等），上手快。适合读取邮件字段、创建约会、遍历收件箱等常规任务。它的限制是只能做 Outlook 暴露出来的事，且受 Outlook 运行状态和安全提示影响。
• Extended MAPI：能力更底层、更完整，可以访问对象模型没有暴露的属性。代价是 C++ 为主、接口复杂，直接调用门槛高。

一个常见的折中是使用封装库。dimastr.com 上的 Outlook Redemption 定位就是“用任何语言获得 Extended MAPI 的能力”，作为 Outlook 对象模型缺失或受限功能的实用替代。也就是说，你可以在较友好的语言环境里调用底层 MAPI 能力，而不必从零写 C++ 接口代码。

开发与调试常用工具

dimastr.com 列出的开发者工具里，与 MAPI 直接相关的有：

• OutlookSpy：在经典 Outlook 内直接检查 Outlook 对象模型、Extended MAPI、EWS 和 Microsoft Graph 数据。调试 MAPI 相关问题时，它用来查看实际属性值和接口状态。
• Outlook Redemption：把 Extended MAPI 能力带到各种语言中，弥补 Outlook 对象模型的不足。
• OfficeSpy：浏览 Office 对象模型、检查属性值、调用函数、监控事件，覆盖 Word、Excel、PowerPoint、Access、Publisher、Visio、Project。
• Proxy Manager：从任意 Exchange 代理 SMTP 地址、以自定义显示名发送 Outlook 邮件。
• Skipper Agent：面向 Outlook 的 AI 助手，可总结会话、起草回复、搜索邮箱历史并执行 Outlook 操作。

什么时候该用 MAPI

可以用下面这组条件来判断：

• 适合直接用 Extended MAPI（或 Redemption 这类封装）：需要访问 Outlook 对象模型没有暴露的属性；要批量、稳定地处理邮箱数据；对性能和底层控制有要求。
• 适合用 Outlook 对象模型：任务属于常规邮件、日历、联系人操作；希望用 VBA 或 .NET 快速实现；能接受对象模型的能力边界。
• 需要先确认的前提：MAPI 是 Windows 平台的消息接口，具体可用能力取决于后端（如 Exchange）和客户端环境。涉及具体版本、授权或价格的部分，需以对应产品页面为准。

如果你正在排查 Outlook 数据读不到、属性对不上，先用 OutlookSpy 看清实际暴露的接口和属性，再决定是走对象模型还是下沉到 MAPI，通常比直接写代码更省时间。