questionermaytonquestioner, мне как-то понадобилось в имена zip-архива складывать нестандартные символы (точки, двоеточия и звездочки).

Я делал их замену на $xxxx где xxxx-код символа в Unicode. И сам символ $ также был заэкранирован.
Все работает хорошо только при чтении таких архивов нужно делать обратную операцию.

Преимущества моего метода в том что таих символов мало и этот реплейсмент в общем не искажает
имена файлов и они остаются читабельными.

Выглядит как почти полный аналог UrlEncoder
Не имеет значения как это называть. Это работает.

NixicBasil A. SidorovЕсли в списке возможных символов упоминается слэш (косая черта), то это "нативный" разделитель путей и он должен быть не в имени файла, а в иерархии каталогов файловой системы.
Более того: слеш не может быть в имени файла физически :)
Почти никогда... а вот это я на всякий случай, мало ли где возможно )))
С практической точки зрения надо быть еще более тщательным в вопросах
взаимодейтсвия пользователя и файловой системы. Пользователи - дураки
по определению и "лупят" такие имена которые я лечил в свое время через
NortonUtilites, e.t.c. Особенно болеет этим линейка Windows. Вы не можете
использовать в качестве имен файлов резервированные имена такие как
NUL, CON и метасимволы *. Не можете использовать двоеточия (это разделитель streams
где хранятся ACL и иногда ЭЦП). Надо быть осторожным с case-sensitive.
NTFS позволяет сохранять разный регистр но матчинг при поиске может
быть толерантным к регистру. Поведение а-ля Паскаль. Длина пути также
может иметь ограничения. Но самая главная беда это не NTFS а прикладное
ПО которое не всегда позволяет ввести с клавиатуры какие-то символы
(из диапазона не-ASCII).

Поэтому эскейпить и еще раз эскейпить.

Длину поля можно было посчитать на этапе проектирования.

Есть кст. атака на XML/DTD основанная на развертывании entities.

Не знаю. Это к бизнесу вопрос. Нужно ли различать аббревиатуры к примеру от других слов.

Нету у меня ничего такого.