11–20 of 50 posts
What are the benefits to base58? Base45 uses chars like backslash. This is super annoying when the encoded string is used in an url.
The draft specifically tells you not to do that: "If the data is to be sent via some other transport, a transport encoding suitable for that transport should be used instead of Base45." Base45 is mainly useful for binary information in QR codes.
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 %…
> I can’t help but wonder if any of the other modes could be more efficient still—numeric mode, kanji mode and byte mode. Byte mode is obviously most efficient. Alphanumeric mode uses 5.5 bits per each character, so combined with base45 it uses 5.5 * 3 = 16.5 bits to pack two octets. Base45 is actually not that bad as it seems (3.1% overhead). [EDIT: I've since seen edflsafoiewq's mention that typical QR readers try…
From the introduction:
> Even in Byte mode a typical QR-code reader tries to interpret a byte sequence as an UTF-8 or ISO/IEC 8859-1 encoded text. Thus QR-codes cannot be used to encode arbitrary binary data directly.
Back to your comment:
> Base45 is actually not that bad as it seems (3.1% overhead)
That’s very close to my logarithm calculations from edflsafoiewq’s 40-L figures (the log₂₅₆ 45⁴²⁹⁶ bit of my comment, just added). Would you mind explaining to me what I did wrong with my 45³ ÷ 256² calculation that said 39%?
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?
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 the qrcode medium.
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?
This is not a realistic choice for many projects.
Earlier quoted context omitted.
> I can’t help but wonder if any of the other modes could be more efficient still—numeric mode, kanji mode and byte mode. Byte mode is obviously most efficient. Alphanumeric mode uses 5.5 bits per each character, so combined with base45 it uses 5.5 * 3 = 16.5 bits to pack two octets. Base45 is actually not that bad as it seems (3.1% overhead). [EDIT: I've since seen edflsafoiewq's mention that typical QR readers try…
> Maybe a compatibility issue? From the introduction: > Even in Byte mode a typical QR-code reader tries to interpret a byte sequence as an UTF-8 or ISO/IEC 8859-1 encoded text. Thus QR-codes cannot be used to encode arbitrary binary data directly. Back to your comment: > Base45 is actually not that bad as it seems (3.1% overhead) That’s very close to my logarithm calculations from edflsafoiewq’s 40-L figures (the lo…
Earlier quoted context omitted.
The draft specifically tells you not to do that: "If the data is to be sent via some other transport, a transport encoding suitable for that transport should be used instead of Base45." Base45 is mainly useful for binary information in QR codes.
I wish they would call it something like QR45 then, not Base45.
Earlier quoted context omitted.
> Maybe a compatibility issue? From the introduction: > Even in Byte mode a typical QR-code reader tries to interpret a byte sequence as an UTF-8 or ISO/IEC 8859-1 encoded text. Thus QR-codes cannot be used to encode arbitrary binary data directly. Back to your comment: > Base45 is actually not that bad as it seems (3.1% overhead) That’s very close to my logarithm calculations from edflsafoiewq’s 40-L figures (the lo…
Oops, I've completely missed the last paragraph and thought that you were giving a wildly larger figure with a wrong assumption. Your actual assumption for optimally-efficient base-45 is correct and close enough to the actual QR code spec.
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 %…
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, single-byte subset): log₂ 128 / 8 = 87.500% efficient
Optimal binary (UTF-8, full): 1 = 128 / 2^(8α) + 1920 / 2^(16α) + 63488 / 2^(24α) + 1048576 / 2^(32α) ⇒ α = 89.706% efficient
Optimal kanji (JIS X 0208): log₂ 6879 / 13 = 98.061% efficient
The mistake in your 39% calculation is that you forgot to take logarithms before calculating the ratio.
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 rest of possible implementations.
For the Dutch variant of the green pass using unlinkable signatures [1], we need all the space we can get, so we use a base45 encoding that uses the exact same method as base58 [2][3], and which has the exact same efficiency as QR binary mode.
[1] https://github.com/minvws/nl-covid19-coronacheck-app-coordin...
[2] https://gist.github.com/confiks/8fcb480d87a50cf1bb5e40e2f093...
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 special characters, making it easier to use through different transports.