游戏开发后端【免费下载链接】kbengineA MMOG engine of server.项目地址https://gitcode.com/gh_mirrors/kb/kbengine点击查看免费下载KBEngine 的服务器端baseapp、cellapp 等由内嵌的 CPython 运行时驱动其源码树随仓库完整保留在 kbe/src/lib/python 下版本为 Python 3.7.3。服务器脚本资产以 Python 编写其中涉及玩家邮箱注册激活、找回密码等流程时开发者常常需要程序化地解析、构造与序列化 MIME 邮件消息。本文以 email.rst 这份官方文档为主体完整还原email包的定位、四大组件架构对象模型、解析器、生成器、策略控制、子模块地图与两套 API现代 API 与 legacy compat32 API并结合仓库内源码逐条印证关键类、默认参数与调用关系帮助你在 KBEngine 脚本环境中正确而高效地处理邮件消息。email 包只负责消息本体不负责投递文档开篇即明确了一个最重要的边界email包是一个管理邮件消息的库它专门不设计用于向 SMTPRFC 2821、NNTP 或其他服务器发送邮件——发送是smtplib、nntplib等模块的职责。email包的目标是在解析、操纵与生成消息时尽可能符合 RFC其遵循的规范包括RFC 5233、RFC 6532头部与正文的 UTF-8 处理与 MIME 相关的 RFC 2045、RFC 2046、RFC 2047、RFC 2183、RFC 2231。这一点在当前仓库中可以得到一个有趣的印证KBEngine 服务器自身的邮件投递走的是 C 实现而非 Pythonemail包。sendmail_threadtasks.cpp 中SendEMailTask::process使用 jwsmtp 库的mailer对象直接发送SMTP 服务器、账号与密文都来自 email_service_defaults.xmlsmtp_server、smtp_port、smtp_auth、username、password等节点其中密码支持 kbe_private.key RSA 加密。也就是说通过 SMTP 发出去这一环由引擎 C 层完成而当你在自己的服务器脚本里需要解析收到的原始邮件、构造 MIME 消息体、生成符合规范的字节流交给某条发送通道时标准库email包就是工具。文档同时说明email包会尽力向应用隐藏各 RFC 的细节概念上应用可以只把邮件视为一个由 Unicode 文本与二进制附件构成的结构化树无需关心序列化时的表示方式。但实践中仍需要了解 MIME 的一些高层结构尤其是 MIME content type 的命名与形式以及它如何标识 multipart 文档。文档指出这类知识通常只在较复杂的应用中需要而且只需了解高层结构不需要知道其底层表示细节——MIME content type 在现代互联网软件中应用广泛多数程序员对此并不陌生。文档末尾的 See also 还列出了与email包配套的传输类模块可视为完整的邮件处理工具箱模块用途smtplibSMTP简单邮件传输协议客户端poplibPOP邮局协议客户端imaplibIMAPInternet 消息访问协议客户端nntplibNNTP网络新闻传输协议客户端mailbox以多种标准格式在磁盘上创建、读取和管理消息集合smtpdSMTP 服务器框架主要用于测试这些模块在本仓库的 Python 树中均真实存在例如 smtplib.py、smtpd.py。四大组件对象模型、解析器、生成器与策略文档将email包的整体结构划分为三个主要组件外加一个控制其他组件行为的第四个组件对象模型object model——包的核心。应用主要通过定义在email.message子模块中的对象模型接口与包交互向已有邮件提问、构造新邮件、或增删本身也使用同一套对象模型接口的邮件子组件。正如同邮件消息及其 MIME 子组件的本性一样邮件对象模型是一个对象树树中所有节点都提供email.message.EmailMessageAPI。解析器email.parser——把邮件消息的序列化版本一个字节流转换成一棵EmailMessage对象树。生成器email.generator——把一棵EmailMessage对象树重新序列化回字节流。文档特别提示解析器与生成器也能处理文本字符流但不推荐使用这种用法因为太容易产生以某种方式不合法的消息。控制组件email.policy——每个EmailMessage、每个生成器、每个解析器都有一个与之关联的policy对象来控制其行为。通常应用只需在EmailMessage被创建时直接实例化新邮件或用解析器解析输入流指定一次 policy 即可但在用生成器序列化消息时也可以更换 policy。例如从磁盘按通用方式解析一封邮件再在发往邮件服务器时改用标准 SMTP 设置序列化。从源码结构看这四个组件与文档描述一一对应对象模型Lib/email/message.py 中第 105 行的class Messagelegacy 基础类与第 1159 行的class EmailMessage现代 API 核心类解析器Lib/email/parser.py 第 17 行class Parser以及 Lib/email/feedparser.py 第 136 行class FeedParser生成器Lib/email/generator.py 第 26 行class Generator与第 392 行class BytesGenerator策略Lib/email/policy.py 与 Lib/email/_policybase.py。文档指出自 Python 3.6 起versionchanged标注文档被重新组织与重写以推广新的EmailMessage/EmailPolicyAPI——这也正是本仓库 3.7.3 版本中代码的形态。email 包的子模块地图文档正文给出了email包的完整文档目录toctree按现代 API与legacy API两组组织。这个目录同样就是email包的子模块结构与仓库 Lib/email 目录下的源文件一一对应现代unicode 友好API文档/子模块角色对应源码email.message对象模型应用使用的主接口message.pyemail.parser字节流 → 消息对象树parser.pyemail.generator消息对象树 → 字节流generator.pyemail.policy控制其余组件的行为policy.pyemail.errors包可能抛出的异常errors.pyemail.headerregistry更精细操纵头部headers的工具headerregistry.pyemail.contentmanager更精细操纵 payload 的工具contentmanager.pyemail.examples基础 API 用法示例Doc 示例其中headerregistry与contentmanager两个子组件除了消费和生成非平凡消息的实用功能外还各自记录了扩展性 APIextensibility API对高级应用很有价值。Legacy API以email.message.Message类一节为起点子模块说明email.message.Messagecompat32直接、更贴近邮件消息底层表示细节email.mimeMIME 便捷构造类text、multipart、nonmultipart 等email.header头部解析/生成email.charset字符集处理email.encodersCTE 编码器email.utils地址、日期等工具函数email.iterators消息迭代器文档对 legacy 部分有一句关键定位compat32API不向应用隐藏 RFC 细节对需要操作在那个层级的应用来说是有用的工具同时也服务于出于向后兼容原因仍在使用email.policy.compat32API 的旧应用。从 Lib/email/init.py 的__all__可见包对外暴露的模块名其中还包含feedparser增量解析器未在文档 toctree 单列以及四个便捷函数message_from_string、message_from_bytes、message_from_file、message_from_binary_file分别定义于该文件第 32、40、48、56 行它们是一行代码把字符串/字节/文件变成消息对象的入口。对象模型 EmailMessage头部字典 payload 树文档正文及紧随其后的email.message小节描述了EmailMessage的概念模型一封邮件由**头部headers和payload也称 content**组成。头部是 RFC 5322 或 RFC 6532 风格的字段名 值冒号不属于名也不属于值payload 可以是简单文本消息、二进制对象或者一个结构化子消息序列——每个子消息有自己的头部和自己的 payload。当消息的 MIME 类型形如multipart/*或message/rfc822时就表明 payload 属于这种结构概念模型是一个头部的有序字典加上一个表示 RFC 5322 正文的 payload可能是子EmailMessage对象列表。除常规的字典式头部访问方法外还提供从头部读取专门信息例如 MIME content type、操作 payload、生成序列化版本、递归遍历对象树的方法EmailMessage的字典式接口以头部名为键索引。在仓库源码中EmailMessage直接继承MIMEPart其set_content覆写会在首次设置内容时自动补上MIME-Version: 1.0头见 message.py 第 1159–1165 行附近这正是对象模型替你维护 RFC 细节的一个具体例子。策略policy驱动一切行为的控制对象文档将email.policy称为控制组件每个消息、解析器、生成器都挂着一个 policy。从仓库源码可以读出具体的默认取值方便你在脚本中显式定制基类策略 Lib/email/_policybase.py 第 162–165 行的类属性给出了核心默认值属性默认值作用raise_on_defectFalse发现 RFC 违规defect时是记录为 defect 还是抛错linesep\n序列化时使用的行分隔符cte_type8bit允许的 content transfer encoding 类型max_line_length78最大行长不含 linesepmax_line_length在折叠头部时会被实际使用_policybase.py第 367–369 行将maxlinelen传给头部编码逻辑保证输出行宽合规。现代 API 的 EmailPolicy第 26 行起源码中同样标注为 PROVISIONAL在此基础上增加了属性默认值作用utf8FalseFalse时头部序列化为 ASCII非 ASCII 字符用 encoded wordsRFC 2047编码True时按 RFC 6532 直接以 UTF-8 序列化refold_sourcelong解析来源的头在重新生成时是否重折叠none/long仅超过max_line_length的行/allheader_factoryHeaderRegistry()可调用对象把(name, value)变成带类型语义的头对象地址、日期字段有专门处理每个新实例会创建独立的 factorycontent_managerraw_data_manager提供get_content/set_contentMessage上的同名方法最终委托给它文档强调的使用要点在此处成立通常只需在创建EmailMessage时指定一次 policy而序列化阶段可以替换 policy。一个典型场景——从磁盘按通用设置解析、发往邮件服务器时按标准 SMTP 设置序列化——正是 KBEngine 这类脚本资产中处理玩家邮件场景需要的能力同一封消息对象入库/落盘与对外发送可以用不同的 policy 分别序列化。典型用法最小示例与 MIME 构造文档的示例章节email.examples与Doc/includes下的可运行脚本给出了email包最基础的用法模式。以 email-simple.py 为代表# Import smtplib for the actual sending function import smtplib # Import the email modules well need from email.message import EmailMessage # Open the plain text file whose name is in textfile for reading. with open(textfile) as fp: # Create a text/plain message msg EmailMessage() msg.set_content(fp.read()) # me the senders email address # you the recipients email address msg[Subject] The contents of %s % textfile msg[From] me msg[To] you # Send the message via our own SMTP server. s smtplib.SMTP(localhost) s.send_message(msg) s.quit()注意其中体现的分工EmailMessage负责消息本体头部 text/plainpayloadsmtplib负责投递——与文档email 包不发送邮件的定位完全一致。同目录还有构造多部分消息的示例email-mime.py附件、email-alternative.py文本/HTML 二选一与 email-dir.py目录式消息它们分别对应multipart/mixed与multipart/alternative两类最常见的 MIME 结构。围绕这套 API仓库还内置了完整的单元测试可作为行为验证的权威依据test_email 目录 下的test_message.py、test_parser.py、test_generator.py、test_policy.py、test_contentmanager.py、test_inversion.py解析-生成互逆性测试等覆盖了对象模型、解析、生成、策略与内容管理的各个角落。与 KBEngine 服务器邮箱体系的关系最后把视角拉回项目本身。KBEngine 服务器的邮件服务由两部分构成C 发送层sendmail_threadtasks.cpp 中的SendEMailTask以线程任务形式运行通过 jwsmtp 的mailer发送smtp_auth取值 1/2 分别映射到jwsmtp::mailer::LOGIN/PLAIN认证类型源码第 17 行并对模板中的${username}等占位符做替换第 27 行配置层email_service_defaults.xml 定义 SMTP 服务器、认证信息以及激活/重置密码/绑定三类邮件的subject、deadline如激活邮件有效期 259200 秒与 HTML 模板支持${backlink}占位链接该文件路径由 kbengine_defaults.xml 中的email_service_config节点指向。由此可以推断email包在 KBEngine 生态中的位置是服务器脚本Python侧的消息处理工具——当你需要在脚本中解析玩家上传/收到的原始邮件字节流、拼装带附件的 MIME 结构、或按特定 policy 生成规范化字节流供 C 层或smtplib发送时它提供的是标准库级的解析、对象模型与序列化能力而通过 SMTP 把信发出去这一环引擎自身已由 jwsmtp 完成。两者职责边界清晰正呼应了文档开篇的那句定位。小结email包是消息本体库解析、操纵、生成不负责 SMTP/NNTP 投递那是smtplib等的职责四大组件——对象模型EmailMessage树、parser、generator、policy——在 kbe/src/lib/python/Lib/email 中有完整、一一对应的实现policy 是贯穿解析与序列化的控制旋钮max_line_length78、linesep\n、cte_type8bit、raise_on_defectFalse是基类默认值EmailPolicy增加utf8、refold_source、header_factory、content_manager现代 APIEmailMessage/EmailPolicy与 legacycompat32API 并存前者隐藏 RFC 细节后者贴近底层表示可按需要选用行为可验证性由 Lib/test/test_email 的成套单测保障示例可直接参考 Doc/includes 中的email-*.py脚本。赞分享游戏开发后端【免费下载链接】kbengineA MMOG engine of server.项目地址https://gitcode.com/gh_mirrors/kb/kbengine点击查看免费下载相关推荐KBEngine 内置 Python 3.7.3 的 email.policy 模块用 Policy 对象掌控邮件消息的解析与序列化KBEngine 内置 Python 3.7.3 的 email.policy 模块用 Policy 对象掌控邮件消息的解析与序列化 本文基于 KBEngin游戏开发后端Python email.message.Message 与 compat32 API 源码级指南KBEngine 内嵌 Python 3.7 邮件对象模型全解析Python email.message.Message 与 compat32 API 源码级指南KBEngine 内嵌 Python 3.7 邮件对象模型全游戏开发后端KBEngine 内嵌 Python 标准库 email.message 模块详解EmailMessage 对象模型与 MIME 消息处理实战KBEngine 内嵌 Python 标准库 email.message 模块详解EmailMessage 对象模型与 MIME 消息处理实战 本文基于当前仓游戏开发后端上一篇FreeCut快速上手指南如何10分钟从零做出第一个视频并导出无需安装下一篇如何快速上手TinyFish Cookbook3步跑通你的第一个网页Agent免费API KeycURL实战创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考