Consecutive Escape Characters Not Parsed Properly

[MLuebbers]

I'm aware of issue #7 regarding \\E\\, and I think I'm able to give a little more context as to what this sequence is after doing some investigation into a a similar issue.

HL7 data coming out of Epic is escaped differently in order to avoid conflicts with the reserved chars in the MSH segment. These always have a trailing \. Confusingly \E\ is used to escape \'s in the original data coming out of the EHR. If the characters are escaped again in your system, you get \\E\\. This seems to now be parsed correctly as of version 3.4. I have noticed another sequence with \\E\\ in the middle of our Hl7 messages that isn't getting parsed correctly: \\E\\X09\\E\\.

In our system there's a field with an escaped tab character represented as \x09\. Coming out of the EHR it gets escaped again as \E\x09\E\ then again in our application as \\E\\x09\\E\\. I tried various permutations of these to try and identify if there was specific character to mixed results.
\\E\\ on its own works, and \\E\\\\E\\ and \\E\\x09 work as well but \\x09\\E\\ does not.

[jaime-olivares]

Hi @MLuebbers , I am looking at this now.
I will need concrete messages to test (positive, negative, expected results)