Version imprimable
Si, je passe bien par là pour faire un eval, mais c'est derrière le compile(code) que j'ai ajouté une (grosse) optimisation. Regarde la différence de taille entre alert("Hello World") compilé par rapport à alert("test"), c'est très minime par rapport aux autres façons de récupérer les lettres "H", "W" etc...
Je ne lâche pas la solution tout de suite, il faut que je corrige ce problème de virgules ; et je vais peut-être rédiger un article pour tout expliquer depuis le début.
Malin !! Si j'ai bien capté, tu récupères l'Unicode de chaque caractère saisi, tu le passes à la moulinette pour récupérer le nombre (traduit en String) en ([]!+). Mais du coup .. tu passes par là pour chaque caractère plutôt que de checker avant s'il se trouve parmi les caractères "simples" à traduire ?
Okay j'ai résolu mon problème de virgules, ça venait de ["to"+(("")["constructor"]+[]).slice(9,15)] ; je n'ai pas pensé à convertir la virgule entre les deux arguments de slice :oops: ; du coup j'ai remplacé par [""]["constructor"]["name"]. Plus long mais tant pis !
Donc maintenant, le code de l'encodeur !
Préchauffez vos neurones et réapprovisionnez-vous en café :mrgreen:
Avant tout je parcours le code et pour chaque caractère, récupère le charCode associé. Les charcodes sont des petits nombres, ils prennent en moyenne moins de place que les conversions de lettres exposées auparavant. De plus, String.fromCharCode() prend une infinité d'arguments et nous permettra de convertir tous les charcode en un seul appel.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
Pour générer une array de charcodes numériques, ce serait très lourd de la constituer en String en encodant les virgules, puis de faire un eval. A la place je constitue une string avec les charcode séparés par un caractère séparateur. Il faut qu'il soit le plus court possible sans être un nombre, j'ai donc choisi le "f" : (![]+[])[+[]] ; Puis il suffit d'appeler split sur ce même code séparateur pour reconstituer l'array.
Seulement avec cette méthode, les éléments de l'array (les charcodes) ne sont plus des nombres mais des String. Donc au lieu d'un appel direct de la fonction String.fromCharCode, je constitue une string "String.fromCharCode(" + (array castée en string) +")" que je retourne évaluée ensuite.
Le premier eval remplace le code ([+!]) par la string "String.fromCharCode(123,145,167,...)", le second exécute la fonction String.fromCharCode pour récupérer le code "décompilé". Et voilà le travail :)
Héhé excellent ! :applo:
Sympa les petites astuces et l'emploie de fromCharCode qui prend tout son sens du coup.
Donc tu pourrais faire de même pour convertir les données "en dur" que tu dois utiliser pour encoder, non ? app.convertTable["String"], _("split") etc car celles-ci, si j'ai bien compris, sont traduites en utilisant la table de correspondance des lettres pré-calculées ?
D'ailleurs, j'ai trouvé un compilateur fonctionnel hier en cherchant un peu : JSF*ck ! Le même charset est employé et il utilise la même table de correspondance à quelques broutilles près. Pour alert(1), il le fait en 1669 car. Mais j'ai testéet là, les perfs sont désastreuses.Code:
2
A priori, il utilise d'abord les caractères connus, il construit les digits à la volée et il remplace les caractères inconnus par la même technique que toi fromCharCode(CharCodeAt()). Une fois tous les caractères matchés, il traduit le tout en soupe ([!+]) à coup de regex.
Je ne comprends pas trop, ces données en dur sont justement celles qui me permettent de faire le String.fromCharcode, autrement le double eval. C'est le serpent qui se mord la queue si on fait ça.Citation:
Envoyé par Kaamo
Je ne connaissais pas JSFuck, on dirait que je ne suis pas le seul à avoir eu cette idée farfelue :P Mais c'est intéressant de comparer les implémentations, par exemple il économise un caractère pour undefined, il a pensé utiliser sort comme moi et il a utilisé return this comme toi pour récupérer Window.
Au niveau du compilateur, il ne passe pas par String.fromCharCode comme wrapper total du code, donc autant il gagne en place pour les petits scripts, autant la taille explose avec les scripts plus gros.
En effet :aie:
Il y a Hieroglyphy, mais qui utilise {} en plus !
Lui n'utilises pas du tout fromCharCode mais il utilise la technique charCodeAt pour chaque lettre de l'input qui n'est pas dans la table des lettres pré-calculées. Ensuite, il emploie plusieurs techniques (unescape, hexa) et prend celle qui fournit la séquence la plus courte et la stocke dans une table pour ne pas recalculer ensuite si le caractère revient ! C'est malin aussi.
Mais ta solution semble la plus optimale. A titre d'exemple, tondonne 55287 caractères chez lui. Par contre, contrairement à JSFuck, il est ultra rapide pour la conversion.Code:
2
Si j'ai bien compris, le jour où je veux balancer les 241k caractères constituant le fatras de mon générateur de phrases dans ton compilateur... >>> :aie:
La question "pour quoi faire ça ?" renvoyant dos à dos nos deux projets :mouarf: qui ont tous deux un petit problème pour répondre à cette question ^^ (quoi que je n'aie pas la moindre prétention de comparer mon jouet avec tes prouesses :ave: )
J'ai regardé ton générateur Romain, ça donne des résultats plutôt amusants ! Il y a quelques temps j'avais vu un outil similaire qui générait des "phrases bidons qui font bien sur les powerpoint d'entreprise" en anglais. C'était à pisser de rire :mouarf:
J'ai pris contact avec l'auteur de JSFuck pour comparer nos implémentations. Il doit y avoir moyen de grapiller quelques centaines de caractères encore, juste pour le plaisir de bien faire ;)