Units-LE

Units-LE：一个量，一个单位

查找文档中的所有量——时长、大小、百分比、频率——并以一个基准单位显示其数值，同时明确指出含义不明的量
YAML · TOML · JSON · INI · dotenv · CSV · 以及其他任何格式，均按文本扫描

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

功能介绍

一个服务中的 timeout: 30s 和另一个服务中的 timeout: 30000，实际上都是 30000 毫秒，但文本本身并未说明这一点。memory: 1GB 和 memory: 1GiB 相差 7%，乍看却一模一样。

运行 Units-LE: Extract Quantities 后，活动文档中的每个量——即与单位紧密相连的数字——都会在编辑器旁边的报告中显示：既保留文档中的原始写法，也用一个基准单位表示，便于比较，并附上行号、列号和键路径。无法明确解析的量会保留在报告中，并标明原因，而不是给出猜测。适用于 VS Code，以及 Cursor 和 VSCodium 等基于 VS Code 的编辑器（可从 Open VSX 安装）。

• 迁移前——列出值文件中的所有超时和内存限制，并以毫秒和字节表示
• 审查配置变更时——找出 500m，它对一位读者意味着分钟，对另一位读者则意味着毫核
• 对照操作手册或保留策略——核对文档规定的限制与配置设定的限制
• 检查整个项目——汇总所有包含量的文件及其数量

它绝不会改写文档，也绝不会猜测。

安装

拒绝本身也是一项发现

这就是整个产品。任何工具都能把 30s 乘以一千； 让这个工具在审查中真正实用的，是它不会假装确定。

每种情况都会保留其行、源文本、位置，以及一句可供人采取行动的说明。拒绝绝不会导致行被丢弃，也绝不会靠猜测得出结果。

si_iec_hazard 会添加标注；不会拒绝提供结果

这是唯一仍会给出结果的原因。按照标准，MB 表示 10^6， 因此 1MB 会返回1000000 字节，并且附带 reason: "si_iec_hazard" — 因为很多软件写 MB 时实际指的是 2^20。与其什么都不报告，不如报告标准结果并附上标记；而选择 2^20，正是这个工具存在的原因：不做这种猜测。

因此，它不计为被拒绝。带有 si_iec_hazard 的行是唯一同时包含 base 和 reason 的行；其他所有原因都表示 base 为 null。

没有单位的裸数字根本不算发现项。 timeout: 30 在这里不会产生任何结果 — 这是 numbers-le 要处理的问题，而这条边界正是区分这两个工具的关键。

四种维度

大小写是符号的一部分。 MB 是兆字节，Mb 是兆比特；若将两者大小写折叠，就会悄然造成八倍的差异，因此不接受 Mb，也不会将其视为同义写法。

1h30m 是一种语法，而 1h + 30m 是算术。 前者是一个由两部分写成的量。在复合写法中，各部分会彼此消除歧义——单独的 m 不接受；而在 h 与 s 之间的 m 只能表示分钟，因为复合写法按从大到小的顺序书写。这个顺序是强制要求，而非默认假设，因此 30s1h 根本不算一个量。

物理单位并非未实现，而是不在目标范围内。 长度、质量和温度属于不同的问题；读取这些单位就意味着要进行单位代数（m/s²），这正是 uom 的用途。参见 crate/SPEC.md。

格式

支持解析 JSON、YAML、CSV、TOML、INI 和 dotenv。其他所有内容都会作为文本扫描——Kubernetes 清单、Terraform 文件、包含限值的 Markdown 表格、日志——因此实际包含这些量的文件能够提取出它们，而不是一无所获。

与 numbers-le 的文本扫描不同，这种扫描会寻找特定结构，因此 v1.2.3 不会产生任何结果，而不是被识别为两个数字。每种带有结构的格式都会附带一个键路径——cache.ttl、limits[0]、server.timeout、TIMEOUT——每条发现结果都会附带从 1 开始计数的行号和列号；列号以 UTF-16 单位计数，也就是编辑器显示的数值。

它的误报类别经过测量，而非臆测。 不透明数据块中的一串字符仍会被识别为一个量：UUID 中的 001d 是一天，base64 哈希末尾的 /2w== 是两周。让这些内容通过的边界字符，与让 -30s 和 ttl=30s 通过的是同一类字符。对 crate/fixtures/documents/opaque.txt 进行扫描——这个文件有 280 行锁文件哈希、容器摘要、git 对象名称、UUID 和签名材料，其中没有任何内容表示一个量——扫描会报告 5 条误报，占 1.8%，而且每次运行测试都会打印这个数字。每条误报都会附带行号和列号，因此你可以把它作为一行丢弃，而不是当作可信数字。

不妄加判断

不会说“这个超时太短”。没有默认值数据库，没有转换开关，不会重写，也不会进行算术计算。它只报告文档写了什么，以及这些内容用一个基本单位表示意味着什么；哪些限值才合适，由审阅者决定。

跨文件夹或工作区

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

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

报告会先显示一个表格，列出所有包含相关内容的文件，然后为每个文件分别显示一个部分：

# Units-LE workspace report

`my-project` · 113 file(s) read · 3 quantit(ies), 1 could not be resolved

| File | Quantities | Could not be resolved |
|---|---|---|
| `deploy/values.yaml` | 3 | 1 |

## `deploy/values.yaml` · yaml (3)

- **2:8** · `1h30m` · duration · → `5400000` milliseconds · key `cache.ttl`
- **3:9** · `512MiB` · bytes · → `536870912` bytes · key `memory`
- **4:7** · `2GB` · bytes · → `2000000000` bytes · key `disk`

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

扫描会读取什么。 文件内容来自磁盘，因此不会读取尚未保存的编辑。如果文件超过安全大小限制，或者不是 UTF-8 文本，则不会读取。扫描最多处理 5,000 个文件或列出 10,000 个数量。报告末尾会逐条列出所有未纳入的内容，因此不会把简短的报告误认为项目干净无异常。

会跳过什么，以及如何更改设置。 默认启用三个开关，每个开关都可以在设置中单独关闭：

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

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

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

无法解析的内容。 一个项目中可能存在很多这类内容，而且它们会挤占其他结果。因此，扫描会在表格中按文件统计它们，但不会逐项列出。units-le.workspace.scanIncludeRefusals 会列出每一项及其原因；units-le.workspace.scanProblemsEnabled 还会将它们显示在“问题”面板中，每一项都可以点击跳转。

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

位置

每行开头都会显示数量所在的行和列：

- **2:8** · `1h30m` · duration · → `5400000` milliseconds · key `cache.ttl`

关闭 units-le.showPositions 后，同一行会显示为：

- `1h30m` · duration · → `5400000` milliseconds · key `cache.ttl`

其他内容都不变：行数相同，数量也相同。剪贴板中的副本由单独的设置 units-le.clipboardIncludesPositions 控制，因此报告可以在屏幕上显示位置，复制时却不包含位置。扫描和 Extract 都会应用这两项设置。

在 AI Agent 中使用

同一引擎也会作为 MCP 服务运行，因此 Agent 可以直接读取数量，无需手动换算单位。

extract_units(content, format?, filename?, dimension?, maxResults?)

它会以数据形式返回编辑器渲染的报告——数量默认上限为 500，并通过 meta.truncated 标明是否截断。它不会读取任何文件，也不会发出网络请求。该工具以 units-le-mcp 的名称发布在 npm 上，并以 io.github.nolindnaidoo/units-le 的名称发布在 MCP registry 中。它的响应与 Rust CLI 服务完全一致：两者使用同一组语料库运行，并通过差异测试向两者输入数千份各种格式的生成文档——包括格式错误的文档，因此也会比较各解析器的错误文本。

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

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

CLI

同一提取功能可从终端或 CI 步骤扫描整个目录树：Rust CLI 位于 crate/，并与扩展共享一组语料库——crate/fixtures/——因此两者读取数量的方式始终一致。同一命令行工具也以 units-le 的名称发布在 npm 上，适用于安装了 Node 但没有 Rust 的机器；CI 会在三种操作系统上逐字节校验它与 crate 的一致性。

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

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

units-le .                                 # every quantity in the tree; one JSON report per file when piped
units-le --dimension duration config/      # only the timeouts
units-le --strict config/                  # exit 2 if anything was refused
cat values.yaml | units-le --stdin --format yaml
units-le mcp                               # extract_units and units_le_scan over MCP on stdio

退出码遵循 grep 的规则——找到数量时为 0，未找到时为 1，问题格式错误时为 2。拒答不会改变退出码；--strict 会将退出码设为 1。

命令

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

设置

语言

除英语外，还支持 12 种语言：

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

涵盖两部分：清单（命令标题、设置名称和描述），以及扩展运行时显示的所有内容（通知、状态栏和报告标题）。拒绝句和解析器错误使用引擎的英语，与 CLI 中的内容相同。

隐私与安全

• 不访问网络。 扩展绝不会向任何地方发送数据。telemetryEnabled 设置只会将事件写入可供检查的本地输出通道（Units-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 中断言——以基准测试作为构建门槛，只能说明运行器当时有多忙。

测试

20 个文件中共有 654 个测试用例，另有一个在真实 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