Unicode-LE

Unicode-LE：看起来并非如此的字符

在当前文件或整个工作区中，查找隐藏含义的 Unicode 字符
双向控制符、不可见字符、同形异义字符、混合文字、非 NFC 文本，以及看起来不像空格的空格

觉得有用？ 点赞或评分能帮助其他开发者找到它 — ★ GitHub · ★ Open VSX · ★ Marketplace

功能

打开文件，运行 Unicode-LE: Detect Unicode Risks，文件中所有看起来并非如此的字符都会出现在编辑器旁的报告中：CVE-2021-42574 背后的双向控制符、零宽字符和其他不可见字符、同形异义字符、无法用单一文字系统解释的词语、非规范化形式 C 的行、非 U+0020 的空格，以及含义尚无定论的码点。Scan Workspace 会对磁盘上的每个文件执行同样的检查。适用于 VS Code，以及 Cursor 和 VSCodium 等基于 VS Code 的编辑器（可从 Open VSX 安装）。

• 审查拉取请求，检查是否存在 Trojan Source — 从右向左覆盖符会使审查者看到的代码与实际运行的代码不同
• 筛查伪造名称 — 在其他字符均为拉丁字母的 pаypal 中出现西里尔字母 а 会被标记；完全由西里尔字母写成的词则不会
• 解释永远无法匹配的字符串 — 两个值之间的零宽空格或分解形式的 é，会让哈希认为它们不同，而人认为它们相同

报告中绝不会出现检测到的字符。 每个发现都写作 U+202E，绝不会直接写出字符本身；文档中的文件路径或键路径也会转义为 ‮。如果报告直接粘贴原始字符，就会扰乱阅读者屏幕上的文本顺序，让工具沦为它所检测问题的传播媒介。它不会改写任何内容：不会规范化，也不会删除空格。

安装

在 AI Agent 中使用

同一引擎也可作为 MCP 服务运行，因此 Agent 可以直接调用它，无需你运行命令。这对这里的情况尤为重要：模型若已将文档粘贴到自己的推理过程中，就已经接触到其中的双向文本控制符；而此服务返回的内容是 U+XXXX 和英文，因此回答不会将这些控制符带入提交消息或审查评论。

detect_unicode_risks(content, kinds?, scripts?, format?, filename?, maxResults?)

每条发现都会返回其类型、严重性、从 1 开始的行号和列号（按编辑器计数的 UTF-16）、字节偏移量、码点、文字，以及在格式允许时它所属的键路径；还会返回任何拒绝信息，既包括结构化内容，也包括警告，避免将空的发现列表误认为文档没有问题。回复中的每个非 ASCII 字符都会以 \uXXXX 形式输出。默认最多返回 500 条，并通过 meta.truncated 标明是否截断。

此服务接收内容并返回数据 — 不读取文件，也不会自行发起网络请求。它以 unicode-le-mcp 的名称发布在 npm 上，并以 io.github.nolindnaidoo/unicode-le 的名称收录于 MCP 注册表。它的回答与 Rust CLI 服务完全一致：同一测试语料会同时用于两者，差异测试会将数千份生成的文档输入两者进行比对，而且两者读取的都是由该 crate 写出的同一套 Unicode 表，而不是宿主 JavaScript 引擎自带的版本。

{
  "mcpServers": {
    "unicode-le": {
      "command": "npx",
      "args": ["-y", "unicode-le-mcp"]
    }
  }
}

echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | npx -y unicode-le-mcp

检查内容

它能检查翻译后的代码，而不会让你应接不暇

简单的易混淆字符检查会标记工作区中俄语和中文字符串里的每个字母——在最需要这项检查的代码库中，这会产生数千条发现，因此检查被关闭，Trojan Source 检查也随之关闭。

• 判断的是词，而不是文件。 Привет 完全由西里尔字母组成，是俄语。日语词语中经常混用汉字、平假名和片假名，而 UTS #39 知道这是日语。
• 明显使用其他文字书写的文件不会接受同形异义字符检查，报告也会说明原因——其中至少 10% 的字母属于未声明的文字。其他所有检查仍会在该文件上运行。
• 声明文字会启用检查，而不是关闭检查。 在 unicode-le.detection.scripts 中指定工作区使用的文字——Han、Cyrillic、Hira——这样，中文字符串中的拉丁文产品名称会被视为翻译，而同一文件中拉丁词里的西里尔字母仍会被捕获。

它会指出文档中的位置，而不只是文件中的位置

在 JSON、YAML、TOML、INI、.properties、.env、CSV 和 TSV 文件中，发现项还会包含其所在的键路径——metrics.headline.eyebrow，而不是五千行目录中的第 412 行。格式不会决定是否存在发现项，只决定如何标注位置：无法解析格式的文件仍会接受扫描，其中的所有内容仍会报告。

它会拒绝处理，而不是妄加猜测

工作区扫描会将每个文件读取为字节。UTF-16 或 UTF-32 文件、二进制文件以及无效 UTF-8 文件都会按名称拒绝处理，而不会被解码成其他内容，因为错误的解码会凭空产生发现项：将 UTF-16 作为 UTF-8 读取时，每隔一个字节都会变成文件中并不存在的不可见字符。

扫描文件夹或工作区

检测会读取当前打开的文档。扫描会从磁盘读取多个文件，并生成一份报告。

• 整个工作区：从命令面板运行 Unicode-LE: Scan Workspace for Unicode Risks。
• 单个文件夹：在资源管理器中右键单击该文件夹，然后选择 Scan Folder for Unicode Risks；或者运行 Unicode-LE: Scan Folder for Unicode Risks 并选择一个文件夹。

报告会为每个包含问题的文件以及每个无法判定的文件分别列出一节：

# Unicode-LE report

3 finding(s) in 4 file(s) scanned; 2 file(s) not fully judged.

## `latin1.txt`

- **Not judged** (`binary_or_undecodable`): not valid UTF-8 at byte 3: the encoding is unknown and is not guessed

## `notes.txt`

- **Not judged** (`encoding_unknown`): a UTF-16LE byte-order mark: this reads UTF-8 only, and decoding UTF-16LE as UTF-8 would invent invisible and unassigned characters that are not in the file

## `src/login.ts`

- **1:7** · mixed-script · high · U+0430
- **1:8** · confusable · high · U+0430 (resembles U+0061)
- **1:17** · bidi-control · high · U+202E

每个问题还会附上一句说明其重要性的文字，此处省略。

扫描会读取什么。 文件从磁盘读取，因此不会看到尚未保存的编辑。超过安全大小限制的文件不会被读取。非 UTF-8 文本文件会在报告中列出，并说明原因；绝不会猜测其编码，也不会跳过不提。扫描最多处理 5,000 个文件，或列出 10,000 个问题。报告末尾会逐项列出所有被排除的内容。

扫描跳过文件并不代表检查通过。 默认情况下，扫描不会读取依赖文件夹、项目的 .gitignore 排除的文件或二进制文件。隐藏在其中的字符不会被报告。若要检查所有内容，请关闭这三个开关。

扫描会跳过什么，以及如何更改。 默认情况下，三个开关均已启用，可在设置中分别关闭：

两个列表可以调整扫描结果，而无需关闭开关。若要跳过更多内容，请将模式添加到 scanExcludes。若要读取开关本会跳过的内容，请将其添加到 scanAlwaysInclude：

{
	// Also skip the test fixtures.
	"unicode-le.workspace.scanExcludes": ["**/fixtures/**"],
	// Read the vendored code, though the built-in list skips it.
	"unicode-le.workspace.scanAlwaysInclude": ["**/vendor/**"]
}

Unicode-LE: Open Settings 会在设置编辑器中打开上述所有设置。

在“问题”面板中。 启用 unicode-le.workspace.scanProblemsEnabled 后，每个问题也会作为警告显示在对应行上。每次扫描都会替换上一次扫描的结果。消息会显示码位，而不是字符。

影响扫描的设置位于设置下。

命令行工具

同一屏幕也可以在终端或 CI 步骤中运行：一个位于 crate/ 中的 Rust CLI，与扩展共用同一份语料库——crate/fixtures/——因此两者读取文档的方式始终一致。同一命令行工具也以 unicode-le 的形式发布在 npm 上，适用于安装了 Node、但没有 Rust 的机器；CI 会在三个操作系统上逐字节验证它与 crate 一致。

从 npm (unicode-le) 或 crates.io (unicode-le) 安装。 两者都会安装同一个 unicode-le 命令。

npm install -g unicode-le   # or run it once: npx unicode-le
cargo install unicode-le

unicode-le .                          # every finding in the tree; JSON on stdout when piped
unicode-le --fail-on bidi .           # in CI, for the CVE and nothing else
unicode-le --script Han,Cyrillic src/ # a translated tree, judged rather than refused
unicode-le mcp                        # the same screen over MCP on stdio

退出代码就是 API——0 表示无问题，1 表示发现了 --fail-on 会计入的问题，2 表示问题格式错误（或使用 --strict 时遇到任何拒绝项）。

命令

默认情况下，没有命令绑定快捷键。可在编辑器的 键盘快捷方式 中为任意命令设置快捷键。

设置

语言

除英语外，支持十二种语言：

德语 · 西班牙语 · 法语 · 印度尼西亚语 · 意大利语 · 日语 · 韩语 · 葡萄牙语（巴西） · 俄语 · 乌克兰语 · 越南语 · 简体中文

两部分内容均已覆盖：扩展清单（命令标题、设置名称和描述），以及扩展运行期间显示的所有内容（通知、状态栏和报告标题）。每个发现项的详细信息使用引擎的英文，与 CLI 和 MCP 服务中的内容一致。

隐私与安全

• 不访问网络。 扩展绝不会向任何地方发送数据。telemetryEnabled 设置只会将事件写入你可查看的本地输出通道（Unicode-LE）。
• MCP 服务遵循相同原则。 它将内容作为参数接收并返回数据：不访问文件系统、不进行网络调用、不收集遥测数据。若服务向 stdout 写入非 ASCII 字符，check:mcp-bundle 会导致构建失败。
• 错误通知会隐藏主目录和类似凭据的片段。
• 评分提示最多出现两次。 第 3 次成功使用时，扩展会询问你是否愿意为其评分；如果你选择了 Later 或关闭提示，则会在第 20 次使用时再询问一次。选择 Don't Ask Again 后将不再提示。你自行将 notificationsLevel 设为 important 或 silent 也会关闭提示。计数保存在 VS Code 的扩展存储中，不会向任何地方发送；点击 Rate 会在浏览器中打开你安装时所用的列表页面——VS Code Marketplace 或 Open VSX。

文档

性能

在 Apple M5 Pro、24 GB RAM、Node 24.3.0 上预热后运行 7 次所得的中位数。输入由 scripts/benchmark.ts 生成，而非纳入版本控制，因此上方所列大小 与实际测量值完全一致。使用 bun run benchmark 重现。

这些数据因机器而异，不会在 CI 中强制要求——用基准测试来阻止 构建，只能说明运行器当时有多忙。

测试

19 个文件中共有 224 个测试用例，另有一套在真实 VS Code 扩展宿主中运行的集成测试，以及一项将构建好的 .vsix 安装到干净配置文件中的端到端测试。

数据由 scripts/coverage-readme.js 根据实际运行生成，来源为 coverage/coverage-summary.json 和 coverage/test-results.json；如果本节内容发生偏差，CI 会失败。使用 bun run test:coverage 重现，测试用例数以 vitest 输出为准。

LE 系列的更多工具

为每个模型眼前的工作打造的 16 款单一用途工具。每款都附带一个 Rust CLI 和一个 MCP 服务。一页尽览：letools.dev

提取

• String-LE — 提取代码库中的所有字符串，方便人工阅读
• Numbers-LE — 提取代码库中所有硬编码数字，方便人工检查
• Units-LE — 提取所有带单位的数量并统一格式，遇到含义不明确的数量时会按名称拒绝处理
• Dates-LE — 提取所有日期和时间戳，并给出每个日期和时间戳解析出的确切时刻
• IDs-LE — 提取所有 UUID、ULID、NanoID、ObjectId 和 Snowflake，并解码其中的时间
• IPs-LE — 提取所有 IP 地址、CIDR 网段和 MAC 地址，统一格式并按范围分类
• URLs-LE — 提取代码库中的所有 URL，并给出协议和确切位置
• Paths-LE — 提取代码库中的所有文件路径，并说明它们是否仍指向实际内容
• Colors-LE — 提取代码库中的所有颜色，并指出哪些颜色不在你的调色板中

检查

• Regex-LE — 查找代码库中的所有正则表达式，并报告哪些可能导致灾难性回溯
• Versions-LE — 查找某个依赖项在仓库的各个清单文件中受到不同约束的位置
• i18n-LE — 识别项目使用的 i18n 库，然后依据该库的规则审查其目录
• Scrape-LE — 在编写抓取器之前检查网页能否抓取，并说明何时无法判断

防护

• Secrets-LE — 查找代码库中的硬编码凭据，绝不在报告中打印凭据
• EnvSync-LE — 比较目录树中的 dotenv 文件，并指出哪些文件缺少哪些键
• Unicode-LE — 查找那些隐藏含义的 Unicode 字符——双向控制字符、不可见字符、同形异义字符、混合文字系统

每款工具都独立运行：没有共享的 crate，也没有发布的核心库。若有两款工具得出相同结论，那是因为这个答案经得起两次验证。

联系 — nolindnaidoo.com · GitHub · LinkedIn

nolindnaidoo 的其他项目

Rust — pixelcoords 和 pixelactions 构成一个工作循环：pixelcoords 回答 位置，pixelactions 在那里执行操作。它们有各自的工具、各自的风格——不属于 LE 系列。

• pixelcoords — 冻结屏幕，标记区域，获取像素级精确的坐标和裁剪图像 pixelcoords.dev · crates.io · docs.rs
• pixelactions — 使用经过人工验证的坐标执行交互，并确认操作已生效 pixelactions.dev · crates.io · docs.rs

许可证

MIT © nolindnaidoo