31 Jan, 2014, quixadhal wrote in the 21st comment:
Votes: 0
You're totally not understanding what this does. Base64 doesn't know or CARE that the thing your'e feeding it is a series of UTF-8 wide characters. Big deal. It sees a series of unsigned byte data. It could be UTF-8, it could be a 16-bit wide character string in some other encoding, it could be an mp3 stream…. it does NOT matter. It breaks the data up into 24-bit chunks (3 8-bit bytes), and re-encodes that RAW data as a series of 4 characters, using a mapping that allows them to share representation with printable 8-bit ASCII characters.

When you reverse the process, you get back the original BINARY data, on the client side, in whatever form it was when you encoded it on the server. If it was some UTF wide character string, that's what it will be. If it was an mp3 buffer, it's now the same mp3 buffer.

The fact that it uses ASCII as the encoding is simply for convenience… since USENET used ASCII encoding for all postings, and that's what it was developed for (as a successor to uuencode).
01 Feb, 2014, Runter wrote in the 22nd comment:
Votes: 0
Quote
It's interesting that for all these solutions, if you go to their web pages, they never come right out and say: "For this to be useful, you need to be using node.js and javascript server-side" or "For this to be useful, you need to be using ruby server-side". Instead, you have to discern this from the details.


You don't have to be using anything in specific to make firehose.io work. It works even if you use curl as the source of the data… The only thing you need to use is a web server of any kind.

socket.io works with any implementation of the software. There's a list of like 10 or so languages it works in. Although, yes, the best one seems to be node.js.
Random Picks
20.0/22