Import SQL WordPress : résoudre « Unknown collation » sans altérer les données

Reconnaître une incompatibilité de collation pendant la restauration

L’import d’une base WordPress s’interrompt avec « Unknown collation », souvent accompagné du numéro 1273 et d’un nom comme utf8mb4_0900_ai_ci. Le serveur de destination ne reconnaît pas le nom demandé dans une instruction SQL. Ce refus porte sur la structure ou une expression du fichier ; réduire sa taille ne rend pas cette collation disponible.

Le résultat recherché est une restauration complète sur une destination qui comprend la structure, sans modifier arbitrairement les contenus. La première approche conserve le fichier et utilise une destination compatible. La seconde adapte une copie de sa structure, seulement après vérification des différences de comparaison. Changer le nom partout dans le fichier ne constitue pas un choix neutre.

Ce guide s’adresse à une restauration SQL autorisée avec accès à la sauvegarde et à l’outil de base de données de l’hébergement. Un import de contenu XML relève d’un autre parcours. Sur une offre gérée, vérifiez les possibilités réelles : accès aux tables, création d’une base d’essai et choix du moteur sont trois droits différents. En multisite, la sauvegarde peut couvrir plusieurs sous-sites et des tables communes ; ne la traitez pas comme la base d’un site isolé.

Préserver le fichier original et isoler la destination d’essai

Gardez la sauvegarde SQL originale sans modification, ainsi que ses fichiers associés si la restauration en dépend. Travaillez sur une copie identifiée par un nouveau nom. Conservez le message complet et le point d’arrêt, sans publier un extrait contenant des données personnelles, des identifiants ou des valeurs de configuration.

Préparez une base d’essai séparée et vide, avec un compte limité à elle. Ne relancez pas l’import sur une production contenant des données plus récentes. Vérifiez si le fichier inclut CREATE DATABASE, USE ou des noms qualifiés comme autre_base.table : le nom sélectionné dans l’interface ne les neutralise pas. Si ces instructions visent un autre périmètre, faites préparer un export adapté avant exécution. Gardez le dump hors d’un dossier web public ; il contient les données du site.

Un premier import interrompu peut déjà avoir créé des tables ou inséré des lignes. Le DDL, c’est-à-dire les instructions de structure, ne se comporte pas comme une opération entièrement annulable dans tous les cas. Conservez l’état utile au diagnostic puis repartez d’une destination propre préparée pour l’essai. La commande Recommencer n’est pas une garantie de restauration cohérente.

Distinguer le jeu de caractères des règles de comparaison

Un jeu de caractères définit la représentation des caractères. Une collation définit notamment leur comparaison et leur tri. Deux colonnes peuvent accepter le même texte tout en le comparant différemment selon leur collation. Des différences d’accents, de casse ou d’espaces peuvent devenir importantes pour une recherche ou pour une contrainte d’unicité.

Le nom utf8mb4 n’est donc pas à lui seul une collation de remplacement. Il ne faut pas non plus transformer toutes les déclarations en utf8 pour supprimer le message : cela change un autre aspect de la structure et peut réduire les caractères représentables selon le moteur et son interprétation de cet alias.

La compatibilité dépend du moteur et de sa version exacte. MariaDB 11.4.5 a ajouté des noms MySQL 0900 comme alias de collations UCA 14.0. Ainsi, utf8mb4_0900_ai_ci y désigne utf8mb4_uca1400_nopad_ai_ci, tandis que MySQL utilise des règles UCA 9.0 pour ce nom. Un alias facilite l’acceptation du fichier, sans prouver que toutes les comparaisons resteront identiques. Vérifiez le nom sur la destination réelle puis contrôlez les valeurs sensibles au tri et à l’unicité.

Interroger les capacités de la destination sans rien modifier

Ouvrez phpMyAdmin depuis le panneau de votre hébergeur, puis sélectionnez la base d’essai dans la colonne gauche. L’onglet SQL permet d’exécuter les lectures ci-dessous, sans modifier les données. Adaptez uniquement le nom de collation à celui de l’erreur. La version de phpMyAdmin affichée dans son accueil est celle de l’outil ; la requête VERSION() relève celle du moteur SQL.

Le résultat identifie le moteur et la base courante ; une base indiquée NULL n’est pas une base d’essai sélectionnée. La recherche de collation doit retourner une ligne avec le nom attendu. Une liste vide signifie que cette connexion ne reconnaît pas ce nom. Si vous recevez une erreur de syntaxe ou de droits, conservez-la pour faire vérifier le contexte ; ne la confondez pas avec un résultat vide.

Vérifiez l’identité du serveur et ouvrez SQL dans la base d’essai.
Exécutez les deux lectures et conservez leurs résultats privés.
Comparez avec les informations de la source si elle reste disponible.
Notez séparément le moteur, sa version et le nom refusé ; ne retenez pas seulement « MySQL compatible ».

SELECT VERSION() AS version_serveur,
       @@version_comment AS moteur,
       DATABASE() AS base_courante;
SHOW COLLATION WHERE Collation = 'utf8mb4_0900_ai_ci';

Localiser la déclaration refusée dans une copie du fichier

Ouvrez la copie SQL dans un éditeur de texte adapté à sa taille, sans l’enregistrer pour commencer. Recherchez le nom exact de collation. Examinez chaque contexte : option par défaut d’une table, définition d’une colonne, instruction de base ou expression particulière. Le nom peut aussi apparaître dans une chaîne de données sans être une instruction de structure.

Relevez le nom de la table et l’instruction à laquelle l’outil attribue l’erreur. Un numéro de ligne permet de se repérer, mais une instruction peut couvrir plusieurs lignes. Gardez l’enveloppe de l’instruction pour savoir ce qui était demandé. Ne diffusez pas le voisinage complet si une insertion de données privées s’y trouve.

Si le nom est vide, mal orthographié ou remplacé par un simple jeu de caractères, le problème peut venir du générateur ou d’un réglage erroné, plutôt que d’un moteur trop ancien. Dans ce cas, privilégiez un nouvel export corrigé depuis la source. Si le nom est valide à la source mais absent à la destination, choisissez entre une destination compatible et une adaptation de structure validée.

Choisir une destination qui reconnaît la structure d’origine

La première approche convient lorsque vous pouvez préparer une destination compatible dans l’hébergement d’essai. Préférer le même moteur avec les collations requises limite les écarts de comparaison. Une autre famille de moteur peut accepter le nom par alias : reprenez alors les contrôles de tri et d’unicité ci-dessous, même sans modification du dump. Reconnaître une collation n’établit pas toute la compatibilité SQL.

Dans le panneau de gestion des bases, relevez les options réellement disponibles et faites créer ou préparer une destination isolée selon les droits du compte. Si la version est imposée, demandez au prestataire une destination qui reconnaît le nom indiqué. N’engagez pas une mise à niveau globale du serveur de production simplement pour réaliser le premier essai d’import.

WordPress.com réserve actuellement phpMyAdmin aux offres Business et Commerce, avec activation de l’hébergement si nécessaire. Depuis le Hosting Dashboard : site concerné, Settings, section Server, Database, puis Open phpMyAdmin. Chaque site y dispose d’une base préconfigurée ; on ne peut pas créer librement une seconde base, changer sa connexion ou y accéder depuis l’extérieur. Le parcours « nouvelle base vide » doit donc se faire dans un environnement autorisé à cet effet, sans vider le site hébergé. Sans accès SQL, faites choisir le parcours de migration avec le prestataire.

Présentez le moteur source, sa version et les déclarations de collation utilisées.
Choisissez une destination d’essai autorisée ; relevez son moteur et vérifiez le nom avec SHOW COLLATION.
Conservez le fichier original sans remplacement de noms.
Préparez son import complet dans cette destination, après contrôle du périmètre des instructions.
Si le choix est inadéquat, abandonnez cette base d’essai sans modifier la source ou la production.

Importer le fichier contrôlé dans une base isolée

Dans phpMyAdmin ou l’outil SQL autorisé, sélectionnez la base d’essai prévue avant de choisir Importer. Vérifiez son nom dans le fil de navigation. Choisissez le fichier contrôlé et le format SQL correspondant. Le réglage d’encodage de lecture doit correspondre au fichier ; le changer au hasard ne rend pas une collation inconnue disponible.

Lancez un seul import et conservez les messages jusqu’à son terme. Si l’outil signale une autre erreur, identifiez son objet avant de modifier de nouveau le fichier. Une progression terminée ou quelques tables affichées ne prouvent pas que toute la sauvegarde a été exécutée. Évitez l’option qui ignorerait les erreurs pour continuer silencieusement.

Confirmez la base isolée et le périmètre du fichier à exécuter.
Ouvrez Importer, sélectionnez le document SQL et contrôlez ses options.
Exécutez une fois et gardez le premier message d’échec éventuel.
Si l’import aboutit, vérifiez les tables et les données avant de relier une copie de WordPress à cette base.
Si l’import s’arrête, préparez une nouvelle destination propre pour le prochain essai, sans effacer une base active.

Adapter une copie de structure seulement si la destination est imposée

La seconde approche s’adresse à une personne capable de lire les instructions SQL et de vérifier leurs effets. Elle convient lorsque la destination est imposée et qu’une collation de remplacement a été choisie pour ses règles, pas seulement parce que son nom existe. Cette décision peut nécessiter le responsable technique d’un composant qui impose ses propres contraintes.

Une adaptation du dump doit toucher uniquement les déclarations SQL concernées. Ne lancez pas un remplacement global sur les chaînes de contenu : le nom recherché peut y apparaître comme donnée, et une modification d’une valeur sérialisée peut rendre cette valeur incohérente. Gardez un relevé de chaque instruction changée et le fichier original intact. L’exemple ci-dessous montre seulement une option de table ; utf8mb4_unicode_ci reste un candidat illustratif à vérifier, sans équivalence universelle avec la collation d’origine. Ces fragments ne sont pas des instructions autonomes à exécuter.

Changer seulement la collation par défaut d’une base ne remplace pas les collations explicites du dump. De même, l’option de table ci-dessous ne remplace pas une clause COLLATE portée par une colonne. Inventoriez ces déclarations séparément ; ne lancez pas une conversion globale de tables existantes pour contourner leur présence. Si le générateur sait produire un export compatible documenté, préférez cette option vérifiée à une transformation artisanale répétée.

Listez les collations du même jeu, par exemple avec SHOW COLLATION WHERE Charset = 'utf8mb4'; si la source utilise utf8mb4.
Choisissez le remplacement après comparaison de ses règles et des contraintes des tables concernées.
Modifiez dans une copie les seules options de structure identifiées, avec relecture du contexte complet.
Importez cette copie dans une nouvelle base d’essai propre.
Si les résultats de comparaison ou d’unicité diffèrent de manière inacceptable, revenez au fichier original et au parcours de destination compatible.

-- Option de table d’origine dans le dump :
DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

-- Option illustrative après validation du remplacement :
DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

Contrôler les index et les différences de comparaison

Une nouvelle collation peut considérer deux valeurs comme égales alors que l’ancienne les distinguait, ou l’inverse. Sur une colonne possédant un index unique, cela peut faire échouer l’insertion de données qui étaient admissibles à la source. Une restauration qui passe l’étape de création de table peut donc rencontrer ensuite un autre refus légitime.

Un cas concret mérite un contrôle : dans MySQL, utf8mb4_0900_ai_ci est NO PAD, alors que utf8mb4_unicode_ci est PAD SPACE. Des espaces finaux pris en compte dans le premier cas peuvent ne plus distinguer deux chaînes dans le second. Ajoutez des paires représentatives avec accents, casse et espaces à votre jeu de vérification privé. Ne retirez pas un index unique pour faire passer l’import : il protège peut-être un identifiant métier.

Si un conflit apparaît, consignez les valeurs en cause dans un environnement privé et faites décider leur traitement par le propriétaire des données. Ne supprimez pas automatiquement les lignes qui gênent la conversion. Le choix d’une destination compatible reste préférable lorsqu’aucune adaptation ne conserve le comportement attendu. Le résultat recherché n’est pas seulement un import sans message rouge, mais une base dont les règles restent utilisables par le site.

Sur la copie, ouvrez la table concernée puis Structure dans phpMyAdmin : relevez la collation de la colonne et les index qui l’utilisent. Si besoin, la lecture SHOW CREATE TABLE nom_table_confirme;, avec le nom exact adapté, expose sa définition complète. Elle peut révéler noms et valeurs par défaut privés. Comparez ensuite une recherche et un tri sur les mêmes enregistrements source et restaurés ; une requête de création acceptée ne suffit pas.

Ne pas utiliser wp-config.php comme convertisseur du fichier SQL

Les constantes DB_CHARSET et DB_COLLATE appartiennent à la configuration de WordPress. Elles n’effacent pas les déclarations explicites présentes dans un fichier SQL que vous exécutez depuis un gestionnaire de bases. Modifier DB_COLLATE avant de relancer le même dump ne transforme donc pas automatiquement son instruction de création refusée.

Ne changez pas une installation existante en supprimant ces réglages uniquement parce qu’un message évoque une collation. Gardez les valeurs originales et leur justification. Une configuration erronée peut demander une correction distincte, notamment lorsque WordPress ou un composant crée ensuite une table ; ce diagnostic ne se confond pas avec la lecture d’une sauvegarde déjà produite.

Aucune nouvelle extension WordPress n’est nécessaire pour reconnaître les capacités du moteur ou importer le fichier SQL contrôlé. Un outil de sauvegarde peut fournir un autre parcours documenté, mais il ne rend pas magiquement toutes les collations disponibles sur le serveur. Évitez d’installer un convertisseur sans connaître les transformations qu’il applique aux structures et aux données. Les lectures SQL et la copie de fichier apportent ici un contrôle plus direct.

Valider la base restaurée avant de la relier au site

Comparez la liste des tables avec celle attendue dans la sauvegarde. Vérifiez les tables propres aux composants, pas seulement celles du cœur WordPress. Contrôlez quelques définitions de colonnes et de collations depuis l’onglet Structure de l’outil SQL. Si une adaptation a été faite, elles doivent correspondre aux décisions consignées.

Comparez les volumes de données par des contrôles adaptés ; les estimations de lignes affichées pour certaines tables ne sont pas toujours des comptages exacts. Vérifiez aussi des enregistrements connus au début et à la fin du périmètre. Un document SQL peut s’être arrêté après plusieurs tables réussies, sans que l’interface de navigation le rende évident.

Reliez ensuite seulement une copie de WordPress à la base d’essai, selon son parcours de restauration prévu. Maintenez les envois neutralisés. Contrôlez la connexion, une recherche, les caractères accentués et une modification réversible, puis les fonctions des composants concernés. Un export de base seul n’inclut pas nécessairement les médias et les fichiers d’extension ; leur absence n’est pas une nouvelle preuve de collation incorrecte. Séparez ces contrôles pour conserver un diagnostic fiable.

Reprendre un essai sans mélanger des restaurations partielles

Si l’import a échoué, gardez son premier message utile et la copie de fichier qui l’a produit. Ne relancez pas un dump modifié par-dessus les tables partielles en espérant que les insertions restantes complètent l’ensemble. Selon le contenu SQL, vous pourriez rencontrer des doublons, écraser une partie des données ou conserver une structure différente de celle voulue.

Pour un nouvel essai, utilisez une base isolée propre préparée à cet effet par le panneau ou le responsable autorisé. Vérifiez son nom avant toute réinitialisation. L’ancienne base de production et la source doivent rester disponibles selon le plan de retour. N’exécutez pas une suppression calculée à partir d’un préfixe supposé pour nettoyer plus vite.

Si une bascule vers la base restaurée est prévue, conservez la configuration précédente et le moment de la bascule. Le retour peut consister à rétablir cette connexion, mais les écritures reçues entre-temps doivent être prises en compte. Il ne suffit pas de remettre un ancien wp-config.php pour résoudre un écart de données. Préparez une fenêtre ou une synchronisation adaptée au site avant l’opération réelle.

Préparer les prochains exports pour la destination prévue

Consignez le moteur et la version de la source, les collations utilisées, la destination validée et l’outil qui a créé l’export. Lorsqu’un composant ajoute des tables ou change ses règles SQL, incluez-les dans le prochain essai de restauration. Les seules tables WordPress connues de mémoire ne décrivent pas nécessairement tout le site.

Gardez le fichier original et, si une adaptation a été validée, son relevé de transformations. Indiquez les colonnes et les contraintes contrôlées, ainsi que les limites restantes. Une recette qui remplace un nom par un autre sans contexte n’est pas un plan de migration reproductible. Les capacités évoluent : vérifiez la destination réelle lors de la prochaine restauration.

Pour obtenir une aide précise, fournissez le nom refusé, le moteur et sa version, l’instruction de structure expurgée et le résultat de SHOW COLLATION. Précisez si le fichier original fonctionne sur une autre destination d’essai. Ces preuves permettent de choisir une compatibilité ou une adaptation assumée, sans faire disparaître l’erreur au prix d’une modification silencieuse des contenus.

Notre méthode éditoriale