Thank you Steve, I'll look into it later. I make gifts for children, woman, myself .... I need 6 hands, three legs and 4 heads ... Just a quick look and try - the expected output for 1 byte input, which is also 7 bits or less, is 7 bits, not 2 bytes. Specifically, try to enter "!" [00100001] is 6 bits long, but your function returns 2 bytes. That doesn't seem to be okay.
for 7 bit encoding, 7 bytes of input (8 * 7) = 56 bits are used,
which are written as 8 seven-bit numbers. If the input has a shorter input, the missing bits are filled with zeroes to the left.
It’s just a case of making certain all data is preserved. The most you’d ever save is a single byte, so it doesnt seem like it’s worth the hit to performance to strip off those leading 0’s.
Space is CHR(32), which is &B00100000.... As long as it’s a singular character, we
could strip off those leading 0’s and write it as 100000, but if we’re dealing with 2 spaces in a row, we’d have to preserve at least one of them.
00100000,
00100000 would translate to: 00,100000
0,0100000... Again, only 1 real byte we can save, from those leading 2 bits in the left byte.
00100000,00100000,00100000 would translate to: 001,0000000,1000000,0100000... At 3 bytes of spaces, we no longer save that single byte of leftover 0’s, as we have a significant 1 in the last byte.
The most we’d ever have is a single byte of padding, and I’m not that concerned over saving that singular byte. It doesn’t bother me to keep it in there, to keep the conversion process simple and efficient.
A simple string check can remove that leading extra byte, if it’s really bothersome. If len(converted_text$) MOD 8 <> 0 AND CHR$(RIGHT$(converted_text$)) = 45 THEN ‘strip off that extra character, which is padding of unused 0’s.
If the input has a shorter input, the missing bits are filled with zeroes to the left.
Either add padding at decode time, or leave padding at encode time — both are perfectly valid means of converting. I’m just doing the second, rather than the first. ;)