The requirement that you've written doesn't have the characteristics of a good requirement. Specifically, it's not cohesive, it's not atomic, and it's not unambiguous. Because of the lack of these characteristics, it's also not easily verifiable.
Your initial state requirement is:
The downloaded file name may contain non-ASCII characters and processing of this shall not crash the application
I would recommend removing the "...and processing of this shall not crash the application". If you have a requirement that a piece of software needs to do something, I think it's OK to make the assumption that it should do it without crashing the software.
This transforms the requirement into:
The downloaded file name may contain non-ASCII characters
Now, you have a cohesive and atomic requirement. However, I'm not sure that it's unambiguous. In your question, you mention a number of different formats. There are a few options.
Some would recommend a separate and unique requirement for each file name encoding that must be supported. This would best support cohesive, atomic, traceable, unambiguous, and verifiable requirements. It would also make it easier to specify importance of each requirement - perhaps support for some encodings are more important or needed sooner.
Others may recommend a table of supported formats and this requirement would link to a table. It would be less complete (you have a textual sentence and a table to be maintained), but they would be in the same document or database. However, if you were going to perform linking in a requirements management tool, they could be linked together so that changes to one would highlight the linked requirement. It would also allow the text to flow to other software packages as is, but with a different table for different encodings.
How you document the requirements does depend on your specific needs, though.