Local graph fails on pages with encoded characters in the URL

[CraftSpider]

When a page contains encoded characters, such as { or }, in its title, then the local graph fails to render. The root node displays an incorrect label with the encoded characters - %7BFoo%7D as an example, and no other nodes. Non-root situations work fine - if Foo links to {Foo}, its local graph renders correctly with {Foo} as a child node.

Reproduction

Put the following files in the content folder:

Foo.md

[[{Foo}]]

{Foo}.md

[[Foo]]

Then run npx quartz build --serve

[kaisnowwolfhan]

Describe the bug

Chinese (CJK) node labels render as garbled/mojibake text (e.g. sequences resembling ...%B8%E9...) in the local graph view, while the exact same notes display correctly in the global graph view.

Since only the local graph is affected, and the underlying data source is confirmed correct (see reproduction/investigation below), this appears to be a client-side string-handling bug specific to the local graph rendering path, not a build-time or configuration issue.

To Reproduce

1. Create a note with a Chinese title and/or Chinese headings, e.g. content/我的筆記.md with title: 我的筆記.
2. Link it to/from at least one other note so it appears in the local graph at depth 1.
3. Build and open the note's page.
4. Observe the local graph panel (right sidebar / inline component): the node label for the Chinese-titled note is garbled, showing corrupted percent-encoding-like sequences instead of the Chinese characters.
5. Click the graph icon (or press Ctrl/Cmd + G) to open the global graph: the same node's label displays the correct Chinese text.

Expected behavior

Local graph node labels should render identically to global graph node labels (i.e. correct Chinese text), since both are presumably sourced from the same contentIndex.json.

Investigation already performed

To narrow down the cause before filing, the following was checked:

Check	Result
/static/contentIndex.json content for the affected note	Correct, readable Chinese (UTF-8)
Browser address bar path when viewing the note	Displays correctly as Chinese (not percent-encoded)
Page HTML via "View Page Source" (server-rendered, pre-JS)	Fully correct — title, headings, and all Chinese text render properly
Changing title in frontmatter	No effect on the garbled local graph label
Changing alias in frontmatter	No effect on the garbled local graph label

Conclusion from investigation: the content pipeline (build output, contentIndex.json, server-rendered HTML) is unaffected and fully correct. The corruption only appears after the local graph's client-side JavaScript runs, and appears unrelated to the title/alias frontmatter fields — suggesting the local graph component may be deriving/reconstructing the displayed label from something other than the contentIndex.json title field (e.g. from a slug/path string), and that reconstruction path has an encoding/decoding bug that the global graph's code path does not go through.

Environment

• Quartz: 5.0.0
• Graph plugin: commit 46f0ba1
• Browser: Vivaldi 8.1.4087.48, Chromium 150.0.7871.120
• Node.js: 24.15.0

[isle-blu]

Found the root cause while debugging this for a Korean-language site.

getSlugFromUrl() derives the current page's slug from window.location.pathname via getFullSlugFromUrl(), but never decodes it. Browsers keep pathname percent-encoded for non-ASCII/reserved characters, so for any slug containing them (CJK, {}, etc.) this local-graph-only seed slug never matches the already-decoded keys in the fetched content index / link list.

Two effects follow from that single mismatch:

1. data.get(url)?.title misses for the current page's own node, so the label falls back to the raw, still-encoded url — that's the garbled/mojibake-looking text everyone's seeing.
2. The BFS neighbourhood walk also keys off this same broken slug, so none of the (correctly-normalized) link.source/link.target pairs ever match it — the node renders with no visible edges, even though it does have backlinks.

This also explains why the global graph is unaffected: its neighbourhood construction (depth < 0) walks the already-normalized link keys directly instead of seeding from the current page's slug — so it never hits the encoding mismatch.

Fix is one line — decode the pathname once, at the source, in getSlugFromUrl() (wrapped in try/catch to fall back gracefully on a malformed escape sequence rather than throwing). Verified against Korean titles and the {Foo} repro from the issue description; both render the correct label and correct edges after the fix.

Opening a PR with this shortly.

[CraftSpider]

A fix was already proposed in #5, and is simply awaiting maintainer approval. Did it not fix your use case?

[isle-blu]

Thanks for flagging #5 — it looks like it addresses the exact same root cause I found (undecoded pathname in getSlugFromUrl). That explains why my case wasn't resolved: since it hasn't been merged into main yet, source: github:quartz-community/graph still pulls the unfixed version, so it never made it into my build. It's already confirmed working across several languages, though.

I'll close my PR in favor of #5. Appreciate the pointer!

[saberzero1]

Fixed in utils@0.1.1. getFullSlugFromUrl() now calls decodeURI() on the browser pathname, so pages with encoded characters in the URL (curly braces, etc.) correctly match their contentIndex entries. Verified via E2E tests.