Hacker News new | past | comments | ask | show | jobs | submit login

"Bad" characters in this context is control characters. So no, it would not affect internationalization at all.

> "Bad" characters in this context is control characters.

For sufficiently narrow definitions of "bad", sure.

It is probably a bad idea to allow mixed character-set filenames, as that allows homograph attacks[0], and there are other non-control characters like the zero-width space and it's brethren that should be disallowed across the board.

In English you probably also want to disallow ligature characters like fi, ffl.[1]

There are other "good idea" limitations that may affect internationalization of various languages (not in terms of making it difficult, just constraining it, as in the above English ligature example).

For example, it is probably a good idea to disallow Hebrew diacritic symbols[2] like niqqud in filenames.

[0] https://en.wikipedia.org/wiki/IDN_homograph_attack

[1] https://en.wikipedia.org/wiki/Typographic_ligature#Ligatures...

[2] https://en.wikipedia.org/wiki/Hebrew_diacritics

> It is probably a bad idea to allow mixed character-set filenames

As someone who would be affected by this directly, I can tell you right away this rule would be a no-go. I plainly need the ability to mix Latin and Cyrillic characters in my filenames. A filesystem or OS that wouldn't let me do so wouldn't even be considered.

A very simple rule of thumb is, if it is a title of a book (or a song, or a film etc), it should also be a valid filename.

Interesting. Are those filenames used in contexts where homographs could be more than a minor annoyance?

BTW, whether a character is or isn't a homograph depends very much on the font. For example, Cyrillic letter 'и' has no obvious visual counterpart in Latin... but as soon as you use cursive, it becomes 'и'. Which is visually indistinguishable from cursive 'u': 'u'.

Same thing with the letter 'т': in cursive, it becomes 'т', which in many (but not all) fonts looks the same as cursive 'm'.

I guess? If a malicious attacker could gain access to my FS and create homographs, figuring out which is which while browsing the filesystem would be non-trivial.

But I find it an unlikely attack vector to begin with. The main concern with homographs is in URLs and other external resources.

I guess I am thinking of contexts like uploaded files, or shared network drives.

I missed the portion where that was said. I read through all of the comments about this and replied to the last one thinking we were still talking about things like spaces and newlines. My comment would have been better placed as a reply elsewhere. Sorry about that.

Still though, even if we only block some control characters, doing so could lead to problems with future character encodings.

Personally I hope UTF-8 / UTF-16 / UTF-32 is the final set of character encodings but we can't know that it will be.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact