抓的页码和实际页码有偏差，例如66-81+125只能抓到66-81而抓不到后半部分。

Jasminum 抓知网元数据的链路大致是：

1. 先从 PDF 内容或文件名提取题名。
2. 用题名去知网检索接口查候选结果：大陆站是 https://kns.cnki.net/kns8s/brief/grid。
3. 解析检索结果里的详情页 URL、exportID/dbname/filename 等。
4. 选中结果后，不是 Jasminum 自己逐项解析页码，而是把知网页面交给 Zotero 官方 CNKI translator：5c95b67b-41c5-4f55-b71a-48d5d7183063。
5. Zotero 的 CNKI translator 再调用知网导出接口，用 RefWorks/EndNote 之类的导出文本生成 Zotero 条目。

关键代码在这里：
cnki.ts 检索知网，
cnki.ts 调 Zotero CNKI translator，
[CNKI.js](https://raw.githubusercontent.com/zotero/translators/master/CNKI.js) 里又用 DisplayMode=Refworks 调知网导出接口。

66-81+125 变成 66-81，更像是导出/导入格式解释造成的，不是 Zotero 页码字段不能存。Zotero 官方 CNKI translator 的测试用例里就有 18-30+115，说明 pages 字段可以保存这种格式。

最可疑点是 RefWorks 导入器的处理逻辑：SP 映射到 pages，OP 只有在现有 pages 还不是范围时才拼成 起页-止页；如果 SP 已经是 66-81，再遇到 OP 125，它会把 125 当作备用页数/其他页码处理，而不会拼成 66-81+125。代码在：
RefWorks Tagged.js

所以结论是：Jasminum 本身没有专门修正页码；它依赖知网导出文本和 Zotero translator。如果知网给出的 RefWorks/EndNote 数据把页码拆成 SP 66-81 + OP 125，当前导入逻辑就容易只留下 66-81。如果知网直接给 SP 66-81+125，则能正常保留。

解决思路：最稳的是在 Jasminum 的 CNKI 翻译后补一层修正，从知网详情页或导出文本中抓完整“页码/Pages”字符串，若发现 数字-数字+数字，就覆盖 newItem.pages。比改 Zotero 全局 RefWorks importer 更安全，因为后者会影响所有 RefWorks 导入。