Operating under the name DownloadZipFile, my service compiles data and constructs a Zip file for easy downloading. This particular service provides a response that contains the stream leading to the file.
A Glimpse of the Service:
[HttpPost]
public ActionResult DownloadZipFile(string zipData)
{
try
{
// Create the Zip File.
using (MemoryStream zipStream = DownloadHelper.BuildZipFileData(zipData))
{
// Construct the response with the file.
HttpContext.Response.ClearContent();
HttpContext.Response.ClearHeaders();
HttpContext.Response.Clear();
HttpContext.Response.Buffer = true;
HttpContext.Response.ContentType = "application/zip";
HttpContext.Response.AddHeader("Content-Disposition", "attachment; filename=MyZipFile.zip;");
HttpContext.Response.BinaryWrite(zipStream.ToArray());
HttpContext.Response.End();
}
}
catch (Exception e)
{
// Log any errors encountered.
_logService.Error(LogHelper.GetWebRequestInfo(ControllerContext.HttpContext.Request), e);
}
}
The download and opening of the zip file occurs seamlessly when employing this service in the following manner:
Call to the Service #1
var form = $("<form></form>").attr('action', "DownloadZipFile").attr("method", "post");
form.append($("<input></input>").attr("type", "hidden").attr("name", "zipData").attr('value', escape(JSON.stringify(zipData))));
form.appendTo('body').submit().remove();
However, utilizing an AJAX Post call yields larger file sizes than expected when converting the response to a blob.
Engage the Service with Call #2:
$.post("DownloadZipFile", { zipData: escape(JSON.stringify(zipData)) },
function (data, status, response) {
var filename = "";
var disposition = response.getResponseHeader('Content-Disposition');
if (disposition && disposition.indexOf('attachment') !== -1) {
var filenameRegex = /filename[^;=\n]*=((['"]).*?\2|[^;\n]*)/;
var matches = filenameRegex.exec(disposition);
if (matches != null && matches[1]) filename = matches[1].replace(/['"]/g, '');
}
var type = response.getResponseHeader('Content-Type');
var blob = new Blob([data], { type: type });
if (typeof window.navigator.msSaveBlob !== 'undefined') {
window.navigator.msSaveBlob(blob, filename);
} else {
var URL = window.URL || window.webkitURL;
var downloadUrl = URL.createObjectURL(blob);
if (filename) {
var a = document.createElement("a");
if (typeof a.download === 'undefined') {
window.location = downloadUrl;
} else {
a.href = downloadUrl;
a.download = filename;
document.body.appendChild(a);
a.click();
}
} else {
window.location = downloadUrl;
}
}
});
Despite externing Service Call #2, the generated Zip File arrives corrupted.
Could it be due to encoding discrepancies? A comparison between the correct and erroneous Zip Files display distinct patterns:
Intact Zip:
PK ú‚ÐJmÇ´¸g € BOM.csvu‘ËNÃ0E÷HüÃÈ+ÆÑØy/›”WÔðH[Ä64IÕ¦| >‰_ÀN(-¢l®,Ýã;wìÏ÷‡m^Ö³ú 35VkUŽtÕf6)óºZcZjqz"0dÒ³ü9TÓ%yd#ˆ3Ö˜R›¡kÙMYæt2'Òâ¦É½dÈhO¶"BXÁ?ùÚ”Ç<‰,ÖÍ ‘ååÎé ÁÝ!Ò ²AˆVG ]3
Malfunctioning Zip:
PK ￿￿￿g ￿ BOM.csvu￿￿￿E￿￿+￿￿/￿￿W￿H[￿4Iզ| >￿_￿(-￿l￿,￿;w￿￿￿m^ֳ￿kU￿t￿6)￿Zjqz"0dҳ￿yd#￿3֘R￿￿k￿MY￿2'￿￿ɽd￿O￿"BX￿￿￿,￿ ￿￿￿￿￿￿￿A￿VG ]3
Evidently, the files have undergone differing forms of encoding. How should we approach this dilemma?