I have a well known problem that is described in Extension Warning On Opening Excel Workbook from a Web Site microsoft blog entry. I've added URL rewrite to have URL nicely formatted and my mime type matches exactly XLSX recommended file type. However I still get a warning. I suspect that service that provides me those xlsx files mismatches real file format and extension.
Is there a way to determine real xlsx file format? Something that would say what is the native extension for particular Excel file.
Thanks in advance.
Have you tried changing the mime header from vnd:excel to octet-stream? This will still bring Excel up, albeit not embedded into IE, which vnd:excel does (but I hate vnd:excel anyways because embedding the spreadsheet into the browser screws up the form flow of my web apps).
Did not find an answer for that anyway.
However I've discovered the reason why I get a warning from Excel - any parameter in query string will trigger such a warning, even for static files:
http://localhost/1.xls
works ok
http://localhost/1.xls?testparam=paramvalue
gives a warning.
Will use URL rewrite to encode parameters.
Related
I have an .xlsx file that when run through the open Office SDK 2.5 generates an error that the document is invalid and contains multiple validation errors involving the slicerCache and invalid attribute values.
I can attach more information about the actual XML if needed from the xlsx file, however my question is actually this. Excel still opens the document without an error. Not even a request to "repair" the document.
I am curious why using the Microsoft open office XML SDK generates validation errors, yet office is still able to open these documents.
Does office make a best guess? Or is the SDK given by microsoft not entirely accurate??
Thanks.
This is a formatting issue as far as I can tell. When you save it in xlsx it saves it as a workbook, not a spreadsheet. I would save it in a different file format or see if there libraries that your sdk needs in order to process the xlsx. I've never worked with office sdk, but I get similar errors when I open xlsx in other programs. 99% of the time I can just change the format. (if you live dangerously you can just manual change the file extension in your folder to something itll read.)
Short background - I'm exporting an Excel file using Classic ASP, in which I generate a table which is originated at an MS SQL database.
One of the columns I retrieve holds paths to images I have on my server. I use the following code to define an "Excel-targeted" response:
Response.ContentType="Application/vnd.ms-excel"
Response.AddHeader "content-disposition", "attachment; filename=""Sales_Report-"& Month(Date())&"-"& Day(Date())&"-"& Year(Date()) &"-"& ".xls"""
The problem - I've been googling for a solution and came to realize (correct me if I'm wrong here) that embedding it as "contents" of a single page is impossible.
However, it is possible to either placing the image in one cell's remark (I'd like to avoid that), or alternatively just set the image as a cell's background.
Important note - my goal is to have the images sort and filter with the rest of the row they're located in. I did manage to place the images exactly where they should be to begin with, but they just float as regular images in the spreadsheet.
I'm using plain HTML elements and not XML - but an XML solution (if exists) would also be awesome.
Thanks.
OK, so after some research I've come to discover the research I was lacking to begin with. It obviously depends on the MS Excel version which eventually opens the generated file.
Generating XLS files with advanced cell settings is quite doable and intuitive when one acquires better understanding of the XML structures which help generating files through the code, with either Classic ASP & ASP.NET code behind.
Requirement:
1.I need to export a table as a excel file.
2.I render it in a html page at first. I have a button to export to html.
My opinion:
1.I get the html from page:
document.getElementById('content').value = document.getElementById('containerId').innerHTML;
form1.submit();
2.I get it from server, response.ContentType = "application/vnd.ms-excel;" // it need the client has installed Microsoft Excel.
3.I got the right Excel file "XXXX.xls".
4.BUT BUT BUT, when I open it, it's alert a waring tell me like
"it's not the right format of Excel, are you confirm to open it?"
I'm feel sorry to see it.
So I want to import the HTML section into a Excel file, then response the right Excel file to USER-AGENT.
I have use the Aspose.Cells library in my project, I don't know how to use it to finish the task, Or is any other solution to solve it ?
If you need to parse html tags/portion to Excel spreadsheet using Aspose.Cells for .NET, you may use Cell.HtmlString attribute to set your desired html code segment in a cell, it will be parsed accordingly in the generated Excel file. Mind you, not all the html tags are supported at the moment.
Aspose.Cells for .NET also supports to convert an Excel file to Html file directly, see the documents on which file formats are supported for conversion, it may help you for your reference:
http://www.aspose.com/documentation/.net-components/aspose.cells-for-.net/opening-files.html
http://www.aspose.com/documentation/.net-components/aspose.cells-for-.net/saving-files.html
If you still have some issue/confusion, kindly give us details with your sample code using Aspose.Cells API, we can help you.
I am developing a small excel plugin. As part of it I need to convert my excel document to PDF format. How can I do that? All the plugins and printers that I've found do not convert links created by the hyperlink function.
I know this is not programmatically related per say, but I am developing this software, and vba is quite a reasonable solution.
Thank you all very much!
I'm not sure any solution will work using the hyperlink function. The reason is typically the convert to PDF functions like a printer driver and the 'printer' only gets the helper text information not the underlying URL. But, using PrimoPDF, any text formatted like a URL "http://www.stackoverflow.com" for example, will get converted to a clickable URL (in the modern readers).
I made a discovery some time back. Just follow these steps:
Create a .doc/.xls/.ppt file in office 2003. Keep some test data in there and close the file. Now rename the file to change it's file extension to a random string, taking care that it is unassociated, like test.asdfghjkl etc.
Double click the file and it opens seamlessly in the parent application.
Now AFAIK, windows checks the file extension of the file and uses it to do an action, viz open an application and pass the file to it to open. Then how does the office suite manage to do this?
EDIT: How about the case when the extension is changed to one that is associated with another application. Is there a priority algorithm in place for handling that ?
Do you have the "View extensions for known types" option on?
EDIT: #Comments....
Yes, its a stupid/insulting question, but when troubleshooting a problem I have learned to assume nothing, and trust the users 0%.
BUT, I tried it, and you're right. Its stupid that MS has this kind of behavior, and it can only lead to security vulnerabilities, which led me on a search for your answer.
From the posts at http://seclists.org/fulldisclosure/2007/Jan/0444.html
"You have stumbled on an age-old
quirky behavior of Windows. Office
document formats are based on a
standard Windows container format, OLE
structured storage files, also known
as "docfiles". A docfile's name and
extension are irrelevant - the file
is, conceptually, a serialization of
an OLE object, and like all
serialization formats it contains the
identifier of the application that
produced it, in the form of an OLE
class id (in GUID format) in this
case. You can easily verify that it
doesn't work with the newer Office XML
formats"
Indeed it doesnt work for the 2007 *X file types, but 2K3 is still a problem. To solve this problem... Upgrade! =)
And here at security focus under TOC point 2.
So, there you go.
I can't seem to make this happen now, but I know I saw Windows reading XML processing instructions a few years back. Maybe that is what's going on?