Skip to content

Rewrite stale charset declarations to UTF-8 - #81

Merged
tamnd merged 1 commit into
tamnd:mainfrom
SihanTeng:fix/charset-utf8
Aug 10, 2026
Merged

Rewrite stale charset declarations to UTF-8#81
tamnd merged 1 commit into
tamnd:mainfrom
SihanTeng:fix/charset-utf8

Conversation

@SihanTeng

@SihanTeng SihanTeng commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Rewrite non-UTF-8 <meta charset> and legacy Content-Type declarations to match the UTF-8 bytes kage writes.
  • Search the full parsed document so malformed markup cannot leave a contradictory declaration outside <head>.
  • Rewrite declarations inside inert <template> content without treating them as the document declaration.
  • Preserve the existing exported Report.CharsetAdded meaning and add CharsetRewritten instead of renaming the field.

Why

This is the charset contribution split out of #74 as requested in review. It builds on the doctype fix already landed in #78 and keeps the public report API backward compatible.

Test plan

  • go test -count=1 ./sanitize/
  • Regression coverage for missing, stale, legacy, malformed, and template-contained declarations

Related: #16

@SihanTeng

SihanTeng commented Aug 7, 2026

Copy link
Copy Markdown
Contributor Author

@tamnd This charset split is ready for review. A final correctness pass now ensures declarations inside inert <template> content are rewritten without suppressing the real document declaration. The focused regression and full go test -count=1 ./sanitize suite pass.

Co-authored-by: SihanTeng <SihanTeng@users.noreply.github.com>
@tamnd
tamnd force-pushed the fix/charset-utf8 branch from f62500c to 5ca4167 Compare August 10, 2026 06:52
@tamnd

tamnd commented Aug 10, 2026

Copy link
Copy Markdown
Owner

Rewriting stale declarations instead of only inserting a missing one is the right fix for #16, and keeping CharsetRewritten as a separate field rather than renaming CharsetAdded was a good call. I squashed onto main to clear the changelog conflicts. I am merging this and sending a follow up straight after for one thing I found while probing it: fixCharsetMetas sets declared from a meta anywhere in the tree, so a page whose only charset meta sits in body comes out with nothing in head, which puts the declaration past the 1024 byte prescan window and mojibakes exactly the pages #16 is about. The rewrite half should stay tree wide, only the declared question needs to go back to head.

@tamnd
tamnd merged commit c996042 into tamnd:main Aug 10, 2026
9 checks passed
tamnd added a commit that referenced this pull request Aug 10, 2026
fixCharsetMetas set declared from a <meta charset> anywhere in the tree, so
a page whose only charset meta sits in <body>, which is the malformed markup
case the walk exists to handle, came out of sanitize with no declaration in
<head> at all. Readers pre-scan the first 1024 bytes for the encoding, so the
declaration was never found and every multibyte character mojibaked, which
is the failure issue #16 reports.

Rewriting stale values stays whole-document. Only the declared question moves
back to <head>, so a stray body meta is rewritten to utf-8 and <head> still
gets its own declaration first.

rewriteContentTypeCharset also starts at the first field rather than the
second, so content="charset=iso-8859-1" with no media type is rewritten
instead of being left to contradict the injected declaration. A real media
type has no equals sign, so the existing Cut rejects it.

Follow-up to #81.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants