Handling Escape characters about nextlevelseven

[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!