抓取知网引用数格式问题 about jasminum HOT 18 OPEN

BUG说明 问题1: 直接把pdf拉到zotero里时会自动识别引用数，格式为“640 citations(CNKI)[2024-1-13]<>”

从 CSL 的角度，最好避免非 key-value 的内容填在 extra 中。这是因为 citeproc-js 处理 extra 的内容时遇到第一行非 key: value 格式会停止处理后续的内容，比如 640 citations(CNKI)[2024-1-13]<>\noriginal-title: Foo，citeproc-js 在第一行会停下，不再读取 original-title。

后期再手动更新引用数时，不会清空字段后重新更新，而是会在原有引用数的下一行增加新引用数，格式为“CNKICite: 640” 两种操作更新的引用数格式不同，希望能统一格式，感谢！

我在想要不要为 extra 中的字段定个标准，至少在中文插件的范围内。这样不同的插件、translator 不会造成冗余信息。@l0o0 @northword @jiaojiaodubai

问题2: “CNKICite: 640”这种格式，引用数字在最后面，很难文档列表中一眼看到引用了多少次，必须要给这个字段拉很长的空出来才行； 在希望能把引用数字放到最前面（或者直接删掉“CNKICite”），这样也方便按引用数排序。

建议插件实现以下功能：将 extra 的中的“引用数”字段信息，在 Zotero 主视图中增加一栏显示出来，这样更直观，而且方便排序。

目前 better bibtex 的处理方式可以供参考，这个插件将 “Citation Key”保存在 extra 中，并单独一栏显示。

from jasminum.

我在想要不要为 extra 中的字段定个标准，至少在中文插件的范围内。这样不同的插件、translator 不会造成冗余信息。

这个是指什么 -- 是指字段的名称吗？

from jasminum.

是的，应该制定extra里面记录那些信息应该用什么键名称的规范。

translators_CN的大部分翻译器已经完成代码标准化任务（即通过了ESLint，详见LintIt），字段标准化正等待@zepinglee 的代码审查。我认为extra的内容也是字段标准化的重要部分，确实需要大家达成共识。

from jasminum.

国内作者开发的插件里，似乎只有茉莉花抓引用数；绿青蛙抓期刊分级，
style的期刊分级等没有存在 extra 而是自己的json里。
translate插件用了titleTranslate和abstractTranslate两个字段，除此之外的字段基本上都是供插件自己使用的了，因此如果是和引用数/期刊分级相关的，只需要 l0o0 和韩老师适配即可。

还有其他字段需要共用的吗？

对于此issue提到的第一种错误的存储方式，我的建议是直接清除掉，这个linter可以做。

from jasminum.

感觉titleTranslate设为original-title更妥当，而关于分区，引用数，知网、万方都可以在抓取的时候顺便抓取这些内容，读秀甚至还有影响因子……这些有必要和插件那边保持一致。

另外，我今天遇到一个引文样式的案例要求中文作者按照姓氏的笔画数排序，我感觉linter应该可以在extra为CSL提供sort所需的键。@northword @zepinglee

from jasminum.

我在想要不要为 extra 中的字段定个标准，至少在中文插件的范围内。这样不同的插件、translator 不会造成冗余信息。

这个是指什么 -- 是指字段的名称吗？

是的。另外还有字段的命名风格可以统一。

有三种命名风格：

1. UI label 风格：# of Pages。
2. Zotero field 风格：numPages
3. CSL 风格：number-of-pages。

我个人比较偏向第一种，因为 BetterBibTeX 的 Citation Key 是这种风格。

国内作者开发的插件里，似乎只有茉莉花抓引用数；绿青蛙抓期刊分级， style的期刊分级等没有存在 extra 而是自己的json里。 translate插件用了titleTranslate和abstractTranslate两个字段，除此之外的字段基本上都是供插件自己使用的了，因此如果是和引用数/期刊分级相关的，只需要 l0o0 和韩老师适配即可。

还有其他字段需要共用的吗？

印象中还有什么 EI 索引、xx 核心之类的。我的领域不太关注这些，所以我也不太了解。

from jasminum.

感觉titleTranslate设为original-title更妥当

当前的并无问题，这个字段存放的是翻译，只是为了便于理解的，与原文无关，不是期刊提供的译文，与origin无关。

印象中还有什么 EI 索引、xx 核心之类的。我的领域不太关注这些，所以我也不太了解。

都是期刊分级，大部分都由绿青蛙提供。

from jasminum.

另外，我今天遇到一个引文样式的案例要求中文作者按照姓氏的笔画数排序，我感觉linter应该可以在extra为CSL提供sort所需的键。@northword @zepinglee

看了看这个要求，我觉得你可能理解错了？他要求的应该是参考文献表中每个项按一作排序，而不是每一项的作者直接按姓氏笔画排序。前者csl应可以实现。我认为将每一个参考文献的作者按姓氏笔画排序而不是保留原始作者列表顺序是不学术的。

理解错了，姓氏笔画排序是指 类似 https://zzb.ecnu.edu.cn/e5/72/c10976a124274/page.htm 这样？

（他的示例里甲乙丙丁都没有按笔画排序 🌚

from jasminum.

姓氏笔画排序是指 类似 https://zzb.ecnu.edu.cn/e5/72/c10976a124274/page.htm 这样？

我对“笔画顺序”的理解仅停留在字面意思上，如果能找到这样的书面规定是再好不过了👍

（他的示例里甲乙丙丁都没有按笔画排序 🌚

这种模板总是这样，说一套做一套（甚至连它正式的出版物上的引用样式也非常混乱）。即使抛开这个不太严谨的具体案例，我猜想按笔画顺序排序可能具有普遍意义，所以告知你们一下。毕竟姓氏是有限的，总可以编制出一个映射表来满足这种手工做起来特别麻烦的中文特色排版需求。我没找到比较权威而全面的列表，但这里有一些常用姓氏。

from jasminum.

另外，我今天遇到一个引文样式的案例要求中文作者按照姓氏的笔画数排序，我感觉linter应该可以在extra为CSL提供sort所需的键。@northword @zepinglee

对插件的需求另开 issue，如果需要 CSL 样式可以在 https://github.com/redleafnew/Chinese-STD-GB-T-7714-related-csl 提。

即使抛开这个不太严谨的具体案例，我猜想按笔画顺序排序可能具有普遍意义，所以告知你们一下。

GB/T 7714—2015 有提到笔画笔顺。

毕竟姓氏是有限的，总可以编制出一个映射表来满足这种手工做起来特别麻烦的中文特色排版需求。我没找到比较权威而全面的列表，但这里有一些常用姓氏。

Unicode 中有对应的数据，参考 https://en.wikipedia.org/wiki/Collation#Radical-and-stroke_sorting 和 https://www.unicode.org/reports/tr38/#SortingAlgorithm。我感觉这个更适合通过修改 citeproc-js 中的排序方式解决，目前中文默认为按拼音排序。

from jasminum.

@zepinglee
我记得官方和插件模板上，都是key-value这种形式。但Zotero 里好像并没有现成的 API 来读写这样的格式，需要借助额外的代码来读取。

在我看来， key-value 这种形式比较容易读写数据。不过对于展示来说，Extra 字段内容多了，确实不好浏览。不过这个问题，可以通过添加自定义列来实现，这个可以利用ItemTreeManager 和插件来实现。

从 CSL 的角度，最好避免非 key-value 的内容填在 extra 中。这是因为 citeproc-js 处理 extra 的内容时遇到第一行非 key: value 格式会停止处理后续的内容

CSL 解析时也是按照 key-value 的格式么？关于不规范的问题，是因为历史遗留问题，之前插件和转换器，在保存时比较随意，后面如果统一规范就直接按照相应的格式保存好。我建议是 key-value，在转换器保存时，如果遇到奇怪的字段，也是按key-value的格式保存。

from jasminum.

但Zotero 里好像并没有现成的 API 来读写这样的格式，需要借助额外的代码来读取。

应该没有。Zotero 导出 CSL-JSON 时处理 extra 的代码在 <https://github.com/zotero/utilities/blob/9c89b23153ce621ed0f1d581a5e32248704c6fb7/utilities_item.js#L609-L615

，也是用 regex 处理的。

CSL 解析时也是按照 key-value 的格式么？

是的。代码在 https://github.com/Juris-M/citeproc-js/blob/73bc1b44bc7d54d0bfec4e070fd27f5efe024ff9/src/load.js#L416-L421。

关于不规范的问题，是因为历史遗留问题，之前插件和转换器，在保存时比较随意，后面如果统一规范就直接按照相应的格式保存好。我建议是 key-value，在转换器保存时，如果遇到奇怪的字段，也是按key-value的格式保存。

赞成。

from jasminum.

另外还有字段的命名风格可以统一。

有三种命名风格：

1. UI label 风格：# of Pages。
2. Zotero field 风格：numPages
3. CSL 风格：number-of-pages。

我个人比较偏向第一种，因为 BetterBibTeX 的 Citation Key 是这种风格。

我不太能理解UI label的风格，它含有空格，对于编程来说，标识符一般不能含有空格（比如作为某个Object的key），2和3的风格我现在在混着用，自定义字段的话，可能用2的风格比较好？这样就能通过命名风格区分哪些是CSL要用到的key-val。不过2的风格遇到一些本就大小写混杂的术语会有点尴尬。

from jasminum.

另外还有字段的命名风格可以统一。
有三种命名风格：

1. UI label 风格：# of Pages。
2. Zotero field 风格：numPages
3. CSL 风格：number-of-pages。

我个人比较偏向第一种，因为 BetterBibTeX 的 Citation Key 是这种风格。

我不太能理解UI label的风格，它含有空格，对于编程来说，标识符一般不能含有空格（比如作为某个Object的key），2和3的风格我现在在混着用，自定义字段的话，可能用2的风格比较好？这样就能通过命名风格区分哪些是CSL要用到的key-val。

我刚试了一下，像 extra 中填写的 Original Date 导出 CSL-JSON 时会自动转为 CSL 的 original-date，但是 Series Editor 就不会转成 series-editor，很奇怪。所以我现在也更倾向于 2 了。这个应该跟 JS 的习惯一致吧？

from jasminum.

我刚试了一下，像 extra 中填写的 Original Date 导出 CSL-JSON 时会自动转为 CSL 的 original-date，但是 Series Editor 就不会转成 series-editor，很奇怪。

我想，应该是Zotero客户端应该是对CSL要用到的key做过优化的，允许我们以2记录而输出3。

所以我现在也更倾向于 2 了。这个应该跟 JS 的习惯一致吧？

JS太灵活了，以至于没有什么语言方面的习惯。
不过Zotero官方的编码指南里有提到：

Objects should be CamelCased and namespaced (Zotero.FooBar within the Zotero XPCOM object, ZoteroFooBar without)

实际上这也是官方给translator制定的Lint规则之一。

在我转换器那边，现在已经定制了一个通用的extra对象可以用来管理extra的键值，考虑到original-author这种键会重复，所以内部是以数组存储的：`[[]key, val, [key, val], ...]，所以转换器这边123这几种样式都可以支持，我喜欢用2只是因为风格更统一。

from jasminum.

一般情况下，js 的变量命名都遵循小驼峰，即 2。

from jasminum.

国内作者开发的插件里，似乎只有茉莉花抓引用数；绿青蛙抓期刊分级， style的期刊分级等没有存在 extra 而是自己的json里。 translate插件用了titleTranslate和abstractTranslate两个字段，除此之外的字段基本上都是供插件自己使用的了，因此如果是和引用数/期刊分级相关的，只需要 l0o0 和韩老师适配即可。

很久没有看文献了，印象中绿青蛙的分区用的键是中文的，即XX分区: 是/否这样的格式，如果我们把引用数和分区的键统一为小驼峰，那插件那边的兼容包袱会不会比较大？@redleafnew
我现在想在知网转换器里添加抓取期刊英文名的功能，可以顺带把分区抓下来，想跟这边统一一下分区的键名。

from jasminum.

我现在想在知网转换器里添加抓取期刊英文名的功能，可以顺带把分区抓下来，想跟这边统一一下分区的键名。

对于 CSL 来所最好使用 original-container-title，这样跟 original-author, original-title 一致。

from jasminum.