You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: