There have been a few questions already regarding biblatex and the handling of special characters in fields like abstract (e.g. not needed for the output), cf. Error with percent sign in bib entry field when using biblatex/biber.

A common answer is to use the sourcemap mechanism of biblatex and to remove such fields.

However, when trying this even on a very simple example, biber removes the field (cf. output of biber --debug),

[314] bibtex.pm:727> DEBUG - Source mapping (type=user, key=test):
Deleting field 'abstract'

but still complains about the contents of such a field.

My question is, whether there is any way to solve such problems or is the modification by \DeclareSourceMap just too late? Is there any other solution (within biblatex)?

   author = {Mustermann, Max},
   title = {Example},
   abstract = {A maybe longer text with a = b or
               c = d and other special characters.}

  • The percent char is special for tex, it is problematic when it ends in the bbl. But here the warning is from the equal sign which is special for biber (it separates key = content). biber does a bit of syntax checking and as the equal sign is on a new line biber warns you that you perhaps have a missing brace. You can avoid the warning by putting braces around the sign: {=}. Mar 2, 2017 at 13:10
  • It's the ='s fault. Since that is a special character for Biber, it warns you about this, since a stray = and could mean that your entry is somehow messed up, because you forgot braces. Apparently that warning about a possible malformed file comes before sourcemapping. (Which makes sense, you would want to know about a malformed .bib file as soon as possible.)
    – moewe
    Mar 2, 2017 at 13:16
  • Thank you. I know, that it is the equal sign's fault. However, I had some hope, that I can use \DeclareSourceMap in this case as well (BTW: Same with \}. I guess I have to do some sed here. The data come from an automatic workflow. Thus manual editing is not an option.
    – Martin
    Mar 2, 2017 at 14:25
  • BTW: I do not mind warning. However, I had real world examples, where biber stopped working. I will check, whether this can be solved with \DeclareSourceMap at least.
    – Martin
    Mar 2, 2017 at 14:28
  • It seems as though the equal sign is recognised as problematic before the fields are actually read and naturally sourcemapping can only happen after the fields have been read. This in a way makes sense, because the = here could be a symptom of a malfomed .bib file, and indeed sometimes the contents of a field (especially the contents of the abstract field when downloaded from another source) has the potential to really mess up parsing if the content is crappy. A really bad input can already cause errors at the parsing phase, from which you can't recover without changing the file.
    – moewe
    Mar 2, 2017 at 14:34

1 Answer 1


Currently there is no way to get around this warning. It already occurs in the 'input' phase, where Biber just collects the data for each field. At this point the only thing Biber needs to do is to save the field name and its contents.

Since field names and their contents are normally separated by a = with the field contents being either bare or wrapped in quotation marks or curly braces topped up with a comma, a = in a new line looks suspicious for Biber, and you get a warning that you might have forgotten something.

Maybe Biber is a bit overzealous here warning you that you might have created a runaway string. Note that the = in a = b is fine, the one from c = d is the evil one in your example.

After the input phase sourcemapping is applied. After all, Biber can only start manipulating the fields, once it has read them and knows their contents.

Only after that advanced parsing such as name and date handling happens.

The upshot of this is that due to the nature of the warning itself you cannot avoid it without changing your .bib file before Biber gets to read it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .