Jestem pewien, że większość z nas słyszała o bombach zip i podobnych sztuczkach z bombami dekompresyjnymi, w których złośliwie spreparowane dane wejściowe generują masowo nieproporcjonalne wyniki. W pewnym momencie mieliśmy nawet pytanie, aby zrobić to z kompilatorem.
Cóż, przychodzi mi do głowy, że Markdown jest rodzajem formatu kompresji, zastępując nieporęczne tagi HTML „skompresowanymi” tokenami MD. Czy zatem można zbudować bombę kompresyjną w Markdown?
Zasady konkursu:
Zgłoszenie powinno być fragmentem tekstu promocyjnego o długości od 50 do 256 znaków. (Nakładając minimum, aby uniknąć mądrego alecku publikującego odpowiedź złożoną z 3 znaków lub podobną).
Zgłoszenie zostanie przetworzone przez procesor Markdown stosowany przez StackExchange zaimplementowany w tej witrynie.
Twój wynik będzie stosunkiem liczby znaków w wynikowym HTML do liczby znaków w tekście Markdown.
Najwyższy wynik wygrywa.
źródło
Odpowiedzi:
Cytaty blokowe, 137 469/256 = 536,99
6 908 znaków, 511 nowych wierszy, 130 050 spacji
Markdown z pewnością obsługuje dziwnie zagnieżdżone cytaty blokowe. Każda
>
postać zamienia się w<blockquote></blockquote>
tak solidny stosunek 1 do 25. Ale poczekaj! Podczas renderowania HTML dodaje także dwie spacje na zagnieżdżenie! Ta próba renderowania wywołuje w mojej przeglądarce smutek i na razie będę go trzymał w klatce. Możesz go odblokować samodzielnie!Kod wejściowy składa się z 255,
>
po którym następuje&
ostatni znak, który się nie transformuje, ale jest usuwany. Dzięki BWO!
jako ostatni znak, który podaje ostatni cytat blokowy, spoiler z pustym znacznikiem p w środku. Dzięki bta, 11 dodatkowych znakówWejście:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>!
Wyjściowy HTML:
Oto jak to wygląda w widoku edytora!
Wykreślenie wyników jako liczby
>
wzrostu zgodnie z sugestią LambdaBeta:źródło
!
przed znakiem ampersand, do ostatniego poziomu cytatu zostanie dodany `class =" spoiler "`. Dodaj go do dowolnego innego poziomu, ale skróci to wyjście.MathJax, 529 252 640 ish / 256 ≈ 2 067 393
Dobry stary kod w stylu tysiąca śmiechu
$$\def\a{🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣}\def\b{\a\a\a\a\a\a\a\a\a\a\a\a\a}\def\c{\b\b\b\b\b\b\b\b\b\b\b}\def\d{\c\c\c\c\c\c\c\c}\d\d\d\d\d\d\d\d$$
pomnaża całkowitą nieefektywność reprezentowania egzotycznych postaci w MathJax przez znaczny czynnik.
Ograniczenie konfiguracji StackExchange MathJax wynoszące 10 Uwzględniono 000 rozszerzeń makr, podczas gdy ograniczenia przeglądarki klienta, które mogą powodować problemy z rozszerzaniem makr, nie są przestrzegane. (Moja przeglądarka również nie współpracuje, więc jest to wartość szacunkowa).
źródło
Stenogramy: 68 960/256 = 269,375
Tylko ASCII: 10 114/256 = 39 508
Dane wyjściowe to sekwencja elementów, które wyglądają następująco:
Po ustalonym narzucie na tworzenie odwołania do adresu URL, każde 5-znakowe łącze rozwija się do
42+strlen(url)
postaci wyjściowej. Utwórz URL, aby mieć maksymalną liczbę znaków, które wymagają ucieczki, a liczba ta rośnie do liczby47+3*strlen(url)
znaków na link. Trochę eksperymentów wykazało, że optymalna wydajność obejmowała 26 linków, z 114 karetkami na link.Aktualizacja : Jeśli interpretujesz limit „256 znaków”, aby uwzględnić znaki Unicode, możesz wycisnąć więcej chaosu. Zastąpienie karetek znakiem wanny Unicode (🛁, codepoint U + 1F6C1) daje w
47+18*strlen(url)
wyniku znaki wyjściowe na znak wejściowy, co daje w sumie5457468960 (dzięki jeszcze krótszej notacji linków jimmy23013).Wejście Unicode:
Dane wyjściowe to seria:
źródło
[1],[1],[1]...
dla linków. 2."
ma więcej znaków niż%5E
w wersji innej niż Unicode.15888/50 = 317,76: Nadużycie MathJaX
To jest kod:
Tak to wygląda:
i i i i i i i i i
Wynikowy kod HTML to:
Nie zapomnij swoich ludzi MathJax.
Uwaga: MathJaX pokazuje błąd tylko podczas edycji, więc musisz go wyświetlić w edytorze. To wciąż implementacja obniżki cen na tej stronie, więc powinna być poprawna. Po opublikowaniu
Misplaced &
ostrzeżenia zmieniają się w normalne &.źródło
Podświetlanie składni,
63766464/256 ≈ 25,25+0,33375 dzięki Ismaelowi Miguelowi (użycie tabulacji zamiast 4 spacji)!
Wykorzystuje to najkrótszą (niestety spacje wydają się mieć znaczenie), aby uzyskać wyróżnianie składni
lang-c
, otwiera blok kodu i wypełnia go&
oraz0
:Zaczynamy od,
&
ponieważ rozwija się&
i używa0
dalej, naprzemiennie tworzy stale nowe<span>
elementy zclass
atrybutem. Niestety nie możemy używać tylko&
lub&<&<...
ponieważ pozostają one takie samepun
-<div>
Produkuje:
Wyrenderowany przez przeglądarkę powoduje:
źródło
<pre class="lang-c prettyprint-override"><code>&0&0& ... 0&0&0& </code></pre>
gdzie...
jest więcej tego samego. Znaczników rozpiętości w ogóle nie ma. To wynik 739/256 = 2,887190/50 = 3,8: Kursywa
Jak się okazuje, Twoje 3-znakowe zmartwienie jest prawdziwe.
*q*
generuje<em>q</em>
dając stosunek 10/3. Dwa zwroty karetki dają<p>...</p>\n\n
(dwa zwroty karetki nie są konieczne, ale wydają się być wyprodukowane), a wynikowy stosunek wynosi 9/2. Całkowity stosunek 19/5.Wynikowy HTML:
W akcji:
q
q
q
q
q
q
q
q
q
q
źródło
> q
używać<blockquote>
zamiast<em>
lepiej. (uwaga: robisz to co drugą linię, w przeciwnym razie to tylko jeden tag)222/53 = <4,2: Nasty ucieka w dołączeniu obrazu.
Prowadzi do:
Wynikowy kod HTML powinien wynosić w przybliżeniu:
To narusza włączenie obrazu i konieczność ucieczki.
Kiedyś było znacznie lepiej, ale najwyraźniej przecena SE jest wystarczająco niestandardowa, aby ją zrujnować.
Moje poprzednie zgłoszenie (które nie było tak, jak przedstawił je SE) to:
428/50 = 8,56: Nasty ucieka w dołączeniu obrazu.![&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&](&)
Wynikowy kod HTML powinien wynosić w przybliżeniu:
To nadużywa faktu, że większość edytorów przecen zastępuje znaki handlowe w tekście alternatywnym znakami podwójnego znaczenia, aby wyświetlały się poprawnie. W międzyczasie pojedynczy znak ampersand jest wrzucany do sekcji src, aby parser faktycznie zobaczył go jako obraz.
źródło
[1]:https://&
na linii, a następnie użyć![&][1]
więcej razy?MathJax: 13.579 / 52 = 261,13
Po prostu tworzy kilka pustych wbudowanych MathJax:
Kod HTML (można sprawdzić na pustej przestrzeni powyżej):
źródło
4830/256 = 18,87
Pomysł oparty na autokorekcie HTML. Jednak niezbyt wysoki wynik.
źródło
421/56 = 7,518
Który produkuje następujący kod HTML na SE:
... i następujące dane wyjściowe:
I
I
I
I
I
I
źródło
11190/255 = ~ 43,88
Zainspirowała mnie ta najlepsza odpowiedź, ale jestem zbyt głupi, aby ją pokonać i osiągnąłem maksymalną liczbę postaci, więc chyba będę musiał być zadowolony z tego, co mam ¯ \ _ (ツ) _ / ¯. Właściwie są dwa spacje po ostatnim cytacie blokowym, ale formatowanie go nie pokazuje.
> - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - >
HTML:
źródło