常见问题解答(FAQ)

答：不是的。AsciiDoc提供全面的Unicode支持（默认UTF-8，带BOM的UTF-16）。👌

AsciiDoc（以及Asciidoctor）中的“Ascii”仅仅指用来定义该语言语法的字符范围（例如，块定界符、章节标记、列表标记、属性列表边界、内置属性和块名称等）。换句话说，你只需使用US-ASCII字符集就能表达一个AsciiDoc文档的结构。至于内容本身，包括段落、标题、逐字块、属性名称和值、自定义块名称等，可以包含Unicode字符集中任意字符范围的字符。

AsciiDoc处理器假定输入使用UTF-8编码，并且它也将输出文档编码为UTF-8。

一个*转换器*是执行从AsciiDoc到可发布格式转换的软件。一个*后端*是针对预期输出格式的标识符，因此会告诉AsciiDoc处理器使用哪个转换器。您可以将后端视为转换器的别名。

后端代表用户的意图将AsciiDoc文档转换为指定格式（例如，`html5`表示HTML 5格式）。该后端也作为一个标识符，告诉处理器使用哪个转换器。一个后端可以绑定（即，宣称拥有）超过一个转换器，以提供用户生成指定输出格式的替代方案。例如，`pdf`后端可以由Asciidoctor PDF满足，但它也可能映射到一个不同的实现。最后一个向后端注册自己的转换器将胜出。

媒体类型（也称为MIME类型）是用于识别通过互联网传输的文件格式和内容格式的代码。目前为止，还没有为AsciiDoc注册官方的媒体类型。然而，负责监督AsciiDoc语言规范的AsciiDoc工作组计划提交一项提案，以注册AsciiDoc的官方媒体类型。详见[asciidoctor#2502](https://github.com/asciidoctor/asciidoctor/issues/2502)。

建议的AsciiDoc媒体类型如下：

name: text/asciidoc extensions: .adoc, .asciidoc

名称`text/asciidoc`遵循了用于Markdown的惯例。首选的扩展名是`.adoc`。`.asciidoc`扩展名只是为了与现有文档向后兼容而包含的。

关于命名媒体类型的详细信息，请参见https://tools.ietf.org/html/rfc7763。

如果文档属性是一个仅限标题的属性，请确保它在文档标题中定义或通过命令行界面（CLI）或应用程序编程接口（API）传入。否则，文档属性将不会有任何效果。

请记住，文档头部在首个空行或者块结束，以先到者为准。如果你打算作为文档头部内容的某处有一个空行，那么在那个空行之后的属性条目将会被定义在正文中，而不是头部。这很可能就是你遇到的问题所在。如果你移除那些空行，你的属性应该就会被识别。

如果文档属性不是仅限标题的属性，请确保它在任何分隔块之外（使用属性条目）被定义，并且与其他块之间至少有一行空行。

当内容在文档的后半部分没有按照你的预期显示时，通常是因为一个限定块缺少了它的关闭界定线。限定块内的解析规则是不同的。如果保持打开状态，它可能会影响AsciiDoc处理器对文档结构的解释。例如，从那一点开始，AsciiDoc处理器将停止识别节标题。

要解决这个问题，首先要寻找缺少的定界线。如果检测到这种情况，AsciiDoc处理器必须警告你。在文本编辑器中的语法高亮显示也可以帮助识别这个问题。另外，查看渲染后的输出，以确定块样式是否延伸到了你未预期的地方。

最狡猾的罪魁祸首是开放式的区块。尽管一个开放区块没有任何特殊的样式，但它确实将定界区块的语义应用到其内容中。你可以添加一个角色来应用自定义样式，例如红色轮廓，这样你就可以看到它的边界。

AsciiDoc 处理器会对段落内容应用正常的替换，包括URL或链接宏的目标。作者需要自己来转义这些语法。请查看macros:complex-urls.html来找到可以用来解决这个问题的技巧。