1. Что я на самом деле пытался сделать
Я не искал идею для продукта. Я дописывал статью, семьдесят шесть ссылок вглубь литературы о цифровой грамотности в сфере ИИ в образовании, и хотел ровно одного перед отправкой: уверенности, что ни одна из моих ссылок не ведёт на мёртвую DOI или, того хуже, на чужую DOI, молча указывающую на статью другого автора. Поэтому я сделал очевидное — экспортировал всю библиотеку из Zotero в BibTeX, тот же инструмент, которым пользуюсь для каждой своей статьи, тот же, к которому в такой ситуации тянется большинство людей. Я открыл файл, рассчитывая пройтись по DOI одну за другой.
До этого дело не дошло. Проблемой оказался сам файл.
2. Заголовок с атрибутами тега, вписанными как обычный текст
Запись armstrong_when_2014 в моей собственной библиотеке — короткая, часто цитируемая методическая статья о том, когда вводить поправку на множественные статистические сравнения.[1] Её поле заголовка, в файле, который выдал мне Zotero, выглядело полностью так:
Настоящий заголовок — «When to use the Bonferroni correction». Где-то до Zotero — метаданные, размещаемые издателями, регулярно так делают, чтобы отрисовать первую букву слова капителью — заголовок был записан как HTML: <span style="font-variant:small-caps;">B</span>onferroni. Zotero не может вставить буквальный < или > в поле BibTeX — оба символа ломают LaTeX, — поэтому его экспортёр экранировал только сами угловые скобки, превратив их в {\textless} и {\textgreater}, а всё, что было написано внутри тега, оставил в поле как обычный текст. Тег исчез. Его содержимое — span, style="font-variant:small-caps;", закрывающий /span — нет. При чтении как прозы заголовок настоящей, корректно опубликованной статьи в моём собственном списке литературы превратился вот во что:
Гладко было на бумаге, да забыли про овраги: в самом BibTeX-файле всё выглядит как обычное поле заголовка в фигурных скобках — ровно до того момента, как кто-нибудь всё-таки прочитает, что в нём написано.
Автоматически сгенерированное Zotero поле shorttitle для той же записи показывает ту же ошибку, пойманную на середине сокращения, и именно это подсказало мне, что дело не в разовом сбое отображения: что бы ни сокращало заголовок для внутренних нужд Zotero, оно работало с той же испорченной строкой и точно так же не подозревало, что стоит посреди тега, как и сам экспорт.
Это именно та ошибка, сквозь которую инструмент проверки цитирования обязан видеть, а не спотыкаться о неё. Сравните эту строку, как она написана, с чистым заголовком, который Crossref хранит для DOI 10.1111/opo.12131, — и совпадения, о котором стоило бы говорить, не найдётся: ложная тревога против цитаты, которая на самом деле абсолютно верна. Поэтому обработка, которую StrictCite выполняет при любой загрузке, раскрывает экранированные скобки обратно в настоящий тег, распознаёт его как разметку, а не как часть заголовка, и удаляет его — закрывая при этом пробел, который именно такой стиль тега оставляет на первой букве слова, так что при сравнении читается «Bonferroni», а не «B onferroni». Это работает независимо от того, приходит ли разметка как настоящий <span> прямо из JSON реестра — Crossref и OpenAlex оба так делают, — или, как в моём собственном файле, экранированной под LaTeX инструментом экспорта, у которого не было способа узнать, что он стоит посреди тега.
3. Тот же механизм, на соседнем поле
Запись о конференции чуть дальше в моей собственной библиотеке несёт ту же ошибку в миниатюре. Поле booktitle для статьи CSEE&T 2024 года[2] выглядело так:
Здесь двойное кодирование, а не половинчатая очистка: исходные метаданные уже записали амперсанд как HTML-сущность & — само по себе признак того, что где-то раньше значение не декодировали, хотя должны были, — а экспортёр Zotero, найдя буквальный символ & внутри этой сущности, дополнительно экранировал его для LaTeX обратной косой чертой. Теперь шесть символов делали работу одного. При буквальном прочтении в моём собственном списке литературы значилась конференция «CSEE&T», а не «CSEE&T». StrictCite декодирует HTML-сущность до того, как включается какая-либо обработка, специфичная для LaTeX, поэтому значение, уже содержавшее такую сущность — независимо от того, какая сторона её ввела, — разрешается ровно в тот символ, который оно всегда обозначало, а не в одну из двух половин двойного кодирования.
4. Количество страниц, оказавшееся размером файла
Третья ошибка в моём собственном файле вообще не была связана с разметкой. Отчёт Мельбурнского университета и KPMG за 2025 год об общественном доверии к ИИ, размещённый на Figshare,[3] содержал следующее:
Это число — не количество страниц. Это размер, в байтах, PDF-файла, который Figshare выдаёт для этой записи, — величина, которую собственные метаданные Figshare хранят рядом с DOI и которую переводчик Zotero для записей Figshare перенёс прямиком в поле, предназначенное для номеров страниц. На первый взгляд в этом не было ничего явно неправильного: это правдоподобно выглядящее целое число, стоящее ровно там, где полагается быть номеру страницы, — именно поэтому я, скорее всего, пропустил бы это, читая файл глазами. Локатор, который не разбирается ни как номер страницы, ни как диапазон, движком StrictCite таковым и не утверждается: на стороне реестра нет ничего в форме «с. 4 974 511», с чем его можно было бы сравнить, а запись отчёта вовсе без диапазона страниц — это не противоречие, так что ничего не заявляется так, будто обе стороны действительно назвали разные числа.
5. Почему я рассказываю об этом, даже если вы никогда не воспользуетесь StrictCite
Хочу быть точным насчёт того, чем это не является: это не повод не доверять именно Zotero, и не аргумент в пользу того, что вручную набранный BibTeX справляется лучше — это не так, и он приносит свой собственный класс ошибок, которых здесь нет. Zotero остаётся тем, чем я пользуюсь для каждой своей статьи. Изменилось то, что я перестал считать экспортировано инструментом, которому я доверяю и готово к подаче одним и тем же утверждением. Экспорт наследует всё, что издатель поместил в метаданные на собственной странице, всё, что конвейер приёма реестра декодировал или не decodировал, и всё, что переводчик где-то по пути занёс не в то поле, — и делает это молча, потому что нигде в этой цепочке между издателем и моим списком литературы никто не был в положении это заметить.
Так что совет здесь — не реклама. То, что я теперь могу проверять это автоматически, — следствие того, что я построил StrictCite, но сама суть верна независимо от того, каким инструментом вы пользуетесь: не принимайте экспорт из Zotero, Mendeley, EndNote или чего угодно ещё за чистый, готовый к печати текст только потому, что его создало программное обеспечение, которому вы доверяете. Одно такое поле, незаметно перенесённое из первого черновика, переживает каждую последующую правку по той же причине, по которой я сам чуть его не пропустил — в нём нет ничего, что выглядело бы неправильным, пока что-то его действительно не прочитает. Оно способно без единой царапины пройти через месяцы правок и оказаться, нетронутым, в списке литературы статьи в её финальном, готовом к печати виде, под вашим собственным именем.
Доверяй, но проверяй — и это в равной мере касается реестра, инструмента и нас самих.
Если хотите увидеть, что на самом деле содержит экспорт вашей собственной библиотеки, поле за полем: strictcite.com. Бесплатный тариф не требует карты.