Не имеет значения, если система это принципиально позволяет — надо поддерживать.

Вообще, в именах папок слеш запрещён. А точка нет!

Нет таких регулярок которые "как везде", есть два основных направления — PCRE и LPEG и ещё несколько. Луёвые похожи на PCRE и реализуют большую часть их функционала.

Тут есть очень много правил, и у разных ОС разные. Например под вендой запрещены имена для файлов и папок COM и ещё несколько других, потому что это резервные имена. Блин, просто открываешь RFC венды/линекса и делаешь по ним. А потом адаптируешь. ... Или берёшь готовую либу, где это сделали за тебя и для тебя.

Берёшь и вставляешь содержимое библиотеки себе в файл со скриптом, или только нужную его часть. Но вообще лучше отдельно.

А что такого? Использовав библиотеку я просто буду использовать её api. А сделав сам с нуля я пойму как это работает изнутри.

И так очевидно как оно работает. Берёт и типично потрошит строчки учитывая всякие мелкие хернюшки конкретных ос. Ничему не научишься, и тем более не поймёшь почему пока не начнёшь всё прогугливать. Тупа унылый бойлерплейт.

Ладно )

Он умеет только енглиш

Базовый вариант — local utf8 = require'utf8' function utf8.sub(self, a, b) a = a and utf8.offset(self, a) b = b and utf8.offset(self, b + 1) a = a or 1; b = b and b - 1 or #self return self:sub(a, b) end

Через os.execute разумеется.

Базовый вариант — local utf8 = require'utf8' function utf8.sub(self, a, b) a = a and utf8.offset(self, a) b = b and utf8.offset(self, b + 1) a = a or 1; b = b and b - 1 or #self return self:sub(a, b) end

io.popen

в луа сырые строки? O_o

Не строки а байты. Да. И это во многом прекрасно.

Карочи, для начала у тебя есть start/fork для os.execute/io.popen.

хотя я встречал некую странную реализацию, где строки обрабатывались как GB2312, при этом все эти функции понимали многобайтные чары

Можно переопределить стандартную библиотеку string на работу с любой кодировкой. Но потеряется работа с байтами, увы.

У меня на работе луа работает стандартными регулярками с 1251. Оно конечно однобайтное, но в регулярках шаблоны тянут кириллицу. Это кек.

хотя я встречал некую странную реализацию, где строки обрабатывались как GB2312, при этом все эти функции понимали многобайтные чары

1251 ещё не вымер

Он всё ещё крайне удобен в куче мест, и за счёт однобайтности с ним крайне высокая скорость работы. Как с ascii.

Когда ты делаешь базу данных в utf32, тебя убьёт начальник за сжирание всего места )

На самом деле не важно. Юникод тянет за собой огро-о-о-омный пласт своих юникодных проблем, о которых ты даже не услышишь не работая с ним плотно. А на моей работе норм и 1251, вообще пофигу, всё что надо влезает, проблем нет. Наружу в utf8.

Это только одна из проблем.

Другая проблема — композиция-декомпозиция, нормализация, попытки реверснуть комбинированные символы автоматически приводят к писосу, ещё много чего.

полная поддержка юникода нужна далеко не везде :)

Например, ты пишешь бота для телеги и хочешь фильтровать спам с сайтами. Пишешь регулярку. ОПАЧКИ СПАМЕР ЗАМЕНИЛ ТОЧКУ НА ПОХОЖУЮ ТОЧКУ ИЗ ДРУГОГО ЯЗЫКА и твой бот обсирается, потому что не умеет нормализовывать. А браузер её автоматом заменяет на нормальную и переходит куда надо спамеру.

Не, это называется украсть код

Урлы сейчас легко состоят из юникода.

Карочи, это дичайше тёмная тема. В неё без подготовки не лезть.