Насколько я проверил в Firefox 20 и Chrome 26 под Ubuntu — обещанную конвертацию браузеры не делают.
На входе в форме имею: <input id="search_char" name="search[char]" value="º" type="hidden">
При передаче контроллеру в логах получается: Started POST "/ru/searches" for 127.0.0.1 at 2013-06-28 08:54:23 +0300
Processing by SearchesController#create as HTML
Parameters: {"utf8"=>"✓", "search"=>{"query"=>"bla-bla-bla", "char"=>"º"}}
Потратил на внедрение этого псевдоспособа 40 минут, надеюсь, этот пост кому-то сэкономит время. Либо я узнаю в чем ошибся :)
Для тех, кому приходится архивировать сотни гигабайт
Пробовал использовать WinRar для бэкапа общего сетевого диска (RAID10) — порядка 400 ГБ. Получался архив около 300 ГБ, при попытке открыть его WinRar сдулся с ошибкой «недостаточно системных ресурсов». Причем, на разных серваках. Видимо, неоптимальная работа с памятью. Степень сжатия была и 1, и 0.
Попробовал 7zip — работает без проблем. Для файловой помойки в Windows этот архиватор однозначно рулит. Исходный архив открывался очень быстро и без проблем. Вот пример простого батника, который, на мой взгляд, оптимально решает данную задачу: "C:\Program Files\7-Zip\7z.exe" u -ssw -mx0 -mmt2 -ms=off -r e:\m_backup.7z @"c:\m_listbackup.txt" >> c:\m_backup_%date%.log
Тип архива 7zip определяет по расширению результирующего файла бэкапа. u — поскольку архивный бит 7zip не понимает, пришлось делать просто обновление основного архива. -ssw — как и написано выше, открываем открытые другими программами файлы -mx0 — поскольку на диске куча pdf, jpg и т.д., то сжатие дает только 4% экономии. нерациональное соотношение место_на_диске/процессорное_время. -mmt2 — использовать два потока. думаю, пригодится при обновлении архива. -ms=off — по дефолту создаются solid-архивы. отключаем ибо они работают медленнее. возможно, для mx0 — некритично, но для mx1 и т.д. — оптимальнее. -r — рекурсивно обрабатывать поддиректории. e:\m_backup.7z — результирующий файл архива @«c:\m_listbackup.txt» — файл в UTF8 с папками, которые следует архивить. >> c:\m_backup_%date%.log — выводим результаты в лог с датой.
К сожалению, сохранять права доступа к файлам 7zip тоже не умеет.
Подчеркиваю, данные настройки оптимальны для достаточно больших объемов. Когда важно, чтобы просто с бэкапом можно было работать быстро и просто работать — извлекать отдельные файлы, лазить по папкам. Имхо — это основной плюс такой «кустарной» архивации.
На входе в форме имею:
<input id="search_char" name="search[char]" value="º" type="hidden">При передаче контроллеру в логах получается:
Started POST "/ru/searches" for 127.0.0.1 at 2013-06-28 08:54:23 +0300 Processing by SearchesController#create as HTML Parameters: {"utf8"=>"✓", "search"=>{"query"=>"bla-bla-bla", "char"=>"º"}}Потратил на внедрение этого псевдоспособа 40 минут, надеюсь, этот пост кому-то сэкономит время. Либо я узнаю в чем ошибся :)
Пробовал использовать WinRar для бэкапа общего сетевого диска (RAID10) — порядка 400 ГБ. Получался архив около 300 ГБ, при попытке открыть его WinRar сдулся с ошибкой «недостаточно системных ресурсов». Причем, на разных серваках. Видимо, неоптимальная работа с памятью. Степень сжатия была и 1, и 0.
Попробовал 7zip — работает без проблем. Для файловой помойки в Windows этот архиватор однозначно рулит. Исходный архив открывался очень быстро и без проблем. Вот пример простого батника, который, на мой взгляд, оптимально решает данную задачу:
"C:\Program Files\7-Zip\7z.exe" u -ssw -mx0 -mmt2 -ms=off -r e:\m_backup.7z @"c:\m_listbackup.txt" >> c:\m_backup_%date%.logТип архива 7zip определяет по расширению результирующего файла бэкапа.
u — поскольку архивный бит 7zip не понимает, пришлось делать просто обновление основного архива.
-ssw — как и написано выше, открываем открытые другими программами файлы
-mx0 — поскольку на диске куча pdf, jpg и т.д., то сжатие дает только 4% экономии. нерациональное соотношение место_на_диске/процессорное_время.
-mmt2 — использовать два потока. думаю, пригодится при обновлении архива.
-ms=off — по дефолту создаются solid-архивы. отключаем ибо они работают медленнее. возможно, для mx0 — некритично, но для mx1 и т.д. — оптимальнее.
-r — рекурсивно обрабатывать поддиректории.
e:\m_backup.7z — результирующий файл архива
@«c:\m_listbackup.txt» — файл в UTF8 с папками, которые следует архивить.
>> c:\m_backup_%date%.log — выводим результаты в лог с датой.
К сожалению, сохранять права доступа к файлам 7zip тоже не умеет.
Подчеркиваю, данные настройки оптимальны для достаточно больших объемов. Когда важно, чтобы просто с бэкапом можно было работать быстро и просто работать — извлекать отдельные файлы, лазить по папкам. Имхо — это основной плюс такой «кустарной» архивации.