Odin Vex

My post was quickly made to align any references regarding trying to add a 'bytes-column' to the [JADX](https://github.com/skylot/jadx/issues/1114) project.

> offset in the dex file I'm not really that interested in offsets but rather the actual raw bytes involved in the actual decompiled instruction.

> @OdinVex File byte data + offset to instruction in that file = raw bytes of the instruction That's obvious. I was just hoping for an easier "bytes: opcode" output...

> No, currently there are no plans to support CT/SCT in the near future. (To be honest: I'm not very familiar with this topic, yet) > > However, pull requests...

I've determined that the base64 characters assumed by Clean Links is incomplete. While [RFC4648](https://www.rfc-editor.org/rfc/rfc4648.txt) states base 64 encoding is `A-Za-z0-9+/=`, it also notes in `(Section 5) Base 64 Encoding with...

On a separate note, the pre-existing base 64 encoding method is not base 64, it is base 32 because it does not also use `a-z`. See chapters 4, 5, 6,...

All in all, for base64, you should use `/\b(?:aHR0|d3d3)[A-Za-z0-9+=/]+/u` for base 64 encoding, `/\b(?:aHR0|d3d3)[A-Za-z0-9\-=_]+/u` for base 64 url encoding, and then decide if you'd like to also support base 32...

> We’re matching base64 currently, otherwise the encoding for http and www wouldn’t start with `aHR0` and `d3d3`. You might be confused by the fact that the regex is case...

> We match strings starting with `aHR0` and `d3d3`, which correspond to base64-encoded prefixes `www` and `http`. Base-32 prefixes are `O53XO` and `NB2HI4`, which we don’t match. Case insensitivity just...

Curious...does Clean Links get a final path to work with such as any links that were HTTP becoming http or not?