Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open to changes to preserving whitespace and sanitizing strings? #34

Open
harrisonhjones opened this issue May 14, 2024 · 0 comments
Open

Comments

@harrisonhjones
Copy link

Hey,

I'd like to contribute two changes upstream but, before I do, I wanted to get your thoughts on if you think you'd accept the changes.

Change #1 - Preserve Whitespace

I'd like to update https://github.com/basgys/goxml2json/blob/master/decoder.go#L136 to not trim white space. I was thinking, to preserve backwards-compatibility I do the following:

  1. Update trimNonGraphic to be a function receiver of *Decoder
  2. Update Decoder to have a doNotTrimWhitespace property
  3. Add a SetDoNotTrimWhitespace *Decoder` function receiver

Change #2 - Customize encoding string sanitization

According to the accepted answer of https://stackoverflow.com/questions/3020094/how-should-i-escape-strings-in-json the only characters we must escape is \, ", and control codes (U+0020 and below). The library currently also escapes <, >, and &. I have an application that needs & to remain unescaped. I was hoping we could allow for users to customize which characters are escaped while retaining backwards-compatibility with the following changes to https://github.com/basgys/goxml2json/blob/master/encoder.go:

  1. Update Encoder with a new charactersToEscape property. If not set, default to <>&
  2. Update https://github.com/basgys/goxml2json/blob/master/encoder.go#L122 to remove <, >, and & specifically and instead check if the b character is contained within the encoder's charactersToEscape. Would also require updating sanitiseString to be a function receiver of *Encoder.

Thoughts? With the changes everything would remain the same (by default) but still allow for folks to customize things as needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant