base64 encoding and CRs
Locked
 
|
As best I can see base64 encoding never results in the output having Character cr embedded, right?
Why would I ask such a dumb question? Because I'm looking at some code that carefully does a copyReplaceAll: on a base64 encoded String that was a bitmap, and I can't imagine how that could ever not corrupt the bitmap *if* there were any chance it did indeed include CRs. And it's late on a Friday and to be honest, anything could be possible in 2020. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- His spirit guide is a three-toed sloth. |
|
Hi Tim, our encoder might not be producing cr's, but base64 payloads in the wild often have lines no longer than 80 characters, so before decoding it makes sense to remove that. On Fri, Aug 21, 2020 at 6:00 PM tim Rowledge <[hidden email]> wrote: As best I can see base64 encoding never results in the output having Character cr embedded, right? |
|
|
In reply to this post by timrowledge
Tim, Correct, base64 encoding only emits a subset of printable characters (see https://en.wikipedia.org/wiki/Base64#Base64_table) At your option, you can also insert CR's into a base64 string which should be ignored on decoding. (as was common for various email clients to do back in the day) Phil On Fri, Aug 21, 2020 at 9:00 PM tim Rowledge <[hidden email]> wrote: As best I can see base64 encoding never results in the output having Character cr embedded, right? |
|
|
> On 2020-08-21, at 6:30 PM, Phil B <[hidden email]> wrote: > > Tim, > > Correct, base64 encoding only emits a subset of printable characters (see https://en.wikipedia.org/wiki/Base64#Base64_table) At your option, you can also insert CR's into a base64 string which should be ignored on decoding. (as was common for various email clients to do back in the day) > > Phil > On 2020-08-21, at 6:29 PM, Vanessa Freudenberg <[hidden email]> wrote: > > Hi Tim, > > our encoder might not be producing cr's, but base64 payloads in the wild often have lines no longer than 80 characters, so before decoding it makes sense to remove that. > > Vanessa Hunh. Fascinating. So maybe there is a tiny bit of sense to the code I was peering tiredly at. Though given it was creating the base64 string right there, probably not in this case. I do love how the software word is so full of kludge upon jury-rig upon WAG! Thanks for the enlightenment. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: UDF: Use Disk for Frisbee |
|
|
Hi
> On 22.08.2020, at 06:35, tim Rowledge <[hidden email]> wrote: > > > >> On 2020-08-21, at 6:30 PM, Phil B <[hidden email]> wrote: >> >> Tim, >> >> Correct, base64 encoding only emits a subset of printable characters (see https://en.wikipedia.org/wiki/Base64#Base64_table) At your option, you can also insert CR's into a base64 string which should be ignored on decoding. (as was common for various email clients to do back in the day) >> >> Phil > > >> On 2020-08-21, at 6:29 PM, Vanessa Freudenberg <[hidden email]> wrote: >> >> Hi Tim, >> >> our encoder might not be producing cr's, but base64 payloads in the wild often have lines no longer than 80 characters, so before decoding it makes sense to remove that. >> >> Vanessa > > Hunh. Fascinating. So maybe there is a tiny bit of sense to the code I was peering tiredly at. Though given it was creating the base64 string right there, probably not in this case. I do love how the software word is so full of kludge upon jury-rig upon WAG! > > Thanks for the enlightenment. Look at the raw email I'm just replying to: =-=-=-= From: tim Rowledge <[hidden email]> Message-Id: <[hidden email]> Subject: Re: [squeak-dev] base64 encoding and CRs Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cgo+IE9uIDIwMjAtMDgtMjEsIGF0IDY6MzAgUE0sIFBoaWwgQiA8cGJwdWJsaXN0QGdtYWlsLmNv bT4gd3JvdGU6Cj4gCj4gVGltLAo+IAo+IENvcnJlY3QsIGJhc2U2NCBlbmNvZGluZyBvbmx5IGVt aXRzIGEgc3Vic2V0IG9mIHByaW50YWJsZSBjaGFyYWN0ZXJzIChzZWUgaHR0cHM6Ly9lbi53aWtp cGVkaWEub3JnL3dpa2kvQmFzZTY0I0Jhc2U2NF90YWJsZSkgIEF0IHlvdXIgb3B0aW9uLCB5b3Ug Y2FuIGFsc28gaW5zZXJ0IENSJ3MgaW50byBhIGJhc2U2NCBzdHJpbmcgd2hpY2ggc2hvdWxkIGJl IGlnbm9yZWQgb24gZGVjb2RpbmcuIChhcyB3YXMgY29tbW9uIGZvciB2YXJpb3VzIGVtYWlsIGNs aWVudHMgdG8gZG8gYmFjayBpbiB0aGUgZGF5KQo+IAo+IFBoaWwKCgo+IE9uIDIwMjAtMDgtMjEs IGF0IDY6MjkgUE0sIFZhbmVzc2EgRnJldWRlbmJlcmcgPHZhbmVzc2FAY29kZWZyYXUubmV0PiB3 cm90ZToKPiAKPiBIaSBUaW0sCj4gCj4gb3VyIGVuY29kZXIgbWlnaHQgbm90IGJlIHByb2R1Y2lu ZyBjcidzLCBidXQgYmFzZTY0IHBheWxvYWRzIGluIHRoZSB3aWxkIG9mdGVuIGhhdmUgbGluZXMg bm8gbG9uZ2VyIHRoYW4gODAgY2hhcmFjdGVycywgc28gYmVmb3JlIGRlY29kaW5nIGl0IG1ha2Vz IHNlbnNlIHRvIHJlbW92ZSB0aGF0LiAKPiAKPiBWYW5lc3NhCgpIdW5oLiBGYXNjaW5hdGluZy4g U28gbWF5YmUgdGhlcmUgaXMgYSB0aW55IGJpdCBvZiBzZW5zZSB0byB0aGUgY29kZSBJIHdhcyBw ZWVyaW5nIHRpcmVkbHkgYXQuIFRob3VnaCBnaXZlbiBpdCB3YXMgY3JlYXRpbmcgdGhlIGJhc2U2 NCBzdHJpbmcgcmlnaHQgdGhlcmUsIHByb2JhYmx5IG5vdCBpbiB0aGlzIGNhc2UuIEkgZG8gbG92 ZSBob3cgdGhlIHNvZnR3YXJlIHdvcmQgaXMgc28gZnVsbCBvZiBrbHVkZ2UgdXBvbiBqdXJ5LXJp ZyB1cG9uIFdBRyEKClRoYW5rcyBmb3IgdGhlIGVubGlnaHRlbm1lbnQuIAoKdGltCi0tCnRpbSBS b3dsZWRnZTsgdGltQHJvd2xlZGdlLm9yZzsgaHR0cDovL3d3dy5yb3dsZWRnZS5vcmcvdGltClN0 cmFuZ2UgT3BDb2RlczogVURGOiBVc2UgRGlzayBmb3IgRnJpc2JlZQoKCgo= =-=-=-=-= Wrapping Base64 is _extremely_ common. Virtually half the SSL Certificates are delivered that way… Pgp keys, signatures, SSH keys, … you name it :) Best regards -Tobias |
|
|
> On 22.08.2020, at 09:50, Tobias Pape <[hidden email]> wrote: > > Hi > >> On 22.08.2020, at 06:35, tim Rowledge <[hidden email]> wrote: >> >> >> >>> On 2020-08-21, at 6:30 PM, Phil B <[hidden email]> wrote: >>> >>> Tim, >>> >>> Correct, base64 encoding only emits a subset of printable characters (see https://en.wikipedia.org/wiki/Base64#Base64_table) At your option, you can also insert CR's into a base64 string which should be ignored on decoding. (as was common for various email clients to do back in the day) >>> >>> Phil >> >> >>> On 2020-08-21, at 6:29 PM, Vanessa Freudenberg <[hidden email]> wrote: >>> >>> Hi Tim, >>> >>> our encoder might not be producing cr's, but base64 payloads in the wild often have lines no longer than 80 characters, so before decoding it makes sense to remove that. >>> >>> Vanessa >> >> Hunh. Fascinating. So maybe there is a tiny bit of sense to the code I was peering tiredly at. Though given it was creating the base64 string right there, probably not in this case. I do love how the software word is so full of kludge upon jury-rig upon WAG! >> >> Thanks for the enlightenment. > > Look at the raw email I'm just replying to: > > =-=-=-= > > From: tim Rowledge <[hidden email]> > Message-Id: <[hidden email]> > Subject: Re: [squeak-dev] base64 encoding and CRs > Content-Type: text/plain; charset="utf-8" > Content-Transfer-Encoding: base64 > > Cgo+IE9uIDIwMjAtMDgtMjEsIGF0IDY6MzAgUE0sIFBoaWwgQiA8cGJwdWJsaXN0QGdtYWlsLmNv > bT4gd3JvdGU6Cj4gCj4gVGltLAo+IAo+IENvcnJlY3QsIGJhc2U2NCBlbmNvZGluZyBvbmx5IGVt > aXRzIGEgc3Vic2V0IG9mIHByaW50YWJsZSBjaGFyYWN0ZXJzIChzZWUgaHR0cHM6Ly9lbi53aWtp > cGVkaWEub3JnL3dpa2kvQmFzZTY0I0Jhc2U2NF90YWJsZSkgIEF0IHlvdXIgb3B0aW9uLCB5b3Ug > Y2FuIGFsc28gaW5zZXJ0IENSJ3MgaW50byBhIGJhc2U2NCBzdHJpbmcgd2hpY2ggc2hvdWxkIGJl > IGlnbm9yZWQgb24gZGVjb2RpbmcuIChhcyB3YXMgY29tbW9uIGZvciB2YXJpb3VzIGVtYWlsIGNs > aWVudHMgdG8gZG8gYmFjayBpbiB0aGUgZGF5KQo+IAo+IFBoaWwKCgo+IE9uIDIwMjAtMDgtMjEs > IGF0IDY6MjkgUE0sIFZhbmVzc2EgRnJldWRlbmJlcmcgPHZhbmVzc2FAY29kZWZyYXUubmV0PiB3 > cm90ZToKPiAKPiBIaSBUaW0sCj4gCj4gb3VyIGVuY29kZXIgbWlnaHQgbm90IGJlIHByb2R1Y2lu > ZyBjcidzLCBidXQgYmFzZTY0IHBheWxvYWRzIGluIHRoZSB3aWxkIG9mdGVuIGhhdmUgbGluZXMg > bm8gbG9uZ2VyIHRoYW4gODAgY2hhcmFjdGVycywgc28gYmVmb3JlIGRlY29kaW5nIGl0IG1ha2Vz > IHNlbnNlIHRvIHJlbW92ZSB0aGF0LiAKPiAKPiBWYW5lc3NhCgpIdW5oLiBGYXNjaW5hdGluZy4g > U28gbWF5YmUgdGhlcmUgaXMgYSB0aW55IGJpdCBvZiBzZW5zZSB0byB0aGUgY29kZSBJIHdhcyBw > ZWVyaW5nIHRpcmVkbHkgYXQuIFRob3VnaCBnaXZlbiBpdCB3YXMgY3JlYXRpbmcgdGhlIGJhc2U2 > NCBzdHJpbmcgcmlnaHQgdGhlcmUsIHByb2JhYmx5IG5vdCBpbiB0aGlzIGNhc2UuIEkgZG8gbG92 > ZSBob3cgdGhlIHNvZnR3YXJlIHdvcmQgaXMgc28gZnVsbCBvZiBrbHVkZ2UgdXBvbiBqdXJ5LXJp > ZyB1cG9uIFdBRyEKClRoYW5rcyBmb3IgdGhlIGVubGlnaHRlbm1lbnQuIAoKdGltCi0tCnRpbSBS > b3dsZWRnZTsgdGltQHJvd2xlZGdlLm9yZzsgaHR0cDovL3d3dy5yb3dsZWRnZS5vcmcvdGltClN0 > cmFuZ2UgT3BDb2RlczogVURGOiBVc2UgRGlzayBmb3IgRnJpc2JlZQoKCgo= > > =-=-=-=-= > > Wrapping Base64 is _extremely_ common. > Virtually half the SSL Certificates are delivered that way… Pgp keys, signatures, SSH keys, … you name it :) > Best regards -Tobias |
|
|
In reply to this post by timrowledge
On Fri, Aug 21, 2020 at 09:35:42PM -0700, tim Rowledge wrote:
> > > > On 2020-08-21, at 6:30 PM, Phil B <[hidden email]> wrote: > > > > Tim, > > > > Correct, base64 encoding only emits a subset of printable characters (see https://en.wikipedia.org/wiki/Base64#Base64_table) At your option, you can also insert CR's into a base64 string which should be ignored on decoding. (as was common for various email clients to do back in the day) > > > > Phil > > > > On 2020-08-21, at 6:29 PM, Vanessa Freudenberg <[hidden email]> wrote: > > > > Hi Tim, > > > > our encoder might not be producing cr's, but base64 payloads in the wild often have lines no longer than 80 characters, so before decoding it makes sense to remove that. > > > > Vanessa > > Hunh. Fascinating. So maybe there is a tiny bit of sense to the code I was peering tiredly at. Though given it was creating the base64 string right there, probably not in this case. I do love how the software word is so full of kludge upon jury-rig upon WAG! > > Thanks for the enlightenment. > Tim, I fear that you have been spending too much time immersing yourself the gratuitous improvements of modern technology. Surely you still remember how to connect your computer with a proper rotary dial phone and acoustic coupler. Once connected, you would use uuencode/uudecode (like base64) to send binary stuff to the uucp network in a shar archive. Naturally you would want to add line terminators in your encoded data, othewise people might not be able to view it in their vi text editor or text mail client. :-) Dave -- |
|
|
> On 2020-08-22, at 7:40 AM, David T. Lewis <[hidden email]> wrote: > > I fear that you have been spending too much time immersing yourself the > gratuitous improvements of modern technology. Surely you still remember > how to connect your computer with a proper rotary dial phone and acoustic > coupler. Once connected, you would use uuencode/uudecode (like base64) > to send binary stuff to the uucp network in a shar archive. I missed that level of 'pleasure' by a couple of years but my first experiences with trying to sned data from one computer to another involved 'cables' made by soldering dress-maker's pins to wires in orderto be able to probe the DB15/25 connectors and work out which ones were the appropriate ones. Such fun! > > Naturally you would want to add line terminators in your encoded data, > othewise people might not be able to view it in their vi text editor or > text mail client. Oh yea, *those* people. It's ok though, there will be at least 42 emacs modes and add-ons to handle it for you, just so long as you have the proper emacs extended edition 432 key keyboard. With the full dozen meta keys. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim "Bother" said Pooh, as he realised Piglet was undercooked. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |