1

In an MVC application I have an action that exports data to CSV files. The code looks like this:

public ActionResult CSV(int id)
{
    var model = GetRaportData(id); // Gets the data that will be exported
    var cd = new System.Net.Mime.ContentDisposition
    {
        FileName = model.Raport.Name + ".csv",
        Inline = false,
    };
    Response.AppendHeader("Content-Disposition", cd.ToString());
    // The contents of the CSV file are rendered via a view
    var csv = ViewToString.RenderRazorViewToString(ControllerContext, "_CSV", model);
    // To make the CSV file compatible with encoding in Excel
    // the file is reencoded in Ansi 1250
    return File(csv.ToAnsi1250(), "text/plain");
}

I presume the problem is related to this piece of code:

var cd = new System.Net.Mime.ContentDisposition
{
    FileName = model.Raport.Name + ".csv",
    Inline = false,
};
Response.AppendHeader("Content-Disposition", cd.ToString());

Whenever I try to save a file that has UTF-8 characters (namely polish characters) in the name and the file name has certain length (or more), this "%0d%0a" string will show up in the name of the saved file at some point.

For instance:

Ę This file has a very long name Lorem Ipsum Lorem Ipsum.csv

becomes

Ę This file has a very long name Lorem Ip%0d%0a sum Lorem Ipsum.csv

It doesn't appear to matter where the UTF-8 character is located, what character it is or how many of them are there.

If there are no UTF-8 characters in the name or the name is relatively short, "%0d%0a" will not appear in the saved file name.

Anyone got a clue why does this happen and\or how to fix it?


Edit: If I name my file:

ABThis file has a very long name Lorem Ipsum Lorem Ipsum.csv

the problem will not occur.

I could possibly remove UTF-8 characters by replacing them with basic latin ones, but I would rather try to fix the problem, than use a workaround.


As suggested by Ricardo Momm, I tested the problem in a different browser (the description above describes how it looked in FireFox). In Chrome, the files that would get "%0d%0a" injected in their name in FireFox, just get renamed to "16" with no extension.

Edit: The "16" came from url that was leading to the file (something like http://someaddress/CSV/16), so it appears Chrome was ignoring the name completely.

jahu
  • 5,427
  • 3
  • 37
  • 64
  • Have you tried whether the same issue occurs when there are *no* non-ASCII characters, and just a file name of such a great length? I'm wondering because `%0d%0a` looks like something based on a linebreak, and if something inserts a linebreak, it probably does so regardless of whether there are any special Polish accented characters around or not. – O. R. Mapper Feb 18 '14 at 10:52
  • Yes I did and I even wrote that in the question. If there are no UTF-8 characters the name is fine. – jahu Feb 18 '14 at 10:54
  • 1
    Is this happening in all browsers? – Ricardo Momm Feb 18 '14 at 11:09
  • Thanks for the tip Ricardo Momm. That was what was happening in Firefox. In Chrome the result is even more strange, rather than injecting “%0d%0a” in the name, Chrome just renames the file to "16" (though it appears to happen under the same conditions: specific length and UTF-8 characters). – jahu Feb 18 '14 at 11:16
  • Can you post the cd.ToString() content? Had you tried to set the Response.HeaderEncoding property? – Ricardo Momm Feb 18 '14 at 11:28
  • I set the HeaderEncoding to UTF8, but it didn't help. I'll try posting cd.ToString() content later, but for now I'll just get rid of UTF-8 characters. – jahu Feb 18 '14 at 11:51
  • Apparently it is a known bug as mentioned in this post https://stackoverflow.com/a/5830215. – jahu Jul 31 '17 at 11:36

1 Answers1

0

I haven't found the source of the problem nor a proper solution, but something had to be done, so I settled for removing polish (UTF-8) characters. I did that using Normalize function.

In relation to my code above:

var cd = new System.Net.Mime.ContentDisposition
{
    FileName = model.Raport.Name.Normalize(NormalizationForm.FormD) + ".csv",
    Inline = false,
};
jahu
  • 5,427
  • 3
  • 37
  • 64