fix: decode numeric character references in text - #4076
Open
Kjubikstronk wants to merge 1 commit into
Open
Conversation
CommonMark treats a numeric character reference as equivalent to the character it names, everywhere except code. marked passed them through unchanged, so `&markedjs#35;` reached the output as written instead of `#`. Fixes CommonMark examples 26, 27, 39 and 40. Named references still pass through, since resolving those needs the HTML5 table. The spec suite could not see this: `&markedjs#35;` and `#` are equivalent once parsed as HTML, so html-differ reports them equal and all four already passed.
|
@Kjubikstronk is attempting to deploy a commit to the MarkedJS Team on Vercel. A member of the Team first needs to authorize it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Marked version: 18.0.11 (53cb13f)
Markdown flavor: CommonMark
Description
CommonMark treats a numeric character reference as equivalent to the character it names, everywhere except code spans and code blocks. marked passes them through unchanged, so they reach the output exactly as written.
escapeTestNoEncodedeliberately declines to escape anything shaped like an entity:/[<>"']|&(?!(#\d{1,7}|#[Xx][a-fA-F0-9]{1,6}|\w+);)/which leaves it to the browser to resolve. That works for display but does not match the spec, and it is visible to anything reading the output as text rather than rendering it.
Expectation
Result
Each one is emitted as written:
#,", ,	.What was attempted
Decoding numeric references in
inlineText, so the token carries the character and the existing escaping handles the rest. Zero, out of range, and surrogate values become the replacement character, per the spec. Raw HTML blocks keep whatever they were written with.This deliberately does not touch named references.
©and friends need the HTML5 named table, which is the dependency question raised in #4050. The numeric half needs no table at all, only digit parsing, which is why it is separate.Measured over the whole spec with the spec's own
test/normalize.py: 28 failures before, 24 after. The four that move are 26, 27, 39 and 40, and nothing else changes, in both the CommonMark and GFM runs.Worth noting why this was not caught:
#and#are equivalent once parsed as HTML, sohtml-differreports them equal. All four of these already report as passing and carry noshouldFail. Same blind spot as #4073, #4074 and #4075, in a different corner.Contributor
Five tests in
test/unit/marked.test.jsundernumeric character references. Three fail without the change; the other two are controls, an invalid reference that must stay literal and a code span that must not decode. Full spec suite (1789) and unit suite (196) pass.Committer
In most cases, this should be a different person than the contributor.