Ideographic space (U+3000) is replaced with an ASCII space on copy, which no longer matches what the user sees #94

Summary

Since #88 (published as 1.3.2 on npm), copyText normalizes U+3000 (IDEOGRAPHIC SPACE) to an ASCII space (U+0020). Unlike U+00A0, U+3000 is visually distinct from an ASCII space: it renders at full width, especially in monospace code blocks. So the copied text no longer matches what the user sees, which is the opposite of the stated goal of #88.

Steps to reproduce

1. On github.com, create a Markdown code block containing U+3000, e.g.

id,name
1,サンプル　商品

2. Click the copy button on the code block.
3. Inspect the clipboard contents.

Expected: 1,サンプル　商品 (U+3000 preserved, as rendered)
Actual: 1,サンプル 商品 (U+0020)

Selecting the text manually and copying preserves U+3000, so the behavior differs depending on how the user copies.

Checked on github.com on 2026-10-13. The script served there contains the same regex as src/clipboard.ts on main.

Why this matters

U+3000 is a standard, everyday character in Japanese (and Chinese) text, not an obscure or deceptive one. Data such as product names or master records often contain it and must be preserved exactly. Because the code block still displays U+3000, users have no visible cue that the copied text was changed. In my case it surfaced only later, as an unexpected diff in test data.

Suggested fix

The original change in #87 (U+00A0 only, referencing a HackerOne report) makes sense to me. This issue is only about U+3000, which was added to the set in #88.

Exclude U+3000 from the replacement set, while keeping the normalization for characters that are genuinely indistinguishable from an ASCII space:

-    .replace(/[\u00A0\u1680\u2000-\u200A\u202F\u205F\u3000]/g, ' ')
+    .replace(/[\u00A0\u1680\u2000-\u200A\u202F\u205F]/g, ' ')