I have two instances where I'm converting a TIFF file before sending the data to google vision AI. Using CLI, the base64 string works fine. I get the expected response
When I use Java I'm getting a different out, which causes my API call to fail. The base64 output is different.
// API call https://vision.googleapis.com/v1/files:annotate
imageBytes = Files.readAllBytes(new File(fileLocation).toPath());
String imageString = Base64.getEncoder().withoutPadding().encodeToString(imageBytes);
// API response "message": "Unsupported input file format."
I'm looking for suggestions on how to convert a file (tiff, pdf, png) to base64 using plain Java
Related
In Esign version 4.1.1, the VS2019 Docusign project code generators produce this type of config file:
Note that the developer must copy and paste the private key generated on the DocuSign "Quick Start" page into the VS2019 Docusign Project Wizard. The key is converted into a string, with each line in the original key file represented with a carriage return.
Using the private key value in this fashion, inline, with all the other params was very convenient.
This "RSAKey" param value does work with the 4.1.1 version. But does not with the 5.2 version.
In the Esign 5.2 version, we are now in the Asp.Net Core 3.1/.NET 5 style of code, so we now have this configuration file format:
This won't work with Esign 5.2. I surmise the change in 5.2 is this - the Docusign server generates a hash value of the key file, and if the generated hash of the key file submitted by an external client does not match, an "Unknown PEM File" error is sent back. I am trying to highlight the nuance that the first “gate” on the DocuSign server checks the file itself, not the RSA key inside the file.
The ramification, if true, is that we now have to treat the key file with kid gloves. If I wanted to store/retrieve this file from a remote source, I would need to take great care that not a single byte was changed/added/removed. This will require careful testing. As you can see from my sample appsettings.json above, I am forced to add "KeyFilePath" param in order to grab the physical file, which means I must always have it on hand in my project or be able to remotely load it (intact byte-wise) from a remote source. This increases the burden on the developer and maintenance staff considerably.
Ideally, what we need is a way to get that capability to put the key-file-as-a-string back into the config params.
Any ideas appreciated.
One way to solve this is by using https://base64.guru/ .
Using the "File-to-Base64" option allow me to provide this as a string parameter in a normal config file.
Then the C# code to use it looks like this:
var cred = LoadDocusingConfigIntoObject();
byte[] buffer = Convert.FromBase64String(cred.PrivateKey);
this.OAuthToken = docusignClient.RequestJWTUserToken(
cred.IntegrationKey,
cred.ImpersonatedUserId,
cred.AuthServer,
buffer,
1,
scopes
);
Does anyone know how to decode the encoded string in IBM task route exported template file? I tried various ways of decoding such as Base64, none of them worked on the encoded string. a screenshot of part of the encoded string is as below. Thanks!
<config>
<Name><![CDATA[FSC Metadata File Collector]]></Name>
<Description><![CDATA[This collector finds metadata files from specified directories according to filter criteria, submits the files described in the metadata file, and then submits the metadata file. .]]></Description>
<ConnectorTypeKey>ibm.ctms.filesystem.Connector</ConnectorTypeKey>
<TypeKey><![CDATA[ibm.ctms.filesystem.metadata_collect]]></TypeKey>
<IsActive>1</IsActive>
<TaskRouteId>46f15f20-5b89-4e89-9ea0-4051e62f44d8</TaskRouteId>
<ScheduleConfiguration>UDC4aQAAAAAAAAAAbABhAEAwuGlfAGwA4wcIAHQAHAAOAAwADABrAOMHCAB0ABwADgAMAAwAawAAAAAAAAAAAA==</ScheduleConfiguration>
<Configuration>FgAAAHNlcmlhbGl6YXRpb246OmFyY2hpdmUIAAQEBAgBAAAAAAEAAAAABAAAAAEAAAAAAQAAAEQAAABcAFwARQBQAFMARQBDAE0AWgBcAEQAYQB0AGEAXABEAGEAdABhAF8AMQBcAEMAbwBuAHQAZQBuAHQAXABJAE0AQgBcADAAYgB5AHQAZQBzAFwARQBQAFMARQBDAE0AegBDAG8AbABsAGUAYwB0AG8AcgBcAEkAbgBwAHUAdABGAGkAbABlAHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAHgAAAAYAAABTAG8AdQByAGMAZQAkAAAAOAA5ADIANgBmADYAMgA4AC0AZAA3ADUAOAAtADQAOAAxAGUALQA4ADgAMgA2AC0AYQA1AGMAZABkAGMANwA2AGMAZgA4ADgAAQADAAAAJAAAADgAOQAyADYAZgA2ADIAOAAtAGQANwA1ADgALQA0ADgAMQBlAC0AOAA4ADIANgAtAGEANQBjAGQAZABjADcANgBjAGYAOAA4AAAAAAAAAAAADQAAAAABAAAABgAAAAAAAAAADAAAAEMAcgBlAGEAdABpAG8AbgBEAGEAdABlAAwAAABDAHIAZQBhAHQAaQBvAG4ARABhAHQAZQAAAAAACgAAAHkAeQB5AHkALwBNAE0ALwBkAGQAHQAAAC8AeABtAGwALwBGAGkAbABlAC8AQwByAGUAYQB0AGkAbwBuAEQAYQB0AGUALwB0AGUAeAB0ACgAKQAFAAAAAAAAAAAHAAAAQwByAGUAYQB0AG8AcgAHAAAAQwByAGUAYQB0AG8AcgAAAAAAAAAAABgAAAAvAHgAbQBsAC8ARgBpAGwAZQAvAEMAcgBlAGEAdABvAHIALwB0AGUAeAB0ACgAKQAFAAAAAAAAAAAJAAAARABvAGMAUwB0AGEAdAB1AHMACQAAAEQAbwBjAFMAdABhAHQAdQBzAAAAAAAAAAAAGgAAAC8AeABtAGwALwBGAGkAbABlAC8ARABvAGMAUwB0AGEAdAB1AHMALwB0AGUAeAB0ACgAKQAFAAAAAAAAAAAIAAAARABvAGMAVABpAHQAbABlAAgAAABEAG8AYwBUAGkAdABsAGUAAAAAAAAAAAAZAAAALwB4AG0AbAAvAEYAaQBsAGUALwBEAG8AYwBUAGkAdABsAGUALwB0AGUAeAB0ACgAKQAFAAAAAAAAAAAIAAAARABvAGMAdQBtAGUAbgB0AAgAAABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAZAAAALwB4AG0AbAAvAEYAaQBsAGUALwBEAG8AYwB1AG0AZQBuAHQALwB0AGUAeAB0ACgAKQAGAAAAAAAAAAAQAAAATABhAHMAdABNAG8AZABpAGYAaQBlAGQARABhAHQAZQAQAAAATABhAHMAdABNAG8AZABpAGYAaQBlAGQARABhAHQAZQAAAAAACgAAAHkAeQB5AHkALwBNAE0ALwBkAGQAIQAAAC8AeABtAGwALwBGAGkAbABlAC8ATABhAHMAdABNAG8AZABpAGYAaQBlAGQARABhAHQAZQAvAHQAZQB4AHQAKAApAAUAAAAAAAAAAAwAAABMAGEAcwB0AE0AbwBkAGkAZgBpAGUAcgAMAAAATABhAHMAdABNAG8AZABpAGYAaQBlAHIAAAAAAAAAAAAdAAAALwB4AG0AbAAvAEYAaQBsAGUALwBMAGEAcwB0AE0AbwBkAGkAZgBpAGUAcgAvAHQAZQB4AHQAKAApAAYAAAAAAAAAABcAAABSAGUAdABlAG4AdABpAG8AbgBJAG4AaQB0AGkAYQB0AGkAbwBuAEQAYQB0AGUAFwAAAFIAZQB0AGUAbgB0AGkAbwBuAEkAbgBpAHQAaQBhAHQAaQBvAG4ARABhAHQAZQAAAAAACgAAAHkAeQB5AHkALwBNAE0ALwBkAGQAKAAAAC8AeABtAGwALwBGAGkAbABlAC8AUgBlAHQAZQBuAHQAaQBvAG4ASQBuAGkAdABpAGEAdABpAG8AbgBEAGEAdABlAC8AdABlAHgAdAAoACkABQAAAAAAAAAABgAAAFMAbwB1AHIAYwBlAAYAAABTAG8AdQByAGMAZQAAAAAAAAAAABcAAAAvAHgAbQBsAC8ARgBpAGwAZQAvAFMAbwB1AHIAYwBlAC8AdABlAHgAdAAoACkABQAAAAAAAAAACgAAAFQAYQByAGcAZQB0AFAAYQB0AGgACgAAAFQAYQByAGcAZQB0AFAAYQB0AGgAAAAAAAAAAAAbAAAALwB4AG0AbAAvAEYAaQBsAGUALwBUAGEAcgBnAGUAdABQAGEAdABoAC8AdABlAHgAdAAoACkABQAAAAAAAAAABAAAAFQAeQBwAGUABAAAAFQAeQBwAGUAAAAAAAAAAAAVAAAALwB4AG0AbAAvAEYAaQBsAGUALwBUAHkAcABlAC8AdABlAHgAdAAoACkABQAAAAAAAAAAEQAAAFAAcgBvAGMAZQBzAHMAaQBuAGcAVAByAGkAZwBnAGUAcgARAAAAUAByAG8AYwBlAHMAcwBpAG4AZwBUAHIAaQBnAGcAZQByAAAAAAAAAAAAHwAAAC8AeABtAGwALwBGAGkAbABlAC8AUAByAG8AYwBlAHMAcwBUAHIAaQBnAGcAZQByAC8AdABlAHgAdAAoACkABgAAAAAAAAAADwAAAFMAZQB0AE0AbwBkAGkAZgBpAGUAZABEAGEAdABlAA8AAABTAGUAdABNAG8AZABpAGYAaQBlAGQARABhAHQAZQAAAAAACgAAAHkAeQB5AHkALwBNAE0ALwBkAGQAIAAAAC8AeABtAGwALwBGAGkAbABlAC8AUwBlAHQATQBvAGQAaQBmAGkAZQBkAEQAYQB0AGUALwB0AGUAeAB0ACgAKQAAAAAAAQEGAAAAUwBvAHUAcgBjAGUAAAAAAAAAAAAAAAAAAAAAAAACAAAAAgAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=</Configuration>
<ParameterMappings>
</ParameterMappings>
</config>
sample encoded strings
In Altova MapForce, when sending XML to the Body of an HTTP POST (a Web Service call) through a mime-entity function, it generates an error "Conversion to base64Binary failed for '<?xml...'". How do I send XML from a string into a web service call Body connector without generating that error?
The mime-entity function expects binary data which is Base64-encoded. That encoding can be performed using the charset-encode function with a suitable encoding such as "utf-8".
I am writing my own http module (I know that node.js includes one)
I am using the net module
when I am getting a request for a static binary(picture) file, how do I generate HTTP response with the binary file?
When I do exactly that for text file(e.g. html file) it just works..
If you are using the net module, you are probably using a code such as :
var server = net.createServer(function (socket) {
});
What is a socket? it represents the stream of data over the network.
In objects, Socket is a WriteableStream, read more here: http://nodejs.org/docs/v0.6.5/api/streams.html
When you are reading a file you can get the content as String, Buffer or as a ReadableStream
The easiest way to read file as a stream is by using the function: http://nodejs.org/docs/v0.6.5/api/fs.html#fs.createReadStream
e.g.
var fileAsAstream = fs.createReadStream(filePath);
In order to transfer the content of a binary read-stream to a write-stream you can use the pipe function http://nodejs.org/docs/v0.6.5/api/streams.html#stream.pipe functions
e.g.
fileAsAstream.pipe(socket);
public void ZipExtract(Stream inputStream, string outputDirectory)
{
using (ZipFile zip = ZipFile.Read(inputStream))
{
Directory.CreateDirectory(outputDirectory);
zip.ExtractSelectedEntries("name=*.jpg,*.jpeg,*.png,*.gif,*.bmp", " ", outputDirectory,
ExtractExistingFileAction.OverwriteSilently);
}
}
[HttpPost]
public ContentResult Uploadify(HttpPostedFileBase filedata)
{
var path = Server.MapPath(#"~/Files");
var filePath = Path.Combine(path, filedata.FileName);
if (filedata.FileName.EndsWith(".zip"))
{
ZipExtract(Request.InputStream,path);
}
filedata.SaveAs(filePath);
_db.Photos.Add(new Photo
{
Filename = filedata.FileName
});
_db.SaveChanges();
return new ContentResult{Content = "1"};
}
I try to read zip archive from stream and extract files. Got the following exception in the line "using (ZipFile zip = ZipFile.Read(inputStream))" : ZipEntry::ReadDirEntry(): Bad signature (0xC618F879) at position 0x0000EE19
Any ideas how to handle this exception?
The error is occurring because the stream you are trying to read is not a valid zip bytestream. In most cases, Request.InputStream will not represent a zip file. It will represent an HTTP message, which will look like this:
POST /path/for/your/app.aspx HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.2; ...)
Content-Type: application/x-www-form-urlencoded
Content-Length: 11132
...more stuff here...
I think what you are doing is trying to read that message as if it were a zip file. That's not gonna work. The file content is actually embedded in the "... more stuff here..." part.
To work toward solving this, I suggest you work in smaller steps.
First, get the file upload to work, saving the content of the uploaded file to a filesystem file on the server. Then, on the server, try to open the file as a zipfile. If it works, then you should be able to replace the file saving portion, with ZipFile.Read(). If you cannot open the file that you saved, then it means that the file that you saved is not a zip file. Either it is incomplete, or, more likely, it includes extraneous data, like the HTTP headers.
If you have trouble successfully uploading a binary file like a zip file, first work on uploading a text file. You can more easily verify the upload of a text file on the server, by simply opening the uploaded content in a text editor, and checking that it contains exactly the content of the file that was uploaded from the client. Once you have this working, move to a binary file. Then you can move to a full streaming approach, using DotNetZip to read the stream. Once you get to this point, there should be no need to save the file to the filesystem, before reading it as a zip file, but you may want to save it anyway, for other reasons.
To help, you may want to use Fiddler2, the debugging HTTP proxy. Install it on the browser machine, turn it on, and it will help you see the messages that get sent from the browser to the ASPNET application on the server. You'll see that a file upload contains more that just the bare file data.
A more stable solution could be to use ICSharpCode ZipLib: http://www.sharpdevelop.net/OpenSource/SharpZipLib/Default.aspx