Entries with hash symbos ('#') are processed incorrectly

[sauliusg]

JabRef version 5.3, master commit 049acb9 on Linuxmint-20.1

JabRef 100.0.0
Linux 5.8.0-45-generic amd64
Java 14.0.2
JavaFX 16+8

• [x ] Mandatory: I have tested the latest development version from http://builds.jabref.org/master/ and the problem persists

When a new entry is created that contains two hash symbols ('#') and a comma between them, such entry when saved produces incorrect bibtex file that can not be parsed again.

Steps to reproduce the behavior:

1. Start a new JabRef process (my JabRef is configured not to open old libraries, so the window is empty);
2. Create a new database and a new entry in it;
3. In the "Abstract" tab of the new entry, type the following text: This is an article about C# programs. It has a comma between the two hashes, and mentions C# for the second time.;
4. Save the new library as 'new.bib' (a variant of this file is provided in the attached .zip);
5. Close the JabRef;
6. Open JabRef, passing the saved file name on the command line, e.g. ./gradlew run --args ~/src/jabref/bugs/entries-with-hashes-are-processed-incorrectly/new.bib. The file triggers a syntax error message:
   
7. Alternatively, start JabRef without a command line argument and open the saved 'new.bib' library using 'File|Open...' dialog. No error message is produced, but the entry is silently skipped:
   
8. The comma between two hashes influences the behaviour; if we delete the comma (see 'new-without-comma.bib' in the submitted 'biblio.zip' file), the error is not triggered but the entry is parsed incorrectly:
   
9. In a somewhat different setting, when reading old entries (produced by older JabRef versions, or by external software) that contain hashes, a similar parsing bug is triggered if the entry is modified before saving. Sometimes the modification happens silently, e.g. when the old entry contains 'timestamp' fields (see 'Wilkinson2006.bib' in the attached 'biblio.zip', which, when read in and just saved as 'Wilkinson2006-saved.bib', can not be read back correctly and triggers parsing error when specified on the command line).

An unexpected corruption of the database when automatically changing time stamps is yet another argument against automatically converting them to 'creationdate' fields, in addition to problems mentioned in the issue #7527.

Below are short BibTeX files used for testing:

biblio.zip

The issue might be related to #7010.

Log File

Paste an excerpt of your log file here

[Siedlerchr]

This is a duplicate of #7010. JabRef tries to interpret # as bibtex macro

[sauliusg]

This is a duplicate of #7010. JabRef tries to interpret # as bibtex macro

The #7010 reports that a markdown disappears from comments, which is not nice but you can still live with it. In the #7553 I reported corruption of the database, which is IMHO much more serious.

Of course if fixing #7010 will also fix #7553, all the better :)