Parsing/Writing of Entry fields containing an @ broken

[matthiasgeiger]

JabRef version 3.6dev

Steps to reproduce:

1. Use the character "@" in a field of an entry
2. Save the file; Entry looks like this:

@Article{asda,
  author = {böser Tit@l},
  title  = {change...},
}

1. Change the entry
2. Save again - file is broken:

@Article{asda,
  author = {böser Tit

@Article{asda,
  author = {böser Tit@l},
  title  = {change...},
}

I don't have any clue why this is happening. But this is clearly a blocker for a 3.6 release. @lenhard You want to waste some of your valuable vacation time? 😉

[matthiasgeiger]

Caused by https://github.com/JabRef/jabref/pull/1638/files#diff-db4bf84f8c8b14426629f6fbb0ac1665R637 ...

Let's see whether I can quickly fix this without breaking the "@comment" functionality introduced in #1638

[ajbelle]

Original reported USER robustness feature request.
Ver2.9.2 managed to read the file that had been corrupted by Ver3.6dev, but could not open if Ver3.6dev saved it/exported it again! The development version could open the file it created, but not any second saved or exported versions! Doesn't make sense to me, but again a pre V3 seems more robust. Robustness is more important than speed for me.

Is it possible to read .bib a file in a way that, if a single entry corrupts, JabRef detects the start of the next entry so that only the affected part is lost (not the whole file)? Exporting corrupt entries to "corrupt bib entries.txt" would allow easier checking and resurrecting the entries as required by non-experts.

Sometimes I do direct PFE edits on my bib file. This is a great strength of JabRef/.bib files and so far so good, but entry corruption is easy.

The current error message for this issue identified the last line in the file, and I only identified it by luck the last listed entry in Jabref corresponded to the fault in the file! By adding a 'new entry' identifier to the read in parser the error location could also be more closely specified. I imagine searching for @'something' and where the 'something' was all entry types used in the .bib file. If this adds too much time if put inline could it be a 'try read corrupt file' option?