Un archivo .bib no tiene ni idea de cómo acabará impreso, y esa ignorancia es todo el diseño. Es una base de datos en texto plano —@article{shannon1948, author = {Shannon, Claude E.}, …}— que registra solo qué es una obra, nunca cómo debe verse; por eso un único .bib sobrevive a todos los artículos LaTeX que uno escribe y a todas las revistas a las que los envía. El inconveniente es que una base de datos tiene una gramática, y esta esconde algunas sorpresas: en un archivo .bib, % no abre un comentario, una coma dentro de un nombre significa algo muy concreto y un solo par de llaves es la única defensa cuando un estilo decide reescribir el título. Esta página trata del archivo en sí: tipos de entrada, campos, cómo elegir una clave de cita, la sintaxis de los nombres, los acentos, @string y crossref.
Ese reparto de tareas es la propia decisión de diseño, tomada a mediados de los años ochenta. Al mantener los datos (.bib) separados de la apariencia (un estilo .bst), cambiar de revista cuesta una línea de estilo y los datos quedan intactos. Dicho al revés: en cuanto uno siente la tentación de codificar la presentación dentro del .bib, la partida suele estar ya perdida. Cómo se manejan las herramientas —el orden latex → bibtex → latex → latex, la elección de un .bst— corresponde a la página de BibTeX, y cómo se escribe \cite en el cuerpo, a la página sobre la cita. Aquí la mirada se queda dentro del archivo.
Dentro de una entrada: @tipo{clave, campo = {valor}}
Una entrada se compone de tres partes: un tipo tras el @, una clave de cita justo dentro de la llave y una serie de campos separados por comas. No hay una cuarta cosa que aprender. Aquí va una entrada: el artículo de Shannon de 1948 que fundó la teoría de la información.
@article{shannon1948,
author = {Shannon, Claude E.},
title = {A Mathematical Theory of Communication},
journal = {Bell System Technical Journal},
volume = {27},
number = {3},
pages = {379--423},
year = {1948}
}Los detalles son indulgentes. Los valores pueden ir entre llaves { } o entre comillas dobles " ", y un valor puramente numérico como year = 1948 puede quedar desnudo. La coma tras el último campo es opcional. Los nombres de tipo y de campo no distinguen mayúsculas de minúsculas: @Article y @article, Title y title son lo mismo. En la práctica conviene ceñirse a las llaves: las comillas se rompen en cuanto un valor contiene un ", y las llaves conviven mejor con las macros @string. El doble guion de pages = {379--423} se compone como una raya corta «–». Un solo guion sale tal cual, lo que es incorrecto para un intervalo.
Cómo elegir una clave de cita (y qué caracteres están prohibidos)
La clave de cita es enteramente suya; vale cualquier cosa mientras sea única dentro del .bib. Eso sí, debe coincidir con \cite{shannon1948} en el cuerpo carácter por carácter, mayúsculas incluidas. La convención habitual es apellido + año (shannon1948), con una letra añadida en caso de colisión —shannon1948a, shannon1948b—, y una clave que uno recuerda gana a la larga a cualquier clave generada por una máquina. Los caracteres prohibidos están fijados: llaves, comas, espacios, barras invertidas, #, % y ~ están vetados en todas partes, y biber rechaza además los paréntesis, las comillas y el =. Si se define la misma clave dos veces, BibTeX responde Repeated entry---line 15 of file refs.bib y descarta por completo la entrada posterior. Es el accidente clásico tras importar dos veces el mismo registro desde un gestor bibliográfico, así que conviene memorizar el mensaje.
Qué tipo de entrada: @article, @book, @inproceedings o @misc
El tipo declara qué es la obra, y en cuanto se elige, el estilo decide también qué campos aparecen y en qué orden. BibTeX clásico tiene los catorce tipos estándar de abajo. Cada uno lleva campos obligatorios (aviso si falta alguno) y campos opcionales, y el archivo que guarda ese reparto no es el suyo: es el estilo (.bst).
| Tipo | Para qué sirve | Campos obligatorios clave |
|---|---|---|
@article | Artículo en una revista o publicación periódica | author, title, journal, year |
@book | Libro con una editorial indicada | author o editor, title, publisher, year |
@booklet | Obra encuadernada sin editorial indicada | title (como mínimo) |
@inproceedings | Ponencia en actas de congreso | author, title, booktitle, year |
@conference | Alias de @inproceedings (compatibilidad con Scribe) | (igual que @inproceedings) |
@proceedings | El volumen de actas en sí; padre de crossref | title, year |
@incollection | Capítulo con título en una obra editada | author, title, booktitle, publisher, year |
@inbook | Parte de un libro (capítulo o rango de páginas) | author/editor, title, chapter o pages, publisher, year |
@phdthesis | Tesis doctoral | author, title, school, year |
@mastersthesis | Tesis de máster | author, title, school, year |
@techreport | Informe emitido por una institución | author, title, institution, year |
@manual | Manual técnico o de software | title (como mínimo) |
@unpublished | Manuscrito o borrador no publicado | author, title, note |
@misc | Cualquier cosa que no encaje arriba | ninguno obligatorio (completar con howpublished, note) |
Dos parejas provocan casi todas las dudas. @inbook frente a @incollection: la primera es una parte de un mismo libro (el capítulo 3 del propio, pongamos), la segunda un texto autónomo, de otra autoría, dentro de una obra colectiva. @inproceedings y @conference son funcionalmente idénticos: @conference solo pervive como alias de compatibilidad con Scribe, el sistema de composición del que desciende BibTeX, así que en material nuevo corresponde escribir @inproceedings. Las tesis se reparten por grado entre @phdthesis y @mastersthesis, y lo que no encaja en ningún sitio cae en @misc, apuntalado con howpublished o note.
El biblatex moderno abarca casi todo esto y añade más: @online (alias @electronic) para recursos web, un @report genérico cuyo campo type precisa la clase, un @thesis independiente del grado y @xdata, un contenedor de datos puro que no puede citarse ni imprimirse y que existe solo para ser heredado. @online encaja con registros de arXiv y preprints, junto a los campos eprint descritos más abajo. Estos tipos recientes presuponen biber/biblatex; el bibtex clásico con un .bst puede no entenderlos.
Campos obligatorios y opcionales, y dónde van el DOI y la URL
Un campo es un par name = {value}. Qué campos son obligatorios y cuáles opcionales varía según el tipo, y quien traza esa línea es el estilo. Si falta uno obligatorio, BibTeX avisa; un campo que no reconoce queda ignorado en silencio en la mayoría de los estilos, de modo que los campos sobrantes que llegan con metadatos importados no hacen daño. Estos son los que aparecen en todos los tipos.
author/editor— autor o editor; la sintaxis para varios nombres ocupa la sección siguiente.title— el título: nombre de artículo, título de libro, encabezado de capítulo.journal/booktitle— el nombre de la revista (@article) o el título del libro o las actas que contienen la contribución (@inproceedings,@incollection).year/month/date— BibTeX clásico usayearymonth; biblatex prefiere una forma ISO comodate = {2026-05-01}(también basta undate = {2026}).volume/number/pages— volumen, número y páginas; los intervalos llevan doble guion,pages = {379--423}.publisher/institution/school— editorial / institución emisora (informes) / universidad que otorga el grado (tesis).doi/url/urldate— el DOI (solo el cuerpo10.…, sin el prefijohttps://doi.org/), una URL y la fecha de consulta de biblatex.eprint/eprinttype/eprintclass— los campos de preprint de biblatex. Para arXiv:eprint = {2405.00001},eprinttype = {arxiv}(antesarchivePrefix),eprintclass(antesprimaryClass) para el área.note/howpublished— comentarios libres / «cómo se publicó», el alojamiento habitual de la URL de una entrada@misc.
Aquí está el bache con el que casi todo el mundo tropieza una vez. Los estilos estándar clásicos no saben nada de doi ni de url. La cadena url no aparece ni una sola vez dentro de plain.bst, y un campo cuidadosamente rellenado sencillamente se evapora, sin siquiera una advertencia. Hay tres salidas: cargar \usepackage{url} y meter la dirección en howpublished = {\url{https://…}}; cambiar a un estilo que sí los entienda, como plainnat (natbib) o IEEEtran; o pasarse a biblatex, donde doi, url y urldate son campos de pleno derecho y la salida se apaga con una opción como \usepackage[doi=false]{biblatex}. La buena costumbre es registrar siempre ambos en los datos y dejar que el estilo decida si los imprime.
% classic BibTeX: standard .bst styles drop doi/url, so use howpublished
@misc{tug2024,
author = {{TeX Users Group}},
title = {TeX Live 2024},
howpublished = {\url{https://tug.org/texlive/}},
note = {Accessed 7 August 2026},
year = {2024}
}
% biblatex: doi, url and urldate are proper fields
@online{arxiv2405,
author = {Doe, Jane},
title = {A Preprint with a {DOI}},
date = {2024-05-01},
eprint = {2405.00001},
eprinttype = {arxiv},
doi = {10.1000/example},
url = {https://arxiv.org/abs/2405.00001},
urldate = {2026-08-07}
}Escribir nombres de autor: and, von, Jr y la gramática de cuatro partes
Varios autores se separan con and, nunca con una coma, porque la coma tiene otro cometido. BibTeX lee un nombre como cuatro partes: First, von, Last y Jr, y admite exactamente tres maneras de escribirlo: First von Last, von Last, First y von Last, Jr, First. La coma es justamente la marca que señala dónde termina una parte. Por eso author = {Shannon, Claude E.} significa apellido Shannon, nombre Claude E. El primer orden, el natural, basta casi siempre, pero falla en dos casos: cuando hay una parte Jr y cuando el apellido tiene varias palabras sin parte von. Al escribir Per Brinch Hansen, BibTeX lee «Brinch» como trozo del nombre de pila; al escribir Brinch Hansen, Per no queda margen para el malentendido.
@book{names2026,
author = {de la Vall{\'e}e Poussin, Charles Louis Xavier Joseph
and Brinch Hansen, Per
and Ford, Jr., Henry
and {The TeX Users Group}
and others},
title = {Four Ways to Write One Name},
publisher = {William Reid {and} Company},
year = {2026}
}¿Cómo sabe entonces BibTeX que de la es una parte von? La regla es de una sencillez desarmante: un elemento cuenta como von si su primera letra fuera de llaves es minúscula. En de la Vall{\'e}e Poussin, de y la empiezan en minúscula y forman la parte von, y las dos palabras siguientes, la parte Last. La regla se puede burlar: una macro postiza que empiece por mayúscula, colocada delante, empuja hacia la parte Last incluso un apellido escrito en minúscula. De ahí salen tres consecuencias prácticas. Cuando hay demasiados autores, la lista termina en and others y el estilo lo sustituye por «et al.». Un nombre corporativo debe ir envuelto entero en llaves, {The TeX Users Group}, para que el and que contiene no se lea como separador. En biblatex la misma regla alcanza a las listas literales publisher, institution, organization y location: un and que forma parte de una razón social debe ir entre llaves — publisher = {William Reid {and} Company}.
Acentos y nombres no ASCII: G{\"o}del no es lo mismo que Gödel
Para el bibtex clásico, un carácter acentuado es un «special character»: todo lo que va desde una llave de apertura de nivel superior, seguida de inmediato por una barra invertida, hasta la llave de cierre correspondiente. {\"o} y {\'e} son bloques de ese tipo, y BibTeX cuenta el grupo entero como una sola letra. El efecto salta a la vista en las etiquetas. Con el estilo alpha, G{\"o}del genera la etiqueta G{\"o}d31; el mismo nombre escrito en UTF-8 crudo, Gödel, genera Gö31, porque ö ocupa dos bytes y bibtex 0.99d, que cuenta bytes, ya ha gastado ahí sus tres caracteres. La ordenación sufre igual, y los nombres japoneses, chinos o coreanos salen aún peor parados. De ello se sigue una sola conclusión práctica: si hay nombres no ASCII, conviene usar biber, pensado para UTF-8 y que ordena con una intercalación sensible a la configuración regional. Si es forzoso permanecer en el BibTeX clásico, se escriben los nombres en la forma {\"o} o se pasa a los bibtex8 / bibtexu de ocho bits.
% classic bibtex + alpha.bst -> label [G{\"o}d31]
@article{godel1931a,
author = {G{\"o}del, Kurt},
title = {On Formally Undecidable Propositions},
journal = {Monatshefte},
year = {1931}
}
% same name in raw UTF-8 -> label [Gö31] under bibtex 0.99d; fine under biber
@article{godel1931b,
author = {Gödel, Kurt},
title = {Same Name, Raw UTF-8},
journal = {Monatshefte},
year = {1931}
}Por qué {DNA} necesita llaves, y cuándo no
Los estilos clásicos —plain, abbrv, unsrt, alpha— pasan a minúscula el título de un artículo salvo su primera letra. Así, title = {A Theory of DNA and Galois Theory} se imprime como «A theory of dna and galois theory». Nombres propios y siglas no reciben clemencia. Contra eso hay una sola herramienta: envolver en un segundo par de llaves el fragmento que se quiere conservar. Escrito {DNA}, ese fragmento queda fuera de la conversión. Desconocer este único gesto es la causa número uno de una bibliografía estropeada. Por qué el programa se comporta así corresponde a la página de BibTeX.
Con biblatex y biber la historia cambia. Los estilos estándar —numeric, authoryear y los demás— no tocan en absoluto las mayúsculas de un título: sale exactamente como se escribió. El paso a sentence case solo ocurre si se pide de forma explícita, con algo como \DeclareFieldFormat{titlecase}{\MakeSentenceCase*{#1}}, y aun entonces la opción predeterminada bibtexcaseprotection=true reproduce la regla de llaves de BibTeX, de modo que {DNA} sigue protegido. Si se fija bibtexcaseprotection=false, las llaves dejan de proteger y la intención se expresa con \NoCaseChange{DNA}. La costumbre de encerrar entre llaves, por tanto, sigue funcionando en biblatex; simplemente hace falta mucho menos que antes.
Un detalle merece aquí la pena. Los archivos .bib antiguos suelen encerrar mayúsculas sueltas —title = {An Introduction to {L}a{T}e{X}}—, pero el manual de biblatex lo desaconseja, porque las llaves matan el kerning a ambos lados de la letra encerrada y dejan la palabra ligeramente suelta. Encerrar la palabra entera, {LaTeX}, protege igual sin estropear el espaciado. Segundo detalle: lo protegido es lo que hay dentro de llaves, no lo que hay dentro de una macro. Una macro debe envolverse junto con su texto, como en {\TeX book}; un \TeX desnudo no queda protegido.
% unprotected: plain.bst prints "A theory of dna and galois theory"
% protected: prints "A theory of DNA and Galois theory"
@article{protect2026,
author = {Doe, Jane},
title = {A Theory of {DNA} and {Galois} Theory},
journal = {J. Test},
year = {2026}
}
% brace the whole word, not single letters: {LaTeX}, not {L}a{T}e{X}
% wrap a macro together with its text: {\TeX book}Abreviaturas @string, @preamble y comentarios en un .bib
Cuando el mismo valor se repite una y otra vez, @string permite definir una macro. El nombre definido se coloca en una posición de valor, sin llaves, y se une a otras cadenas con #. Es la manera habitual de alternar entre nombres de revista abreviados y completos; una disposición frecuente es guardar las definiciones @string en un .bib aparte y leerlo primero, como en \bibliography{strings,refs}. De hecho el mecanismo ya está en uso: los estilos estándar predefinen los meses jan a dec como macros @string, y por eso month = jan se escribe sin llaves —month = {jan} no da la macro, sino la cadena literal «jan».
@string{bstj = {Bell System Technical Journal}}
@preamble{ "\newcommand{\noopsort}[1]{} " }
@article{shannon1948,
author = {Shannon, Claude E.},
title = {A Mathematical Theory of Communication},
journal = bstj # { (Supplement)},
month = jan,
year = {1948}
}
@comment{ everything in here is skipped, portably }@preamble es de otra especie: envía su contenido —normalmente definiciones de macros LaTeX— tal cual a la cabecera del .bbl. Se recurre a él cuando una herramienta pequeña, como el truco de ordenación \noopsort, debe viajar con los datos. En cuanto a los comentarios, conviene disipar un malentendido célebre: en un archivo .bib, % no es un carácter de comentario. El bibtex clásico ignora todo lo que queda fuera de una entrada (@…{}), así que una línea que empieza por % pasa como texto ignorado y solo parece un comentario. El peligro está dentro: un % desnudo en el valor de un campo se vierte en el .bbl, donde se convierte en un auténtico carácter de comentario de LaTeX que devora el resto de la línea. Dentro de un valor hay que escribir siempre \%.
La forma portable es @comment{ … }: su contenido se omite por completo y resulta segura también con biber. Y eso importa, porque biber es más estricto que el bibtex clásico: el texto suelto fuera de una entrada se gana la advertencia warning: 30 characters of junk seen at toplevel. Y si lo único que se busca es desactivar una entrada por un tiempo, el camino más corto es borrar un carácter: @article{…} pasa a article{…} y deja de ser una entrada para volverse texto ignorado.
Escribir las actas una sola vez: el campo crossref
El campo crossref hace que una entrada herede de otra los campos que le faltan. Al citar cinco artículos del mismo volumen no hace falta teclear cinco veces el nombre del congreso, los editores y el año. Una entrada @proceedings hace de padre, cada @inproceedings hijo lleva crossref = {gg1988}, y booktitle, editor y year bajan desde arriba. La duplicación desaparece, y con ella la molestia de cinco grafías ligeramente distintas del mismo nombre de congreso.
@inproceedings{gneisser1988,
crossref = {gg1988},
author = {Gneisser, Rocky},
title = {No Gnats Are Taken for Granite},
pages = {133--139}
}
% the parent must appear LATER in the file than every entry citing it
@proceedings{gg1988,
editor = {Ford, Gerald and Carter, Jimmy},
title = {The Gnats and Gnus 1988 Proceedings},
booktitle = {The Gnats and Gnus 1988 Proceedings},
year = {1988}
}A esto se atan tres reglas. Primera, el padre debe figurar más adelante en el archivo que cualquier entrada que lo referencie, de ahí la costumbre de reunir los padres crossref al final. Segunda, aunque nunca se haga \cite del padre, este aparece por sí solo en la lista de referencias en cuanto dos o más hijos lo señalan; con un único hijo se queda fuera, y sus campos se imprimen en cambio dentro de ese hijo. El umbral se ajusta con bibtex --min-crossrefs=N. Tercera, el crossref anidado no es fiable, así que conviene no darle un padre a un padre. biblatex ofrece un mecanismo aparte, xdata, que hereda datos sin establecer relación de padre e hijo: la elección natural para un conjunto como editorial más lugar, que no es en sí una obra.
Quién decide el orden de la lista de referencias
Usted no, y eso es una buena noticia. El orden en que aparecen las entradas no guarda relación con el orden en que se teclearon; lo decide la herramienta. En BibTeX clásico el orden lo fija el estilo (.bst). El margen es casi nulo: elegir el estilo es elegir el orden. plain y alpha ordenan alfabéticamente por autor, unsrt sigue el orden de primera cita en el texto, y estilos de ingeniería como ieeetr hacen lo mismo. Sin tocar los datos, basta cambiar \bibliographystyle{plain} por \bibliographystyle{unsrt} para que toda la lista se reorganice. La ordenación de referencias japonesas corre a cargo de pbibtex / upbibtex (véase la página de BibTeX).
biblatex devuelve esa decisión a quien escribe. Con independencia del estilo, \usepackage[sorting=nyt]{biblatex} fija el orden. Las claves de ordenación se escriben como combinaciones de letras: n de name, y de year, t de title.
| Opción | Orden de claves | Significado |
|---|---|---|
nty | name → title → year | nombre, luego título, luego año (predeterminado de biblatex) |
nyt | name → year → title | nombre, año, título (preferido para autor-año) |
ynt | year → name → title | año, luego nombre, luego título (cronológico) |
ydnt | year (descendente) → name → title | años más recientes primero |
none | (sin ordenar) | orden de cita (equivalente a unsrt) |
En resumen: para conservar el orden de cita, el estilo unsrt en BibTeX o sorting=none en biblatex. Para orden alfabético, plain en BibTeX o el nty predeterminado en biblatex (nyt para autor-año). En cualquier caso, nunca hace falta reordenar a mano las entradas del .bib. Ese es trabajo de la herramienta; el suyo consiste solo en registrar los datos con exactitud: elegir el tipo correcto, escribir los nombres según la gramática de cuatro partes y encerrar entre llaves las mayúsculas que deben sobrevivir. Un .bib que cumpla esos tres puntos sobrevivirá con creces al artículo que se está escribiendo ahora.