Prevent escaping in xer and jer output#158
Open
f-ohler wants to merge 2 commits intoeerimoq:masterfrom
Open
Conversation
Codecov Report
@@ Coverage Diff @@
## master #158 +/- ##
=======================================
Coverage 35.18% 35.18%
=======================================
Files 7 7
Lines 8567 8567
=======================================
Hits 3014 3014
Misses 5553 5553 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Currently the JER and XER encoder escapes non-ascii characters.
ISO/IEC 8825-4:2015 clause 8.1.3 and ISO/IEC 8825-8:2015 clause 7.6.2 demand that both outputs should use UTF-8.
Escaping seems to be allowed for XER, but is forbidden in CXER.
Escaping seems to be allowed for JER.
So, this is probably not a bug.
In my eyes, using the escaping mechanism makes no sense here and leads to less readable output (readability for a human is one of the key features of these encodings).
This PR prevents this escaping mechanism.
If for any reason the current behaviour is beneficial, I suggest adding a further parameter (similar to indent) to control the escaping behaviour.