# What is the difference between a biblatex literal and string?

Some biblatex fields are of type 'literal' and some are of type 'string'. What is the difference between the two types?

Given that 'string' is used for the ID, it would make sense if a string must not have spaces. Is that right? Are there any other restrictions?

Relatedly, are there any restrictions other than no spaces on IDs when using biblatex and/or biber?

• Ad 1: Actually, 'fields' are: literal, range, integer, ... (see section 2.2 in general). Fields are distinguished from 'name' and 'literal' lists. These are all used in the basic data model of biblatex for the entry fields. I believe 'string' is used in a generic 'computer science' sense, and means only something like 'a sequence of characters' (like a constant or a variable); it can have spaces. Thus, fields are strings in this sense. Ad 2: yes and no. Ad 3 & 4: Although an entrykey is a string, it cannot have spaces; generally try to stick to plain ASCII, & generally avoid special charcters.
– jon
May 7, 2015 at 21:22
• @jon Thanks. I was confused by the manual saying things like 'entrykey field (string)'.
– twsh
May 7, 2015 at 21:33
• For example, avoid especially `@`, `#`, `\$`, `%`, `&`, `{`, `}`, `"`, `\ `, `,` -- and probably a whole host of other special characters. (I hope the reason is obvious.) Also, it is probably better to use an entry key like `godel1931` over `gödel1931` -- in BibTeX, it might be necessary to do so.
– jon
May 7, 2015 at 21:37
• Yeah, I don't think "string" is ever explained, but fields and lists are.
– jon
May 7, 2015 at 21:38
• What all those "string" fields seem to have in common is that they are produced by the back-end and (in most cases) not intended to be printed in a document. You don't even have control over the majority of those string fields. When it comes to output that is printed, the documentation uses "literal". (Which makes me think that Biber will probably choke on TeX commands being used in "string" fields, but will happily accept them in "literal" fields. See also here.) May 17, 2015 at 16:16

A `literal` field can normally hold text as you would write it in your `.tex` document. `%`s are dangerous, but most of everything else should go through without a problem. The documentation is indeed quite tight-lipped about what a 'string' field is. Of the dozen or so fields marked as 'string' in the `biblatex` documentation only a few are relevant for input in `.bib` files and even these are special in one way or another. Normally you would not want to print the contents of any of these fields.
• `presort`: Since it is used for sorting by the backend it should ideally not contain any fancy stuff like macros and command sequences (they are accepted, but simply treated as a string).
• `entrykey` (and by extension `ids` as well as `clonesourcekey`, though `ids` is slightly less restrictive when it comes to round brackets): The possible value for `entrykey` is on the one hand restricted by the backend and on the other hand by the TeX engine in use. The backend imposes restrictions so that a `.bib` entry with the respective `entrykey` may be properly parsed.
• Biber forbids `" # % ' ( ) , = { }` (see Using BibTeX keys containing parentheses with Biber, also interesting What characters are allowed to use as delimiters for BibTeX keys?). A space is also forbidden.
• The TeX/LaTeX side also forbids certain characters so that the entry may be processed on the TeX side. `biblatex` sometimes needs to build control sequence names from the `entrykey` (with `\csname`...`\endcsname`), so they can't contain unexpandable control sequences. An `entrykey` should not contain active characters. For pdfLaTeX that means non-ASCII chars such as `ä`, `ö`, `ß`, `é` are out, XeLaTeX and LuaLaTeX are fine with non-ASCII chars, though.
• `entrytype`: Naturally the standard entry types restrict themselves to `a-z` only. With Biber you could define new types, the restrictions should be similar to those for `entrykey`.
All other strings are produced by the backend itself and either contain one value of a pre-defined list (`dateunspecified`) or some sort of hash (`hash`, `namehash`, `fullhash`, `sortinithash`). You can expect the hashes to return alphanumerical values.
A few fields marked as 'literal' are probably more akin to 'string': `labeltitlesource`, `labelnamesource` and `extradatescope` just return the name of a field. `labeldatesource` is very similar, but may also contain a literal expression (so I would not classify `labeldatesource` as string).