RICHER
SOLUTION
RICHER
SOLUTION
Modernisez votre code entre deux versions d'un même langage : PHP 5.6 vers 7.x ou 8.x, Python 2 vers 3, MySQL 5.7 vers 8.0, MySQL et MariaDB dans les deux sens, Oracle 11g vers 19c. Ce qui se corrige sans risque est appliqué ; ce qui demande un arbitrage est signalé, ligne par ligne, sans être touché. Tout se passe dans votre navigateur — votre code ne quitte pas votre machine.
Corrigé : réécrit sans risque. À vérifier : réécrit, mais relisez. À reprendre : signalé, votre code n'a pas été modifié. Information : rien à faire, mais bon à savoir.
Passer de PHP 5.6 à PHP 8 n'est pas une traduction : c'est le même langage, dont certaines constructions ont disparu et d'autres ont changé de comportement. La liste des ruptures est publiée, finie et vérifiable — ce qui rend l'opération mécanisable, contrairement à une conversion entre deux langages différents où la moindre ligne suppose un choix de conception.
Cet outil s'en tient donc à ce périmètre. Il ne prétend pas transformer du Python en Java : un tel résultat compile parfois et se comporte autrement, ce qui est le pire des résultats puisqu'il inspire confiance.
Une réécriture n'est appliquée que lorsqu'elle est équivalente : array() en crochets, $s{0} en $s[0], isset($a) ? $a : $b en $a ?? $b, print "x" en print("x"). Ces transformations ne changent ni le résultat ni les cas limites.
Tout le reste est signalé sans être touché. Un appel mysql_query() ne devient pas du PDO par substitution : il faut reprendre la connexion, la gestion des erreurs et l'échappement. Un outil qui produirait ici du code d'apparence correcte rendrait un mauvais service.
Le SQL se prête particulièrement bien à cet exercice, parce que ses ruptures sont peu nombreuses et documentées. Passer de MySQL 5.7 à 8.0, c'est surtout une vingtaine de mots devenus réservés — rank, row, groups, system —, la disparition de PASSWORD(), celle du tri implicite du GROUP BY, et le préfixe ST_ devenu obligatoire sur les fonctions spatiales.
Entre MySQL et MariaDB, la difficulté n'est plus la version mais la divergence : les collations utf8mb4_0900_* et JSON_TABLE() n'existent pas côté MariaDB, tandis que les séquences, RETURNING et CREATE OR REPLACE TABLE n'existent pas côté MySQL. Un fichier de sauvegarde restauré dans l'autre moteur échoue le plus souvent sur la collation, dès la première table.
Côté Oracle, les ruptures purement syntaxiques sont rares : l'essentiel des points relevés concerne des constructions devenues inutiles — la pagination par ROWNUM depuis que FETCH FIRST existe, le couple séquence et déclencheur depuis les colonnes IDENTITY — ou dépréciées, comme DBMS_JOB. C'est le jeu de règles le plus mince des quatre, et il faut le savoir.
L'analyse s'exécute entièrement en JavaScript, sur votre machine. Aucun envoi, aucun enregistrement, aucune trace côté serveur — ce qui compte quand on colle du code appartenant à un client ou à un employeur.
Avant toute transformation, le texte est parcouru pour repérer les chaînes, les commentaires et les heredocs, qui sont mis de côté. Un array( écrit dans un commentaire ou une parenthèse à l'intérieur d'une chaîne ne sont donc jamais confondus avec du code — c'est précisément là que se cassent les outils fondés sur de simples expressions régulières.
7 / 2 valait 3, il vaut 3.5. Aucune erreur n'est levée, le programme continue — et les résultats sont faux là où l'on attendait une division entière. C'est pourquoi l'outil la signale même sans rien réécrire : le remplacement par // dépend de l'intention, que seul l'auteur connaît.${var} à corriger pour PHP 8.2.utf8mb4_0900_ai_ci, une collation fondée sur Unicode 9.0 que MariaDB n'implémente pas. Le fichier de sauvegarde la mentionne à chaque table, et l'import s'arrête sur la première. Le remplacement le plus proche est utf8mb4_general_ci, ou utf8mb4_uca1400_ai_ci sur MariaDB 10.10 et suivants — sachant que l'ordre de tri ne sera pas rigoureusement identique.