Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Base45 Data Encoding

datatracker.ietf.org

Post reply on HN
Print view View original

31–40 of 50 posts

Re: The Base45 Data Encoding

#31

Post by dolmen »

atoav wrote: post #14
codeflo wrote: post #9

So instead of extending QR codes, which are inherently binary, to efficiently handle binary payloads, we invent yet another ASCII-based tunneling scheme. Why ever fix any problem when we can just pile workaround upon workaround upon workaround?

Becaus sometimes you need your solution to be used be the public, voluntarily. If they have to install an extra app to read your "looks-like-QR-code-but-not-quite" thing, then you have at least an increased risk of not getting the adoption you want to get. This is not a realistic choice for many projects.

Do you mean that humans will have to decode Base45?

If not, there is a software layer anyway. Adding another skin to the onion is not the best way to compress data.

Re: The Base45 Data Encoding

#32

Post by zaxomi »

eventreduce1 wrote: post #3

What are the benefits to base58? Base45 uses chars like backslash. This is super annoying when the encoded string is used in an url.

slash = /

backslash = \

They are using slash.

And space, which is confusing. Did not see the space in the "Hello!!" example since the space is the last character on the line.

Re: The Base45 Data Encoding

#33

Post by masklinn »

dolmen wrote: post #29
masklinn wrote: post #13

Earlier quoted context omitted.

Qrcode already has a binary mode. The problem is that qrcode software treats qrcode data as text and fucks up. You’re not going to get every software out there fixed. This does not extent qrcode at all, instead it defines a binary-to-text encoding designed to fit in qrcode’s existing alphanumeric mode, exactly like base32, base64 or base85 (or base36, base62, binhex, quopri) but fitting the specific constraints of th…

> You’re not going to get every software out there fixed. You don't need every QR code software to be fixed anyway. Only the one which will use those QR codes which don't yet exist. These softwares will have to understand Base45 anyway. If you wrote that QRcode is not extensible (I don't know if that's the case) I would have agreed.

> You don't need every QR code software to be fixed anyway. Only the one which will use those QR codes which don't yet exist.

No, the existing software misbehaves (and possibly crashes) when scanning pure binary data. If it did nothing problematic then the use of binary data would not matter, only the sofware which “will have to understand base45 anyway” would need to be binary-clean.

And here qrcode software does not need to understand base45: the user can copy the base45 textual data to whichever other program cares for it.

> If you wrote that QRcode is not extensible (I don't know if that's the case) I would have agreed.

Why would I write that when it has nothing to do with the issue?

And qrcode can be extended: the encoding mode is specified by a nibble, only 9 values are currently in use.

Re: The Base45 Data Encoding

#34

Post by mjevans »

Confiks wrote: post #19

Note that this encoding isn't of the same efficiency as QR binary mode, as it converts 3 bytes into 2 base45 characters. So it's more like 'base41 using the base45' charset. I'm still a bit sad that with this standard and the packages available now, the namespace of 'base45' is clobbered with this suboptimal implementation. It can best just be renamed to 'base41'. It's a good tradeoff for the DCC, but not for the res…

32 bits raw 33 bits (3 pairs of 11 bits) QR alphanum.

In blocks of 4 bytes this encodes as 6 'base45' (QR alphanum) characters, and uses the same lookup table.

https://en.wikipedia.org/wiki/QR_code#Encoding

The "Alphanumeric character codes" table, at least at a visual glance, is identical to the RFC's lookup table.

Re: The Base45 Data Encoding

#35

Post by rkangel »

masklinn wrote: post #13
codeflo wrote: post #9

So instead of extending QR codes, which are inherently binary, to efficiently handle binary payloads, we invent yet another ASCII-based tunneling scheme. Why ever fix any problem when we can just pile workaround upon workaround upon workaround?

Qrcode already has a binary mode. The problem is that qrcode software treats qrcode data as text and fucks up. You’re not going to get every software out there fixed. This does not extent qrcode at all, instead it defines a binary-to-text encoding designed to fit in qrcode’s existing alphanumeric mode, exactly like base32, base64 or base85 (or base36, base62, binhex, quopri) but fitting the specific constraints of th…

Realistically, if you test with the camera apps from Apple, Google and Samsung I suspect you have 90% of the public's usage covered and everyone else will be forced to follow.

Re: The Base45 Data Encoding

#36

Post by lifthrasiir »

mjevans wrote: post #34
Confiks wrote: post #19

Note that this encoding isn't of the same efficiency as QR binary mode, as it converts 3 bytes into 2 base45 characters. So it's more like 'base41 using the base45' charset. I'm still a bit sad that with this standard and the packages available now, the namespace of 'base45' is clobbered with this suboptimal implementation. It can best just be renamed to 'base41'. It's a good tradeoff for the DCC, but not for the res…

32 bits raw 33 bits (3 pairs of 11 bits) QR alphanum. In blocks of 4 bytes this encodes as 6 'base45' (QR alphanum) characters, and uses the same lookup table. https://en.wikipedia.org/wiki/QR_code#Encoding The "Alphanumeric character codes" table, at least at a visual glance, is identical to the RFC's lookup table.

The GP is saying that the equal efficiency is possible with using only 41 out of 45 characters, so reducing the symbol set would make base45 (now base41) more useful as a general encoding, not just an encoding for QR codes.

Re: The Base45 Data Encoding

#37

Post by kristov »

dolmen wrote: post #27
EdSchouten wrote: post #20

The idea of this encoding is to store two bytes of data in three characters. To me it's not obvious why you need a base as high as 45 for that. Assuming you either want to store two bytes, or a trailing one, you have 256*256 + 256 combinations: 65792. Using three base45 characters, you can get up to 45^3=91125 combinations. It looks like base41 would have been sufficient. That way you can get rid of some of those spe…

+1 This would allow to avoid space, %, / and + to be more URL friendly, and so allow more usages.

Having these chars is a pain (particularly space). Manipulating lists of these in files with standard Unix tools will mean having to escape, quote, etc.

Re: The Base45 Data Encoding

#38

Post by cellularmitosis »

dolmen wrote: post #31
atoav wrote: post #14

Earlier quoted context omitted.

Becaus sometimes you need your solution to be used be the public, voluntarily. If they have to install an extra app to read your "looks-like-QR-code-but-not-quite" thing, then you have at least an increased risk of not getting the adoption you want to get. This is not a realistic choice for many projects.

Do you mean that humans will have to decode Base45? If not, there is a software layer anyway. Adding another skin to the onion is not the best way to compress data.

The issue is that there are two layers of software: the SDK, and the software which you write which uses the SDK.

If the crash is happening in the SDK (on binary QR codes), then your only option is to ditch binary QR and implement a workaround.

Re: The Base45 Data Encoding

#39

Post by chrismorgan »

anderskaseorg wrote: post #18
chrismorgan wrote: post #6

So, it’s using a 45-character alphabet which matches the QR code alphanumeric values table, which lets the QR code encoder switch to a more efficient mode that takes less space. I just tried rendering a QR code of the 692 characters of the introductory paragraph (with lines joined appropriately), and compared it with a QR code of the same text, uppercased and with out-of-range characters `,`, `[` and `]` changed to %…

The right way to measure the area ratio is using entropy. An optimal encoding would save at most 3% area over Base45: Base64 in binary: log₂ 64 / 8 = 75.000% efficient Base45 in alphanumeric: 4 log₂ 256 / 33 = 96.970% efficient Optimal numeric: 3 log₂ 10 / 10 = 99.657% efficient Optimal alphanumeric: 2 log₂ 45 / 11 = 99.851% efficient Optimal binary (ISO 8859-1): log₂ 191 / 8 = 94.718% efficient Optimal binary (UTF-8…

Ah hah, yes, the 39% was linear but needed to be log. Thanks for that, and all the other figures too.

Re: The Base45 Data Encoding

#40

Post by mr_mitm »

kristov wrote: post #37
dolmen wrote: post #27

Earlier quoted context omitted.

+1 This would allow to avoid space, %, / and + to be more URL friendly, and so allow more usages.

Having these chars is a pain (particularly space). Manipulating lists of these in files with standard Unix tools will mean having to escape, quote, etc.

I don't understand why they didn't use lower case letters instead of special characters. Does anyone here know?
Post reply on HN