Комментарии 7
Принципиально переименовываю всю кириллицу в латиницу ещё с нулевых... И всем советую. Выходит не всегда но хотя бы в работе с кодом и в части случаев... На крайний случай экранировать / придумать костыль. И судя по этой статье - не зря...
Действительно описанный выше способ помог бы не столкнуться с этим вопросом)
В нашем случае файлы грузят пользователи - они должны оставаться в неизменном виде, сделать их с латинскими буквами не можем :(
А что мешает сделать базу данных, прикрутить тот же мускуль лайт и уже от него плясать? Вместо мускуля подойдёт любое kv хранилище. Сохранять оригинальное имя и заливать под новым экранированным? Или вам прямо физически важно имя?
Имя важно.
И прикручивать базу данных, добавлять новые точки отказа, всё это администрировать явно сложнее выглядит чем написать одну строчку с (quote_fields=False)
Дык локально. Mysql lite. Там администрировать ничего толком и не надо и добавится от силы 5-10 строк в зависимости от вашего яп - все свое с собой.
Ваш способ работает - спору нет. Однако можете ли вы гарантировать что при переезде на другой стек / машину / связку софта итд итп ничего не сломается из за кодировки? Как вы выяснили, даже в нынешнее время все ещё бывают приколы с кириллицей...
Извините, что так поздно, но одна точка отказа уже существует в вашей статье. Никто в продакшене не заливает файлы пользователей в том виде, в котором они есть.
Да, имя важно, и поэтому если внезапно на сервере с файлом окажется обработчик PHP, а файл зальют .php, то ни к чему хорошему это не приведет.
Особенности работы с русской кодировкой при загрузке файлов через aiohttp