Jul
31
2009
I had to debug an interesting error yesterday. After reading the message given to me I thought it would be easy straightforward, but after looking at the stack trace, I soon realized it was going to be a little more challenging. My first thought was that while sending out an email, we had an invalid character in the header. I’ll just find it, and write a routine to make sure that only valid characters are passed through.
According to the stack trace this error wasn’t thrown while sending an email, it was thrown while sending a file to the client. No biggie, the dev just called an existing method to make sure the value passed was clean. Granted the message is a little unclear considering we weren’t sending mail, but I can deal with that. Was bothered me more was that there was already a routine in place that was being called to strip invalid characters out, and all tests confirmed that it was working as expected. After a bit of digging I found something I never knew before. According to the RFC 2183 spec “Parameter values longer than 78 characters, or which contain non-ASCII characters, MUST be encoded as specified in [RFC 2184].” It turns out that it is very possible (and even required in some cases) that the file name have non US-ASCII characters. When this was written to the response header the .net framework threw an error. Now that I knew what was causing this an why, it was an easy fix.
public static string GetCleanedFileName(string s)
{
char[] chars = s.ToCharArray();
StringBuilder sb = new StringBuilder();
for (int index = 0; index < chars.Length; index++)
{
string encodedString = EncodeChar(chars[index]);
sb.Append(encodedString);
}
return sb.ToString();
}
private static string EncodeChar(char chr)
{
UTF8Encoding encoding = new UTF8Encoding();
StringBuilder sb = new StringBuilder();
byte[] bytes = encoding.GetBytes(chr.ToString());
for (int index = 0; index < bytes.Length; index++)
{
sb.AppendFormat("%{0}", Convert.ToString(bytes[index], 16));
}
return sb.ToString();
}