清除神秘的引用標記

症狀

該文件會編譯，但在引用應該出現的地方，您會看到一個粗體問號“[?]”，並且日誌包含諸如“LaTeX警告：引用’knuth84’未定義”之類的行。有時每個引用都會受到影響，有時只有一兩個引用受到影響。因為這是警告而不是錯誤，所以 PDF 仍然可以構建，而這些標記很容易被忽略，直到讀者指出它們為止。

為什麼會發生

LaTeX 不直接解析引用。在第一次傳遞時，它將每個請求的金鑰記錄在輔助文件中。然後，後端程式（“bibtex”或“biber”）在“.bib”資料庫中尋找這些鍵並寫入格式化條目。另外两次 LaTeX 传递将结果折回。問號表示在最後傳遞時，該鍵不存在格式化條目。造成這種症狀的每個原因都是某種破壞管道的方式。

依序找出原因

首先檢查密鑰本身。 \cite{knuth84} 和 @article{knuth1984,...} 是不同的字串，並且匹配是精確的，包括大小寫。在「.bib」檔案中搜尋警告中指定的金鑰；任何一方的拼字錯誤都是最常見的罪魁禍首，日誌中的第一個缺失鍵警告就是要追蹤的警告。

接下來，確保完整的編譯週期運行。順序是 LaTeX，然後是 bibtex 或 biber，然後是 LaTeX 兩次。一次編譯永遠無法解析引用，因為後端尚未執行。 Oleafly 會自動驅動整個週期，但手動建置或配置錯誤的編輯器可能會在第一次通過後停止。

第三，驗證資料庫路徑。 \bibliography{refs} 和 \addbibresource{refs.bib} 相對於主檔案解析，因此子資料夾中的資料庫必須編寫為 bib/refs 或 bib/refs.bib。錯誤的路徑會悄悄失敗，並且通常會毀掉整個參考文獻清單；對於更大的失敗，請參閱空參考書目。

最後，將後端與系統進行配對。載入 biblatex 的文檔必須使用「biber」進行處理。給它經典的“bibtex”不會產生可用的輸出，並且無論您重新編譯多少次，每個引用都仍然是一個問號。

如果一切都失敗了

陳舊的輔助文件可以保留舊的、損壞的狀態。刪除文件旁邊的「.aux」、「.bbl」和「.blg」檔案並從頭開始重建。在刪除之前，.blg 檔案也值得閱讀：它是後端自己的日誌，並且明確命名了遺失的資料庫和格式錯誤的條目。