Je suis sûr que la plupart d’entre nous ont entendu parler des bombes zip et autres manipulations similaires, dans lesquelles une intervention malicieuse crée une sortie massivement disproportionnée. Nous avions même une question ici pour faire cela à un compilateur à un moment donné.
Eh bien, il me semble que Markdown est un format de compression qui remplace les balises HTML volumineuses par des jetons MD "compressés". Par conséquent, pourrait-il être possible de construire une bombe de compression dans Markdown?
Règles du challenge:
La soumission doit être un morceau de texte de démarcation, entre 50 et 256 caractères. (Imposer un minimum pour éviter qu'une partie intelligente envoie une réponse à 3 caractères ou similaire.)
La soumission sera traitée par le processeur Markdown de StackExchange comme implémenté dans ce site.
Votre score correspondra au rapport entre le nombre de caractères dans le code HTML résultant et le nombre de caractères de votre texte Markdown.
Le score le plus élevé gagne.
la source
Réponses:
Devis de blocs, 137 469/256 = 536,99
6 908 caractères, 511 nouvelles lignes, 130 050 espaces
Markdown gère les guillemets imbriqués curieusement. Chaque
>personnage est transformé en<blockquote></blockquote>un solide ratio de 1 à 25. Mais attendez! Lors du rendu du code HTML, il ajoute également deux espaces par imbrication! Avoir cette tentative de rendu cause un peu de peine à mon navigateur et je vais le garder dans la cage de code pour le moment. N'hésitez pas à le déverrouiller vous-même!L'entrée de code est composée de 255
>suivis de&car le dernier caractère ne se transforme pas mais il est échappé. Merci BWO!pour le dernier caractère qui donne le dernier blockquote de la classe spoiler avec une balise p vide à l'intérieur. Merci bta, 11 caractères supplémentairesContribution:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>!HTML de sortie:
Voici à quoi cela ressemble dans la vue éditeur!
Tracer les résultats comme le nombre d'
>augmentation suggéré par LambdaBeta:la source
!avant l'esperluette, alors le dernier niveau de blockquote recevra `class =" spoiler "`. Ajoutez-le à n'importe quel autre niveau et cela raccourcira la sortie.MathJax, 529
Un bon vieux code de style mille-rires
$$\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$$multiplie par un facteur considérable l’inefficacité flagrante de la représentation de caractères exotiques dans MathJax.
La limite de configuration StackExchange MathJax de 10
la source
Liens raccourcis: 68 960/256 = 269,375
ASCII seulement: 10 114/256 = 39,508
La sortie est une séquence d'éléments ressemblant chacun à:
Après la surcharge fixée pour la création de la référence d'URL, chaque lien de 5 caractères se développe en
42+strlen(url)sortie de caractères. Créez l'URL de manière à ce qu'il y ait un nombre maximal de caractères à échapper, et le nombre de47+3*strlen(url)caractères par lien augmente . Un peu d'expérimentation a montré que la sortie optimale impliquait 26 liaisons, avec 114 carets par liaison.Mise à jour : si vous interprétez la limite de "256 caractères" comme incluant les caractères Unicode, vous pouvez dissiper davantage de chaos. Le remplacement des caractères par le caractère de baignoire Unicode (, point de code U + 1F6C1) génère
47+18*strlen(url)des caractères de sortie par caractère d'entrée pour un total de5457468960 (grâce à la notation de liaison encore plus courte de jimmy23013).Entrée Unicode:
La sortie est une série de:
la source
[1],[1],[1]...pour les liens. 2."a plus de caractères que%5Edans la version non-Unicode.15888/50 = 317.76: Abus de MathJaX
C'est le code:
Voici à quoi ça ressemble:
Le HTML résultant est:
N'oubliez pas vos gars de MathJax.
Mise en garde: MathJaX n'affiche l'erreur qu'en cours d'édition. Vous devez donc la visualiser dans l'éditeur. Ceci est toujours une implémentation de démarques sur ce site, donc devrait être valide. Une fois postés, les
Misplaced &avertissements deviennent normaux.la source
Mise en surbrillance de la syntaxe,
63766464/256 ≈ 25,25+0.34375 grâce à Ismael Miguel (en utilisant une tabulation au lieu de 4 espaces)!
Ceci utilise l'annotation la plus courte (malheureusement, les espaces semblent compter) pour obtenir la coloration syntaxique
lang-c, ouvre un bloc de code et le remplit avec&et0:Nous commençons avec
&car il se développe&et utilise0ensuite, leur alternance crée constamment de nouveaux<span>éléments avec unclassattribut. Malheureusement, nous ne pouvons pas utiliser seulement&ou&<&<...comme ils restent dans le mêmepun-<div>Cela produit:
Et rendu par votre navigateur, il en résulte:
la source
<pre class="lang-c prettyprint-override"><code>&0&0& ... 0&0&0& </code></pre>où il en...est de même. Les balises span ne sont pas du tout. C'est un score de 739/256 = 2.887190/50 = 3.8: italiques
En fin de compte, votre inquiétude à 3 caractères est vraie.
*q*génère<em>q</em>un rapport de 10/3. Deux retours chariot donnent<p>...</p>\n\n(les deux retours chariot ne sont pas nécessaires, mais semblent avoir été produits) et un ratio résultant de 9/2. Ratio total, 19/5.Résultat HTML:
En action:
q
q
q
q
q
q
q
q
q
q
la source
> qpour utiliser<blockquote>au lieu de,<em>c'est mieux. (note: vous le faites à toutes les autres lignes, sinon ce n'est qu'une balise)222/53 = <4.2: Nasty s'échappe dans une inclusion d'image.
Résulte en:
Le résultat HTML devrait être approximativement:
Cela abuse de l’inclusion d’images et du fait d’échapper aux choses.
C'était bien mieux, mais apparemment, le démarquage de SE est suffisamment non standard pour le ruiner.
Ma soumission précédente (qui n'était pas comment SE l'a rendue) était:
428/50 = 8.56: Nasty s'échappe dans une inclusion d'image.Le résultat HTML devrait être approximativement:
Ceci abuse du fait que la plupart des rédacteurs Markdown remplacent les esperluettes du texte alternatif par des esperluettes doublement échappées pour qu'il s'affiche correctement. Pendant ce temps, une seule esperluette est jetée dans la section src afin que l’analyseur le voie réellement comme une image.
la source
[1]:https://&sur une ligne, puis utiliser![&][1]plusieurs fois?MathJax: 13,579 / 52 = 261.13
Crée juste un tas de MathJax vides en ligne:
Code HTML (peut inspecter l'espace vide ci-dessus):
la source
4830/256 = 18,87
Une idée basée sur la correction automatique HTML. Pas assez élevé cependant.
la source
421/56 = 7,518
Qui produit le code HTML suivant sur SE:
... et la sortie suivante:
Et
Et
Et
Et
Et
Et
la source
11190/255 = ~ 43,88
Cette réponse m'a inspiré , mais je suis trop bête pour la battre et atteindre le nombre maximal de caractères, alors, je suppose que je devrai être satisfait de ce que j'ai ¯ \ _ (ツ) _ / ¯. Il y a en fait deux espaces après la dernière citation, mais le formatage ne l'affiche pas.
> - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - > - >HTML:
la source