目录    上一章节：1 简介    下一章节：3 解析

本章节定义了 DOI® 号语法，该编号可用于标识任何形态（数字的或物质的）对象或抽象创作物（如文字作品），以将不同对象区分开来。DOI® 系统可与其他标识符方案同时使用（如增加目前还不具备的附加功能），其他方案的字符串可通过 DOI 元数据记录和/或 DOI 语法整合到 DOI 系统。本章节还将讨论字符集、区分大小写、唯一性和互联网标识符规范。

© 国际数字对象标识符 (DOI) 基金会  •    最后更新：2014 年 2 月 13 日

每个 DOI® 号都是唯一“编码”，只用于标识一个实体。尽管 DOI 系统可以确保同一 DOI 号不会分配两次，但注册者（分配 DOI 号的公司或个人）和注册机构的首要责任就是在其 DOI 号前缀的范围内为对象分配唯一的标识。

DOI 系统确保了唯一性（规定所指对象有且只有一个 DOI 号）。两个 DOI 号不会分配到同一对象。

DOI 系统设计的初衷就尽可能简化知识产权的唯一命名（包括有有形或无形的、数字形式或物质形式的）。已有的标识符可作为 DOI 号或 DOI 记录的一部分使用，便于注册者为所有已有“内容资产”分配 DOI 号。建议根据适当的标准分配前缀，以满足机构业务需求。通常情况下，注册机构可能将前缀分配给每个客户、每个品牌，或一些公认的产品合集（例如出版事项）。

DOI 系统比多数已有标识符方案更加先进，可标识现有标识方案（或“传统标识符”）无法标识的、更加琐碎的内容和更加具体的知识产权类型。

本节定义了 DOI 号语法，该编号可用于标识任何形态（数字的或物质的）对象或抽象创作物（如文字作品），以将不同对象区分开来。DOI 系统可与其他标识符方案同时使用（如增加目前还不具备的附加功能），其他方案的字符串可通过 DOI 元数据记录和/或 DOI 语法整合到 DOI 系统。

DOI 号语法标准最初定为 ANSI/NISO Z39.84-2000（于 2005 年和 2010 年再次确认），之后成为 ISO 26324 (2010)一部分。

使用过程中，DOI 号只是一个“模糊字符串”或“模糊编码”。不能也不应从中推断出任何有关其在 DOI 系统中使用的信息。准确了解某一 DOI 号所标识的实体信息的唯一方式，是查看 DOI 号注册者在注册时申报的元数据。这意味着，即使某个项目的所有权发生了变更，其标识符依然保持不变。这就是 DOI 号被称为“持久标识符”的原因。

2.2.1 基本特点

DOI 语法应包括 DOI 前缀和 DOI 后缀，中间用斜线分开。

DOI 号、DOI 前缀或 DOI 后缀没有特定的长度限制。

DOI 号不区分大小写，可使用 Unicode 编码合法图形字符中的任何可印刷字符。ISO 26324 注册中心为应用定义了更多的字符使用限制（如特定语言的字母数字字符）。

唯一 DOI 前缀（分配给某个 DOI注册者）和唯一 DOI 后缀（由该注册者提供给特定对象）的组合是唯一的，允许 DOI 号的分散式分配。

DOI 号是一个用于 DOI 系统的模糊字符串。无法从 DOI 号的特定字符串推断出任何确定性信息。特别是，当 DOI 号包含分配到特定注册者的任何注册者代码时，并不能说明注册者拥有该所指对象的知识产权或当下管理责任。此类信息可由相关元数据声明。

2.2.2 DOI 前缀

通则

DOI 前缀应由目录指示器加上注册者代码组成。两者应用句点分开。

目录指示器

目录指示器应为 “10”。目录指示器将解析系统内的数字对象标识符识别为完整的字符串（前缀和后缀）集。

注册者代码

DOI 前缀的第二部分应为注册者代码。注册者代码为分配给注册者的唯一字符串。

变更

无论是所指对象所有权还是管理权发生变更，DOI 号一经分配，不再变更。

注： 虽然注册者代码仍为 DOI 号的永久性部分，但原注册者可能不再维护该 DOI 号和其相关记录。

2.2.3 DOI 后缀

DOI 后缀为注册者选定的字符串，长度不限。各后缀对于之前的前缀部分应具有唯一性。唯一后缀可以是一系列数字，也可以包含使用或基于其他系统生成的标识符（如 ISAN、ISBN、ISRC、ISSN、ISTC、ISNI）；此类情况下（如例一），可规定后缀的首选结构。

2.3.1 分配原则

DOI 号不应用于代替其他 ISO 标识符方案详细信息见 2.7 节。

DOI 号可以随时分配给任何对象，以满足区分其他对象的功能需要。

“DOI”可理解为“一个对象的数字标识符”（而非一个数字对象的标识符）。

DOI 号分配规则可通过 DOI 应用配置文件，将基于适合元数据范围的功能定义纳入进来。

2.3.2 粒度

DOI 号可分配给任何对象，该对象可为某些实体的组成部分，范围大小不限。DOI 号可以按照注册者的需求，以任意精度和粒度进行分配。

例如，就文字材料中的粒度而言，小说的不同 DOI 号可以分配给整部小说，或该小说的特定版本，或特定版本中的某个章节、某个段落、某个图片、某句引语，以及该小说出版等所展现的内容。

2.3.3 变更项目

功能粒度之一即选择是否向已有 DOI 号的变更项目分配新的 DOI 号：需要区分时应随时标识实体。IDF 本身对此不做任何规定。各个注册机构可决定采纳适合各自社区的规定。

2.3.4 描述

DOI 号分配要求注册者提供描述正在分配 DOI 号的对象的元数据。元数据应详细描述对象，以使其可作为单独实体在 DOI 系统中加以区分。

2.3.5 唯一性

在 DOI 系统中，各 DOI 号指定一个且只有一个所指对象。尽管可以使用不同的 DOI 号指定同一个所指对象，但建议为各所指对象分配唯一的 DOI 号。

2.3.6 持久性

DOI 号的存在无时间限制，其任何分配、服务或应用均无时间限制。

DOI 号及其所指对象不受所指对象相关权利变更或所指对象管理责任变更的影响。

DOI 系统通过交换被标识实体（至少是 DOI 号和所指对象描述）的信息，保证其互操作性得以继续。

DOI 号区分大小写，使用 ASCII 大小写转换区分不同的文本。（DOI 号不区分大小写的情况仅适用于 ASCII 字符。对于 DOI 号中包含的非 ASCII Unicode 字符，大小写不同可能表示不同的标识符。） 10.123/ABC 与 10.123/AbC 完全相同。通常，注册 DOI 号时均将其转化为大写，从而保证各种服务不区分大小写。解析也是同样如此。如果 DOI 号注册为 10.123/ABC，那么 10.123/abc 就会解析，当再试图注册 10.123/AbC 时就会被拒绝，并提示此 DOI 号已存在。

尽管从字符编码角度看后缀区分大小写，如 10.123/ABC 和 10.123/AbC 是不同的，两者可视为不同的标识符，但经 IDF 详细审查后决定取消区分大小写。Handle System 通过服务可选择是否配置区分大小写以及是否允许配置。这一限制很早就开始实施，当时 IDF 机构还未引入使用 ASCII 大小写区分两个 DOI 号的机制，大小写不同的 ASCII 字符被解析为同样的编号。

区分大小写（图书管理员和出版商做法、人类可读性和期望）具有优势，但其重要性不敌数据完整性。互联网应用对大小写的要求各不相同：DNS 不区分大小写，其余的 URL 多数情况下（取决于服务器）要区分大小写；Unix 与 PC/Mac 文件名称对大小写的要求不同（微软 Windows 通常不区分，Unix 操作系统一直区分）；标记语言标签中大小写的错误使用可能引发意想不到的问题。谁也不能保证某一软件会遵循区分大小写，而不会将本应不同的两个 DOI 号合并为一个 。一些搜索引擎和目录区分大小写。不同网络浏览器处理大小写方式不同（网络浏览器研发者建议“作者不应根据大小写创建独特的标识符，除非这些标识符只针对真正的标准兼容浏览器”）。

因此，不区分大小写意味着更加安全与稳定，是未来 DOI 系统进步和发展的必然选择。

2.5.1 编码原则

DOI 号可从 ISO/IEC 10646 的通用字符集 (UCS-2) 中引入任何可印刷字符，这是 Unicode v2.0 定义的字符集。UCS-2 字符集包含了当今各主要语言中使用的多数字符。然而，对于一些互联网技术使用的某些特定字符（例如 xml 中尖括号“< >”的使用），日常使用可能会有一些限制（见下文）。

考虑前缀、后缀和字符集时，把 DOI 系统与基础技术和 Handle System 区分开来非常重要。DOI 系统是 Handle System 的一种实现。当前几乎全部在万维网（和互联网不完全相同）的环境中使用（尽管不是唯一可能或潜在用途），并遵守不断发展的 IDF 政策。

前缀/后缀。Handle System 、DOI 系统和当今可以想到的任何网络使用均未对编码外的后缀做出任何限制（见下文）。Handle 语法对前缀做出两个限制，斜线和点为“保留字符”，斜线用于分隔前缀和后缀，点用于扩展子前缀。Handle System 的根管理员为 IDF 保留了所有以“10.”开头的前缀（如10.1000, 10.1000.1, 10.23），以供 DOI 号使用。

编码。Handle System 核心使用 UTF-8，UTF-8 为 Unicode 编码实现，其纯形式没有任何字符集限制：任何字符均可发送至 handle 服务器，并进行存储和提取操作。IDF 未添加其他字符集限制。但实际操作中，当前网络环境对于字符集有诸多限制，这主要取决于用户环境，如使用的浏览类型等。(This is something of a moving target — does your current browser display kanji characters, for example?Do you know?).下节将提供当前编码建议清单。

实现。同时考虑实现的标准和现实情况是非常重要的。例如，URL 中的“# ”字符用于说明 URL 部分的开头，有必要将其变为“十六位编码”。该字符对 Handle System 或 DOI 号语法没有特殊意义，但 URL 内包含的 handle 必须有 # 字符编码，也就是说浏览器将把 handle 缩写为 # 符号。所有网络实现均如此。特定浏览器实现不同，因此将其他字符（如“”）变为“十六进制编码”的需要也不同。NISO 标准便考虑了 DOI 号语法所需的此类编码。从更广范围意义上讲，任何数字环境中的标识符的实现都需要考虑可能遇到的编码问题。应当消除字符集限制，并以平稳的方式、从网络等环境中移除那些字符。

2.5.2 编码规范

除本标准（如 Unicode 编码的使用和保留字符）特殊要求外，不对 DOI 使用的字符做限制或假设。本节讨论一些在 URL 应用环境中，按照 HTTP 协议使用 DOI 产生的编码问题。其他应用环境中所使用的 DOI 可能也会有类似的要求或限制。不过此类对特定字符使用所做的编码或限制要求，仅适用于 DOI 用于那些特定应用环境中的情况。它们不属于本文档定义的 DOI 语法本身。

有关表示 DOI 号其他形式（包括 URI 和 URN）的说明，请参见 2.6 节和专题资料 DOI ® 系统与互联网标识符规范。

2.5.2.1 UTF-8 编码

Handle System 确定 UTF-8 为 DOI 字符串编码。ASCII 字符以 UTF-8 编码保存。无需变更 ASCII 字符以遵循 UTF-8 编码。Unicode 编码默认各字符包含 16 位（2 个八位字节）。UTF-8 是 Unicode 编码的变体，Unicode 编码可允许字符使用 1 到 6 个八位字节编码。使用非 ASCII 字符时，UTF-8 编码便发挥作用。例如，日语 “nihongo” 写为：

汉语字符代表 “nihongo” 的 Unicode 序列为：65E5 672C 8A9E。用 UTF-8 编码则为：E6 97 A5 E6 9C AC E8 AA 9E。有关 UTF-8 的详细信息，请参见 “UTF-8，Unicode 与 ISO10646 的格式转换”，RFC 2044，1996年10月。

详细信息请查看最新版本的 Unicode。Unicode 为 Unicode 的商标。Unicode 标准针对多个八位字节编码字符集（通常称为通用字符集，缩写为UCS）ISO/IEC 10646:2003 的实现做出了其他限制。

2.5.2.2 使用 URL 时的编码建议

当前网络浏览器技术需要增加功能才能使浏览器充分利用 DOI。可以预见，在不久的将来，浏览器将普遍具有解析功能。

可从 Handle System 网站免费下载一个“解析插件”，其他 HANDLE.NET 软件。该插件可以扩展普通浏览器的功能，以兼容该 Handle 协议。

或者无需增加网络浏览器功能，使用默认的公共 DOI 代理服务器 http://doi.org （或 http://dx.doi.org，完整支持前期语法，但已不推荐使用）。这种情况下，DOI 解析主要依靠使用 URL 语法。例如“doi:10.123/456”会写成 http://doi.org/10.123/456。

DOI 也主要用于 HTML 页面。DOI 10.1006/rwei.1999".0001 作为一个网页链接，表示为：

10.1006/rwei.1999%22.0001

注意 ：以为" 符号编码（见下节），从而区分 URL 中的 DOI 和周围的其他文本。 用户可以直接在浏览器中输入 DOI，但该 DOI 将以编码形式出现。

2.5.2.3 编码问题

DOI 用于 HTML、URL 和 HTTP 时需要符合特殊的编码要求。统一资源标识符 (URL) 语法限制比 DOI 语法限制多得多。URI 可能是统一资源定位符 (URL)，也可能是统一资源命名 (URN) 。

URL 或 URN 中不允许使用的或有其他意义的 DOI 字符必须使用十六进制 (%) 编码。十六进制编码由百分号和代替先前字符的十六进制值组成。因此，# 变成 %23，http://doi.org/10.1000/456#789 编码后变成 http://doi.org/10.1000/456%23789。 浏览器不会遇到单独出现的 #，通常情况下 # 视为 URL 的结尾和某一部分的开头，因此会将整个字符串发送至服务器网络进行解析，而不会单独落下 #。注：DOI 自身不会随编码改变，只是其 URL 表示的改变。 已编码的 DOI 发送至 DOI 注册之前应解码。代理服务器 http://doi.org/ 负责处理解码。只有未编码的 DOI 才存储于 DOI 注册数据库。 例如，上述编码存储于 DOI 注册的是 “10.1000/456#789”，而非 “10.1000/456%23789”。而在 URL 中则必须保持十六制编码 (%25)。

DOI 编码字符串本身几乎没有字符限制。DOI 嵌入 URL 时，必须遵循 URL 语法协议。同一 DOI 在其他环境中无需遵守这些协议。

2.5.2.4 DOI 存储与 URL 的强制与推荐编码

表 1 和 2 总结了 DOI 编码指南。URL 字符限制集最多。 表 1 列出了必须使用十六制编码的字符。表 2 列出了建议使用十六制编码代替的字符。两个列表的区别在于一个是当前网络浏览器的实际使用经验，另一个是更加正式的 URL 语法规范。 DOI 目录中所有字符均代表自身。

表1：强制编码

表2：建议编码

注意：网络浏览器对“/./”和“/../../../../”的处理方式可能不同。因此，建议两个斜线中的一个使用 % 编码，如将 “/./” 改为 “/.%2F”，“/../../../../“ 改为 “/..%2F”。

2.6.1 屏幕和纸质表达

DOI 号在屏幕或纸张上显示时，除文本清楚说明是指 DOI 号，应使用小写的 “doi:”标记开头。“doi” 标签不是 DOI 号值的一部分。

2.6.2 URI 表达

使用小写字符串 “doi” 符合 IETF 规范 RFC 3986，表示为 URI（统一资源标识符），如 “ftp:” 和 “http:”。在网络浏览器显示时，DOI 号可附上适合的代理服务器地址，通过标准网络超链接实现 DOI 号解析。要通过标准网络超链接实现 DOI 号解析，DOI 号自身应添加到代理服务器地址中。

URL 表示的和 HTTP 协议传输的 DOI 号受到限制，以遵守表示 URI 的标准 IETF 指南。URI 语法限制比 DOI 语法限制多，包含一些保留字符，需要使用 % 编码。

注： 特定客户或服务器软件可利用本地解析技术（如浏览器可编译 doi:10.1006/jmbi.1998.2354 并自动解析，而无需添加代理服务器地址）处理 DOI。

注：DOI 系统尽可能独立于特定技术实现。就网络应用而言，DOI 号可表达为 HTTP URI。做法很简单，只需将 DOI 预设为 http://doi.org/，然后（若需）使用 URL 或 URN 所要求的十六进制 (%) 编码。详细说明请见上述 2.5.2.4 小节。

有关如何使用 DOI 号网络解析的详细信息，请参见第 3 章，“解析”。有关本操作相关工具的信息，请参见DOI 工具。有关互联网标识符规范的 DOI 信息，请参见 DOI 系统专题资料 DOI 系统与互联网标识符规范。

2.6.3 URN 表达

为在 URN 标准工作流程中使用 DOI，DOI 代理服务器中使用冒号代替 DOI 号原有的斜线。因此，根据如下形式，DOI 号可表示为 doi.org 域名中的 URN，例如：把 DOI 号 10.123/456 写成 http://doi.org/urn:doi:10.123:456。不过，请注意 DOI 后缀可能包含其他斜线，此时必须使用 % 编码，而不能用冒号代替：例如 DOI 号 10.123/456ABC/zyz 可变为 http://doi.org/urn:doi:10.123:456ABC%2Fzyz，其中最后一个斜线字符编码为 %2F。

2.6.4 其他表达

DOI 号可在特定文本（如信息 URI 方案 RFC 4452）中使用其他形式表达。

根据特定的网络环境和所指对象所处的环境，或在可能发生的歧义的情况下（如减号、连字号和短破折号在屏幕上看起来很相似，但拥有不同的字符值），不能直接处理字符，而应采用合理的方式（如将 URL 转换为 UTF-8 加上 % 编码），以避免编码错误。

DOI 号亦可通过 ShortDOI 服务表示（shortdoi.org，请参见本文 2.10 小节）。ShortDOI 便于人们阅读，且标识符长度较短，不易出错。

一些特定的表达可以满足特殊的技术要求。例如，ANSI 标准“电缆传输的数字程序插入式字幕”(SCTE 35:201) 特别定义了有线电视系统的标准传输方法，将 EIDR DOI 号嵌入带内与节目同时播出。它采用了紧凑无损的 EIDR 表达方式，而非完整的 ASCII DOI 字符（请参见表 8-7）。同时也利用了 DOI 号的可解析性，说明此种方式插入的 ID 可以通过带外机制进行解析，从而收集更多的数据。

2.6.5 原则

既然内容多是通过数字和印刷媒体出版，通常会要求在出版时重新生成 DOI 号。出版商可将 DOI 号放入其命名的文档，以保证在下载或印刷项目时出现该 DOI 号。印刷数字版本时也会出现。如果网页中的一个按钮代表 DOI 号，则将光标移动到该按钮上面时，会在网络浏览窗口底部显示完整的 DOI 号。

在数字环境中，DOI 号可能被视为符合其环境且是最新的（其所指的活动链接是正确的），鉴于此，印刷版本一旦发布便不能更新或变更。在期刊文章等的印刷版本中标识 DOI 号的目的是告知读者该文章的 DOI 号，而非告诉读者如何从网上获取该篇文章；读者无需知道该 DOI 号是可用的。据此，印刷 DOI 号时需使用一种公认的形式，例如：http proxy server URL 形式，如 http://doi.org/10.1002/prot。不建议使用 URL 形式的原因如下：URL 不是文章的标识符，DOI 号才是；URL 的 doi.org 形式可能不是最具持久性的形式，需谨记这些印刷副本会存在几十年甚至上百年且保持不变。

实际操作中，使用 doi.org 形式很安全。即使在一些其他形式中普遍使用 DOI 号时，该形式依然会持续数年。但有可能几百年后，http:// 不再流行，那时这个问题就不太容易处理了。因此，我们建议制定方案，以展示无格式的 DOI 号并进行在线解析（以一种便捷的方式说明“该文章的 DOI 号为 10.1002/prot.999，可通过 http://doi.org/10.1002/prot.999 获在网络上获取其当前信息”或“经由 http://doi.org/... 获取……”）。

特定 DOI 系统实现和注册机构可针对特定应用，给出可行性建议。

DOI 系统的目的之一是获取已有的编码系统，DOI 号功能可以根据需求方便地添加到系统中。请参见以下专题资料，以获取更多信息：

2.7.1 简要说明

当单一资源拥有多个标识符（共指关系）时，可能在关联数据、语义网络应用等方面引发问题，主要起因在于不同系统之间的互操作性。如果不知道已存在另一个一模一样的标识符，就会出现问题；如果两个标识符据称但实际并不拥有同一个所指对象（这将彻底打破互操作性），就可能出现更大的问题。要成功统一多个本体和所指方案，则需要尽可能明确地声明和整合各种方案。本问题的一个重要方面就是 DOI 系统和其他 ISO 标识符方案之间的关系。

假设有一个 DOI 应用注册，我们称为 DOI-X，和一个已有 ISO 标准注册，我们称为 ISXI。两者都有一个注册中心（分别为 DOI-X RA 和 ISXI RA）。如果 DOI-X 认为正在标识一个已经拥有 ISXI 的对象，则 DOI-X 注册中心应询问 ISXI RA（或通过 IDF 询问 ISXI RA）是否同意以某种标准方式，在 DOI 号中对 ISXI 进行说明（可能是单独元数据或语法+元数据）。如果 ISXI 同意，则可达成并使用该机制；如果 ISXI 不同意，DOI-X 实际中仍应在 DOI 核心中（作为 referentIdentifier）对该 ISXI 进行说明。需要考虑的主要问题有：(1) ISXI 标识的和 DOI-X 所指的是否是同一对象（上述情况仅适用于两者为同一对象的情况）；(2) ISXI RA 和 DOI-X RA 是否有意愿达成交换记录的协议，如果有，条件是什么？ 如果该 ISXI RA 和 DOI-X RA 为同一机构，该情况通过内部协商即可解决。

其他 ISO TC46/SC9 标准请参见参考书目。

2.7.2 原则

DOI 号不应用于代替其他标识符方案如 ISAN、ISBN、ISRC、ISSN、ISTC、ISNI 和其他常见的标识符等，但和它们一起使用可以增加 DOI 系统功能，从而增强标识能力。

在 DOI 系统引入其他标识方案的指导原则是：为潜在用户提供最多功能，最大程度提高内部管理效率。

2.7.3 DOI 号与其它标识符方案在 DOI 系统内的关系表达

2.7.3.1 DOI 号的所指对象的标识符已存在于其他标识符方案

如果一个 DOI 号的所指对象的标识符已存在于其他一个或多个常见的标识符方案，则至少使用下列方法中的一种，以表示其关系：

a）在 DOI 元数据字段“referentIdentifier(s)”（标识同一所指对象的其他标识符）中对其他已有标识符进行说明，无论该标识符是否加入该 DOI 号语法。

b）将已有标识符作为所指对象 DOI 号的一个部分添加进来。

例一和例二表示的是将 ISBN 和 ISSN 添加到 DOI 号里。也可以使用其他达成一致的整合语法，国际数字对象标识符 (DOI) 基金会负责维护当前达成一致的方案的信息（请参见专题资料 DOI 系统®和标准标识符方案。例三表示 DOI 号不是其他标识符方案的替代品。

不过，两个标识符字符串的所指对象是相同的。

2.7.3.2 向 DOI 号添加已有的标识符

如果语法规则允许从另一方案向 DOI 号添加已有标识符，则此类规则不能作为本国际标准的内容。这种情况下，要注意以下几点：

a) 相同所指对象应由 DOI 号和所包含的标识符字符串共同表示，使其可作为单独实体在 DOI 系统中区分出来。

b) DOI 系统自身内，DOI 号是个模糊字符串。无法从 DOI 号的特定字符串推断出任何确定性信息。对于为其他标识符方案设计的任何非 DOI 应用，不保证 DOI 号是可用的（见上述例三）。

c) 应在 DOI 元数据字段“referentIdentifier(s)”（标识同一所指对象的其他标识符）中对多个（三个、四个等）标识符进行说明，而非将其添加至 DOI 号。

d) ISO 26324 注册中心应负责维护从另一方案添加已有标识符的特定语法规则。

2.7.3.3 附加功能

DOI 系统功能可补充其他标识符服务，这些服务来自于其他参与方，例如各种环境下的标识符解析等。多个服务商可提供使用标识符的服务。某些标识符系统规则让使用指定的首选服务提供商成为必然；这种情况下，标识符应用应遵守相关注册中心的规定。各标识符方案注册中心在其自己的方案或社区内自主决定使用规则。国际数字对象标识符 (DOI) 基金会负责维护当前达成一致的、与其他标识符方案共同使用的特定机制的信息。

ISO 方案原则同样适用于非 ISO方案。已有的标准标识系统编码可添加到一个 DOI 号，如果注册者认为这么做很方便；或者已有的标准标识系统编码可添加到 DOI 元数据。如果将已有的标准标识系统编码添加到一个 DOI 号，则同样也应该将其添加到 DOI 元数据。任何情况下，同一实体在 DOI 和其他系统下的准确标识都至关重要。DOI 系统不是唯一一个可以添加已有标识符的系统：如条形码亦可用于表达 ISBN。

由于可在 DOI 号或记录内使用任何已有的传统标识符，使用特定的 DOI 系统可以带来前所未有的互操作性。例如，在 DOI 系统的 CrossRef 实现中，一些出版社通过添加 PII 作为后缀，创建出自己的 DOI 号；一些添加 SICI 作为后缀；一些可能在以后添加 ISTC 作为后缀；还有一些则可能全部使用专用内部生产编码作为后缀。通过使用 DOI 号，各出版商在 CrossRef 系统内获得了数据互操作性的好处，他们无需为已在另一方案中分配标识符的实体“重新编码”。

注意 DOI 号核心元数据必须包括“标识符”：“唯一标识符（如传统方案中的）用于标识实体……如果该实体存在，则它通常会包含传统的标识符。”考虑包含已有（传统）标识符的数据集表明了此类要求存在的原因：即任何自动化处理均可使用已有传统方案。自动化处理使用该元素的核心声明，从 DOI 系统服务获取结构化元数据。正如前文所讲，DOI 号一直是隐性非解析字符串，传统标识符不能从 DOI 后缀自身安全恢复（例如 CrossRef 应用中后缀的异构集合 ）。此外，在后缀内包含传统标识符非常方便，使 DOI 号更加容易理解，更加便于管理。当然，这并非创建 DOI 号的必要要求。

2.8.1 使用 DOI 号表达与已有传统标识符的关系

实体之间的关系可通过元数据表达。例如抽象作品的一章即为该作品的一个节选（正如 ISTC 元数据所表达的一样），也（如果需要标识为一件作品）可以拥有有 ISTC。一旦对实体进行规定，实体间的关系就可表达为元数据中的一项（“有人认为这种关系存在于两个实体之间”）。如果可获得合适的元数据或规范，就可以表达任何想要表达的关系。DOI 系统细化了应用配置文件的技术架构，可利用 DOI 系统服务进行例证。

2.8.2 使用带有 DOI 号的传统标识符的好处

除了 DOI 号的一般好处外，将已有标准编码方案添加到 DOI 号还有一些独特优点：

2.8.3 其他标识符方案中的 DOI 号表达方式

具体应用的行业可以定义其正式的表达方式，从而在其系统中应用 DOI 号。例如，电影与电视工程师协会 (SMPTE) 推荐标准 2079（SMPTE RP 2079:2013： “数字对象标识符 (DOI) 号娱乐业标识注册 (EIDR) 标识符表达方式”）就定义了 SMPTE 领域内 DOI 号的表达方式。SMPTE RP 2021-5:2013 中的一条相关内容指出：“使用 AD-ID 和 EIDR 作为 SMPTE BXF 和 ATSC PMCP 的备用标识符”，从而允许电视机和有线电视的内容管理系统使用 EIDR 注册机构的 DOI 号。

DOI 号是一个模糊字符串。DOI 系统本身不能利用校验数位。这是有意为之，原因如下：

不过，其他应用可利用校验数位，如果对其他一些应用有用，可将校验和数位插入 DOI 号。特定 DOI 系统应用使用的校验和，可由相关注册机构作为应用规则引入。例如：EIDR 应用中，仅在 DOI 后缀上计算校验字符。这里不包括前缀是因为如果前缀不正确，DOI 很可能会进入错误解析系统。EIDR 注册单独验证通过 API 发送的任何 DOI 前缀。

shortDOI 服务是一项面向所有人的公共服务，为包含冗长字符串的 DOI 号创建短路径。shortDOI 服务的功能和 URL 短地址服务类似。

注意 shortDOI 本身并不是 DOI。shortDOI 不是 DOI，因此不符合 ISO 标准句法和其他要求。shortDOI 仅可为已有的 DOI 创建。IDF 根据 handle 提供两种服务： DOI 服务和 shortDOI 服务。

该服务以 10/abcde 的形式创建短 handle，http://doi.org/abcde 形式的短 HTTP URI 非常适合电子邮箱、博客、手机短信等使用。

http://doi.org 的 shortDOI 服务代理服务器只解析短路径，与 http://doi.org DOI 系统代理服务器解析完整 DOI 号的方式一样。（两代理的错误页面在适当的时候会提供指向另一代理的链接。）该服务或创建一个新的短路径，或返回已创建的短路径。

为实现自动化，shortDOI 服务只需将原 DOI 号附到 URl 上即可使用。可使用格式化的参数指定返回信息的方式。详细信息请参见 shortDOI 服务 网页。

该专题资料目前已上线，介绍了 DOI 系统和 URL，URN 和 URI 等通用标识符的关系。请详见“DOI® 系统与互联网标识符规范”。

上一章节：1 简介    下一章节：3 解析