I would like to be able to keep newlines when/after decoding.
It's hard having to separate a number of decoded lines when they have all been appended to the starting line. Sometimes this can be (partially) done by replacing the NUL characters, sometimes there is no clue at all where to insert the line break.
Would it be much work to add this functionality?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It would also be nice if the Base64 Plug-In warned when trying to decode incorrect characters instead of always decoding it into one and the same set of bits.
It's possible to "decode" anything, now, but of course this does not always give valid results.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
While it should read at least:
7318[NUL][NUL]139UUU
Encoding the last string gives the coded string above, again.
Encoding the decoded string results in:
NzMxOAAAMTM5VQ==
This is clearly not correct.
It looks very much like the two last U characters have been removed "because of" the two [NUL] characters that the code on the first line ends with (==).
When there are no = signs preceding the string to be decoded, it will be decoded correctly. Also, this happens only for the last two characters of the decoded string. Any previous occurrence will be handled correctly. Perhaps this has something to do with the number of bytes reserved for the decoded string, not taking into account the (last) [NUL] characters.
I think at least one of both processing "failures" should be handled:
either
- decode each separate coded string separately, that is on a line-by-line basis or separated by = character occurrences,
or
- fix the [NUL][NUL] bug, so at least the total string to be decoded will be decoded correctly
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like to be able to keep newlines when/after decoding.
It's hard having to separate a number of decoded lines when they have all been appended to the starting line. Sometimes this can be (partially) done by replacing the NUL characters, sometimes there is no clue at all where to insert the line break.
Would it be much work to add this functionality?
It would also be nice if the Base64 Plug-In warned when trying to decode incorrect characters instead of always decoding it into one and the same set of bits.
It's possible to "decode" anything, now, but of course this does not always give valid results.
I'm having a decode error with this "feature".
Decode this:
NzMxOA==
MTM5VVVV
It reads:
7318[NUL][NUL]139U
While it should read at least:
7318[NUL][NUL]139UUU
Encoding the last string gives the coded string above, again.
Encoding the decoded string results in:
NzMxOAAAMTM5VQ==
This is clearly not correct.
It looks very much like the two last U characters have been removed "because of" the two [NUL] characters that the code on the first line ends with (==).
When there are no = signs preceding the string to be decoded, it will be decoded correctly. Also, this happens only for the last two characters of the decoded string. Any previous occurrence will be handled correctly. Perhaps this has something to do with the number of bytes reserved for the decoded string, not taking into account the (last) [NUL] characters.
I think at least one of both processing "failures" should be handled:
either
- decode each separate coded string separately, that is on a line-by-line basis or separated by = character occurrences,
or
- fix the [NUL][NUL] bug, so at least the total string to be decoded will be decoded correctly