Hot answers tagged

8

Based on the error message you get when you attempt to retrieve the body of an attachment: Visualforce Remoting Exception: No serializer found for class common.udd.object.EncryptableFfxBlobField$DeferredEncryptableFfxBlobValueImpl It would appear that you can't work with blob fields in Visualforce Remote Objects. I'll see if I can find an official ...


8

The actual limit is going to be closer to 4,500,000 bytes before encoding. Note that it has never been possible to send more than 12,000,000 bytes of data in a single transaction, and even then, only for asynchronous code. If for some reason you were able to send more than 6MB/12MB, this was a bug that has since been fixed. It should never have been ...


7

Based on my research, I have concluded that at the time of this writing (using REST API v32), Salesforce does not decode uploaded base64 encoded data for Attachments. This is a bit confusing, since the Attachments documentation specifies the following: The API sends and receives the binary file attachment data encoded as a base64Binary data type. Prior ...


7

The content you are receiving is not Base64: it is Base64 inside JSON, which you are asking the server to provide to you. Base64 encoding uses the characters [A-Za-z0-9+/]. The backslash and quote characters shown here are not part of the Base64 encoding but the JSON wrapper around it. You need to deserialize the JSON first, into a String, and then Base64-...


6

Following trigger parses case description for base64 images and creates attachments for case. Email-to-Case functionality stores email body in case description. Let's assume we have next html: <html> <head> <title>Base64 image</title> <h5>How to store (or ignore) Base64 images in emails processed by email-to-...


6

Because PayloadBody2 and PayloadBody3 are null, you end up adding extra junk text to the end of the base64 string, which subsequently fails to decode. Make sure they're not null first: String part1 = ebi.PayloadBody1__c, part2 = ebi.PayloadBody2__c, part3 = ebi.PayloadBody3__c; part1 = part1 == null? '': part1; part2 = part2 == null? '': part2;...


5

String.fromCharArray is going to create a UTF-8 encoded string, which will alter the bytes in the stream. For example, 242 will be encoded as two bytes instead of one. Any value outside 0-127 will be encoded as multiple bytes when using this function, including all negative integers. Since we can't really work with binary data directly in Apex Code, just ...


5

Did you set the contentType as application/pdf? I tried this following code and it is working for me. String jsonStr = '<Base64 String>'; Attachment attach = new Attachment(); attach.contentType = 'application/pdf'; attach.name = 'myfile.pdf'; attach.parentId = '0010H00002DW2Ds'; attach.body = EncodingUtil.base64Decode(jsonStr); insert attach;


5

Unfortunately for you, there's not much that can be done here aside from checking to see if someone else has already implemented a Base85Encode method (a cursory google reveals that nobody has done this...yet) or implementing your own. Given that you're working with image data, rather than a string, your data in Salesforce is probably a Base64 encoded Blob (...


5

Figured it out after debugging a bit more. Blob img; public Object getImg () { List<ContentVersion> bodyList = [SELECT VersionData FROM ContentVersion WHERE ContentDocumentId='insert your id']; img = (Blob) bodyList[0].get('VersionData'); return EncodingUtil.base64Encode(img); } All I had to do was to typecast the Object as Blob and ...


4

You need to take data and base-64 decode it: String myFile = EncodingUtil.base64Decode(file.split(',')[1]).toString(); Alternatively, you could have decoded it in JavaScript and sent the string in directly. Also, do not encode the data: objFileReader.onload = $A.getCallback(function() { var fileContents = objFileReader.result; action....


4

Use: EncodingUtil.base64Decode(file).toString() Instead of: EncodingUtil.urlDecode(file, 'UTF-8') Encoding Util class Blob Class


4

If you change the way your component works rather than using a force:navigateToURL event and instead put your octet stream into an anchor tag, you can use the download attribute on the <a> tag to specify a filename and extension. <a download="myfile.pdf" href="data:application/octet-stream;base64,...">Download PDF</a> ...


4

You can have 2 steps in your automation to solve this: 1- SQL Query to Pull data into a DE 2- SSJS Script to go through the Data extension and Update an "encodedEmail" field with the new encoded email using the Base64encode() Method. (Documentation Link below) https://developer.salesforce.com/docs/atlas.en-us.noversion.mc-programmatic-content.meta/mc-...


3

Since you are storing the Blob value of the PDF in the class variable b, the entire Blob is considered part of the Visualforce view state, so the page can't be rendered. One option is to only use the Blob with a local variable within the method where it is used. If it's not stored at the class level, it will not be retained in the view state. The other ...


3

Here is a sample JS fetch request I converted in Postman (this is pseudocode and probably wont work). I use the the following endpoint /services/data/v48.0/sobjects/Attachment/<ATTACHMENT_FILE_ID>/Body BUT the response is binary so you would need to handle that response and convert it to JPG https://developer.salesforce.com/docs/atlas.en-us.api_rest....


3

If you can upload in binary format, do so. If your source platform cannot use binary, then use base64. Base64-encoded data is approximately 33% larger, meaning longer upload times, more bandwidth used, and a lower maximum file size for non-multipart uploads. You can insert or update blob data using a non-multipart message, but you are limited to 50 MB of ...


3

Can you try validating your base64 photo URL at https://base64.guru/tools/validator. maybe there is some issue with URl or undefined value. Sometimes you need to deserialize the JSON first, into a String, and then Base64-decode that String.


3

You can take the "long way around" by first converting to hex, then converting to URL-encoded form, and then finally to UTF-8 via ISO-8859-1 decoding. // 'ááááá' in base64 in ISO-8859-1 Blob source = EncodingUtil.base64Decode('4eHh4eE='); String hexSource = EncodingUtil.convertToHex(source); String urlEncoded = hexSource.replaceAll('(.{2})','%$1');...


2

As long as your only concern is generating a unique ID that can safely be included in a URL querystring, you could just escape ("urlEncode") the output of your current code: EncodingUtil.urlEncode(EncodingUtil.base64Encode(Crypto.encryptWithManagedIV('AES128', privateKey, Blob.valueOf(i.Id))),'UTF-8')


2

I suspect we can use the new fileUpload in Lightning. https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/aura_compref_lightning_fileUpload.htm


2

I didn't find a way to directly return the base64 field as part of the ContentNote record. I ended up having to use the workaround in the question - omitting the base64 field from the query, and returning the list of records without that field - and then decoding the base64 field using .toString(), and passing it separately to the client side as a string......


2

Access to User.SmallPhotoURL or User.LargePhotoURL needs authentication. In your case this might be a issue. Instead use ChatterUsers class to get the photo URls. There is a variable called standardEmail​PhotoUrl is available which is A temporary URL to the small profile. The URL expires after 30 days and is available to unauthenticated users. So you can ...


2

Encoding/Decoding is different from Serialization/Deserialization The JSON you have for fake response is malformed. If all you are getting from the response is Base64 encoded string, you don't need to deserialize So in this case there is no need for JSON at all Try this instead: public String requestBody = 'Um05dkxFSmhjZz09'; b = EncodingUtil....


2

The problem was jQuery ajax method. XMLHttpRequest with responseType set to "blob" solved the problem.


2

As JWT is meant to be url-safe, the 62nd and 63rd characters used in Base64 encoding (+ and /, respectively) which are not url-safe must be replaced with characters that are url safe. + is mapped to -, and / is mapped to _ This is known as "Base64url" encoding, and is mandatory for JWT (described in the relevant IETF RFC) Salesforce doesn't provide ...


2

Converting to base64 increases the size by 33% (4/3). If this exceeds the heap size of 6MB, you'll get this error. This limits you to processing approximately 4,500,000 actual bytes. If you use Future/Batchable/Queueable instead, you can get content up to 9,000,000 bytes instead, but you can't return the results directly to the trigger context, since it ...


1

You can use Data Loader to bulk upload documents and links into libraries in Salesforce CRM Content. Before uploading documents or links, note the following. If you intend to upload via the Bulk API, verify that Upload Bulk API Batch as Zip File on the Settings > Settings page is enabled. When you upload a document from your local drive using Data Loader,...


1

.replaceAll('=','%3D') should instead be EncodingUtil.urlEncode(... ,'utf-8'). This will make sure that all characters are properly encoded.


1

Code is same as the other answer, this answer serves to show proof / reproducible example, that doing it as suggested will produce a PDF file that can be viewed. If it is not working for you then there may be something else going on? This worked fine for me in exec anon attaching to an account then viewing it: String t = '...


Only top voted, non community-wiki answers of a minimum length are eligible