I have a string like in this link http://pastie.org/private/n7bu5qlknphtyyv5sqla.
I am trying to decode it using different methods
new Uint8Array(encodedString);
and also tried some octal decoders online but no success. Can anyone help me to understand encoding type and how to decode it.
Edit:
Progress: It is a file loaded from client side. Before I was using readAsBinaryString and now I changed it to reader.readAsArrayBuffer(blob); Now I am getting ArrayBuffer and converted it to new Uint8Array(arrayBuffer). It seems now I have some data zipped data.
Related
In the official documentation and many other solutions posted online, the following code is supposed to be the way of writing data to a file in Cordova
function writeFile(fileEntry, dataObj) {
fileEntry.createWriter(function (fileWriter) {
fileWriter.write(dataObj);
});
}
writeFile(someFileEntry, blob);
In the documentation, they explicitly shown that a blob can be passed as the "dataObj", but whenever I passed a blob as "dataObj", the resulting file only has 2 bytes of data. After inspecting the file, I found that the contents of the file only contain a single string
{}
hence the 2 bytes.
I've tried passing a string as the "dataObj", and the contents of the resulting file was the exact same string, so string works I guess? But the data I'm wishing to write to a file is a blob that contains video data recorded from a canvas, so either I'll have to
somehow convert the the video blob into a string and write the string into the file
somehow fix the "fileWriter.write" function
But I've gone nowhere with these solutions. I've tried "blob.text()" or using a "fileReader" to get the contents of the blob as a string, but the resulting file is always broken. And fixing the "fileWriter.write" function is way out of my depth. Can someone help me out on this?
I am having the same issue. I think it might have something to do with the following as stated on the cordova-plugin-file docs:
But I find that odd since the examples all use FileWriter.write(blob) but it says that the platforms do not support that function.
I am working on an application that was created by a colleague that is no longer with the company. I am trying to open what I believe is a PDF in blob file format, but none of the tutorials is giving me the expected result.
I notice that I have some data preceding what I believe to be the blob file, leading me to wonder if I am understanding what I am working with correctly. The whole blob is too large to post here, but this is how it starts:
data:application/pdf;base64,JVBERi0xLjcNJeLjz9MNCjIxIDAgb2JqDTw8L0xpbmVhcml6ZWQgMS9MIDQyMTExNC9PIDIzL0UgMzc0MzIwL04gMi9UIDQyMDU3NC9IIFsgMjYxNiA0NDhdPj4NZW5kb2JqDSAgICAgICAgICAg
In the posts and tutorials I am reading, like this one for instance, they use code similar to this:
var file = new Blob([response], {type: 'application/pdf'});
Since my blob file includes the "application/pdf" portion as part of the string, I am starting to wonder if I misunderstood and that this is another kind of file instead of a blob. I have also seen other examples of blob files, and they also do not include the "data:application/pdf;base64,".
I am having issues opening the files in a browser if they are too large. I have outlined my problem in this post, but have yet to receive any advice, so I am trying to find a different way to approach this. The results are not as expected, which leads me to wonder if I am looking for the right thing.
Here is what I have tried and what the result is:
var file = new Blob([upload.split(',')[upload.split(',').length - 1]], { type: 'application/pdf' });
var fileURL = URL.createObjectURL(file);
I remove the "data:application/pdf;base64," portion of the string using "[upload.split(',')[upload.split(',').length - 1]]", thinking that this will leave me with only the blob data, but this invariably fails to open, giving me the below result:
So my question is this: Am I working with a blob file or not? If not, what kind of data file is this so I can start looking for more relevant tutorials?
"Blob files" aren't really a thing. You can think of the term "blob" as "just some binary data", or if you're a database vendor, call them "Binary Large OBject"s.
Your data:application/pdf;base64,JVBERi0xLjcNJeLjz9MNCjIxIDAgb2JqDTw8L... string is a data URL; a way to represent arbitrary binary data in an URL string. Since the URI has the base64 marker, you know the data is encoded as Base64 and you can use any Base64 decoder you can find (there are plenty online) to decode the data.
Your (truncated) data begins
%PDF-1.7
%
21 0 obj
<</Linearized 1/L 421114/O 23/E 374320/N 2/T 420574/H [ 2616 448]>>
endobj
so it is representing something like a valid PDF file.
I am using a library to recieve attachments (image) from salesforce using OAuth and a proxy. Without the library (and the proxy) I am able to the same using XHR, but I have to use the library because I need the proxy.
In chrome debugger I can see image is downloaded fine, but I can't get it to work in my code. Data looks like:
So far methods I have tried:
btoa(unescape(encodeURIComponent(file.body)));- produces a base64 that does not work. decoding it using online tools gives me back the same string.
escape(file.body) - using this as base64 also does not work.
Converting to a blob.
var blob = new Blob([file.body], {type : "image/png"});
urlCreator.createObjectURL(blob);
The url it points to displays nothing, and if I remove {type : "image/png"} the url points to a page displaying same binary string.
Long story short this looks like someone read the image with readAsText() which mangles ("interprets") binary into utf8, instead of utf16. You need to get the server to return the data in arraybuffer or blob format ideally, or even base64, these preserve binary.
Long version with snippet. (those question marks symbols in the snippet show the lost information, compare it to the binary where they are not question marks in utf16):
https://stackoverflow.com/a/56523118/2962797
I would create an <img /> element, equal its src attribute to the image data you received. Now you have the image.
If you want to extract it or convert it to PNG, I would apply this another answer process.
I am making a simple web app that needs to play a some audio files, using howler.js. howler.js accepts base64 URI as input, so I wanted to try that out. To test it, I took a sample audio file and used an online audio-to-base64 encoder to get the base64 URI. I added the data description ("data:audio/wav;base64,") the front of the base64 string and copy and pasted into the following JS function...:
function playSound() {
var data = "";
var sound = new Howl({
src: [data],
loop: false
});
sound.play();
}
...and it worked perfectly. Since I would be dealing with a fair number of audio files, I figured I'd use a short python script to convert them all to the base64. To test, I converted the same audio to a base64 string with the following python code:
import base64
with open("0.wav", "rb") as f1,open("b64.txt", "w") as f2:
encoded_f1 = base64.b64encode(f1.read())
f2.write("data:audio/wav;base64,")
f2.write(str(encoded_f1))
I noticed the base64 string was different front the one I got from the website earlier. I pasted this into the JS function shown earlier, but when I attempt to play the sound, I get the following error:
Uncaught DOMException: Failed to execute 'atob' on 'Window': The string to be decoded is not correctly encoded.
There seems to be some sort of difference in the way python is encoding to base64. What could the cause for this be?
Came back to this after a while and the problem became apparent. It was just a problem with the block of code I mentioned in OP (the second block) that I used to write the base64 encoding to a file.
base64.b64encode(f1.read()) returns a bit string, which in Python, is symbolized with the following notation (i.e. when you print/write it, you'll see it like this): b'string goes here'. So the issue was just that the b' ' was wrapped around my actual base64 string, and I was using that. All I had to do get rid of the b' ' which I did by converting the bitstring to ASCII like this: str(encoded_f1,'ascii', 'ignore').
Really silly mistake, but hopefully it helps someone out.
At work we are trying to upload files from a web page to a web service using html 5/javascript in the browser end and C# in the web service. But have some trouble with encoding of some sort.
As for the javascript we get the file's binary data with help from a FileReader.
var file = ... // gets the file from an input
var fileReader = new FileReader();
fileReader.onload = dataRecieved;
fileReader.readAsBinaryString(file);
function dataRecieved() {
// Here we do a normal jquery ajax post with the file data (fileReader.result).
}
Wy we are posting the data manually and not with help from XmlHttpRequest (or similar) is for easier overall posting to our web service from different parts of the web page (it's wrapped in a function). But that doesn't seem to be the problem.
The code in the Web Service looks like this
[WebMethod]
public string SaveFileValueFieldValue(string value)
{
System.Text.UnicodeEncoding encoder = new UnicodeEncoding();
byte[] bytes = encoder.GetBytes(value);
// Saves file from bytes here...
}
All works well, and the data seems to be normal, but when trying to open a file (an image as example) it cannot be opened. Very basic text files seems to turn out okay. But if I upload a "binary" file like an image and then open both the original and the uploaded version in a normal text editor as notepad to see what differs, it seems to be wrong with only a few "invisible" characters and something that displays as a new line a few bytes in from from the start.
So basicly, the file seems to encode just a few bytes wrong somewhere in the conversions.
I've also tried to create an int array in javascript from the data, and then again transformed to a byte[] in the web service, with the exact same problem. If I try to convert with anything else than unicode (like UTF-8), the data turns out completly different from the original, so I think om on the right track here, but with something slightly wrong.
The request itself is text, so binary data is lost if you send the wrong enc-type.
What you can do is encode the binary to base64 and decode it on the other side.
To change the enc-type to multi-part/mixed and set boundaries (just like an e-mail or something) you'd have to assemble the request yourself.