当你从 ChatGPT、Google Docs、Microsoft Word、网页或其他编辑器中复制文本，并在 Windows 上使用 Ctrl+Shift+V 或在 macOS 上使用 Cmd+Shift+V 粘贴时，字体、颜色、链接和排版样式都会消失。
很多人容易得出结论：此时文本已经完全干净了。
这种结论并不准确。
纯文本粘贴移除的是格式层；它既不是 Unicode 清理器，也不是 Markdown 解析器。
剪贴板可以同时承载同一复制内容的多重表示形式。纯文本粘贴通常只是指示目标应用程序使用纯文本表示，而不是富文本 HTML 表示。这虽然去除了视觉样式，但选中的纯文本中仍可能包含非标准空格、零宽字符、方向标记、智能标点以及可见的 Markdown 语法。
这些属于不同的层面，需要分别进行针对性清理。
“无格式粘贴”的实际含义
“无格式粘贴”描述的是目标应用程序处理剪贴板数据的方式，并不是一种通用的字符清理算法。
该命令的主要目的是防止复制的样式进入目标文档。它会丢弃字体族、字号、文本颜色、背景色、富文本超链接、表格、缩进以及其他排版细节。
它不会自动执行以下操作：
- 将所有类空格字符转换为 U+0020；
- 移除所有不可见的 Unicode 字符；
- 规范化所有 Unicode 序列；
- 删除 Markdown 标记；
- 识别文本是否来自 AI 系统；
- 将内容重写为其他风格。
这种区别首先源于剪贴板数据的表示方式。
剪贴板可提供多种数据表示形式
剪贴板标准允许复制的内容以多种格式呈现。两种常见的表示形式是：
text/plaintext/html
text/html 版本可以保留富文本格式，其中可能包含用于段落、标题、链接、列表、强调、表格和行内样式的 HTML 元素。
text/plain 版本则包含去除了 HTML 排版层的字符。当你选择纯文本粘贴命令时，应用程序通常请求的就是这种表示形式。
但这并不意味着纯文本表示仅限于基础英文字母或 ASCII。它可以包含复制源应用程序所支持的全部 Unicode 字符。
例如，纯文本载荷中仍可能包含：
- U+202F 窄不换行空格（NARROW NO-BREAK SPACE）；
- U+200B 零宽空格（ZERO WIDTH SPACE）；
- U+00A0 不换行空格（NO-BREAK SPACE）；
- 弯引号（全角/智能引号）；
- 破折号（em dash）；
- 非拉丁文字；
- Emoji 表情符号；
- Markdown 标记，例如
#、**和反引号。
剪贴板格式与该格式内部包含的字符是两个独立的概念。
选择 text/plain 代替 text/html 只是移除了一层数据表示，并不能决定纯文本表示内部保留哪些 Unicode 码位。
Word 与 Google Docs 中纯文本粘贴的定义
Microsoft Word 使用的术语通常是 只保留文本（Paste Text Only），而 Google Docs 使用的是 无格式粘贴（Paste without formatting）。
这两个命令的核心都集中在格式处理行为上：即要求目标编辑器仅插入复制的文字内容，而不带入源文档中丰富的视觉排版样式。
这在从网页复制代码到报告中、在样式不同的文档之间迁移文本，或避免源字号和颜色打乱目标排版时非常有用。
但这与以下请求有着本质区别：
> 检查每一个字符，并替换或移除指定的 Unicode 码位。
应用程序在执行粘贴操作时可能会发生附带的转换。不同的操作系统、浏览器、源应用程序和目标应用程序的行为可能各有不同。你不应将这些附带的变化视为有保证的 Unicode 清理机制。
可靠的结论更为严谨：纯文本粘贴的主要目的仅仅是丢弃富文本格式。
纯文本中仍可能包含非标准 Unicode 字符
“纯文本”描述的是缺乏富文本排版结构的状态，并不代表其中的每一个字符都是常规、可见、可互换或兼容 ASCII 的。
一个纯文本文件可以包含数千种不同的 Unicode 字符。有些是可见字符；有些会影响间距或换行；有些会改变文字书写方向；有些则没有可见宽度。
这种灵活性是国际化文本处理所必需的，但当在不同应用程序之间迁移内容时，它也会产生不易察觉的残留字符。
U+0020 与 U+202F 是不同的字符，而非不同的字形样式
U+0020 是基础拉丁文本中通用的标准空格字符（SPACE）。
U+202F 则是窄不换行空格（NARROW NO-BREAK SPACE）。
它们在许多界面中看起来十分相似，但它们并非同一字符应用了两种不同的视觉样式，而是具备不同行为机制的独立 Unicode 码位。
U+202F 具有正当的排版用途。它能在产生较窄间距的同时防止该位置发生换行。它常出现在特定语言的排版中（包括法语排版规范），以及其他需要窄间距且不换行的场景下。
因为 U+202F 本身就是一个字符，而不仅是 HTML 样式，所以即使移除了富文本格式，它依然会保留下来。
请看下面这个简化序列：
word<U+202F>word如果该序列存在于剪贴板的 text/plain 表示中，执行纯文本粘贴在逻辑上并不要求目标应用程序将其转变为：
word<U+0020>word粘贴命令可能会移除 HTML 表示中外层的 <span> 元素、字体声明或不换行空格的 HTML 实体，但并不能保证它会规范化纯文本表示中已存在的每一个类空格码位。
当需要精确控制字符本身时，应当直接检查或清理 Unicode 层。Unicode 清理工具 专门用于此项任务，而 粘贴残留检测工具 则有助于找出常规肉眼审查容易忽略的字符。
为什么“纯文本”并不等同于“ASCII”
ASCII 是一个较小的字符集，仅涵盖基础英文字母、数字、标点符号和控制字符。
Unicode 的范围要广泛得多。它支持全球各语言的书写系统、符号、标点习惯、Emoji、数学符号、组合字符、格式控制符以及专用间距字符。
现代意义上的纯文本通常就是 Unicode 文本。一个 .txt 文件即使包含汉字、阿拉伯语文本、带变音符号的字母、Emoji、智能引号和窄不换行空格，它依然属于纯文本。
如果将所有纯文本强制转为 ASCII，将会破坏正常内容，可能导致姓名、非英语语言文字、数学符号和具有语义的标点被直接删除。
因此，一个严谨的清理工具必须具备明确的规则，能够区分：
- 正当的国际化字符；
- 虽不常见但符合意图的字符；
- 在特定工作流中不需要的不可见控制符；
- 可能需要规范化的兼容字符；
- 应当保持原样的标点符号；
- 仅在特定规则下才需转换的间距字符。
“移除格式”完全无法满足这些需求，它仅仅指明了要丢弃排版展示层。
ChatGPT 中的 U+202F 案例：客观事实与主观假设
关于 AI 生成文本中出现 U+202F 的讨论，导致部分用户将该字符视为隐藏 AI 水印的证据。
仅凭观察到的现象并不能支撑这一结论。
某个字符的出现，只能证明特定文本处理链路生成了特殊的间距，并不能直接作为意图、作者归属、追踪手段或正式水印系统的证据。
OpenAI 社区报告中实际记录的内容
一份公开的 OpenAI 社区报告描述了 GPT-5 输出中出现 U+202F 的现象。
该报告之所以值得关注，是因为它记录了一项具体的用户观察：在特定上下文生成的文本中，出现了用户未曾预料到的窄不换行空格字符。
但仍需客观描述这一情况：它是一份公开的用户 Bug 反馈或问题报告，并非 OpenAI 官方发布的系统架构或机制说明文档。
该报告本身无法确定：
- 该字符出现的原因；
- 它是否直接来自模型生成；
- 前端界面处理是否对其产生影响；
- 它是否影响所有输出；
- 这种行为在各产品或版本之间是否稳定存在；
- OpenAI 是否有意将其作为水印使用。
当你的实际目标是检查或移除此类残留时，使用专用的 ChatGPT 文本清理工具 比单纯依赖纯文本粘贴更为有效。它会直接检查字符层，而不是假定粘贴命令已经对其进行了转换。
它无法证明的事实
发现 U+202F 既不能证明该文本必然由 ChatGPT 生成，
也不能证明 ChatGPT 是故意插入该字符以作为水印、数字指纹或追踪标记。
U+202F 具有合法的排版用途，可能通过多种途径进入文本：
- 针对特定语言优化的排版逻辑；
- 文档编辑器；
- 网页内容；
- 复制与粘贴过程中的数据转换；
- 导入的外部文档；
- 格式转换工具；
- 内容发布系统；
- 手动输入；
- 与 ChatGPT 无关的其他系统生成的文本。
即使某条被反馈的 ChatGPT 输出中确实包含 U+202F，最稳妥的结论也仅限于：该特定输出中包含了 U+202F 字符。
得出更进一步的推断都需要额外的确凿证据。
字符清理工具可以移除不需要的码位，但它无法可靠地还原文本的完整来源，也不应被用作作者归属检测工具。
Markdown 得以保留的原因截然不同
在执行纯文本粘贴后，即使所有富文本格式都消失了，Markdown 语法标记仍可能会保留下来。
这并非粘贴操作失败，而是因为 Markdown 本身就属于纯文本层。
Markdown 是纯文本语法
CommonMark 将 Markdown 定义为纯文本格式。其格式排版指令完全是通过可见的常规字符来表达的。
例如：
# Heading
**Bold text**
- List item
[Link text](https://example.com)
`inline code`其中的 #、星号、连字符、方括号、圆括号和反引号都是标准的文本字符，而不是附加在剪贴板载荷上的 HTML 格式。
当由 Markdown 解析器渲染时，这些字符会生成标题、粗体文本、列表、链接和代码；而当粘贴到不支持 Markdown 渲染的编辑器中时，它们会作为字面语法保持可见。
纯文本粘贴会保留它们，正是因为它们是所选纯文本流的一部分。
这构成了鲜明的对比：
- HTML 粗体可能会消失，因为 HTML 表示被丢弃了；
- Markdown 粗体标记可能会保留，因为
**本就存在于纯文本表示中。
移除 Markdown 需要借助解析器或受控的语法剔除流程。这与选择 text/plain 属于完全不同的操作。
Markdown 移除工具 专门用于针对性处理这些可见语法。
三项独立的清理任务
要获得干净的文本结果，往往需要做出三项独立的决定：
- 应该粘贴剪贴板的哪种数据表示？
- 哪些 Unicode 字符应该保留、规范化或移除？
- 哪些可见的纯文本语法需要剔除？
下表对这些操作进行了区分：
| 操作 | 移除富文本格式 | 更改 Unicode 码位 | 剔除 Markdown 语法 |
|---|---|---|---|
| 普通粘贴 | 不保证 | 否 | 否 |
| 作为纯文本粘贴 | 是 / 主要目的 | 无法假设会更改 | 否 |
| Unicode 清理 | 并非主要功能 | 是（根据具体规则） | 否 |
| Markdown 剔除 | 否 | 否 | 是 |
没有任何单一操作能够同时覆盖所有需求。
富文本格式 —— 目标应用程序的粘贴模式
当主要问题是源内容的继承排版样式时，请使用 Ctrl+Shift+V、Cmd+Shift+V、无格式粘贴 或 只保留文本。
当复制的内容引入了不需要的字体、颜色、字号、HTML 链接或文档样式时，这是合适的第一步。
最终结果由目标应用程序控制。对于同一份剪贴板数据，文字处理器、内容管理系统（CMS）、代码编辑器、表单输入框或即时通讯工具的处理方式可能各不相同。
请将此步骤视为数据表示形式的选择，而非彻底的清理净化。
Unicode 残留 —— 不可见字符
当问题涉及字符层面时，请使用 不可见字符（Invisible Characters）处理流程。
这包括文本中包含意外的窄空格、零宽字符、不换行空格、方向控制符或其他在标准粘贴操作后依然存在的 Unicode 残留情况。
免费清理流程完全在浏览器本地运行，不会将数据上传至服务器。它会根据所选的清理规则扫描并剔除相应的 Unicode 字符。
标准操作步骤：
- 粘贴源文本。
- 打开 不可见字符 面板。
- 查看检测到的残留字符。
- 点击 清理。
- 确认具有实际语义的标点、空格、数字和文字内容保持完好。
如需统一入口，可以使用 Clean Paste。这能让字符处理变得明确可控，而无需盲目假设快捷键已经完成了清理。
可见 Markdown 语法 —— Markdown 标签页
当不需要的内容包含标题、强调标记、列表标记、代码块标记或链接语法等可见标记时，请使用 Markdown 标签页。
该操作在概念上与 Unicode 清理完全独立。
以 ## 开头的行不是隐藏残留；词组前后的两个星号不是非标准空格；Markdown 链接也不是剪贴板存储的 HTML。
免费版本在浏览器本地处理 Unicode 与 Markdown。只需选择对应的标签页，检查文本，然后点击 清理 执行目标操作即可。
将这些操作解耦可以避免非预期的内容修改，同时也让处理结果更易于审核，因为每项改动（移除格式、修改码位或剔除语法）都是独立执行的。
本工作流无法针对 Claude 做出判定的事项
Anthropic 于 2026 年 8 月 14 日发布的关于官方文本水印的声明属于另一项独立的技术范畴。
根据该声明，其官方水印并未在 Claude 的文本中添加隐藏字符。因此，字符清理工具无法仅通过删除零宽字符、U+202F 或其他 Unicode 残留来移除此类水印。
这一区别非常根本：
- 隐藏字符清理针对的是文本中的字面码位；
- 不依赖隐藏字符的水印机制不会产生可被移除的 Unicode 残留；
- Markdown 剔除针对的是可见语法，与该机制无关；
- 纯文本粘贴仅用于切换所选的剪贴板表示形式。
截至上述日期，Anthropic 尚未公开发布与该系统配套的官方检测 API。在无法调用官方检测器的情况下，仅通过字符检查无法验证某段文本中是否包含该水印。
本工作流用于清理格式、指定的 Unicode 残留以及 Markdown 语法。它无法检测是否存在 Claude 的官方水印，无法移除不以隐藏字符形式存储的水印机制，也无法对 AI 文本检测器的判定结果提供特定保证。
