Passing js string with null chars to plugin


#1

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(file.name, oFREvent.target.result, ...); // result is a binary string, and might contain null chars.
};
reader.readAsBinaryString(file);

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.
		....
	}
}

Thanks


#2

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.


#3

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


#4

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.


#5

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?


#6

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

Bruce


#7

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 ?


#8

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?


#9

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 ?


#10

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