Herramientas e integración (CSL / arXiv / gestores)

Lo que de verdad devora tiempo en una bibliografía no es teclear entradas .bib. Es mantener un único .bib coherente entre una tesis, tres envíos y dos coautores. Por eso la mayoría de las herramientas bibliográficas de LaTeX están pensadas menos para acelerar la entrada de datos que para encontrar lo que se rompió después. Esta página recorre el camino completo: traer registros desde un DOI o arXiv, limpiar las entradas sucias, eliminar duplicados y fijar las claves de cita antes de pasar el archivo a un coautor, tanto con gestores de referencias como Zotero y JabRef como con los ayudantes de línea de comandos bibcop, checkcites y biber --tool que TeX Live ya instaló.

Obtener BibTeX a partir de un DOI o un identificador de arXiv

Si un artículo lleva DOI, su entrada .bib está a un comando de distancia. El mecanismo se llama negociación de contenido: se le indica a doi.org, mediante una cabecera HTTP, que se quiere BibTeX, y la agencia que registró ese DOI —para artículos académicos casi siempre Crossref— da formato a sus metadatos como entrada BibTeX y la devuelve. No hace falta abrir la página de la editorial: el propio DOI es la interfaz.

# fetch BibTeX for a DOI; -L follows the redirect to the registration agency
curl -LH "Accept: application/x-bibtex" \
  "https://doi.org/10.1145/3186893" >> refs.bib

Sin -L no se obtiene nada. doi.org no es más que un mostrador que averigua qué agencia guarda los metadatos y redirige hacia ella; si no se siguen las redirecciones, la petición muere ahí. Si la línea de comandos incomoda, basta con pegar el DOI en doi2bib.org, que envuelve la misma negociación de contenido en una página web (también acepta identificadores de arXiv y PubMed). Un preprint de arXiv ofrece «Export BibTeX citation» en su página de resumen, y Google Scholar esconde lo mismo tras «Cite → BibTeX» en cada resultado. Sea cual sea la vía, apenas se teclea nada.

Por qué el BibTeX importado casi nunca sirve tal cual

Porque el exportador se limita a volcar las cadenas que hay en su propia base de datos; nada sabe de lo que LaTeX necesita. Descarga el mismo artículo desde la web de la editorial, desde Crossref y desde Google Scholar y obtendrás tres entradas BibTeX distintas. Siempre se rompen las mismas cuatro cosas, y todas ellas solo salen a la luz cuando se compone la bibliografía.

• Las mayúsculas no están protegidas. Si el título no las envuelve en llaves —{DNA}, {Fourier}—, los estilos de la familia plain las pasan a minúscula: «dna», «fourier». La página sobre la base de datos bibliográfica explica el mecanismo.
• Los nombres de revista van abreviados, o no. La misma revista llega una vez como Comput. J. y otra como The Computer Journal, y la lista de referencias acaba contradiciéndose. Las normas de envío casi siempre exigen una u otra forma.
• El tipo de entrada es incorrecto. Las comunicaciones a congresos se exportan a menudo como @article o @misc, y un @inproceedings sin booktitle se compone como un galimatías.
• Se confunde la versión de arXiv con la publicada. El BibTeX de un preprint no suele tener ni journal ni doi, así que se sigue citando el registro antiguo mucho después de que el artículo aparezca en una revista arbitrada.

Revisar y normalizar un .bib: bibcop y biber --tool

En lugar de buscar esos cuatro problemas a ojo, conviene dejárselo a un linter. TeX Live ya incluye bibcop, un linter escrito para archivos .bib: sin instalar nada más, basta con bibcop refs.bib. Lo que devuelve no es una columna de números de línea, sino reproches en frases completas: por ejemplo Do not shorten the words in the journal, such as Comput., All major words in the title must be capitalized, A mandatory doi tag for @article is missing. Que te riñan en un idioma legible no deja dudas sobre qué hay que arreglar.

# lint a database in place
bibcop refs.bib

# reformat and sort every entry; also reports duplicate keys
biber --tool --output-align --output-fieldcase=lower \
  --output-file=clean.bib refs.bib

El reformateo en sí corre a cargo de biber --tool. Además del modo normal que procesa un documento, biber tiene un modo tool que actúa como filtro independiente: entra un .bib, sale un .bib. Recoloca los campos en columnas alineadas, ordena las entradas y, si dos comparten clave, avisa Duplicate entry key: ... skipping y descarta una. Aquí hay una trampa. La salida del modo tool se normaliza por defecto a los nombres de campo de biblatex, de modo que year se convierte en date y journal en journaltitle. Para un documento biblatex es justo lo deseado; pero si pasas por él un .bib destinado a BibTeX puro, los años y los nombres de revista desaparecen de la lista de referencias.

Encontrar entradas duplicadas y claves de cita huérfanas

Cuando la misma clave aparece dos veces, BibTeX dice Repeated entry---line 8 of file refs.bib y descarta la posterior; biber avisa con Duplicate entry key. El caso más molesto es el duplicado con claves distintas pero contenido idéntico, del que nada te avisa. Fusiona las exportaciones de Zotero de dos coautores y el mismo artículo estará ahí dos veces, como smith2020 y como Smith2020a: un accidente que normalmente se descubre al ver la misma línea repetida en la bibliografía compuesta.

Para el cotejo por contenido, la pista más fiable es el DOI. Los nombres de autor y los títulos varían, pero dos entradas con el mismo DOI son el mismo artículo, y punto. Eso es justo lo que implementa bibtex-tidy: se elige el criterio con --duplicates doi (o key, abstract, citation) y --merge funde una en la otra. El problema inverso —citar una clave que el .bib no contiene, con lo que el texto imprime [?]— es cosa de checkcites. --undefined lista las claves que citas pero nunca definiste; --unused, las entradas definidas que nadie cita.

# BibTeX projects read the .aux; biblatex projects read the .bcf
checkcites paper.aux
checkcites --backend biber paper.bcf

# keys cited but missing from the database
checkcites --undefined paper.aux

Qué gestor de referencias elegir: Zotero, JabRef, BibDesk

Hasta unas decenas de entradas se puede editar el .bib a mano; con unos cientos hace falta un gestor. La bifurcación está en si el .bib es el original o una exportación. JabRef y BibDesk abren y guardan el propio .bib, así que conviven sin problema con editar el archivo en un editor de texto. Zotero considera original su propia biblioteca, y el .bib pasa a ser un producto derivado que genera a partir de ella.

• Zotero — la opción gratuita y de código abierto por defecto. Un conector de navegador captura un artículo con un clic, guarda el PDF y admite bibliotecas de grupo compartidas. Quien escriba en LaTeX debe considerar el complemento Better BibTeX prácticamente obligatorio.
• Better BibTeX (complemento de Zotero) — genera claves de cita a partir de un patrón y ofrece auto-export, que lleva cada cambio de la biblioteca directamente al .bib. Ese es todo su sentido: el .bib se convierte en un artefacto siempre actualizado.
• JabRef — un gestor de código abierto que trabaja sobre .bib de forma nativa. No tiene formato interno propio, obtiene entradas desde un DOI, un identificador de arXiv o un ISBN, y ofrece una limpieza masiva de las entradas seleccionadas. Funciona en Windows, macOS y Linux.
• BibDesk (macOS) — un front-end de BibTeX para Mac que viene incluido con MacTeX (/Applications/TeX/BibDesk.app). Edita el .bib directamente y se encarga del archivado automático de PDF y de búsquedas en bases de datos externas.
• Mendeley — el antiguo Mendeley Desktop se retiró el 1 de septiembre de 2022, y con él desapareció la sincronización automática de un .bib. Su sucesor, Mendeley Reference Manager, sigue exportando BibTeX, pero solo como paso manual.
• Paperpile — servicio de pago, muy integrado con Google Docs, que también exporta BibTeX.

El lado de Zotero se movió mucho en 2026. Zotero 8 convirtió la clave de cita en un campo nativo de Zotero, sustituyendo la casilla que antes era de Better BibTeX. Las claves están ahora siempre fijadas (pinned) y se sincronizan entre equipos, así que el viejo ritual de hacer «Pin BibTeX Key» en cada elemento ha desaparecido. Pero Zotero por sí solo no genera claves: construirlas a partir de un patrón y mantener el .bib al día mediante auto-export sigue siendo tarea de Better BibTeX. Conviene saber además que Better BibTeX ha dejado de dar soporte a Zotero 7, así que este montaje implica mantener también Zotero actualizado.

Fijar las claves de cita y compartir un .bib con coautores

Una clave de cita es la interfaz entre el manuscrito y la base bibliográfica, y por eso es lo único que jamás debe moverse. Si la exportación está configurada para volver a derivar las claves cada vez, todos los \cite{...} del cuerpo dejan de resolverse a la vez y el PDF se llena de [?]. La convención concreta importa poco, pero apellido + año + título abreviado —algo como knuth1984literate— choca pocas veces y regala una ventaja: la clave sola ya dice de qué artículo se trata.

Para compartir, lo menos propenso a accidentes es poner el .bib en el mismo repositorio Git que el manuscrito. Es texto plano, así que los diffs se leen y el historial registra quién añadió cada entrada. Dejado a su aire, sin embargo, provocará conflictos continuos, y el remedio es fijar el orden de salida. Que todo el mundo pase biber --tool antes de hacer commit, o que el auto-export de Better BibTeX apunte a una ruta acordada: de cualquiera de las dos formas, en cuanto el orden de las líneas se estabiliza, los conflictos de fusión se desploman. Lo que no hay que hacer es enviarse por correo los .bib locales. Dos semanas después existen cuatro .bib distintos.

# ship only the entries this paper actually cites
pdflatex paper.tex
bibexport -o submission.bib paper.aux

Justo antes del envío el flujo se invierte: ahora hay que recortar un .bib. La mayoría de las revistas pide las fuentes completas del manuscrito, y no puedes adjuntar tu base personal de 800 entradas. bibexport lee el .aux y escribe en un .bib nuevo solo las entradas realmente citadas con \cite, que es exactamente la forma de este problema (bibtool puede analizar el .aux y hacer lo mismo). Por la misma razón, mantener un .bib maestro grande y recortar una porción por manuscrito suele resultar más cómodo en el día a día.

Pasar el mismo .bib a quien no usa LaTeX: CSL y pandoc

Aunque un coautor escriba en Word, no hay por qué abandonar el .bib. CSL (Citation Style Language) es un formato XML que describe el aspecto de las citas y de las listas de referencias, y su propiedad definitoria es ser independiente del motor de composición. Un .bst de BibTeX solo funciona con BibTeX y un estilo biblatex solo dentro de LaTeX; un .csl, en cambio, no está atado a nada. El formateo lo realiza un procesador citeproc, y Zotero, los complementos de Word y diversos conversores leen el mismo .csl cada uno con su propia implementación de citeproc. El repositorio de estilos de Zotero guarda miles de estilos de revistas, de uso libre.

pandoc paper.md --citeproc \
  --bibliography=refs.bib \
  --csl=ieee.csl \
  -o paper.pdf

La herramienta que más se apoya en CSL es pandoc. Convierte un manuscrito en Markdown con --citeproc y las claves de cita del cuerpo, como [@knuth1984], se transforman en citas formateadas, con una lista de referencias añadida al final. --bibliography acepta tu .bib tal cual (y puede repetirse para fusionar varios); si se omite --csl, se recurre a Chicago author-date. En resumen: el mismo .bib alimenta la salida directamente de Markdown a PDF, Word o HTML, sin LaTeX por medio.

Al final, todas las herramientas de esta página descansan en la misma premisa: el activo es el .bib, no la ruta de salida. En cuanto existe una sola base de datos —alimentada desde DOIs, reprendida por bibcop, pulida con biber --tool, con las claves fijadas y guardada en Git—, producir un PDF con biblatex o entregar un Word a un coautor con pandoc no es más que elegir la salida. Mantener una única base rinde mucho más que sumar herramientas.