[boost] base64?

[Greger via Boost]

Hi

Is anyone interested in a base64 encode/decode library (for boost)?

ty

Greger


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Richard Hodges via Boost]

Yes. I'm shocked if it doesn't already have one.

Post by Greger via Boost
Hi
Is anyone interested in a base64 encode/decode library (for boost)?
ty
Greger
_______________________________________________
http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vinnie Falco via Boost]

On Mon, Jul 24, 2017 at 8:09 AM, Richard Hodges via Boost

Post by Richard Hodges via Boost
Yes. I'm shocked if it doesn't already have one.

What are the expectations from a library claiming the moniker
"Boost.Base64?" Does it support just radix=64? Or is it a general
purpose library that works with any radix and a user-supplied
alphabet? If the latter is it limited to using integral types or does
it work with multiprecision integers? Does it use std::string? Fixed
size buffers? Does it work with Allocators? Which base-64 alphabets
does it support? MIME? UTF-7? RFC3548? RFC4648? Does it support
url-encoding and decoding i.e. ("modified Base64 for URL")?

Please be specific in the type of base64 library you are proposing.

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Greger via Boost]

Here is some documentation:

http://www.multi.fi/~ghaga/base64docs/html/index.html

br
Greg

Post by Vinnie Falco via Boost
On Mon, Jul 24, 2017 at 8:09 AM, Richard Hodges via Boost

Post by Richard Hodges via Boost
Yes. I'm shocked if it doesn't already have one.

What are the expectations from a library claiming the moniker
"Boost.Base64?" Does it support just radix=64? Or is it a general
purpose library that works with any radix and a user-supplied
alphabet? If the latter is it limited to using integral types or does
it work with multiprecision integers? Does it use std::string? Fixed
size buffers? Does it work with Allocators? Which base-64 alphabets
does it support? MIME? UTF-7? RFC3548? RFC4648? Does it support
url-encoding and decoding i.e. ("modified Base64 for URL")?
Please be specific in the type of base64 library you are proposing.
Thanks
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vinnie Falco via Boost]

Post by Greger via Boost
http://www.multi.fi/~ghaga/base64docs/html/index.html

Thank you. From the docs, I see these signatures:

std::string base64_encode (const char *buf, int len);
std::string base64_decode (const char *buf, int len);

1. How are errors communicated?
2. How does the caller specify the Allocator to use?
3. Are there routines to operate on fixed-size buffers (no allocation)?

Post by Greger via Boost
It is available for a moderate compensation. Let me know by
email and I will send you the source.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vinnie Falco via Boost]

Post by Greger via Boost
It is available for a moderate compensation. Let me know by
email and I will send you the source.

Is this library open source or commercial in nature? What license is
it furnished under? Also, how is this better than the numerous other
base64 libraries (which are free) such as this one:

<http://renenyffenegger.ch/notes/development/Base64/Encoding-and-decoding-base-64-with-cpp>

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Roger Leigh via Boost]

Post by Vinnie Falco via Boost

Post by Greger via Boost
It is available for a moderate compensation. Let me know by
email and I will send you the source.

Is this library open source or commercial in nature? What license is
it furnished under? Also, how is this better than the numerous other
<http://renenyffenegger.ch/notes/development/Base64/Encoding-and-decoding-base-64-with-cpp>

Or https://github.com/ome/ome-common-cpp/blob/master/lib/ome/common/base64.h

which I probably wrote based on a similar source when I realised the
Boost base64 support was broken and needed a quick implementation. It
avoids allocation issues by allowing the use of iterators including
back_inserter.

We already have base64 conversion in
boost/archive/iterators/*base64*.hpp. It works but screws up the
whitespace
(https://stackoverflow.com/questions/10521581/base64-encode-using-boost-throw-exception/10973348#10973348).
It's a shame the various adapters don't work properly together; is
there any prospect of this being fixed, or is the existing design simply
too inflexible to make a proper base64 implementation?


Regards,
Roger

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vinnie Falco via Boost]

On Mon, Jul 24, 2017 at 9:54 AM, Roger Leigh via Boost

We already have base64 conversion in boost/archive/iterators/*base64*.hpp.
It works but screws up the whitespace
(https://stackoverflow.com/questions/10521581/base64-encode-using-boost-throw-exception/10973348#10973348).
It's a shame the various adapters don't work properly together; is there any
prospect of this being fixed, or is the existing design simply too
inflexible to make a proper base64 implementation?

I think a good base64 implementation would be an excellent subject for
GSoC or someone who wants to participate in Boost we would just have
to clearly define the things we want from it:

* Caller provided buffers
* Allocator awareness
* Flexible types of input
* Choice of alphabet
* Choice of radix?
* Option for line-widths / newlines
* Iterator based interface
* Variations such as rfc3548, rfc, 4648, modified Base64 for URL

Could be called Boost.Radix

I know such a library would be immensely useful to a higher-level
library which tries to address some of those "out-of-scope" items in
Beast. Base-64 and other radix encodings come up often in HTTP field
values and uri targets, as well as in the body of certain message
types.

If anyone is interested I wouldn't mind getting together on Google
Hangouts with a https://kobra.io/#/ shared document and hammering out
a prototype set of declarations, which someone else could implement.

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Robert Ramey via Boost]

Post by Roger Leigh via Boost

Post by Vinnie Falco via Boost

On Mon, Jul 24, 2017 at 8:24 AM, Greger via Boost

Post by Greger via Boost
It is available for a moderate compensation. Let me know by
email and I will send you the source.

Is this library open source or commercial in nature? What license is
it furnished under? Also, how is this better than the numerous other
<http://renenyffenegger.ch/notes/development/Base64/Encoding-and-decoding-base-64-with-cpp>

Or
https://github.com/ome/ome-common-cpp/blob/master/lib/ome/common/base64.h
which I probably wrote based on a similar source when I realised the
Boost base64 support was broken and needed a quick implementation. It
avoids allocation issues by allowing the use of iterators including
back_inserter.
We already have base64 conversion in
boost/archive/iterators/*base64*.hpp. It works but screws up the
whitespace
(https://stackoverflow.com/questions/10521581/base64-encode-using-boost-throw-exception/10973348#10973348).
It's a shame the various adapters don't work properly together; is
there any prospect of this being fixed, or is the existing design simply
too inflexible to make a proper base64 implementation?

I'm guessing it would be pretty easy to fix. I base this on the design
which is built up as a stack of iterator pairs. This is documented in
the serialization library under

http://www.boost.org/doc/libs/1_64_0/libs/serialization/doc/dataflow.html

This is used for the base64 stuff in the serialization library which as
far as I know is correct. That doesn't include adding on padding at the
end - which maybe it should.

In any case making a stand along base64 component would require
understanding the issues, making a small variation on the one in the
library, make a test and adding it the test suite and making a
commitment to support it in the future. I just haven't had the
motivation to do that - even though I think the code and design are very
convenient and flexible. Result is decent performance as well. FYI it
was made before boost ranges and can be considered a demonstration of
the validity of using the range idea.

Robert Ramey

Post by Roger Leigh via Boost
Regards,
Roger
_______________________________________________
http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Andrey Semashev via Boost]

Post by Greger via Boost
http://www.multi.fi/~ghaga/base64docs/html/index.html

The interface documented there does not account for the possibility that
the original data may not be a string (of characters). My requirements
to a Base64 libraries would be:

- The library should be able to work with any binary data.
- It should be able to produce encoded/decoded data in a user-supplied
storage.
- I would like to be able to supply custom character conversion rules
and possibly disable trailing padding so that different variants of
Base64 (e.g. [1]) can be implemented.
- The library should be fast.

[1]: https://tools.ietf.org/html/rfc4648#section-5

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost