Текст, упаковывающий алгоритм
В итоге я решил не обрабатывать шифрование SSL в каждом отдельном приложении. Но вместо этого я изменил обратный прокси-сервер на
version: '3.6'
services:
nginx-proxy:
image: jwilder/nginx-proxy:alpine
container_name: nginx_proxy
ports:
- '80:80'
- '443:443'
volumes:
- ./certs:/etc/nginx/certs
- /var/run/docker.sock:/tmp/docker.sock:ro
restart: unless-stopped
networks:
default:
external:
name: nginx-proxy
Так что теперь я могу обращаться к каждому приложению на порту 80, пока не добавлю сертификат для него, и в этом случае оно станет доступным на порту 443.
8 ответов
Это самая короткая задача суперстроки : найти самую короткую строку, содержащую набор заданных строк как подстрок. Согласно этой статье IEEE (к которой у вас, к сожалению, может не быть доступа), точное решение этой проблемы является NP-полным . Однако доступны эвристические решения.
В качестве первого шага, вы должны найти все строки, которые являются подстроками других строк, и удалить их (конечно, вам все равно нужно каким-то образом записать их позиции относительно содержащихся строк). Эти полностью содержащиеся строки могут быть эффективно найдены с помощью обобщенного суффиксного дерева .
Затем, многократно объединяя две строки, имеющие наибольшее перекрытие, вы гарантированно получите решение, длина которого не хуже 4 раз минимально возможную длину. Должно быть возможно быстро найти размеры перекрытия, используя два дерева счисления, как это было предложено в комментарии Зифре к ответу Конрада Рудольфа . Или вы могли бы каким-то образом использовать обобщенное суффиксное дерево.
Извините, я не могу найти для вас подходящую ссылку - похоже, страницы в Википедии нет, или любую общедоступную информацию по этой конкретной проблеме. Это кратко упоминается здесь , хотя никаких предлагаемых решений не предоставляется.
Я думаю, вы можете использовать Radix Tree . Это требует некоторой памяти из-за указателей на листы и родительские элементы, но легко сопоставить строки (O (k) (где k - самый длинный размер строки).
Моя первая мысль: используйте структуру данных для определения общих префиксов и суффиксов ваших строк. Затем отсортируйте рассматриваемые слова по этим префиксам и постфиксам. В результате получится желаемый рэгдолл-хаус .
Похоже на задачу о ранце , которая является NP- полная, поэтому нет "окончательного" алгоритма.
Это то, что меня всегда раздражало. Если вы инициализируете int шестнадцатеричным литералом, вы можете использовать полный диапазон положительных значений до 0xFFFFFF ; все, что больше 0x7FFFFF , действительно будет отрицательным значением. Это очень удобно для битовой маскировки и других операций, когда вас интересуют только местоположения битов, а не их значения.
Но если вы используете Integer.parseInt () для преобразования строки в целое число , все, что больше «0x7FFFFFFF» , рассматривается как ошибка. Вероятно, есть веская причина, по которой они так поступили, но это все еще разочаровывает.
Простейший обходной путь - использовать вместо этого Long.parseLong (), а затем преобразовать результат в int.
int n = (int)Long.parseLong(s, 16);
Конечно,
Чтобы вернуть исходный текст, вы выполняете (1) декодирование Хаффмана, (2) обратную MTF, а затем (3) обратную BWT. Обо всем этом есть несколько хороших ресурсов в Интернете.
Уточнить шаг 3.
- Просмотрите текущий список и посмотрите, начинается ли какое-либо слово в списке с суффикс текущего слова. (Вы можете захотеть, чтобы суффикс был длиннее некоторой длины - например, длиннее 1.)
- Если да, то добавьте отдельный префикс к этому слову в качестве префикса к существующему слову и соответствующим образом скорректируйте все существующие ссылки ( медленно!)
- Если нет, добавьте слово в конец списка, как на текущем шаге 3.
Это даст вам 'ragdollhouse' в качестве сохраненных данных в вашем примере.
Непонятно, что вы хотите сделать.
Сделайте вам нужна структура данных, которая позволяет хранить строки с учетом памяти, позволяя при этом выполнять такие операции, как поиск, в разумные сроки?
Вам просто нужен сжатый массив слов?
В первом случае вы можете использовать patricia trie или String B-Tree.
Во втором случае вы можете просто применить некоторую технику сжатия индексов, например:
Если у вас есть что-то вроде:
aaa
aaab
aasd
abaco
abad
You можно сжать следующим образом:
0aaa
3b
2sd
1baco
2ad
Число - это длина наибольшего общего префикса с предыдущей строкой. Вы можете настроить эту схему, например. планирование «перезапуска» общего префикса после всего K слов для быстрой реконструкции
Я бы не стал изобретать это колесо еще раз. На создание алгоритмов сжатия уже потрачено огромное количество рабочей силы, почему бы не воспользоваться одним из уже имеющихся?
Вот несколько хороших вариантов:
- gzip для быстрой скорости сжатия / распаковки
- bzip2 для горького сжатия, но гораздо более медленной декомпрессии
- LZMA для очень высокой степени сжатия и быстрой распаковки (быстрее, чем bzip2, но медленнее, чем gzip)
- lzop для очень быстрого сжатия / распаковки
Если вы используете Java, gzip уже интегрирован .