Ecoji-d v1.0.0 is released - Base1024 using emojis 😂👌

bauss jj_1337 at live.dk
Fri Mar 16 08:25:30 UTC 2018


On Thursday, 15 March 2018 at 18:45:51 UTC, Anton Fediushin wrote:
> On Thursday, 15 March 2018 at 09:32:50 UTC, bauss wrote:
>> Fun, but seems pretty useless in practice.
>
> I disagree. Ecoji (base1024) has bigger character set meaning 
> that it can encode more information per emoji than base64 can 
> encode per character.
>
> For example ecoji encoded "abcde" looks like this: "👖📸🎦🌭"
> And base64 encoded one looks like this: "YWJjZGU=".
>
> Even though each emoji is 4 bytes long, there is a noticable 
> difference in size when we are talking about larger chunks of 
> data:
>
> ---
> $ dd if=/dev/urandom bs=4K count=16K of=test.raw
> 16384+0 records in
> 16384+0 records out
> 67108864 bytes (67 MB, 64 MiB) copied, 1.90423 s, 35.2 MB/s
> $ dd if=test.raw | ./ecoji-d |  wc -c
> 67108864 bytes (67 MB, 64 MiB) copied, 6.7699 s, 9.9 MB/s
> 71591534 # Size increased just by 6%
> $ dd if=test.raw | base64 |  wc -c
> 67108864 bytes (67 MB, 64 MiB) copied, 0.750174 s, 89.5 MB/s
> 90655837 # 35%(!) increase in size
> ---
>
> And if we move to real word scenarios, where web pages are 
> gzip'ped most of the time:
>
> ---
> $ dd if=test.raw | gzip -c | wc -c
> 67108864 bytes (67 MB, 64 MiB) copied, 5.49022 s, 12.2 MB/s
> 67119122 # Raw files are terrible for compression
> $ dd if=test.raw | ./ecoji-d | gzip -c | wc -c
> 67108864 bytes (67 MB, 64 MiB) copied, 27.9972 s, 2.4 MB/s
> 32178275 # 48% improvement
> $ dd if=test.raw | base64 | gzip -c | wc -c
> 67108864 bytes (67 MB, 64 MiB) copied, 10.3381 s, 6.5 MB/s
> 68892893 # Pretty bad, yeah
> ---
>
> So yeah, ecoji is better than base64 in everything but speed. 
> Speed will be improved. Later.

If your care about size of data then you're not going to encode 
anyway.
Same goes for speed.

Besides your encoding isn't going to work with actual web-pages 
anyway, because your encoder doesn't have browser support.

Sure you can encode your data and gzip it, but once it reaches 
the browser and it unzips it, then what? The browser doesn't know 
what to do with the data. You can't even use base64 for http 
headers.

At most it could be used for email clients, since they do support 
"Content-Transfer-Encoding" but browsers don't. They only support 
"Content-Encoding" which at most can be compressions such as gzip.


More information about the Digitalmars-d-announce mailing list