Passing js string with null chars to plugin


I’m trying to pass a javascript string that might have null chars in it (i get the string from html5 FileReader.readAsBinaryString) to my plugin. However when casting it to a juce::String , all chars after the null char are lost. I want to write this String to a juce::File. Any ideas on how to fix this?

javascript snippet:

var reader = new FileReader(); 
reader.onload = function(oFREvent) { 
  m_plugin.SetDroppedFileData(,, ...); // result is a binary string, and might contain null chars.

and in the plugin:

const var CBrowserObject::SetDroppedFileData(const var* params, int numParams)
	if (numParams == 3) 
		String filename = params[0]; // <-- contains just the name part without full path unfortunally.
		String data = params[1];  // <--- data is wrong, since it was truncated at the first null char.



Don’t put it in a string put it in a MemoryBlock, you can’t have NULLs in Strings i had that problem some time ago.


How exactly would i do that? Can you give me an example ?


That’s actually a good question i just looked at the browser plugin demo and it’s all var and var has no way to access the data pointer it’s holding, so i think someone smarter may need to answer that, as i can’t, sorry.


can’t you use a special character to replace the NULL characters with and then set them back again when you receive the js string?


Can you get the length of the js string? Use String::fromtUTF8 (str, len);



No, its a binairy string, so all char codes are used.

No, if i have a null char at position 4 (zerobased), length will be 4.

I looked in the juce code and saw that NPP arguments are copied and converted to juce arguments - in this process the orginal string (with correct length) is lost, and a wrong string (wrong length) is passed to my method. I would say this is a bug of juce, and there might not be a workaround at this moment. Jules, can you confirm this ?


Well, it’s not a bug… Juce strings are designed only for holding valid unicode data, and cannot contain null chars, so if you try passing it a heap of random binary data, don’t be surprised if it doesn’t come out right!

I’ve no idea how javascript handles strings, but maybe you should pass your data as a uuencoded string and then decode that into a memoryblock?


uuencode would take way too long in javascript - even for smallish files like 30mb (average image size). I’m talking minutes of hanging the browser during this.

I dont remember (and cannot check right now) the exact call stack, but if i do remember correctly, NPObjectWrappingDynamicObject::invoke is called, where NPVariant “args” contains the correct string + length. Its then converted to “var*” using createValueFromNPVariant. Is there no way to somehow tell the juce framework not to do that? Or somehow return the pointer to the NPVariant ?


You’d have to dig in deep and modify it yourself to do that - it’s not something I’ve ever considered.