Email messages in RTF format can have embedded in-line attachment. MAPI gives file name of inline attachment but without extension. How to know the extension?
MAPI gives content-description as 'Picture (Device Independent Bitmap)'. I can depend on this data to compute file extension as BMP. But this works for BMP but not for PDF, WORD, EXEL. I would like to know if there is a solution (like looking in to REGISTRY) that works for everything without me changing the code for every file type.
Mime headers generated by reading MAPI properties of attachment. You see that attachment is missing extension.
Content-Disposition: inline; filename=ATT87266
Content-Transfer-Encoding: Base64
content-type: application/ole;name="Picture (Device Independent Bitmap)"
content-description: Picture (Device Independent Bitmap)
Embedded OLE attachments are not files, they are IStorage COM storage. If you look at an OLE attachment with OutlookSpy (I am its author - click IMessage button, go to the GetAttachmentTable, double click on the attachment), you will see that there is no PR_ATTACH_DATA_BIN binary property where the regular by-value attachments are stored; what you have instead is PR_ATTACH_DATA_OBJ object (PT_OBJECT) property. You can open it in OutlookSpy by right clicking and selecting IMAPIProp::OpenProperty, then selecting IStorage as the interface.
The OLE storage will contain several streams that contain flags used by Outlook, metafile used to render the object when viewing it, and the actual data used by whatever OLE server was used to create the OLE attachment. You can look at the storage CLSID to figure out the application used to create the attachment. Once you know that, you can extract the raw file data from the application-specific storage stream inside that IStorage.
Related
Using Plone 4.3.4, I have created file system products to create a new Dexterity content type ("Article") and a new Transform. Article contains a RichTextField and a custom transform ("xml_to_html").
The xml_to_html transform is designed to convert the raw XML input of the RichTextField into HTML output using a SAX-based parser and templating system. This works perfectly when creating or modifying Article items through the web.
The mime_types_registry is set to map Article to *.xml and mimetype text/xml.
When uploading an XML file via WebDav, Plone correctly creates an Article with the RichTextField designated as primary. However, the xml_to_html transform does not run to create the transformed output. RichTextValue.raw contains the uploaded file content, but RichTextValue.output is never generated.
A further complication is that the WebDav client is setting Content-Type: text/xml but the RichTextValue.mimeType is always coming through as text/plain.
I can see that my type-specific event hooks are working. I can execute arbitrary code based on zope.lifecycleevent.interfaces.IObjectAddedEvent, but the object creation process never hits the xml_to_html transform.
Questions:
a) Are portal_transforms applied to content items created via WebDav? If not, then that's my answer.
b) Why is the mimetype of the primary field not respecting the value set by the webdav client?
Thanks,
Don
Content Type
The mimeType and encoding properties are sets on the value of the Content-Type header - docs.plone.org
Checkout your webdav client content-type headers.
The Content-Type request header MUST be set appropriately for an XML body (e.g., set to "text/xml" or "application/xml").
Second case
New Article Item object creates with 'text/plain' by default.
In this case you can call
context.portal_transforms.convert('xml_to_html',context.richtextfield_name)
directly in article-template-view.pt and other content specific views.
I have a function that retrieves PDF bytes from another Webservice. What I wanted to do is make the PDF bytes also available to others by creating an API call that returns HttpResponseMessage.
Now, my problem is I don't think that passing it through json is possible, because it converts the PDF bytes into a string?
Is there any other practical way of passing the PDF, or making the PDF visible to the requestors?
(Note: saving the PDF file in a specific folder and then returning the URL is prohibited in this specific situation)
I just solved it. There is a new paramater responseType: 'arrayBuffer' which addresses this problem. Sample: $http.post('/api/konto/setReport/pdf', $scope.konta, { responseType: 'arraybuffer' }) View my question and answer on SO: How to display a server side generated PDF stream in javascript sent via HttpMessageResponse Content
My Mysql database stores images (in PNG, JPG)of our personnel and it's field type is set to longblob.
Is there any possibility to load blob data type using HttpService and render it in Image component in Flex .??? ^..^
I'm eager to know about as it comes in handy in the nearest future!!!
You can, but I don't see the point of storing your images in a DB.
Simplest way to get it into an Image is to load the blob, convert to a ByteArray which you can set as the source of of said Image.
If you override HttpService you can use it to receive binary data. If you don't want to override HttpService you have the option of encoding you binary data in base64 before sending it.
But if have the option to store the images in a directory on the server and just send links to the client - that would be a better solution.
I am using file upload mechanism to upload file for an employee and converting it into byte[] and passing it to varBinary(Max) to store into database.
Now I what I have to do is, if any file is already uploaded for employee, simply read it from table and show file name. I have only one column to store a file and which is of type VarBinary.
Is it possible to get all file information from VarBinary field?
Any other way around, please let me know.
If you're not storing the filename, you can't retrieve it.
(Unless the file itself contains its filename in which case you'd need to parse the blob's contents.)
If the name of the file (and any other data about the file that's not part of the file's byte data) needs to be used later, then you need to save that data as well. I'd recommend adding a column for the file name, perhaps one for its type (mime type or something like that for properly sending it back to the client's browser, etc.) and maybe even one for size so you don't have to calculate that on the fly for each file (useful when displaying a grid of files and not wanting to touch the large blob field in the query that populates the grid).
Try to stay away from using the file name for system-internal identity purposes. It's fine for allowing the users to search for a file by name, select it, etc. But when actually making the request to the server to display the file it's better to use a simple integer primary key from the table to actually identify it. (On a side note, it's probably a good idea to put a unique constraint on the file name column.)
If you also need help displaying the file to the user, you'll probably want to take the approach that's tried and true for displaying images from a database. Basically it involves having a resource (generally an .aspx page, but could just as well be an HttpHandler instead) which accepts the file ID as a query string parameter and outputs the file.
This resource would have no UI (remove everything from the .aspx except the Page directive) and would manually manipulate the response headers (this is where you'd set the content type from the file's type), write the byte stream to the client, and end the response. From the client's perspective, something like ~/MyContent/MyFile.aspx?fileID=123 would be the file. (You can suggest a file name to the browser for saving purposes in the response headers, which you'd probably want to do with the file's stored name.)
There's no shortage of quick tutorials (some several years old, it's been around for a while) on how to do this with images. Just remember that there's essentially no difference from the server's perspective if it's an image or any other kind of file. All the server needs to do is send the type in the response headers and write the file's bytes to the client. How the client handles the file is up to the browser. In the vast majority of cases, the browser will know what to do (display an image, display via a plugin a PDF, save a .doc, etc.).
I able to upload my file through uploadify + .ashx, but the problem is I always get ContentType = application/octet-stream
Lets say I upload an image, I expected to return me "image/pjpeg", but it always return "application/octet-stream" no matter what file I uploaded.
Please advice how to get the correct contentType in .ashx
I believe that most probably content type is getting set by browser. Regardless, different browsers may set different content type for different files - and they may fall back to generic content type such as "application/octet-stream" for any binary file (pdf, zip, doc, xls). Its possible that one browser would report docx as "application/vnd.openxmlformats" while other as ""application/x-zip-compressed" and yet another as "application/octet-stream". And yet all of them are correct, because docx are binary file and are compressed (zip) files.
In short, my suggestion is that you should not rely on the content type sent by client (beyond certain extent such as deciding whether its text, html or binary etc) and rather use server side sniffing logic to determine type of file content. Simple sniffing can be based on file extension while more robust implementation will loot at actual file contents where typically first few bytes of file indicate the file type.