Sencha’s premium grid exporter has a bugs I’ve spent some time working around with little result in the final bug.
When exporting a file using a Safari, the exporter has to send to a server backend to convert the blog to utf8, set the proper header attributes and return that response to the browser prior to Safari being able to open the save dialog to save either Excel, HTML or CSV.
Sencha does a good job providing server side solutions for either PHP or Node.js backends. Nothing for a C# backend.
I’ve been able to get CSV and HTML files to work correctly using a C# backend; but have yet to find a solution for Excel files. The code below works for both CSV and HTML
string content = ""; var base64 = System.Convert.FromBase64String(Request.Form["content"]); content = Encoding.UTF8.GetString(base64); string mimetype = Request.Form["mime"]; string filename = "attachment; filename=\"" + Request.Form["filename"] + "\""; Response.Charset = Request.Form["charset"]; Response.ContentType = mimetype; Response.AppendHeader("Pragma", "public"); Response.AppendHeader("Cache-Control", "must-revalidate, post-check=0, pre-check=0"); Response.AppendHeader("Cache-Control", "public"); Response.AppendHeader("Content-Description", "File Transfer"); Response.AppendHeader("Content-Disposition", filename); Response.AppendHeader("content-Transfer-Encoding", "binary"); Response.AppendHeader("Content-Length", content.Length.ToString()); Response.Flush(); Response.Write(content);
The problem is converting to Excel. Using the above method to convert this type of file, the content returned looks like an Excel file code to a truncated point. The entire file is not converted and generates a damaged Excel file that cannot be fixed.
We don’t have PHP on our IIS, Windows server so I wasn’t able to test the PHP example provided by Sencha in the exporter plugin directory.
However I was able to implement the Node.js server example provided by Sencha with some minor modifications for things we require in our products for logging and catching errors. Other than those changes it was quite simple to drop into our Node.js server, modify the plugin url attribute to send those requests to our server; getting the expected returned results. Until it was tested in Firefox, whereby the currently unsolved problem still exists.
When an Excel file is returned, the mime type is set to application/octet-stream. It would seem like a straight forward solution until reading the documentation from MDN library.
* application/octet-stream is the default value for all other cases. An unknown file type should use this type. Browsers play a particular care when manipulating these files, attempting to safeguard the user to prevent dangerous behaviors. * .xlxs Excel Document should have mime-type application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Mozilla treats octet-stream as an unsafe/unknown file type and appends the .zip extension to the download results. This happens, the user doesn’t see what is happening and then finds they have a corrupt zip file they cannot open. Changing the extension from .zip to .xlsx allows them to open the file with Excel, they can even change it during the save process and open an Excel file. So the file is a properly formatted Excel file.
We all know as developers we will get tons of calls even after educating users to change the extension from .zip to .xlsx. Although we can get frustrated with these types of calls, the user is right; if we are returning them an Excel file they shouldn’t have to remember to change the file extension prior to or after saving in order to be able to open the file.
This issue is isolated to Firefox as Chrome, Edge (Chrome based), and Safari all append the .xlsx extension even with the mime type of application/octet-stream.
When the file is sent we have some attributes where we can attempt to catch the Excel file export and set the correct mime type when we return the file. Unfortunately these are not solid enough to know they will in fact remain the same with a future update to the Grid Exporter plugin.
- mime-type – sent as application/zip to the backend when the file is an Excel conversion
- charset – sent as ASCII to the backend when the file is an Excel conversion
Either one of these could be subject to change during a future update.
This is a work around that frankly I am not too sure how well it will work due to upgrades in the future. Already we modify the plugin to set the url to our web server from https://exporter.sencha.com. This means documentation will need to be in place when upgrading the plugin, another in a long check list to make sure a plugin upgrade doesn’t bring down our code processing and cause users issues as it did when these bugs were discovered.
Unfortunately currently there isn’t anything else to work around this issue with. Code will have to be modified, check the mime type or charset, possibly both and then set the returned mime type to
This is the mime-type Mozilla Firefox is expecting when receiving an Excel file. Yes, there is the counterpart for older Excel files, although there shouldn’t be too many out there using Excel versions that old.
Of course even this solution of modifying code on the Node.js solution is subject to breaking when the next update to the Sencha Grid Exporter is released. A modification that unfortunately could bring bugs and breaking errors once updated, exposed to our users due to our missing something in the update release cycle to users.