For much too long, this bug annoyed Camping.Info users with Microsoft's Edge browser. Encoding problem with non-ASCII urls When redirecting the browser to a URL such as https://www.camping.info/österreich/tirol/camping-sölden-19387 via the Location header, Edge would request this URL from our server: https://www.camping.info/österreich/tirol/camping-sölden-19387 whereas the correctly encoded version of above URL looks like this: http://www.camping.info/%C3%B6sterreich/tirol/camping-s%C3%B6lden-19387. Here are two bug reports at Microsoft that complain about this exact problem: EDGE: URLs with Unicode characters do not load and become garbled EDGE: Does not cope with UTF Location headers Using a hex editor to look at those weird characters ö I found out that those actually represent the characters with hex value C3 and B6. So, instead of percent encoding the UTF-8 representation of the character ö, Edge would use the UTF-8 hex values for ö to retrieve the given resource. That's surely a bug. How to fix this behavior The only viable fix I could come up with was to send Edge an encoded Location header value. Strictly speaking, that is how it should be done anyway but all major browsers including IE have learned to understand and correctly load even unencoded UTF-8 urls. And with IE there was always the problem that a once encoded URL would not be shown in its friendly unencoded version but would stay full of those %AB%CD blocks which look rather ugly. That's why for a long time, we've been returning unencoded Location header values in redirects. Well, Edge, you'll get an encoded version then, if you need. In a central spot, where all of our redirects are handled, we now have this:var redirectLocation = IsBrokenEdge(app.Request) ? Uri.EscapeUriString(sb.ToString()) : sb.ToString(); And we determine broken Edge version via its build number knowing that at least 14905 contains an official fix:private Regex _regexEdge = new Regex(@"Edge\/\d+\.(?'build'\d+)", RegexOptions.Compiled); private bool IsBrokenEdge(HttpRequest request) { var match = _regexEdge.Match(request.UserAgent ?? ""); if (!match.Success) return false; var buildNumber = int.Parse(match.Groups["build"].Value); // at least, build number 14905 is fixed // see: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8477507/ return buildNumber < 14905; } Thanks to http://stackoverflow.com/questions/31223702/how-to-detect-new-microsoft-browser-edge-in-asp-net for some hints on user agent detection for Edge. End of story. Happy coding!

Thanks to this stackoverflow answer I stumbled upon the comment by Aryeh Leib Taurog who shared his solution and a link to the OpenOffice documentation on the available options for the CSV filter. Here's how to convert the file input.xlsx to the UTF-8 encoded file input.csv in the current directory, with semicolons as field delimiter: soffice.exe --convert-to "csv:Text - txt - csv (StarCalc):59,,76,1" input.xlsx On my Windows system the soffice.exe is located under C:\Program Files\LibreOffice 5\program. Hre's the explanation of the cryptic filter arguments: csv – the extension of the output file Text - txt - csv (StarCalc) – the (ancient) name of the filter (kept for compatibility) 59,,76,1 – these are four arguments: the first parameter is the delimiter in the output file – 59 is the ASCII code for ';' the second parameter is the text delimiter – it's missing because I don't want to wrap text in quotes the third parameter is the file encoding – 76 is the internal OpenOffice code for UTF-8 (from the table on the documentation page) the fourth parameter defines the line number with which to start the export – here, we start with line 1 Thank you, open source community, and happy converting! PS: For non-windows users, Gnumeric with its command line tool ssconvert might be a good choice for this job, as well.