Manual:ContentHandler/zh

内容处理器（ContentHandler）是一种在维基页面上支持任意内容类型的机制，而不是一切都依赖于维基文本来处理所有内容. 这原先是作为维基数据项目的一部份开发的，而从1.21版本开始成了MediaWiki核心的一部分.

有关内容处理器架构的典型概述，请参阅MediaWiki代码文档中的内容处理器.

有关可用的内容处理器的列表，请参阅.

关于
这一相当激进的改变背后的原因是，在MediaWiki中，被迫依赖wikitext来获取所有内容使得很多事情变得相当麻烦. 新的可插拔架构适用于任意类型的页面内容，这将使我们能够：


 * 在部分或全部页面上使用不同的标记语言，如TeX或Markdown.
 * 取消CSS和JavaScrip 页面的特例.
 * 存储和编辑结构化配置数据的方式比Gadgets扩展在MediaWiki:Gadgets-definition页面或 LanguageConverter在MediaWiki:Conversiontable***页面上使用的方式更合理.
 * 为 wikitext 页面提供数据“附件”，例如地理数据（使用页面的“多部分”内容模型，类似于使用多部分信息格式实现电子邮件附件的方式）. （注：该计划从未实现，现已被取代）.
 * 过渡到不在维基文本中维护类别等内容的系统，但仍以通常的方式进行存储和版本控制（再次使用多部分内容模型）.
 * 为維基數據轻松存储结构化数据，并将其作为页面内容.



设计理念
我们的想法是，以与目前存储 wikitext 完全相同的方式存储其他类型的数据，但要让MediaWiki知道每个页面所处理的内容类型. 这样，任何类型的数据都可以用作维基页面的内容，而且其存储和版本控制都与以前完全一样. 为了实现这一目标，我们在MediaWiki核心中实现了以下功能：


 * 追踪每个页面的“内容模型”. 这主要是在数据库中的表（也包括和表）中完成的，并可通过 、 、和 等相关核心类別访问.  “内容模型”定义了内容的“原生形式”，无论是包含文本的字符串、嵌套数组结构，还是PHP-{zh:对象;zh-hans:对象;zh-hant:物件;}-.  对内容的所有操作都是在其“原生形式”上进行的.
 * 跟踪每次修订的“内容格式”（序列化格式）. 这主要是在数据库中的表（也包括表，但不包括表）中完成的，并可通过相关的核心类（如 ）访问.  请注意，序列化格式只与加载和存储修订版时相关，不会对内容的序列化形式执行任何操作.
 * 注意：对于平面文本内容（如 wikitext），内容的原始形式与序列化形式（即字符串）相同. 不过，可以想象，维基文本的原生形式将来可能是某种形式的 AST 或 DOM.
 * 注：表记录当前修订版的内容模型，而表记录内容模型和序列化格式. 从理论上讲，模型和格式都可以从一个修订版变为另一个修订版，但这可能会造成混淆，而且无法实现有意义的差异.

这意味着所有需要对内容执行任何操作的代码都必须了解内容的原生形式. 这些知识通过基于两个类别的可插拔处理器框架进行封装：


 * 类別表示内容本身，并为在内容原生形式上执行所有标准操作提供接口. 它不知道内容属于哪个页面或版本.  内容对象一般是、但不必然是，不可变的.
 * 类別，代表有关内容模型具体内容的知识，但不能访问具体的内容. 最重要的是，内容处理器的实例可作为内容对象的工厂，并提供序列化/反序列化功能.  内容对象是无状态的單例模式，每个内容模型都有一个.

内容处理器也用于生成, , 等子类別的合适实例. 这样，就可以通过内容处理器接口轻松为每种内容类型插入专门的用户界面.

所有以任何方式访问修订文本的代码都应修改为使用内容对象所提供的方法. 访问修订文本的核心类別（最重要的是 和 类）已进行调整，以提供对相应内容对象的访问，而不是对文本的访问.



向后兼容
在MediaWiki代码库中，页面包含有维基文本的假设是非常普遍的. 因此，与仍然如此假设的部分代码，尤其是与扩展，保持兼容是非常重要的. 当然，提供良好兼容性的正确方法是不去更改公共接口. 因此，所有提供访问修订内容的方法（就像等）仍然保留，而是以允许访问内容对象的替代方法（如）辅助. 基于文本的方法现已弃用，但对所有包含维基文本的页面/修订版而言，其功能与以前完全相同. This is also true for the action API.

A convenience method,, is provided to make it easy to retrieve a page's text. For flat text-based content models such as wikitext (but also JS and CSS),  will just return the text, so the old text-based method will return the same as it did before for such revisions. However, in case a text-based backwards-compatible method is called on a page/revision that does not contain wikitext (or another flat text content model, such a CSS), the behavior depends on the setting of : ignore makes it return null, fail causes it to raise an exception, and serialize causes it to return the default serialization of the content. The default is ignore, which is probably the most conservative option in most scenarios.

For editing however, non-text content is not supported per default. and the respective handlers in the action API will fail for non-textual content.

链接

 * 和 类 :


 * -{zh-hans:设置; zh-hant:設定;}- :


 * 使用内容处理器的扩展 :
 * 如何添加带有扩展名的内容模型：
 * 基本例子： Extension:Markdown
 * 扩展
 * — 所有内容模型的列表（包括核心和扩展中的）
 * — 所有内容模型的列表（包括核心和扩展中的）