Hacker News new | past | comments | ask | show | jobs | submit login

It's a shame nobody is really using yEnc instead of base64. yEnc only has a overhead cost of about 2%, compared to 33% for base64, and would be perfect for use on webpages.



yEnc has a fair share of problems related to reliable encoding and decoding for some character sets (UTF-8 for example). Normally this is solved with the MIME types, but yEnc is not officially registered. Nor does it have an official RFC standard. base64 on the other hand "just works".


yEnc is very much designed specifically for Usenet though. It gets its low overhead largely from using almost all characters which aren't special in NNTP (and also adapts allowed characters depending on NNTP context), which isn't appropriate for many cases where base64 is used.

There's encodings which may be more appropriate, which use more than 64 codepoints, such as base85 (https://en.wikipedia.org/wiki/Ascii85), assuming that these are allowed.

As an aside, I've implemented a fast SIMD accelerated yEnc encoder/decoder here (https://github.com/animetosho/node-yencode), for anyone interested.


To embed binary data into web-pages one needs encoding that is friendly to the text encoding that the page uses and uses characters that only the source syntax allows. Any of this rules out yEnc. Besides, web pages where one embeds the binary data should be transmitted compressed and gzip removes the overhead of base64 down to few percent.


base64 is supported in browsers with atob() and btoa(), no need for an external lib


Usenet uses yEnc




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: