Enclosing middleware fails for certain content

[claell]

Describe the bug
https://bibtexparser.readthedocs.io/en/main/customize.html#default-parse-stack says that there is Enclosing middleware used, likely to make sure no illegal characters exist in fields.

Reproducing

Version: 2.0.0b2

Note the abstract of the following excerpt (The 396$\{2}$ chip is):

Bibtex:

@Article{Konstadinidis2009,
  author = {Konstadinidis, Georgios K. and Tremblay, Marc and Chaudhry, Shailender and Rashid, Mamun and Lai, Peter F. and Otaguro, Yukio and Orginos, Yannis and Parampalli, Sudhendra and Steigerwald, Mark and Gundala, Shriram and Pyapali, Rambabu and Rarick, Leonard D. and Elkin, Ilyas and Ge, Yuefei and Parulkar, Ishwar},
  title = {Architecture and physical implementation of a third generation 65 nm, 16 Core, 32 thread chip-multithreading SPARC processor},
  date = {2009-01-01},
  doi = {10.1109/JSSC.2008.2007144},
  abstract = {This third-generation Chip-Multithreading (CMT) SPARC processor consists of 16 cores with shared memory architecture and supports a total of 32 main threads plus 32 scout threads. It is targeted for high-performance servers, and is optimized for both single- and multi-threaded applications. The 396$\{2}$ chip is fabricated in an 11 metal layer 65-nm CMOS process and operates at a nominal frequency of 2.3 GHz, consuming a maximum power of 250 W at 1.2 V. This paper provides an overview of the architectural highlights and describes the physical implementation challenges and solutions including circuit innovations in memory arrays, register files, and floating-point hardware that boost the performance and circuit robustness with low area overhead. © 2006 IEEE.},
  author_keywords = {Arrays; Chip multi-threading (CMT); Clocking; Computer architecture; Execute ahead; Hardware scout; Microprocessor; Multi-core; Multi-threaded; Power management; Register files; SerDes; SPARC architecture; Transactional memory}
}

Workaround
Manually looking for the problematic character

Remaining Questions (Optional)
Please tick all that apply:

• I would be willing to contribute a PR to fix this issue.
• This issue is a blocker, I'd be grateful for an early fix.

[claell]

This gives me an error when parsing the file (written from bibtexparser):

WARNING:root:Parsing of `@article` block (line 1026) aborted on line 1038  due to syntactical error in bibtex:
 Expected a `=` after entry key, but found `,`.
WARNING:root:Unknown block type <class 'bibtexparser.model.ParsingFailedBlock'>

So, not sure whether the problem is with writing or reading.

[MiWeiss]

There seems to be some confusion about the meaning of the EnclosingMiddleware, which has the purpose of removing the {} or " which are potentially wrapping field values.

E.g. {Konstadinidis, Georgios K. and Tremblay, Marc} becomes Konstadinidis, Georgios K. and Tremblay, Marc

You may want to try the follow wrappers around a well-known latex en-/decoding library which allows many if not most usecases:

• bibtexparser.middlewares.LatexEncodingMiddleware
• bibtexparser.middlewares.LatexDecodingMiddleware

[claell]

Ah, alright. I didn't find documentation on this, so I misinterpreted the purpose of that Middleware.

So, regarding my issue: I think there is some check for the sanity of field values? Right now, I can write fields with said value, but when I read a file with that value, I get a parsing error.

I think, this should not happen. And right now, I need to use a manual workaround for the specific problematic (invalid) field value content.

[claell]

I revisited this with a stricter regression: current main can return a normal entry while silently dropping every field after the escaped-brace sequence. Draft PR #572 contains the focused splitter fix and a parse/write/reparse assertion for the later fields.