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

Retire mahonia for code.google.com/p/go.text/encoding #3

Open
GoogleCodeExporter opened this issue Mar 16, 2015 · 1 comment
Open

Comments

@GoogleCodeExporter
Copy link

Mahonia maintainers have decided to discontinue support, and suggest
go.text/encoding to achieve the same ends.

https://code.google.com/p/mahonia/code.google.com/go.text/encoding/

Below, a more current incarnation of the library: https://godoc.org/golang.org/x/text

An example of a cutover:

oov/the_platinum_searcher@c5c5960

A brief look at go.text/encoding indicates it's a very different approach. This
is a nice-to-have, but not yet critical unless a manhonia bug appears that
effects go-dbf.

@LindsayBradford
Copy link
Owner

Biggest difference to work out between the libraries is that Mahonia automatically bridges the charset mappings to their matching encoders/decoders. It's then a piece of cake to ask for a new encoder/decoder, based only on the charset name string.

In the example cutover link above, the authors had to build their own decoder/charset name bridging.

Either this is something offered by the golang.org/x/text library (but I'm missing), or I'd need to backfill this charset/encoding bridge within the go-dbf library. The backfilling option is unappealing given my lack of knowledge on a) which chartsets need supporting, and b) which encoder/decoders then match the charset names I need to support.

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

No branches or pull requests

2 participants