MD写作规则

本文档描述了所有规则及其检查的内容，以及违反规则的文档示例和修正后的示例版本。来源于https://github.com/DavidAnson/markdownlint/

`MD001` - 标题级别应一次只递增一级

标签：headings

别名：heading-increment

参数：

front_matter_title：用于匹配 Front Matter 中标题属性的正则表达式（string，默认值为 ^\s*title\s*[:=]）

如果在 Markdown 文档中跳过了标题级别，则会触发此规则，例如：

# 一级标题

### 三级标题

在此文档中我们跳过了二级标题

使用多个标题级别时，嵌套标题应每次只增加一级：

# 一级标题

## 二级标题

### 三级标题

#### 四级标题

## 另一个二级标题

### 另一个三级标题

如果存在 YAML 格式的 Front Matter 且包含 title 属性（常用于博客文章），此规则会将其视为顶级标题，并在实际出现的第一个标题不是二级标题时报告违规。如需在 Front Matter 中使用其他属性名，请通过 front_matter_title 参数指定正则表达式文本。若要禁用此规则对 Front Matter 的检测，可将 front_matter_title 设为 ""。当没有 Front Matter 时，第一个标题可以是任意级别。

理由：标题代表文档的结构，跳过级别会令人困惑——尤其对于无障碍访问场景而言。更多信息：https://www.w3.org/WAI/tutorials/page-structure/headings/。

`MD003` - 标题样式

标签：headings

别名：heading-style

参数：

style：标题样式（string，默认值为 consistent，可选值：atx / atx_closed / consistent / setext / setext_with_atx / setext_with_atx_closed）

当在同一文档中使用了不同的标题样式时，会触发此规则：

# ATX 风格一级标题

## Closed ATX 风格二级标题 ##

Setext 风格一级标题
===============

要修正此问题，请在整个文档中使用一致的标题样式：

# ATX 风格一级标题

## ATX 风格二级标题

setext_with_atx 和 setext_with_atx_closed 设置允许在包含 Setext 风格标题（仅支持一级和二级标题）的文档中对三级及以上的标题使用 ATX 样式：

Setext 风格一级标题
===============

Setext 风格二级标题
---------------

### ATX 风格三级标题

注意：配置的标题样式可以指定为必须使用的某种样式（atx、atx_closed、setext、setext_with_atx、setext_with_atx_closed），也可以通过 consistent 要求所有标题样式与第一个标题的样式保持一致。

注意：在文本行正下方放置水平分隔线会将该文本转换为二级 Setext 风格标题，从而触发此规则：

一行文本，后跟水平分隔线，会成为标题
---

理由：一致的格式使文档更容易理解。

`MD004` - 无序列表样式

标签：bullet、ul

别名：ul-style

参数：

style：列表样式（string，默认值为 consistent，可选值：asterisk / consistent / dash / plus / sublist）

可修复：部分违规可通过工具自动修复

当文档中用于无序列表项的符号与配置的无序列表样式不符时，会触发此规则：

* 条目 1
+ 条目 2
- 条目 3

要修正此问题，请在整个文档中使用配置的列表符号样式：

* 条目 1
* 条目 2
* 条目 3

配置的列表样式可以确保所有列表使用特定的符号（asterisk、plus、dash），确保每个子列表使用的符号与其父列表不同（sublist），或要求所有列表样式与第一个列表的样式保持一致（consistent）。

例如，以下内容对于 sublist 样式是有效的，因为最外层缩进使用星号，中间缩进使用加号，最内层缩进使用减号：

* 条目 1
  + 条目 2
    - 条目 3
  + 条目 4
* 条目 4
  + 条目 5

理由：一致的格式使文档更容易理解。

`MD005` - 同级列表项的缩进不一致

标签：bullet、indentation、ul

别名：list-indent

可修复：部分违规可通过工具自动修复

当列表项被解析为同一级别，但缩进不一致时，会触发此规则：

* 条目 1
  * 嵌套条目 1
  * 嵌套条目 2
   * 一个未对齐的条目

此规则通常因笔误而触发。修正列表的缩进即可解决：

* 条目 1
  * 嵌套条目 1
  * 嵌套条目 2
  * 嵌套条目 3

顺序列表标记通常左对齐，以使所有条目具有相同的起始列：

...
8. 条目
9. 条目
10. 条目
11. 条目
...

此规则也支持列表标记的右对齐，以使所有条目具有相同的结束列：

...
 8. 条目
 9. 条目
10. 条目
11. 条目
...

理由：违反此规则可能导致内容渲染不正确。

`MD007` - 无序列表缩进

标签：bullet、indentation、ul

别名：ul-indent

参数：

indent：缩进空格数（integer，默认值 2）
start_indent：第一级缩进空格数（当 start_indented 设置时）（integer，默认值 2）
start_indented：是否缩进列表的第一级（boolean，默认值 false）

可修复：部分违规可通过工具自动修复

当列表项未按照配置的空格数（默认：2）缩进时，会触发此规则。

示例：

* 条目
   * 嵌套条目缩进了3个空格

修正后示例：

* 条目
  * 嵌套条目缩进了2个空格

注意：此规则仅当子列表的所有父列表也是无序列表时适用（否则，有序列表的额外缩进会干扰此规则）。

start_indented 参数允许列表的第一级缩进配置的空格数，而不是从零开始。start_indent 参数允许列表的第一级缩进不同数量的空格（当 start_indented 未设置时忽略）。

理由：缩进2个空格使得嵌套列表的内容在列表标记后使用单个空格时与父列表内容的起始位置对齐。缩进4个空格与代码块一致，且更易于编辑器的实现。此外，这可能是其他 Markdown 解析器的兼容性问题，它们要求4个空格的缩进。更多信息：Markdown 样式指南。

注意：参见 Prettier.md 了解兼容性信息。

`MD009` - 尾随空格

标签：whitespace

别名：no-trailing-spaces

参数：

br_spaces：换行的空格数（integer，默认值 2）
code_blocks：包含代码块（boolean，默认值 false）
list_item_empty_lines：允许列表项中的空行使用空格（boolean，默认值 false）
strict：包含不必要的换行（boolean，默认值 false）

可修复：部分违规可通过工具自动修复

此规则在任意以意外空格结尾的行上触发。要修复，请删除行尾的尾随空格。

br_spaces 参数允许对此规则设置特定数量的尾随空格作为例外，通常用于插入显式换行。默认值允许2个空格表示硬换行（<br> 元素）。（必须将 br_spaces 设置为 >= 2 的值才能使此参数生效。将 br_spaces 设置为 1 与设置为 0 的行为相同，不允许任何尾随空格。）

默认情况下，缩进和围栏代码块中允许尾随空格，因为某些编程语言需要。要报告此类情况，请将 code_blocks 参数设置为 true。

默认情况下，此规则不会在使用允许数量的空格时触发，即使它没有创建硬换行（例如，在段落末尾）。要报告此类情况，请将 strict 参数设置为 true。

文本 文本 文本
文本[2个空格]

通常不需要在列表项内的空白行使用空格，但某些解析器可能需要。将 list_item_empty_lines 参数设置为 true 以允许这种情况（即使 strict 为 true）：

- 列表项文本
  [2个空格]
  列表项文本

理由：除了用于创建换行外，尾随空格没有用途，并且不影响内容的渲染。

`MD010` - 硬制表符

标签：hard_tab、whitespace

别名：no-hard-tabs

参数：

code_blocks：包含代码块（boolean，默认值 true）
ignore_code_languages：要忽略的围栏代码语言（string[]，默认值 []）
spaces_per_tab：每个硬制表符的空格数（integer，默认值 1）

可修复：部分违规可通过工具自动修复

此规则在包含硬制表符而不是使用空格缩进的行上触发。要修复，请用空格替换任何硬制表符。

示例：

一些文本

	* 使用硬制表符缩进条目

修正后示例：

一些文本

    * 使用空格缩进条目

您可以为此规则排除代码块和代码范围。为此，请将 code_blocks 参数设置为 false。默认情况下包含代码块和范围，因为 Markdown 工具对制表符的处理可能不一致（例如，使用4个空格 vs. 8个空格）。

当扫描代码块时（例如，默认情况下或如果 code_blocks 为 true），可以将 ignore_code_languages 参数设置为一个应忽略的语言列表（即，允许但不需要硬制表符）。这使文档更容易包含需要硬制表符的语言的代码。

默认情况下，此规则的违规通过将制表符替换为1个空格字符来修复。要使用不同数量的空格，请将 spaces_per_tab 参数设置为所需值。

理由：硬制表符通常被不同的编辑器不一致地渲染，并且可能比空格更难使用。

更多信息：

`MD011` - 反转的链接语法

标签：links

别名：no-reversed-links

可修复：部分违规可通过工具自动修复

当遇到看似链接但语法似乎反转（[] 和 () 顺序颠倒）的文本时，会触发此规则：

(不正确的链接语法)[https://www.example.com/]

要修复，请交换 [] 和 ()：

[正确的链接语法](https://www.example.com/)

注意：Markdown Extra 风格的脚注不会触发此规则：

For (example)[^1]

理由：反转的链接不会渲染为可用的链接。

`MD012` - Multiple consecutive blank lines

Tags: blank_lines, whitespace

Aliases: no-multiple-blanks

Parameters:

maximum: Consecutive blank lines (integer, default 1)

Fixable: Some violations can be fixed by tooling

This rule is triggered when there are multiple consecutive blank lines in the document:

Some text here


Some more text here

To fix this, delete the offending lines:

Some text here

Some more text here

Note: this rule will not be triggered if there are multiple consecutive blank lines inside code blocks.

Note: The maximum parameter can be used to configure the maximum number of consecutive blank lines.

Rationale: Except in a code block, blank lines serve no purpose and do not affect the rendering of content.

`MD013` - Line length

Tags: line_length

Aliases: line-length

Parameters:

code_block_line_length: Number of characters for code blocks (integer, default 80)
code_blocks: Include code blocks (boolean, default true)
heading_line_length: Number of characters for headings (integer, default 80)
headings: Include headings (boolean, default true)
line_length: Number of characters (integer, default 80)
stern: Stern length checking (boolean, default false)
strict: Strict length checking (boolean, default false)
tables: Include tables (boolean, default true)

This rule is triggered when there are lines that are longer than the configured line_length (default: 80 characters). To fix this, split the line up into multiple lines. To set a different maximum length for headings, use heading_line_length. To set a different maximum length for code blocks, use code_block_line_length

This rule has an exception when there is no whitespace beyond the configured line length. This allows you to include items such as long URLs without being forced to break them in the middle. To disable this exception, set the strict parameter to true and an issue will be reported when any line is too long. To warn for lines that are too long and could be fixed but allow long lines without spaces, set the stern parameter to true.

For example (assuming normal behavior):

IF THIS LINE IS THE MAXIMUM LENGTH
This line is okay because there are-no-spaces-beyond-that-length
This line is a violation because there are spaces beyond that length
This-line-is-okay-because-there-are-no-spaces-anywhere-within

In strict mode, the last three lines above are all violations. In stern mode, the middle two lines above are both violations, but the last is okay.

You have the option to exclude this rule for code blocks, tables, or headings. To do so, set the code_blocks, tables, or headings parameter(s) to false.

Code blocks are included in this rule by default since it is often a requirement for document readability, and tentatively compatible with code rules. Still, some languages do not lend themselves to short lines.

Lines with link/image reference definitions and standalone lines (i.e., not part of a paragraph) with only a link/image (possibly using (strong) emphasis) are always exempted from this rule (even in strict mode) because there is often no way to split such lines without breaking the URL.

Rationale: Extremely long lines can be difficult to work with in some editors. More information: https://cirosantilli.com/markdown-style-guide#line-wrapping.

`MD014` - Dollar signs used before commands without showing output

Tags: code

Aliases: commands-show-output

Fixable: Some violations can be fixed by tooling

This rule is triggered when there are code blocks showing shell commands to be typed, and all of the shell commands are preceded by dollar signs ($):

$ ls
$ cat foo
$ less bar

The dollar signs are unnecessary in this situation, and should not be included:

ls
cat foo
less bar

Showing output for commands preceded by dollar signs does not trigger this rule:

$ ls
foo bar
$ cat foo
Hello world
$ cat bar
baz

Because some commands do not produce output, it is not a violation if some commands do not have output:

$ mkdir test
mkdir: created directory 'test'
$ ls test

Rationale: It is easier to copy/paste and less noisy if the dollar signs are omitted when they are not needed. See https://cirosantilli.com/markdown-style-guide#dollar-signs-in-shell-code for more information.

`MD018` - No space after hash on atx style heading

Tags: atx, headings, spaces

Aliases: no-missing-space-atx

Fixable: Some violations can be fixed by tooling

This rule is triggered when spaces are missing after the hash characters in an atx style heading:

#Heading 1

##Heading 2

To fix this, separate the heading text from the hash character by a single space:

# Heading 1

## Heading 2

Rationale: Violations of this rule can lead to improperly rendered content.

`MD019` - Multiple spaces after hash on atx style heading

Tags: atx, headings, spaces

Aliases: no-multiple-space-atx

Fixable: Some violations can be fixed by tooling

This rule is triggered when more than one space is used to separate the heading text from the hash characters in an atx style heading:

#  Heading 1

##  Heading 2

To fix this, separate the heading text from the hash character by a single space:

# Heading 1

## Heading 2

Rationale: Extra space has no purpose and does not affect the rendering of content.

`MD020` - No space inside hashes on closed atx style heading

Tags: atx_closed, headings, spaces

Aliases: no-missing-space-closed-atx

Fixable: Some violations can be fixed by tooling

This rule is triggered when spaces are missing inside the hash characters in a closed atx style heading:

#Heading 1#

##Heading 2##

To fix this, separate the heading text from the hash character by a single space:

# Heading 1 #

## Heading 2 ##

Note: this rule will fire if either side of the heading is missing spaces.

Rationale: Violations of this rule can lead to improperly rendered content.

`MD021` - Multiple spaces inside hashes on closed atx style heading

Tags: atx_closed, headings, spaces

Aliases: no-multiple-space-closed-atx

Fixable: Some violations can be fixed by tooling

This rule is triggered when more than one space is used to separate the heading text from the hash characters in a closed atx style heading:

#  Heading 1  #

##  Heading 2  ##

To fix this, separate the heading text from the hash character by a single space:

# Heading 1 #

## Heading 2 ##

Note: this rule will fire if either side of the heading contains multiple spaces.

Rationale: Extra space has no purpose and does not affect the rendering of content.

`MD022` - Headings should be surrounded by blank lines

Tags: blank_lines, headings

Aliases: blanks-around-headings

Parameters:

lines_above: Blank lines above heading (integer|integer[], default 1)
lines_below: Blank lines below heading (integer|integer[], default 1)

Fixable: Some violations can be fixed by tooling

This rule is triggered when headings (any style) are either not preceded or not followed by at least one blank line:

# Heading 1
Some text

Some more text
## Heading 2

To fix this, ensure that all headings have a blank line both before and after (except where the heading is at the beginning or end of the document):

# Heading 1

Some text

Some more text

## Heading 2

The lines_above and lines_below parameters can be used to specify a different number of blank lines (including 0) above or below each heading. If the value -1 is used for either parameter, any number of blank lines is allowed. To customize the number of lines above or below each heading level individually, specify a number[] where values correspond to heading levels 1-6 (in order).

Notes: If lines_above or lines_below are configured to require more than one blank line, MD012/no-multiple-blanks should also be customized. This rule checks for at least as many blank lines as specified; any extra blank lines are ignored.

Rationale: Aside from aesthetic reasons, some parsers, including kramdown, will not parse headings that don’t have a blank line before, and will parse them as regular text.

`MD023` - Headings must start at the beginning of the line

Tags: headings, spaces

Aliases: heading-start-left

Fixable: Some violations can be fixed by tooling

This rule is triggered when a heading is indented by one or more spaces:

Some text

  # Indented heading

To fix this, ensure that all headings start at the beginning of the line:

Some text

# Heading

Note that scenarios like block quotes “indent” the start of the line, so the following is also correct:

> # Heading in Block Quote

Rationale: Headings that don’t start at the beginning of the line will not be parsed as headings, and will instead appear as regular text.

`MD024` - Multiple headings with the same content

Tags: headings

Aliases: no-duplicate-heading

Parameters:

siblings_only: Only check sibling headings (boolean, default false)

This rule is triggered if there are multiple headings in the document that have the same text:

# Some text

## Some text

To fix this, ensure that the content of each heading is different:

# Some text

## Some more text

If the parameter siblings_only is set to true, duplication is allowed for headings with different parents (as is common in changelogs):

# Change log

## 1.0.0

### Features

## 2.0.0

### Features

Rationale: Some Markdown parsers generate anchors for headings based on the heading name; headings with the same content can cause problems with that.

`MD025` - Multiple top-level headings in the same document

Tags: headings

Aliases: single-h1, single-title

Parameters:

front_matter_title: RegExp for matching title in front matter (string, default ^\s*title\s*[:=])
level: Heading level (integer, default 1)

This rule is triggered when a top-level heading is in use (the first line of the file is an h1 heading), and more than one h1 heading is in use in the document:

# Top level heading

# Another top-level heading

To fix, structure your document so there is a single h1 heading that is the title for the document. Subsequent headings must be lower-level headings (h2, h3, etc.):

# Title

## Heading

## Another heading

Note: The level parameter can be used to change the top-level (ex: to h2) in cases where an h1 is added externally.

If YAML front matter is present and contains a title property (commonly used with blog posts), this rule treats that as a top level heading and will report a violation for any subsequent top-level headings. To use a different property name in the front matter, specify the text of a regular expression via the front_matter_title parameter. To disable the use of front matter by this rule, specify "" for front_matter_title.

Rationale: A top-level heading is an h1 on the first line of the file, and serves as the title for the document. If this convention is in use, then there can not be more than one title for the document, and the entire document should be contained within this heading.

`MD026` - Trailing punctuation in heading

Tags: headings

Aliases: no-trailing-punctuation

Parameters:

punctuation: Punctuation characters (string, default .,;:!。，；：！)

Fixable: Some violations can be fixed by tooling

This rule is triggered on any heading that has one of the specified normal or full-width punctuation characters as the last character in the line:

# This is a heading.

To fix this, remove the trailing punctuation:

# This is a heading

Note: The punctuation parameter can be used to specify what characters count as punctuation at the end of a heading. For example, you can change it to ".,;:" to allow headings that end with an exclamation point. ? is allowed by default because of how common it is in headings of FAQ-style documents. Setting the punctuation parameter to "" allows all characters - and is equivalent to disabling the rule.

Note: The trailing semicolon of HTML entity references like ©, ©, and © is ignored by this rule.

Rationale: Headings are not meant to be full sentences. More information: Punctuation at the end of headers.

`MD027` - Multiple spaces after blockquote symbol

Tags: blockquote, indentation, whitespace

Aliases: no-multiple-space-blockquote

Parameters:

list_items: Include list items (boolean, default true)

Fixable: Some violations can be fixed by tooling

This rule is triggered when blockquotes have more than one space after the blockquote (>) symbol:

>  This is a blockquote with bad indentation
>  there should only be one.

To fix, remove any extraneous space:

> This is a blockquote with correct
> indentation.

Inferring intended list indentation within a blockquote can be challenging; setting the list_items parameter to false disables this rule for ordered and unordered list items.

Rationale: Consistent formatting makes it easier to understand a document.

`MD028` - Blank line inside blockquote

Tags: blockquote, whitespace

Aliases: no-blanks-blockquote

This rule is triggered when two blockquote blocks are separated by nothing except for a blank line:

> This is a blockquote
> which is immediately followed by

> this blockquote. Unfortunately
> In some parsers, these are treated as the same blockquote.

To fix this, ensure that any blockquotes that are right next to each other have some text in between:

> This is a blockquote.

And Jimmy also said:

> This too is a blockquote.

Alternatively, if they are supposed to be the same quote, then add the blockquote symbol at the beginning of the blank line:

> This is a blockquote.
>
> This is the same blockquote.

Rationale: Some Markdown parsers will treat two blockquotes separated by one or more blank lines as the same blockquote, while others will treat them as separate blockquotes.

`MD029` - Ordered list item prefix

Tags: ol

Aliases: ol-prefix

Parameters:

style: List style (string, default one_or_ordered, values one / one_or_ordered / ordered / zero)

Fixable: Some violations can be fixed by tooling

This rule is triggered for ordered lists that do not either start with ‘1.’ or do not have a prefix that increases in numerical order (depending on the configured style). The less-common pattern of using ‘0.’ as a first prefix or for all prefixes is also supported.

Example valid list if the style is configured as ‘one’:

1. Do this.
2. Do that.
3. Done.

Examples of valid lists if the style is configured as ‘ordered’:

1. Do this.
2. Do that.
3. Done.

0. Do this.
1. Do that.
2. Done.

All three examples are valid when the style is configured as ‘one_or_ordered’.

Example valid list if the style is configured as ‘zero’:

0. Do this.
1. Do that.
2. Done.

Example invalid list for all styles:

1. Do this.
2. Done.

This rule supports 0-prefixing ordered list items for uniform indentation:

...
8. Item
9. Item
10. Item
11. Item
...

Note: This rule will report violations for cases like the following where an improperly-indented code block (or similar) appears between two list items and “breaks” the list in two:

1. First list

```text
Code block
```

1. Second list

The fix is to indent the code block so it becomes part of the preceding list item as intended:

1. First list

   ```text
   Code block
   ```

2. Still first list

Rationale: Consistent formatting makes it easier to understand a document.

`MD030` - Spaces after list markers

Tags: ol, ul, whitespace

Aliases: list-marker-space

Parameters:

ol_multi: Spaces for multi-line ordered list items (integer, default 1)
ol_single: Spaces for single-line ordered list items (integer, default 1)
ul_multi: Spaces for multi-line unordered list items (integer, default 1)
ul_single: Spaces for single-line unordered list items (integer, default 1)

Fixable: Some violations can be fixed by tooling

This rule checks for the number of spaces between a list marker (e.g. ‘-’, ‘*’, ‘+’ or ‘1.’) and the text of the list item.

The number of spaces checked for depends on the document style in use, but the default is 1 space after any list marker:

* Foo
* Bar
* Baz

1. Foo
2. Bar
3. Baz

4. Foo
   * Bar
1. Baz

A document style may change the number of spaces after unordered list items and ordered list items independently, as well as based on whether the content of every item in the list consists of a single paragraph or multiple paragraphs (including sub-lists and code blocks).

For example, the style guide at https://cirosantilli.com/markdown-style-guide#spaces-after-list-marker specifies that 1 space after the list marker should be used if every item in the list fits within a single paragraph, but to use 2 or 3 spaces (for ordered and unordered lists respectively) if there are multiple paragraphs of content inside the list:

* Foo
* Bar
* Baz

vs.

*   Foo

    Second paragraph

*   Bar

1.  Foo

    Second paragraph

2.  Bar

To fix this, ensure the correct number of spaces are used after the list marker for your selected document style.

Rationale: Violations of this rule can lead to improperly rendered content.

Note: See Prettier.md for compatibility information.

`MD031` - Fenced code blocks should be surrounded by blank lines

Tags: blank_lines, code

Aliases: blanks-around-fences

Parameters:

list_items: Include list items (boolean, default true)

Fixable: Some violations can be fixed by tooling

This rule is triggered when fenced code blocks are either not preceded or not followed by a blank line:

Some text
```
Code block
```

```
Another code block
```
Some more text

To fix this, ensure that all fenced code blocks have a blank line both before and after (except where the block is at the beginning or end of the document):

Some text

```
Code block
```

```
Another code block
```

Some more text

Set the list_items parameter to false to disable this rule for list items. Disabling this behavior for lists can be useful if it is necessary to create a tight list containing a code fence.

Rationale: Aside from aesthetic reasons, some parsers, including kramdown, will not parse fenced code blocks that don’t have blank lines before and after them.

`MD032` - Lists should be surrounded by blank lines

Tags: blank_lines, bullet, ol, ul

Aliases: blanks-around-lists

Fixable: Some violations can be fixed by tooling

This rule is triggered when lists (of any kind) are either not preceded or not followed by a blank line:

Some text
* List item
* List item

1. List item
2. List item
***

In the first case above, text immediately precedes the unordered list. In the second case above, a thematic break immediately follows the ordered list. To fix violations of this rule, ensure that all lists have a blank line both before and after (except when the list is at the very beginning or end of the document):

Some text

* List item
* List item

1. List item
2. List item

***

Note that the following case is not a violation of this rule:

1. List item
   More item 1
2. List item
More item 2

Although it is not indented, the text “More item 2” is referred to as a lazy continuation line and considered part of the second list item.

Rationale: In addition to aesthetic reasons, some parsers, including kramdown, will not parse lists that don’t have blank lines before and after them.

`MD033` - Inline HTML

Tags: html

Aliases: no-inline-html

Parameters:

allowed_elements: Allowed elements (string[], default [])
table_allowed_elements: Allowed elements in tables (string[], default [])

This rule is triggered whenever raw HTML is used in a Markdown document:

<h1>Inline HTML heading</h1>

To fix this, use ‘pure’ Markdown instead of including raw HTML:

# Markdown heading

To allow specific HTML elements anywhere in Markdown content, set the allowed_elements parameter to a list of HTML element names. To allow a specific set of HTML elements within Markdown tables, set the table_allowed_elements parameter to a list of HTML element names. This can be used to permit the use of <br>-style line breaks only within Markdown tables.

Rationale: Raw HTML is allowed in Markdown, but this rule is included for those who want their documents to only include “pure” Markdown, or for those who are rendering Markdown documents into something other than HTML.

`MD034` - Bare URL used

Tags: links, url

Aliases: no-bare-urls

Fixable: Some violations can be fixed by tooling

This rule is triggered whenever a URL or email address appears without surrounding angle brackets:

For more info, visit https://www.example.com/ or email user@example.com.

To fix this, add angle brackets around the URL or email address:

For more info, visit <https://www.example.com/> or email <user@example.com>.

If a URL or email address contains non-ASCII characters, it may be not be handled as intended even when angle brackets are present. In such cases, percent-encoding can be used to comply with the required syntax for URL and email.

Note: To include a bare URL or email without it being converted into a link, wrap it in a code span:

Not a clickable link: `https://www.example.com`

Note: The following scenario does not trigger this rule because it could be a shortcut link:

[https://www.example.com]

Note: The following syntax triggers this rule because the nested link could be a shortcut link (which takes precedence):

[text [shortcut] text](https://example.com)

To avoid this, escape both inner brackets:

[link \[text\] link](https://example.com)

Rationale: Without angle brackets, a bare URL or email isn’t converted into a link by some Markdown parsers.

`MD035` - Horizontal rule style

Tags: hr

Aliases: hr-style

Parameters:

style: Horizontal rule style (string, default consistent)

This rule is triggered when inconsistent styles of horizontal rules are used in the document:

---

- - -

***

* * *

****

To fix this, use the same horizontal rule everywhere:

---

---

The configured style can ensure all horizontal rules use a specific string or it can ensure all horizontal rules match the first horizontal rule (consistent).

Rationale: Consistent formatting makes it easier to understand a document.

`MD036` - Emphasis used instead of a heading

Tags: emphasis, headings

Aliases: no-emphasis-as-heading

Parameters:

punctuation: Punctuation characters (string, default .,;:!?。，；：！？)

This check looks for instances where emphasized (i.e. bold or italic) text is used to separate sections, where a heading should be used instead:

**My document**

Lorem ipsum dolor sit amet...

_Another section_

Consectetur adipiscing elit, sed do eiusmod.

To fix this, use Markdown headings instead of emphasized text to denote sections:

# My document

Lorem ipsum dolor sit amet...

## Another section

Consectetur adipiscing elit, sed do eiusmod.

Note: This rule looks for single-line paragraphs that consist entirely of emphasized text. It won’t fire on emphasis used within regular text, multi-line emphasized paragraphs, or paragraphs ending in punctuation (normal or full-width). Similarly to rule MD026, you can configure what characters are recognized as punctuation.

Rationale: Using emphasis instead of a heading prevents tools from inferring the structure of a document. More information: https://cirosantilli.com/markdown-style-guide#emphasis-vs-headers.

`MD037` - Spaces inside emphasis markers

Tags: emphasis, whitespace

Aliases: no-space-in-emphasis

Fixable: Some violations can be fixed by tooling

This rule is triggered when emphasis markers (bold, italic) are used, but they have spaces between the markers and the text:

Here is some ** bold ** text.

Here is some * italic * text.

Here is some more __ bold __ text.

Here is some more _ italic _ text.

To fix this, remove the spaces around the emphasis markers:

Here is some **bold** text.

Here is some *italic* text.

Here is some more __bold__ text.

Here is some more _italic_ text.

Rationale: Emphasis is only parsed as such when the asterisks/underscores aren’t surrounded by spaces. This rule attempts to detect where they were surrounded by spaces, but it appears that emphasized text was intended by the author.

`MD038` - Spaces inside code span elements

Tags: code, whitespace

Aliases: no-space-in-code

Fixable: Some violations can be fixed by tooling

This rule is triggered for code spans containing content with unnecessary space next to the beginning or ending backticks:

`some text `

` some text`

`   some text   `

To fix this, remove the extra space characters from the beginning and ending:

`some text`

Note: A single leading and trailing space is allowed by the specification and trimmed by the parser to support code spans that begin or end with a backtick:

`` `backticks` ``

`` backtick` ``

Note: When single-space padding is present in the input, it will be preserved (even if unnecessary):

` code `

Note: Code spans containing only spaces are allowed by the specification and are also preserved:

` `

`   `

Rationale: Violations of this rule are usually unintentional and can lead to improperly-rendered content.

`MD039` - Spaces inside link text

Tags: links, whitespace

Aliases: no-space-in-links

Fixable: Some violations can be fixed by tooling

This rule is triggered on links that have spaces surrounding the link text:

[ a link ](https://www.example.com/)

To fix this, remove the spaces surrounding the link text:

[a link](https://www.example.com/)

Rationale: Consistent formatting makes it easier to understand a document.

`MD040` - Fenced code blocks should have a language specified

Tags: code, language

Aliases: fenced-code-language

Parameters:

allowed_languages: List of languages (string[], default [])
language_only: Require language only (boolean, default false)

This rule is triggered when fenced code blocks are used, but a language isn’t specified:

```
#!/bin/bash
echo Hello world
```

To fix this, add a language specifier to the code block:

```bash
#!/bin/bash
echo Hello world
```

To display a code block without syntax highlighting, use:

```text
Plain text in a code block
```

You can configure the allowed_languages parameter to specify a list of languages code blocks could use. Languages are case sensitive. The default value is [] which means any language specifier is valid.

You can prevent extra data from being present in the info string of fenced code blocks. To do so, set the language_only parameter to true.

Info strings with leading/trailing whitespace (ex: js ) or other content (ex: ruby startline=3) will trigger this rule.

Rationale: Specifying a language improves content rendering by using the correct syntax highlighting for code. More information: https://cirosantilli.com/markdown-style-guide#option-code-fenced.

`MD041` - First line in a file should be a top-level heading

Tags: headings

Aliases: first-line-h1, first-line-heading

Parameters:

allow_preamble: Allow content before first heading (boolean, default false)
front_matter_title: RegExp for matching title in front matter (string, default ^\s*title\s*[:=])
level: Heading level (integer, default 1)

This rule is intended to ensure documents have a title and is triggered when the first line in a document is not a top-level (HTML h1) heading:

This is a document without a heading

To fix this, add a top-level heading to the beginning of the document:

# Document Heading

This is a document with a top-level heading

Because it is common for projects on GitHub to use an image for the heading of README.md and that pattern is not well-supported by Markdown, HTML headings are also permitted by this rule. For example:

<h1 align="center"><img src="https://placekitten.com/300/150"/></h1>

This is a document with a top-level HTML heading

In some cases, a document’s title heading may be preceded by text like a table of contents. This is not ideal for accessibility, but can be allowed by setting the allow_preamble parameter to true.

This is a document with preamble text

# Document Heading

If YAML front matter is present and contains a title property (commonly used with blog posts), this rule will not report a violation. To use a different property name in the front matter, specify the text of a regular expression via the front_matter_title parameter. To disable the use of front matter by this rule, specify "" for front_matter_title.

The level parameter can be used to change the top-level heading (ex: to h2) in cases where an h1 is added externally.

Rationale: The top-level heading often acts as the title of a document. More information: https://cirosantilli.com/markdown-style-guide#top-level-header.

`MD042` - No empty links

Tags: links

Aliases: no-empty-links

This rule is triggered when an empty link is encountered:

[an empty link]()

To fix the violation, provide a destination for the link:

[a valid link](https://example.com/)

Empty fragments will trigger this rule:

[an empty fragment](#)

But non-empty fragments will not:

[a valid fragment](#fragment)

Rationale: Empty links do not lead anywhere and therefore don’t function as links.

`MD043` - Required heading structure

Tags: headings

Aliases: required-headings

Parameters:

headings: List of headings (string[], default [])
match_case: Match case of headings (boolean, default false)

This rule is triggered when the headings in a file do not match the array of headings passed to the rule. It can be used to enforce a standard heading structure for a set of files.

To require exactly the following structure:

# Heading
## Item
### Detail

Set the headings parameter to:

[
    "# Heading",
    "## Item",
    "### Detail"
]

To allow optional headings as with the following structure:

# Heading
## Item
### Detail (optional)
## Foot
### Notes (optional)

Use the special value "*" meaning “zero or more unspecified headings” or the special value "+" meaning “one or more unspecified headings” and set the headings parameter to:

[
    "# Heading",
    "## Item",
    "*",
    "## Foot",
    "*"
]

To allow a single required heading to vary as with a project name:

# Project Name
## Description
## Examples

Use the special value "?" meaning “exactly one unspecified heading”:

[
    "?",
    "## Description",
    "## Examples"
]

When an error is detected, this rule outputs the line number of the first problematic heading (otherwise, it outputs the last line number of the file).

Note that while the headings parameter uses the ”## Text” ATX heading style for simplicity, a file may use any supported heading style.

By default, the case of headings in the document is not required to match that of headings. To require that case match exactly, set the match_case parameter to true.

Rationale: Projects may wish to enforce a consistent document structure across a set of similar content.

`MD044` - Proper names should have the correct capitalization

Tags: spelling

Aliases: proper-names

Parameters:

code_blocks: Include code blocks (boolean, default true)
html_elements: Include HTML elements (boolean, default true)
names: List of proper names (string[], default [])

Fixable: Some violations can be fixed by tooling

This rule is triggered when any of the strings in the names array do not have the specified capitalization. It can be used to enforce a standard letter case for the names of projects and products.

For example, the language “JavaScript” is usually written with both the ‘J’ and ‘S’ capitalized - though sometimes the ‘s’ or ‘j’ appear in lower-case. To enforce the proper capitalization, specify the desired letter case in the names array:

[
    "JavaScript"
]

Sometimes a proper name is capitalized differently in certain contexts. In such cases, add both forms to the names array:

[
    "GitHub",
    "github.com"
]

Set the code_blocks parameter to false to disable this rule for code blocks and spans. Set the html_elements parameter to false to disable this rule for HTML elements and attributes (such as when using a proper name as part of a path for a/href or img/src).

Rationale: Incorrect capitalization of proper names is usually a mistake.

`MD045` - Images should have alternate text (alt text)

Tags: accessibility, images

Aliases: no-alt-text

This rule reports a violation when an image is missing alternate text (alt text) information.

Alternate text is commonly specified inline as:

![Alternate text](image.jpg)

Or with reference syntax as:

![Alternate text][ref]

...

[ref]: image.jpg "Optional title"

Or with HTML as:

<img src="image.jpg" alt="Alternate text" />

Note: If the HTML aria-hidden attribute is used to hide the image from assistive technology, this rule does not report a violation:

<img src="image.jpg" aria-hidden="true" />

Guidance for writing alternate text is available from the W3C, Wikipedia, and other locations.

Rationale: Alternate text is important for accessibility and describes the content of an image for people who may not be able to see it.

`MD046` - Code block style

Tags: code

Aliases: code-block-style

Parameters:

style: Block style (string, default consistent, values consistent / fenced / indented)

This rule is triggered when unwanted or different code block styles are used in the same document.

In the default configuration this rule reports a violation for the following document:

Some text.

    # Indented code

More text.

```ruby
# Fenced code
```

More text.

To fix violations of this rule, use a consistent style (either indenting or code fences).

The configured code block style can be specific (fenced, indented) or can require all code blocks match the first code block (consistent).

Rationale: Consistent formatting makes it easier to understand a document.

`MD047` - Files should end with a single newline character

Tags: blank_lines

Aliases: single-trailing-newline

Fixable: Some violations can be fixed by tooling

This rule is triggered when there is not a single newline character at the end of a file.

An example that triggers the rule:

# Heading

This file ends without a newline.[EOF]

To fix the violation, add a newline character to the end of the file:

# Heading

This file ends with a newline.
[EOF]

Rationale: Some programs have trouble with files that do not end with a newline.

More information: What’s the point in adding a new line to the end of a file?

`MD048` - Code fence style

Tags: code

Aliases: code-fence-style

Parameters:

style: Code fence style (string, default consistent, values backtick / consistent / tilde)

This rule is triggered when the symbols used in the document for fenced code blocks do not match the configured code fence style:

```ruby
# Fenced code
```

~~~ruby
# Fenced code
~~~

To fix this issue, use the configured code fence style throughout the document:

```ruby
# Fenced code
```

```ruby
# Fenced code
```

The configured code fence style can be a specific symbol to use (backtick, tilde) or it can require all code fences match the first code fence (consistent).

Rationale: Consistent formatting makes it easier to understand a document.

`MD049` - Emphasis style

Tags: emphasis

Aliases: emphasis-style

Parameters:

style: Emphasis style (string, default consistent, values asterisk / consistent / underscore)

Fixable: Some violations can be fixed by tooling

This rule is triggered when the symbols used in the document for emphasis do not match the configured emphasis style:

*Text*
_Text_

To fix this issue, use the configured emphasis style throughout the document:

*Text*
*Text*

The configured emphasis style can be a specific symbol to use (asterisk, underscore) or can require all emphasis matches the first emphasis (consistent).

Note: Emphasis within a word is restricted to asterisk in order to avoid unwanted emphasis for words containing internal underscores like_this_one.

Rationale: Consistent formatting makes it easier to understand a document.

`MD050` - Strong style

Tags: emphasis

Aliases: strong-style

Parameters:

style: Strong style (string, default consistent, values asterisk / consistent / underscore)

Fixable: Some violations can be fixed by tooling

This rule is triggered when the symbols used in the document for strong do not match the configured strong style:

**Text**
__Text__

To fix this issue, use the configured strong style throughout the document:

**Text**
**Text**

The configured strong style can be a specific symbol to use (asterisk, underscore) or can require all strong matches the first strong (consistent).

Note: Emphasis within a word is restricted to asterisk in order to avoid unwanted emphasis for words containing internal underscores like__this__one.

Rationale: Consistent formatting makes it easier to understand a document.

`MD051` - Link fragments should be valid

Tags: links

Aliases: link-fragments

Parameters:

ignore_case: Ignore case of fragments (boolean, default false)
ignored_pattern: Pattern for ignoring additional fragments (string, default “)

Fixable: Some violations can be fixed by tooling

This rule is triggered when a link fragment does not match any of the fragments that are automatically generated for headings in a document:

# Heading Name

[Link](#fragment)

To fix this issue, change the link fragment to reference an existing heading’s generated name (see below):

# Heading Name

[Link](#heading-name)

For consistency, this rule requires fragments to exactly match the GitHub heading algorithm which converts letters to lowercase. Therefore, the following example is reported as a violation:

# Heading Name

[Link](#Heading-Name)

To ignore case when comparing fragments with heading names, the ignore_case parameter can be set to true. In this configuration, the previous example is not reported as a violation.

Alternatively, some platforms allow the syntax {#named-anchor} to be used within a heading to provide a specific name (consisting of only lower-case letters, numbers, -, and _):

# Heading Name {#custom-name}

[Link](#custom-name)

Alternatively, any HTML tag with an id attribute or an a tag with a name attribute can be used to define a fragment:

<a id="bookmark"></a>

[Link](#bookmark)

An a tag can be useful in scenarios where a heading is not appropriate or for control over the text of the fragment identifier.

HTML links to #top scroll to the top of a document. This rule allows that syntax (using lower-case for consistency):

[Link](#top)

This rule also recognizes the custom fragment syntax used by GitHub to highlight specific content in a document.

For example, this link to line 20:

[Link](#L20)

And this link to content starting within line 19 running into line 21:

[Link](#L19C5-L21C11)

Some Markdown generators dynamically create and insert headings when building documents, for example by combining a fixed prefix like figure- and an incrementing numeric counter. To ignore such generated fragments, set the ignored_pattern regular expression parameter to a pattern that matches (e.g., ^figure-).

Rationale: GitHub section links are created automatically for every heading when Markdown content is displayed on GitHub. This makes it easy to link directly to different sections within a document. However, section links change if headings are renamed or removed. This rule helps identify broken section links within a document.

Note: Section links are not part of the CommonMark specification; this rule enforces the GitHub heading algorithm:

Convert text to lowercase
Remove punctuation characters
Convert spaces to dashes
Append an incrementing integer (as needed for uniqueness)
URI-encode the result

`MD052` - Reference links and images should use a label that is defined

Tags: images, links

Aliases: reference-links-images

Parameters:

ignored_labels: Ignored link labels (string[], default ["x"])
shortcut_syntax: Include shortcut syntax (boolean, default false)

Links and images in Markdown can provide the link destination or image source at the time of use or can define it elsewhere and use a label for reference. The reference format is convenient for keeping paragraph text clutter-free and makes it easy to reuse the same URL in multiple places.

There are three kinds of reference links and images:

Full: [text][label]
Collapsed: [label][]
Shortcut: [label]

Full: ![text][image]
Collapsed: ![image][]
Shortcut: ![image]

[label]: https://example.com/label
[image]: https://example.com/image

A link or image renders correctly when the corresponding label is defined, but displays as text with brackets when the label is not present. By default, this rule warns of undefined labels for “full” and “collapsed” reference syntax but not for “shortcut” syntax because it is ambiguous.

The text [example] could be a shortcut link or the text “example” in brackets, so “shortcut” syntax is ignored by default. To include “shortcut” syntax, set the include_shortcut parameter to true. Note that doing so produces warnings for all text in the document that could be a shortcut. If bracketed text is intentional, brackets can be escaped with the \ character: \[example\].

If there are link labels that are deliberately unreferenced, they can be ignored by setting the ignored_labels parameter to the list of strings to ignore. The default value of this parameter ignores the checkbox syntax used by GitHub Flavored Markdown task list items:

- [x] Checked task list item

`MD053` - Link and image reference definitions should be needed

Tags: images, links

Aliases: link-image-reference-definitions

Parameters:

ignored_definitions: Ignored definitions (string[], default ["//"])

Fixable: Some violations can be fixed by tooling

Links and images in Markdown can provide the link destination or image source at the time of use or can use a label to reference a definition elsewhere in the document. The latter reference format is convenient for keeping paragraph text clutter-free and makes it easy to reuse the same URL in multiple places.

Because link and image reference definitions are located separately from where they are used, there are two scenarios where a definition can be unnecessary:

If a label is not referenced by any link or image in a document, that definition is unused and can be deleted.
If a label is defined multiple times in a document, the first definition is used and the others can be deleted.

This rule considers a reference definition to be used if any link or image reference has the corresponding label. The “full”, “collapsed”, and “shortcut” formats are all supported.

If there are reference definitions that are deliberately unreferenced, they can be ignored by setting the ignored_definitions parameter to the list of strings to ignore. The default value of this parameter ignores the following convention for adding non-HTML comments to Markdown:

[//]: # (This behaves like a comment)

`MD054` - Link and image style

Tags: images, links

Aliases: link-image-style

Parameters:

autolink: Allow autolinks (boolean, default true)
collapsed: Allow collapsed reference links and images (boolean, default true)
full: Allow full reference links and images (boolean, default true)
inline: Allow inline links and images (boolean, default true)
shortcut: Allow shortcut reference links and images (boolean, default true)
url_inline: Allow URLs as inline links (boolean, default true)

Fixable: Some violations can be fixed by tooling

Links and images in Markdown can provide the link destination or image source at the time of use or can use a label to reference a definition elsewhere in the document. The three reference formats are convenient for keeping paragraph text clutter-free and make it easy to reuse the same URL in multiple places.

By default, this rule allows all link/image styles.

Setting the autolink parameter to false disables autolinks:

<https://example.com>

Setting the inline parameter to false disables inline links and images:

[link](https://example.com)

![image](https://example.com)

Setting the full parameter to false disables full reference links and images:

[link][url]

![image][url]

[url]: https://example.com

Setting the collapsed parameter to false disables collapsed reference links and images:

[url][]

![url][]

[url]: https://example.com

Setting the shortcut parameter to false disables shortcut reference links and images:

[url]

![url]

[url]: https://example.com

To fix violations of this rule, change the link or image to use an allowed style. This rule can automatically fix violations when a link or image can be converted to the inline style (preferred) or a link can be converted to the autolink style (which does not support images and must be an absolute URL). This rule does not fix scenarios that require converting a link or image to the full, collapsed, or shortcut reference styles because that involves naming the reference and determining where to insert it in the document.

Setting the url_inline parameter to false prevents the use of inline links with the same absolute URL text/destination and no title because such links can be converted to autolinks:

[https://example.com](https://example.com)

To fix url_inline violations, use the simpler autolink syntax instead:

<https://example.com>

Rationale: Consistent formatting makes it easier to understand a document. Autolinks are concise, but appear as URLs which can be long and confusing. Inline links and images can include descriptive text, but take up more space in Markdown form. Reference links and images can be easier to read and manipulate in Markdown form, but require a separate link reference definition.

`MD055` - Table pipe style

Tags: table

Aliases: table-pipe-style

Parameters:

style: Table pipe style (string, default consistent, values consistent / leading_and_trailing / leading_only / no_leading_or_trailing / trailing_only)

This rule is triggered when a GitHub Flavored Markdown table is inconsistent about its use of leading and trailing pipe characters (|).

By default (consistent style), the header row of the first table in a document is used to determine the style that is enforced for every table in the document. A specific style can be used instead (leading_and_trailing, leading_only, no_leading_or_trailing, trailing_only).

This table’s header row has leading and trailing pipes, but its delimiter row is missing the trailing pipe and its first row of cells is missing the leading pipe:

| Header | Header |
| ------ | ------ |
| Cell   | Cell   |

To fix these issues, make sure there is a pipe character at the beginning and end of every row:

| Header | Header |
| ------ | ------ |
| Cell   | Cell   |

Note that text immediately following a table (i.e., not separated by an empty line) is treated as part of the table (per the specification) and may also trigger this rule:

| Header | Header |
| ------ | ------ |
| Cell   | Cell   |
This text is part of the table

Rationale: Some parsers have difficulty with tables that are missing their leading or trailing pipe characters. The use of leading/trailing pipes can also help provide visual clarity.

`MD056` - Table column count

Tags: table

Aliases: table-column-count

This rule is triggered when a GitHub Flavored Markdown table does not have the same number of cells in every row.

This table’s second data row has too few cells and its third data row has too many cells:

| Header | Header |
| ------ | ------ |
| Cell   | Cell   |
| Cell   |
| Cell   | Cell   | Cell |

To fix these issues, ensure every row has the same number of cells:

| Header | Header |
| ------ | ------ |
| Cell   | Cell   |
| Cell   | Cell   |
| Cell   | Cell   |

Note that a table’s header row and its delimiter row must have the same number of cells or it will not be recognized as a table (per specification).

Rationale: Extra cells in a row are usually not shown, so their data is lost. Missing cells in a row create holes in the table and suggest an omission.

`MD058` - 表格应有空行包围

Tags: table

Aliases: blanks-around-tables

Fixable: 部分违规可通过工具修复

当表格前后缺少空行时，会触发此规则：

Some text
| Header | Header |
| ------ | ------ |
| Cell   | Cell   |
> Blockquote

要解决此规则的违规，请确保所有表格前后均有空行（除非表格位于文档的开头或结尾）：

Some text

| Header | Header |
| ------ | ------ |
| Cell   | Cell   |

> Blockquote

注意：紧跟在表格之后的文本（即未用空行分隔）根据规范被视为表格的一部分，不会触发此规则：

| Header | Header |
| ------ | ------ |
| Cell   | Cell   |
This text is part of the table and the next line is blank

Some text

原理：除了美观因素外，某些解析器可能会错误解析前后没有空行的表格。

`MD059` - 链接文本应具有描述性

Tags: accessibility, links

Aliases: descriptive-link-text

Parameters:

prohibited_texts: 禁止的链接文本（string[]，默认["click here","here","link","more"]）

当链接包含像[click here](...)或[link](...)这样的通用文本时，会触发此规则。

链接文本应具有描述性，传达链接的目的（例如[Download the budget document](...)或[CommonMark Specification](...)）。这对于有时会在无上下文情况下呈现链接的屏幕阅读器尤为重要。

默认情况下，此规则禁止少量常见的英语单词/短语。要自定义该列表，请将prohibited_texts参数设置为string类型的Array。

注意：对于英语以外的语言，请使用prohibited_texts参数为该语言自定义列表。此规则不旨在为每种语言提供翻译。

注意：此规则检查 Markdown 链接；HTML 链接将被忽略。

更多信息：

`MD060` - 表格列样式

Tags: table

Aliases: table-column-style

Parameters:

aligned_delimiter: 对齐分隔符列（boolean，默认false）
style: 表格列样式（string，默认any，值aligned / any / compact / tight）

当GitHub Flavored Markdown 表格的列分隔符管道字符（|）使用不一致时，会触发此规则。

此规则根据常见用法识别三种表格列样式。

样式aligned确保管道字符垂直对齐：

| Character | Meaning |
| --------- | ------- |
| Y         | Yes     |
| N         | No      |

aligned样式忽略单元格内容，因此以下表格也有效：

| Character | Meaning |
| --------- | ------- |
| Y         | Yes     |
| N         | No      |

样式compact避免在单元格内容周围额外添加单个空格：

| Character | Meaning |
| --------- | ------- |
| Y         | Yes     |
| N         | No      |

样式tight对单元格内容完全不使用填充：

| Character | Meaning |
| --------- | ------- |
| Y         | Yes     |
| N         | No      |

当此规则的style参数设置为aligned、compact或tight时，每个表格必须匹配相应的模式，并将报告任何违规。默认情况下，或使用any样式时，会分析每个表格是否符合任何支持的样式。如果是，则不报告违规。如果不是，则将报告对于产生最少问题（即最接近匹配）的样式的违规。

将aligned_delimiter参数设置为true要求分隔符行中的管道字符与标题行中的字符对齐。这可以与compact和tight表格一起使用，使标题文本更醒目。（对于样式aligned的表格，这已经是必需的。）

样式compact与aligned_delimiter：

| Character | Meaning |
| --------- | ------- |
| Y         | Yes     |
| N         | No      |

样式tight与aligned_delimiter：

| Character | Meaning |
| --------- | ------- |
| Y         | Yes     |
| N         | No      |

注意：此规则不要求表格的首尾有管道字符，因此以下表格对compact样式也有效：

| Character | Meaning |
| --------- | ------- |
| Y         | Yes     |
| N         | No      |

注意：aligned样式的管道对齐基于视觉外观而非字符数。因为编辑器通常以拉丁字符两倍宽度渲染表情符号和CJK 字符，此规则对使用aligned样式的表格会考虑这一点。以下表格格式正确，在大多数编辑器和等宽字体中会显示对齐：

| Response | Emoji |
| -------- | ----- |
| Yes      | ✅     |
| No       | ❎     |

原理：一致的格式有助于理解文档。

MD001 - 标题级别应一次只递增一级

MD003 - 标题样式

MD004 - 无序列表样式

MD005 - 同级列表项的缩进不一致

MD007 - 无序列表缩进

MD009 - 尾随空格

MD010 - 硬制表符

MD011 - 反转的链接语法

MD012 - Multiple consecutive blank lines

MD013 - Line length

MD014 - Dollar signs used before commands without showing output

MD018 - No space after hash on atx style heading

MD019 - Multiple spaces after hash on atx style heading

MD020 - No space inside hashes on closed atx style heading

MD021 - Multiple spaces inside hashes on closed atx style heading

MD022 - Headings should be surrounded by blank lines

MD023 - Headings must start at the beginning of the line

MD024 - Multiple headings with the same content

MD025 - Multiple top-level headings in the same document

MD026 - Trailing punctuation in heading

MD027 - Multiple spaces after blockquote symbol

MD028 - Blank line inside blockquote

MD029 - Ordered list item prefix

MD030 - Spaces after list markers

MD031 - Fenced code blocks should be surrounded by blank lines

MD032 - Lists should be surrounded by blank lines

MD033 - Inline HTML

MD034 - Bare URL used

MD035 - Horizontal rule style

MD036 - Emphasis used instead of a heading

MD037 - Spaces inside emphasis markers

MD038 - Spaces inside code span elements

MD039 - Spaces inside link text

MD040 - Fenced code blocks should have a language specified

MD041 - First line in a file should be a top-level heading

MD042 - No empty links

MD043 - Required heading structure

MD044 - Proper names should have the correct capitalization

MD045 - Images should have alternate text (alt text)

MD046 - Code block style

MD047 - Files should end with a single newline character

MD048 - Code fence style

MD049 - Emphasis style

MD050 - Strong style

MD051 - Link fragments should be valid

MD052 - Reference links and images should use a label that is defined

MD053 - Link and image reference definitions should be needed

MD054 - Link and image style

MD055 - Table pipe style

MD056 - Table column count

MD058 - 表格应有空行包围

MD059 - 链接文本应具有描述性

MD060 - 表格列样式

`MD001` - 标题级别应一次只递增一级

`MD003` - 标题样式

`MD004` - 无序列表样式

`MD005` - 同级列表项的缩进不一致

`MD007` - 无序列表缩进

`MD009` - 尾随空格

`MD010` - 硬制表符

`MD011` - 反转的链接语法

`MD012` - Multiple consecutive blank lines

`MD013` - Line length

`MD014` - Dollar signs used before commands without showing output

`MD018` - No space after hash on atx style heading

`MD019` - Multiple spaces after hash on atx style heading

`MD020` - No space inside hashes on closed atx style heading

`MD021` - Multiple spaces inside hashes on closed atx style heading

`MD022` - Headings should be surrounded by blank lines

`MD023` - Headings must start at the beginning of the line

`MD024` - Multiple headings with the same content

`MD025` - Multiple top-level headings in the same document

`MD026` - Trailing punctuation in heading

`MD027` - Multiple spaces after blockquote symbol

`MD028` - Blank line inside blockquote

`MD029` - Ordered list item prefix

`MD030` - Spaces after list markers

`MD031` - Fenced code blocks should be surrounded by blank lines

`MD032` - Lists should be surrounded by blank lines

`MD033` - Inline HTML

`MD034` - Bare URL used

`MD035` - Horizontal rule style

`MD036` - Emphasis used instead of a heading

`MD037` - Spaces inside emphasis markers

`MD038` - Spaces inside code span elements

`MD039` - Spaces inside link text

`MD040` - Fenced code blocks should have a language specified

`MD041` - First line in a file should be a top-level heading

`MD042` - No empty links

`MD043` - Required heading structure

`MD044` - Proper names should have the correct capitalization

`MD045` - Images should have alternate text (alt text)

`MD046` - Code block style

`MD047` - Files should end with a single newline character

`MD048` - Code fence style

`MD049` - Emphasis style

`MD050` - Strong style

`MD051` - Link fragments should be valid

`MD052` - Reference links and images should use a label that is defined

`MD053` - Link and image reference definitions should be needed

`MD054` - Link and image style

`MD055` - Table pipe style

`MD056` - Table column count

`MD058` - 表格应有空行包围

`MD059` - 链接文本应具有描述性

`MD060` - 表格列样式