It's not for avoiding looks-similar-to-a-human chars like Base58. It's for QR codes. The alphabet is exactly the alphabet for Alphanumeric mode QR codes.

A 40-L code allows 4296 characters in Alphanumeric-mode = 2864 bytes after Base45 decoding.

The same code allows 2953 characters in Byte mode. If you use Byte mode to hold Base64, that's 2214 bytes after decoding, so Base45 is more efficient.

The reason it gives for why you can't use Byte mode to directly hold binary data is

> 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.

It also says you're not supposed to use it anywhere but QR codes (like URLs)

> If the data is to be sent via some other transport [not stored in a QR-code], a transport encoding suitable for that transport should be used instead of Base45. It is not recommended to first encode data in Base45 and then encode the resulting string in for example Base64 if the data is to be sent via email. Instead the Base45 encoding should be removed, and the data itself should be encoded in Base64.

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.

It’s a B2T encoding, not a qrcode mode (the mode is 2).

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.

Trailing spaces too?