Handling Escape characters

[stevengopmo]

I'm evaluating your library for performance and wow it's good. One issue I've encountered however is handling of escape characters. For instance \T\ should evaluate to &. I was thinking this should happen in the converter but I don't see how yet. Can you point me in the right direction? Or if you don't handle this, could you offer a suggestion on the best way to do so?

Here's a link to some of the accepted escapes https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=EHL72_escape_sequences It doesn't appear as if there are too many.

[SaxxonPike]

I'll take this one.

[SaxxonPike]

I spent some time looking into this one today - looks like EncodingOperations.Unescape is not implemented yet, so while escape codes are being used when converting text to be HL7 compatible, they are not being decoded when coming from an HL7 message. I think this is simply a case of a missing feature. I'll prioritize this one (I've been wanting to do it for a while now anyway!)

[SaxxonPike]

There's support for what you're looking for now in the PR, although it's kind of awkward to use for the time being. You will need to access it via Builder.Encoding.Escape() or Parser.Encoding.Escape() whenever you want to create HL7 compatible values, and Builder.Encoding.UnEscape() or Parser.Encoding.UnEscape() whenever you want to extract a string from the HL7 compatible value.

In the next major version of this library, this functionality will be incorporated directly into Value and a new property called RawValue will provide access to the raw value (how it works at this time.)

If you're keen on building this one yourself, pull from the escape-ampersand branch (which is named after this issue) and try that one. I'm going to get some peer review before I merge this one.

[stevengopmo]

Thank you. On my side I did a quick string extension to resolve the issues that I was having so I'm good for the moment. I'll keep an eye out for 2.0 though!