If you're talking about getting content out of Awasu via a report, yes, it will be UTF-8. But how are you then getting it into SQL Server? The easiest would would probably to take the UTF-8 report and convert it into something SQL Server can handle before importing it.

As an aside, I'm completely astounded that SQL Server doesn't support UTF-8. When I read your post, my first thought "nah, he must be mistaken" but a bit of research suggests that you're right

BTW, when you say "D0%B5%D0%BA%D1%81%D0%", do you mean you're seeing these exact characters (with %'s) or do you mean binary bytes? Wouldn't these be the UTF8-encoded Cyrillic characters you're expecting to see? What are you using to look at the generated output?

I created a feed with some Cyrillic text in the item title, description and URL, then generated a report using your template, with an output file with a .TXT extension. The output was generated using UTF-8, and after I told IE to interpret it as UTF-8, everything displayed correctly.

Can you send me an example of one of your output files, and what you're expecting it to contain.

Just as background information, Awasu always encodes everything it outputs as UTF-8 since I figured (incorrectly, as it turns out - thanks Microsoft ) that everyone understands UTF-8. It doesn't check whether it's outputing item titles, descriptions, URL's, etc. - everything gets UTF8'ed. Awasu was written long before internationalized domain names came out and quite frankly, the whole idea gives me the screaming heebie-jeebies If you really are having to deal with internationalized URL's, I think your best bet would be to take the UTF-8 output generated by Awasu, then run a post-processing step (which you're doing anyway) to encode the URL's appropriately. I had a quick look at the IDNA spec and it's definitely not UTF-8. It looks horrendous... But depending on your circumstances, it may not be necessary to encode it like this, UTF-16 might be enough.