mhart / stringstream

Encode and decode streams into string streams in node.js

Decode streams into strings without setEncoding

const fs = require('fs')
const zlib = require('zlib')
const strs = require('stringstream')

const utf8Stream = fs.createReadStream('massiveLogFile.gz')
  .pipe(zlib.createGunzip())
  .pipe(strs('utf8'))

utf8Stream.on('data', str => console.log(`This will be a string: ${str}`))

API

• strs(to, [options]) – creates a transform stream that converts the input into strings in to encoding (eg, utf8, hex, base64)
• strs(from, to, [options]) – creates a transform stream converts the input from strings in from encoding to strings in to encoding

options can be anything compatible with the standard Node.js new stream.Transform([options]) constructor

NB: This library was originally written before Node.js correctly encoded base64 strings from streams

Back in the day, calling .setEncoding('base64') on a readable stream didn't align correctly, which was one of the main reasons I wrote this library – however this hasn't been the case for a long time, so this library is now really only useful in scenarios where you don't want to call .setEncoding() for whatever reason.

It also handles input and output text encodings:

// Stream from utf8 to hex to base64... Why not, ay.
const hex64Stream = fs.createReadStream('myFile.txt')
  .pipe(strs('utf8', 'hex'))
  .pipe(strs('hex', 'base64'))

Also deals with base64 output correctly by aligning each emitted data chunk so that there are no dangling = characters:

const stream = fs.createReadStream('myFile.jpg').pipe(strs('base64'))

let base64Str = ''

stream.on('data', data => base64Str += data)
stream.on('end', () => {
  console.log('My base64 encoded file is: ' + base64Str)
  console.log('Original file is: ' + Buffer.from(base64Str, 'base64'))
})

stringstream's Issues

Is pipe from stringstream work correctly?

Well, I have large gzip archive of kern.log kern.log.2.gz (72 megabytes).
Code for this file.

const fs = require("fs")
const zlib = require('zlib')
const sstream = require("stringstream")

fs.createReadStream('kern.log.2.gz')
    .pipe(zlib.createGunzip())
    .pipe(sstream('utf8')) // stringstream
    .pipe(fs.createWriteStream('kern.log.2.sstream'))

fs.createReadStream('kern.log.2.gz')
    .pipe(zlib.createGunzip())
    .pipe(fs.createWriteStream('kern.log.2.try'))

After run I get: kern.log.2.sstream (480 kilobytes) and kern.log.2.try (1,4 gigabytes).
kern.log.2.sstream didn't ended correctly: the file contain only part of kern.log.2.gz information.
Is it conceived behavior?

no method 'on'

Trying to run the example, getting this:

TypeError: Object function StringStream(from, to) {
  if (!(this instanceof StringStream)) return new StringStream(from, to)

  Stream.call(this)

  from = from || 'utf8'

  this.readable = this.writable = true
  this.paused = false
  this.toEncoding = (typeof to === 'undefined' ? from : to)
  this.fromEncoding = (typeof to === 'undefined' ? '' : from)
  this.decoder = new AlignedStringDecoder(this.toEncoding)
} has no method 'on'

node v0.8.17

Out-of-bounds Read vulnerability

StringStream/stringstream.js

Line 32 in 1efe3bf

data = new Buffer(data, this.fromEncoding)

https://nodesecurity.io/advisories/664

out of index, crashing !!!

when using this error crashes process... for bigger sized image.
any thoughts?
thanks

new Buffer() in Node is deprecated

See: https://nodejs.org/api/buffer.html#buffer_new_buffer_size

Uninitialized Memory Exposure

According to Snyk, stringstream has a vulnerability when run on Node.js 4.x and below.

The bug comes from this line : https://github.com/mhart/StringStream/blob/v0.0.5/stringstream.js#L32
More details can be found here : https://hackerone.com/reports/321670

Thank you for the package, by the way !

Time for 1.0.0?

I noticed you just pushed a 0.0.6 (I assume in response to https://nodesecurity.io/advisories/664?), but, a semver dependency on ^0.0.5 will not automatically pick up 0.0.6. So to get your bugfix, I'm going to have to wait for the libraries I use which depend on stringstream to be updated.

It's been almost 6 years. I think it's safe to declare 1.0.0. ;)