From 80f96efb56cfe77b36a2c1312615238fc9b1732a Mon Sep 17 00:00:00 2001 From: Arnaud Date: Thu, 28 May 2026 20:51:13 +0200 Subject: [PATCH] fix(seed): documenter --default-character-set=utf8mb4 sous Windows MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Le client mysql sous Windows + Git Bash utilise cp850 comme `character_set_client` par défaut. Quand on applique 002_seed_categories.sql avec un simple `mysql < ...`, le client réinterprète les bytes UTF-8 du fichier via cp850 AVANT de les insérer : `é` (0xC3 0xA9) devient `├®` (E2949C C2AE) stocké en clair dans la base, et apparaît tel quel dans l'API + le SPA. Le `SET NAMES utf8mb4` côté serveur ne corrige pas ça parce que la conversion est déjà faite côté client. Il faut le flag `--default-character-set=utf8mb4` sur la ligne de commande mysql. - README.md : doc de la commande correcte + commande de vérif HEX - 002_seed_categories.sql : commentaire d'alerte + SET NAMES utf8mb4 (no-op côté connexion mais documente l'intention) Côté prod (apply.sh + docker exec mariadb) le client interne utilise utf8mb4 par défaut, donc pas de souci là-bas. Co-Authored-By: Claude Opus 4.7 (1M context) --- README.md | 20 ++++++++++++++++---- migrations/002_seed_categories.sql | 7 +++++++ 2 files changed, 23 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 7f2688c..c3148ee 100644 --- a/README.md +++ b/README.md @@ -46,13 +46,25 @@ FLUSH PRIVILEGES; ### 2. Appliquer les migrations +> ⚠️ **Important sous Windows** : passer `--default-character-set=utf8mb4` au client +> `mysql`. Le client Windows utilise par défaut `cp850` comme charset de session, ce +> qui mangle les bytes UTF-8 du fichier seed avant insertion (`Démocratie` devient +> `D├®mocratie` en base). Le flag force le client à passer les bytes intacts. + ```bash -mysql -uinfolab -p'dev-pass-change-me' infolab < migrations/001_init_schema.sql -mysql -uinfolab -p'dev-pass-change-me' infolab < migrations/002_seed_categories.sql +mysql --default-character-set=utf8mb4 -uinfolab -p'dev-pass-change-me' infolab \ + < migrations/001_init_schema.sql +mysql --default-character-set=utf8mb4 -uinfolab -p'dev-pass-change-me' infolab \ + < migrations/002_seed_categories.sql + +# Vérifier (les bytes de "é" doivent être C3 A9, pas E2 94 9C C2 AE) : +mysql -uinfolab -p'dev-pass-change-me' -Nse \ + "SELECT HEX(name) FROM categories WHERE slug='democratie-citoyennete'" infolab +# Attendu : 44C3A96D6F6372617469652026204369746F79656E6E6574C3A9 ``` -> Le script `migrations/apply.sh` est conçu pour la prod (Docker) ; en local, -> on applique les fichiers à la main comme ci-dessus. +> Le script `migrations/apply.sh` est conçu pour la prod (Docker) ; le client +> `mariadb` du conteneur utilise déjà utf8mb4 par défaut, donc pas de souci là-bas. ### 3. Créer un fichier `.env` (gitignoré) diff --git a/migrations/002_seed_categories.sql b/migrations/002_seed_categories.sql index 2f0e78a..b7e4870 100644 --- a/migrations/002_seed_categories.sql +++ b/migrations/002_seed_categories.sql @@ -1,3 +1,10 @@ +-- Ce fichier contient des caractères accentués (é, É, ...). À appliquer avec +-- un client MySQL en charset utf8mb4. Sous Windows + Git Bash, passer +-- `--default-character-set=utf8mb4` à la commande mysql, sinon le client +-- réinterprète les bytes UTF-8 via cp850 et stocke des `├®` à la place des `é`. +-- Voir README.md "Appliquer les migrations". +SET NAMES utf8mb4; + INSERT INTO categories (slug, name, description, color_hex, icon, dimension, sort_order) VALUES ('data-open-data', 'Data & Open Data', 'Projets autour de la donnée ouverte, de la médiation et de la littératie des données.', '#3B82F6', 'database', 'transversal', 10), ('democratie-citoyennete','Démocratie & Citoyenneté', 'Projets favorisant la participation citoyenne, la transparence et la gouvernance ouverte.', '#EF4444', 'users', 'social', 20),