IDs-LE

IDs-LE：看起来像标识符的 ID

找出文档中的每个标识符，解码其中的时间，并拒绝那些无法确认为标识符的内容
UUID · ULID · NanoID · MongoDB ObjectId · Snowflake

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

功能介绍

一张支持工单引用了 6a7bb780a1b2c3d4e5f60718，并询问记录是什么时候创建的。正则表达式判断它是 ObjectId，生成于 2026-08-12。但它其实是 Git 提交哈希的前缀，那个日期只是碰巧落在一个看似合理的年份。

打开文档，运行 IDs-LE: Extract IDs，即可按类型列出其中的每个标识符，并显示其行列位置、文档自身为其指定的键路径、是否有效；对于包含时钟信息的六种方案，还会显示其生成时刻，格式为 ISO-8601 UTC。报告会在编辑器旁打开。IDs-LE: Scan Workspace for IDs 会对项目中的每个文件执行相同操作，IDs-LE: Scan Folder for IDs 则扫描单个文件夹。支持 VS Code，以及 Cursor 和 VSCodium 等基于 VS Code 的编辑器（可从 Open VSX 安装）。

• 阅读日志或转储文件 — 哪些是 UUID v7？每个分别是什么时候生成的？
• 审查配置 — 查找漏进生产环境的占位空 UUID
• 信任十六进制字符串之前 — 确认文档是否真的表明它是标识符
• 扫描整个项目 — 在一张表中查看所有包含标识符的文件及其数量

无法如实命名的内容会连同原因一并报告，绝不会被丢弃。 不会改写任何内容。

安装

宁可拒绝，也不猜测

一个自信地给出错误答案的工具，比停止处理并说明所需信息的工具更糟。因此，对于本 crate 不会明确判定类型的每个结果，都会在报告中列出一行并说明原因——绝不丢弃行，也绝不默默猜测。

有些情况值得特别说明，因为正则表达式常会在这些情况上自信地判断错误：

• 5d41402abc4b2a76b9719d911017c592 既是未加连字符的 UUID，也是 MD5 摘要。文档中没有信息可以区分它们，因此这里也不会做出选择。
• 6a7bb780a1b2c3d4e5f60718 是 24 个十六进制字符。在 _id 下，它是一个于 2026-08-12 生成的 ObjectId。在 checksum 下或正文中，则会被拒绝——ObjectId 的完整规范就是 24 个十六进制字符，因此截断的 SHA-1 也完全符合其格式，只有文档才能区分二者。
• channel_id 下的 1536886938009600000 是一个时间为 2026-08-12 的 Discord Snowflake。单独出现在 user_id 下时会被拒绝，因为它也符合 Twitter 时间纪元，而文档没有说明应采用哪一种。在 population 下，它根本不会被识别。

完整表格以及工具遵循的界限，请参见 crate/SPEC.md。

类型

其中两种类型需要文档授权。 ObjectId 是 24 个十六进制字符，Snowflake 是一个大整数；它们都不包含版本、变体、校验和或受限字符集，因此仅凭自身都无法判定类型——截断的 git 哈希在结构上完全符合 ObjectId，字节计数在结构上完全符合 Snowflake。只有当字段名以 id 结尾时（_id、userId、USER-ID、$oid），才会将它们识别为对应类型；否则会以 ambiguous_kind 拒绝。在纯文本文件中，由于完全没有键名，因此永远不会识别这两种类型。

RFC 9562 定义的全部八种 UUID 版本都会被识别，全部四种变体——ncs、rfc4122、microsoft、future——都会被报告。只有在 RFC 变体下才会报告版本，因为在其他任何布局中，那四个位都不是版本字段。

时间戳

这一部分没人想写两遍。以下六种格式都包含时钟信息，但位布局各不相同，使用的纪元也有四种不同，其中一个始于 1582 年：

所有格式都会转换为相同的 ISO-8601 UTC 字符串，并且始终显示毫秒。UUID v2 会被识别，但不会解码：它的时钟低 32 位被 POSIX uid 覆盖，因此解码结果大约会相差七分钟，不能算作同一种时间戳。

如果解码结果早于 1990 年，或晚于当前时间一年以上，则会拒绝解码并标记为 timestamp_implausible。解码结果会显示在标记旁边的同一行，因为隐藏依据的拒绝结论无法供读者核验。

格式

JSON（及 JSONC）、YAML、TOML、INI（.properties）、dotenv、CSV 和 TSV 会为每项发现结果提供键路径，例如 service.requestId、documents.[0]._id、discord.channel_id。其他所有内容都按文本读取：相同的匹配项，出现在相同位置，但不带键路径。

键路径是证据，不是装饰。只有当文档将某个字段称为 id 时，ObjectId 和 Snowflake 才会被命名。因此，在 .json 中被命名的匹配项，在旁边的 .md 中会显示为 ambiguous_kind——同一行、同一位置、同一解码结果，但显示原因而非名称。

扫描文件夹或工作区

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

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

报告会先显示一张表，列出包含内容的所有文件，随后为每个文件单独显示一个部分：

# IDs-LE workspace report

`my-project` · 113 file(s) read · 2 named, 3 could not be named

| File | Named | Could not be named |
|---|---|---|
| `lib/transcripts.ts` | 2 | 3 |

## `lib/transcripts.ts` · text (2)

- **55:40** · `019ff344-cc00-7abc-8def-0123456789ab` · uuid · v7 · 2026-08-12T00:00:00.000Z
- **56:24** · `01KZSM9K00ABCDEFGH12345678` · ulid · 2026-08-12T00:00:00.000Z

> 2 file(s) larger than the safety limit were not read.

扫描会读取哪些内容。 文件从磁盘读取，因此不会看到尚未保存的编辑。超过安全大小限制或不是 UTF-8 文本的文件会被跳过。扫描会在达到 5,000 个文件或 10,000 个已列出的标识符时停止。报告末尾会为每个被跳过的内容添加一行，避免将简短报告误认为项目没有问题。

跳过哪些内容，以及如何更改设置。 默认启用三个开关，可在设置中分别关闭：

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

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

IDs-LE: Open Settings 会在设置编辑器中打开所有这些设置。

无法命名的内容。 在整个项目中，这类内容可能有数千个，其中大多是生成文件中的摘要。因此，扫描会在表格中按文件计数，但不会逐一列出。ids-le.workspace.scanIncludeRefusals 会逐项列出并说明原因；ids-le.workspace.scanProblemsEnabled 还会将它们显示在“问题”面板中，每项都是一行可点击的内容。

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

位置

每行开头都会显示标识符所在的行和列：

- **3:13** · `f47ac10b-58cc-4372-a567-0e02b2c3d479` · key `service.id` · v4

关闭 ids-le.showPositions 后，同一行会变为：

- `f47ac10b-58cc-4372-a567-0e02b2c3d479` · key `service.id` · v4

其他内容都不会改变：行数和计数都相同。剪贴板中的内容由单独的设置 ids-le.clipboardIncludesPositions 控制，因此报告可以在屏幕上显示位置，而复制时不包含位置。与“提取”一样，这两个设置也适用于扫描。

在 AI Agent 中使用

相同的引擎也可作为 MCP 服务运行，因此 Agent 可以直接调用它，而不必猜测哪串十六进制字符对应什么。

extract_ids(content, format?, filename?, kind?, maxResults?)

它会以数据形式返回编辑器所呈现的行，包括拒绝结果；默认上限为 500 行，并通过 meta.truncated 标记是否截断。它不会读取任何文件，也不会发起网络请求。该工具以 ids-le-mcp 的名称发布在 npm 上，并以 io.github.nolindnaidoo/ids-le 的名称发布在 MCP 注册表中。它的回答与 Rust CLI 服务完全一致：两者使用同一语料库运行，并通过差异测试，将数千份各格式的生成文档分别输入两者，再比较每个回答。

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

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

CLI

同样的提取功能也可以通过终端或 CI 步骤扫描整个目录树：这是一个位于 crate/ 中的 Rust CLI，与扩展共用同一语料库——crate/fixtures/——因此两者对标识符的读取方式绝不会不同。相同的命令行工具也以 ids-le 的名称发布在 npm 上，适用于已安装 Node 但未安装 Rust 的机器；CI 会在三种操作系统上逐字节地将它与 crate 版本进行比对。

从 npm 安装（ids-le）或从 crates.io 安装（ids-le）。两种方式都会安装相同的 ids-le 命令。

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

ids-le src/                    # a tree; one JSON line per file on stdout when piped
ids-le --kind uuid src/        # one scheme; refusals still reported
ids-le --strict src/           # exit 2 on anything that could not be named
ids-le --hidden src/           # include .env
ids-le mcp                     # extract_ids and ids_le_scan over MCP on stdio

退出码遵循 grep 约定——找到标识符时为 0，未找到时为 1，问题格式错误时为 2。拒绝结果不会改变退出码；使用 --strict 可让流水线将拒绝结果视为失败。

命令

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

设置

语言

除英语外支持 12 种语言：

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

两部分均已覆盖——清单（命令标题、设置名称和说明），以及扩展运行时显示的所有内容（通知、状态栏和报告标题）。拒绝详情使用引擎的英文，与 CLI 中的内容一致。

隐私与安全

• 不访问网络。 扩展绝不会向任何地方发送数据，也不会通过数据库或 API 验证任何内容。telemetryEnabled 设置只会将事件写入可供检查的本地输出通道（IDs-LE）。
• MCP 服务也遵循同样的原则。 它接收作为参数传入的内容并返回数据：不访问文件系统、不进行网络调用、不收集遥测数据。
• 错误通知会对主目录和类似凭据的片段进行隐藏处理。
• 评分提示最多出现两次。 第 3 次成功使用时，扩展会询问一次是否愿意评分；如果你选择了 稍后 或关闭提示，则会在第 20 次使用时再询问一次。选择 不再询问 后将不再显示提示。自行将 notificationsLevel 设置为 important 或 silent 也会关闭此提示。计数保存在 VS Code 的扩展存储中，不会发送到任何地方；点击 评分 会在浏览器中打开你安装扩展的平台页面——VS Code Marketplace 或 Open VSX。

文档

性能

在 Apple M5 Pro、24 GB RAM、Node 24.3.0 上预热后运行 7 次所得的中位数。输入由 scripts/benchmark.ts 生成，而非纳入版本库，因此上述大小就是实际测得的值。 运行 bun run benchmark 可复现。

这些数据因机器而异，CI 不会对此作出保证——用来卡住构建的基准测试，只能告诉你运行器当时有多忙。

测试

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

由真实运行生成——coverage/coverage-summary.json 和 coverage/test-results.json——再通过 scripts/coverage-readme.js 生成；若本节内容发生偏差，CI 将失败。运行 bun run test:coverage 可复现，用例数量以 vitest 输出为准。

LE 系列更多工具

十六款专用工具，满足每个模型日常工作的需要。每款都提供 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