MD051 fails with cjk characters

[Mister-Hope]

This issue seems to start with 0.30.0

[DavidAnson]

Can you please paste some example characters here in this issue?

[DavidAnson]

(The "Copy link" link at the bottom of that demo page will create a sample directly from your demo.)

[Mister-Hope]

# 标题

[标题](#标题)

[charlesbouchardlegare-qc]

Looks related: #955

[DavidAnson]

Please see my comments in issue #955 for an explanation. As in that case, using the URI-encoded form for the link works fine:

https://dlaa.me/markdownlint/#%25m%23%20%E6%A0%87%E9%A2%98%0A%0A%5B%E6%A0%87%E9%A2%98%5D(%23%E6%A0%87%E9%A2%98)%0A%0A%5B%E6%A0%87%E9%A2%98%5D(%23%25E6%25A0%2587%25E9%25A2%2598)%0A

I would not expect this to have worked in a previous version, but the intent was always to require the use of the GitHub canonical version as is currently being done and observed in the demo page.

[DavidAnson]

You're right that this was not reported in v0.29.0 of the library. I debugged and that's because the markdown-it parser automatically applied a URI encoding to the link destination (likely because it's tokenized as an href) and so it matched the canonical GitHub form. In v0.30.0 of the library, the micromark parser is used for this rule and it does not do that (being a lower-level parser) and so there is a mismatch which leads to the reported issue. The current/updated behavior is what is intended and I consider it an improvement that the rule catches something it didn't before.

[Mister-Hope]

I hope you can have an option for this because many editors like vscode, And a lot of markdown renderers like markdown-it, do not requird users to.encode anchor hash.

I would be disappointing If I can only disable this rule, Instead of having their non-url-encoded version being checked.

[copperwalls]

@DavidAnson I know this issue is already “Closed” and I’m probably missing something here but,

Please see my comments in issue #955 for an explanation. As in that case, using the URI-encoded form for the link works fine:

https://dlaa.me/markdownlint/#%25m%23%20%E6%A0%87%E9%A2%98%0A%0A%5B%E6%A0%87%E9%A2%98%5D(%23%E6%A0%87%E9%A2%98)%0A%0A%5B%E6%A0%87%E9%A2%98%5D(%23%25E6%25A0%2587%25E9%25A2%2598)%0A

both the URI-encoded and the non-URI-encoded form works there. One of them would generate an error in the CLI for example.

The current/updated behavior is what is intended and I consider it an improvement that the rule catches something it didn't before.

True. But as already mentioned, URI-encoding is not required in many tools. Both encoded and non-encoded should be allowed. Besides, URI-encoding makes the (raw) Markdown looks hideous.

I hope there’s a way to make it work like your demo site above.

[DavidAnson]

I changed the behavior of this library to allow both kinds in v0.31.0 and that's what you can see in the demo page now. This version of the library is not yet part of a release of CLI or CLI2, so you will not see the change if using either. A new release for both should be forthcoming.

[copperwalls]

Awesome! Thanks for the heads-up.

[silverwind]

We also got hit by this. Is it the same issue?

Heading:

### 设置HTTP重定向

Link:

[HTTP 重定向](#设置http重定向)

It worked in 0.29.0, fails in 0.30.0.

[DavidAnson]

@silverwind Your example produces no errors in the latest version: https://dlaa.me/markdownlint/#%25m%23%20Issue%20954%0A%0A%23%23%20%E8%AE%BE%E7%BD%AEHTTP%E9%87%8D%E5%AE%9A%E5%90%91%0A%0A%5BHTTP%20%E9%87%8D%E5%AE%9A%E5%90%91%5D(%23%E8%AE%BE%E7%BD%AEhttp%E9%87%8D%E5%AE%9A%E5%90%91)%0A