You wouldn’t get an eof if the data is properly encoded. Not sure what the
problem is.
You need to be doing something with the Reader - most likely writing to a file,
streaming to a database record, etc.
I would simplify the code to a single test case that demonstrates the issue you
are having
I'm just doing the reverse of that, I think, by removing the padding.
I can't seem to trigger an EOF with this code below:
> >n, err = b.br.Read(h)
> >if err != nil {
> >return n, err
> >}
On 13/01/25, robert engels (reng...@ix.netcom.com) wrote:
> As has bee
As has been pointing out, you don’t need to read the whole thing into memory,
just wrap the data provider with one that adds the padding it doesn’t exist -
and always read with the padded decoder.
To add the padding you only need to keep track of the count of characters read
before eof to deter
I'm also curious why Plan 9 doesn't include a tzdata or zoneinfo
database
file for programs to use for time zone logic/math, like most OSs, if
anyone
happens to know.
If I understand the question correctly, I think it does in the
[/adm/timezone] directory. Those files are in a format described
AS I wrote earlier, I'm trying to avoid reading the entire email part into
memory to discover if I should use base64.StdEncoding or base64.RawStdEncoding.
The following seems to work reasonably well:
type B64Translator struct {
br *bufio.Reader
}
func NewB64Translator(r io.R
Hello gophers,
We plan to issue Go 1.23.5, Go 1.22.11, and Go 1.24 RC2 during US business
hours on Thursday, January 16.
These releases include PRIVATE security fixes to the standard library,
covering the following CVEs:
-
CVE-2024-45336
-
CVE-2024-45341
The Go 1.24 RC2 release
Thanks very much for the playground link and thoughts.
The use case is reading base64 email parts, which could be of a very large
size. It is unclear when processing these parts if they are base64 padded or
not.
I'm trying to avoid reading the entire email part into memory. Consequently I
thin
> I'm looking to develop an alternative to an existing piece of code that
reads email parts into byte slices and then returns these after decoding
Aside: are you actually seeing invalid (unpadded) base64-encoded MIME parts
in the wild?
Since a padded base64-encoded block will always be a multip
Just realized: If you twist the idea around, you get something easy to
implement and more correct.
Instead of stripping padding if it exist, you can ensure that the body *is*
padded to a multiple of 4 bytes: https://go.dev/play/p/SsPRXV9ZfoS
You can then feed that to base64.StdEncoding. If the wrap
Hi,
one way to solve your problem is to wrap the body into an io.Reader that
strips off everything after the first `=` it finds. That can then be fed to
base64.RawStdEncoding. This approach requires no extra buffering or copying
and is easy to implement: https://go.dev/play/p/CwcVz7oietI
The down
10 matches
Mail list logo
