Problème d'accent

icath · 30-09-2009 23:33:58

Bonsoirà tous,

je sais que ce sujet a été bordé de nombreuse fois, mais malgré mes recherche, je n'ai rien trouvé qui puissepaier à mon poblème.

Sur mon forum: http://kit-icath.ifrance.com/Forum_BTS2011/

Les accents ne marche pas. Je ne peu créer de message comportant es accent, ni même des section ou sous-forum. Par contre, j'ai pus faire une modif avec accen (A la place de dernier utilisateur enregistré), j'ai pu mettre, "dernier élève", et là, les accents marche.

Je suis en utf8_general_ci

Je n'arrive pas à trouver l'endroit ou mettre lebon code qui arangerati tout

Si vous avez une lumiere, ca m'aiderai ben

Bonne soirée à tous.

fanf73 · 01-10-2009 00:04:49

La branche 1.2 ne fonctionne pas en utf8 mais en ISO, il faudrait donc que les tables et champs de ta base de données soient en latin_x.

P.S. : discussions, pas discutions.

icath · 01-10-2009 06:37:50

Bonjour,

j'ai bien essayé de me mettre en en latin_general_ci ou latin_general_cs mais n'y fait.

Je suis en fr-iso-8859-1

EDIT: j'ai mis toute mes tables en latin1_general-ci car elle etait en latin1_swedish.

Mais ca n'a rien changé...

Dernière modification par icath (01-10-2009 07:13:48)

fanf73 · 01-10-2009 07:53:44

Et les champs eux-même dans les tables, ils ont bien un interclassement autre que lutf8 ?

icath · 01-10-2009 08:13:59

Qu'appel tu, les champs? car hier j'ai cherché dans mes fichiers "viewforum", "viewtopic", "common" etc... mais j'ai pas trouvé de utf8. Un pote m'a dit de mettre une ligne de code dans la balise <head>, mais je ne l'ai pas trouvé non plus.

Je ne pourrais voir ca que ce soir (si je peux me connecter à mon serveur, ce qui n'était plus le cas ce matin...pffff).

fanf73 · 01-10-2009 09:33:51

Je parle de ta base de données, les champs sont les différentes colonnes de tes tables, par exemple "username", "title"... dans la table users.

De modifier l'encodage dans le header ne va pas résoudre le problème d'enregistrement dans la base de donnée.

teopath · 01-10-2009 09:36:28

C'est dans la base de données qu'il faut regarder, pas dans les scripts

icath · 01-10-2009 11:02:41

Sauf erreur, j'ai mis tout en latin1_general_ci. Je suis aller dans ma BDD et je suis allé dans chaque champs de chaque table, et j'ai fait "modifier" pour passe en latin_x.

J'ai lu sur internet: "Si la base est en utf8 et que la table est en latin1, la base sera en iso"... En gros je dois passer en latin7_x ?

Clairement, mes champs doivent être en latin7_x avec une base en iso?

Otomatic · 01-10-2009 11:13:39

Bonjour,

Grosses confusions entre « charset » et « collation ».

MySQL, jeux de caractères et collation

Un jeu de caractères (character set) est un ensemble de lettres, signes de ponctuations et autres symboles auquels on a associè un numéro de code.
Par exemple, le jeu « standard ASCII » (American Standard Code for Information Interchange) donne le numéro 65 au A majuscule, le 44 à la virgule et le 13 au retour chariot. C'est un jeu créé pour la langue anglaise, et qui ne comporte que 128 caractères. Il ignore donc les caractères accentués, les ligatures, le signe euro et, bien sûr, les caractères grecs, arabes ou japonais.

Remarque : un « jeu de caractères » n'est pas une « police de caractères » (character font) : celle-ci associe à chaque caractère un « glyphe », c'est-à-dire une représentation graphique. Ainsi, les lettres A et A sont-elles deux glyphes du même caractère ASCII 65.

L'information est codée informatiquement sous forme de bits, valant chacun zéro ou un. Une série ordonnée de 8 bits est un octet (byte), qui peut donc avoir 2^8 combinaisons différentes de 1 et de 0, numérotées de 0 à 255. Avec le code ASCII, puis ses extensions, un octet suffit pour enregistrer un caractère.
Ce principe « un octet = un caractère » a très longtemps prédominé. Il a été décliné en de nombreux jeux de 256 caractères (certains reprenant l'ASCII pour les 128 premières positions et complétant les 128 suivantes). La série des jeux de caractères normalisés ISO 8859 fonctionne de cette manière. L'ISO 8859-1, également appelé latin-1 ou occidental (western) comprend (presque) tous les caractères nécessaires pour écrire une vingtaine de langues d'Europe occidentale comme le français et l'anglais, tandis que l'ISO 8859-6 fournit les caractères arabes et que l'ISO 8859-15 (latin-9) est une version réactualisée du latin-1 comprenant, entre autres, le caractère euro et la ligature oe.

Unicode a pour but de fournir un jeu de caractères unique pour représenter toutes les langues. Cela permet notamment de gérer des textes multi-alphabétiques, par exemple ceux d'un dictionnaire français-arabe. Comme cela nécessite beaucoup plus de 256 caractères, les jeux Unicode utilisent plusieurs octets. Pour rester comptabible avec les jeux mono-octet, Unicode permet d'utiliser des caractères de taille variable, de 1 à 4 octets pour le jeu UTF-8, potentiellement plus de 4 milliards de caractères différents.

Remarque : Si, à cause de mauvais paramétrages, un caractère Unicode codé sur plusieurs octets est interprété comme mono-octet, il sera représenté par plusieurs caractères, d'où par exemple la transformation du é en A©.

MySQL vous permet d'utiliser différents jeux de caractères, mono-octet et multi-octets.

Quelques commandes pour interroger la liste des jeux installés sur votre serveur MySQL, à utiliser, par exemple, dans une fenêtre SQL de PhpMyAdmin :
- Liste de tous les jeux de caractères disponibles sur votre MySQL
SHOW CHARACTER SET ;
- Liste des jeux de caractères fondés sur l'alphabet latin
SHOW CHARACTER SET LIKE 'latin%' ;
- Liste des jeux de caractères multi-octets
SELECT *
FROM Information Schema.Character_Sets
WHERE MaxLen > 1;

En plus du jeu de caractère, MySQL permet de choisir comment les données seront classées (ORDER BY) par ce qui est appelé une « collation » (COLLATE). Ceci permet de répondre, par exemple, au problème classique de la sensibilité à la casse :
- Les majuscules doivent-elles précéder les minuscules, ou bien faut-il considérer A et a comme de même valeur ?
- La sensibilité aux accents : comptent-ils dans le tri ? Font-ils une différence lors de la recherche ?
- La possibilité qu'un caractère (ligature oe) puisse correspondre à plusieurs (o suivi de e) : c'est ce qu'Unicode appelle « l'expansion ».
C'est pour formaliser ces choix qu'ont été inventées les collations (Le terme anglais signifie à la fois « rassemblement » et « comparaison » ; collation est parfois traduit par « interclassement »). Une collation est liée à un jeu de caractères. Elle donne à la fois l'ordre dans lequel classer les caractères, et si certains d'entre eux doivent être considérés comme équivalents. Chaque jeu de caractère possède plusieurs collations, dont une par défaut.
Quelques commandes pour interroger la liste des collation installées sur votre serveur MySQL, à utiliser, par exemple, dans une fenêtre SQL de PhpMyAdmin :
- Liste des collations du jeu latini
SHOW COLLATION LIKE 'latinl%' ;
- Liste des collations du jeu utf8
SHOW COLLATION LIKE 'utf8%' ;
Toutes les collations ont un nom qui commence par le jeu de caractère auquel elles sont liées, et se terminent par l'une de ces trois abréviations :
- _bin comme binary : les caractères sont dans l'ordre de leurs numéros de code (ce qui donne d'abord toutes les majuscules, puis toutes les minuscules, puis les lettres accentuées, en vrac).
- _cs comme case sensitive : les caractères sont triés selon le ou les langages de référence, mais de manière sensible à la casse.
- _ci comme case insensitive : idem, mais en ignorant la casse.

Pour que vous puissiez faire les choix qui conviennent, il faut explicitement déclarer le jeu de caractère et la collation utilisés jusqu'au niveau de la colonne (Champ), sinon, ce sont les valeurs par défaut du niveau supérieur qui s'appliquent : Les données utilisent le jeu de caractères et la collation de leur colonne. Si le jeu et la collation n'ont pas été spécifiés pour la colonne, ce sont ceux de la table. Si ceux de la table n'ont pas été spécifiés, ce sont ceux de la base, et si ceux de la base n'ont pas non plus été spécifiés, ce sont le jeu et la collation par défaut du serveur. Voilà comment on se retrouve à avoir, presque partout, latin1_swedish_ci comme collation, MySQL AB étant une société suédoise.

- Changer le jeu de caractères et la collation aux niveaux supérieurs (serveur, base ou table) n'a pas de conséquence immédiate : seuls les nouveaux objets créés utiliseront ces valeurs par défaut.
- Changer la collation d'une colonne, en restant dans le même jeu de caractères, se fait sans difficulté. En effet, cela n'affecte pas les données elles-mêmes, mais la façon dont elles sont traitées. Lors du prochain Select, les tris et recherches se comportent différemment.
- Changer le jeu de caractères d'une colonne convertit les données vers le nouveau jeu. Cela peut poser un problème si certains caractères de l'ancien jeu n'ont pas d'équivalent dans le nouveau jeu.

Le jeu de caractères et la collation des requêtes

Ces valeurs dépendent des paramètres du client MySQL.
À chaque ouverture de sessions, MySQL renseigne quatre variables système :

- Le jeu de caractères que le client utilise en saisie, cette indication est enregistrée dans la variable @@character_set_client.
- Le jeu de caractères utilisé pour la communication entre le client et MySQL (@@character_set_connection) : la collation par défaut de ce jeu de caractères détermine la @@collation_connection.
- Le jeu de caractères utilisé pour afficher le résultat des requêtes dans le client (@@character_set_results).

Le texte de la requête est interprété selon le jeu du client, puis converti dans le jeu de la connexion (@@character_set_connection et @@collation_connection). MySQL envoie ensuite le résultat en utilisant à nouveau le @@characterset_connection, puis en le convertissant ensuite en @@character_set_results.
Pour connaître la valeur des variables système liées aux jeux et collations, lancer les requêtes suivantes :
- Affichage de l'ensemble des variables systèmes liées aux jeux de caractères et collations :
SHOW VARIABLES LIKE 'char%';
SHOW VARIABLES LIKE 'colla%'';

Outre les quatre variables citées ci-dessus, on retrouvera les jeux et collations par défaut du serveur et de la base de données en cours. Quant au @@character_set_system, c'est celui que MySQL utilise pour enregistrer les métadonnées, c'est-à-dire les noms des bases, tables, colonnes, etc. Il s'agit toujours d'utf8.

Sur un serveur local, par exemple avec Wampserver ou EasyPHP, les valeurs par défaut peuvent être modifiées dans le fichier my.ini :
# CLIENT SECTION
[client]
[mysql]
default-character-set=latin1
# SERVER SECTION
[mysqld]
#Jeu de caractères par défaut utilisé lors de la création de tables
#lorsque celui-ci n'est pas explicitement défini.
default-character-set=latin1

Sous Windows XP SP3 avec PhpMyAdmin 3.1.5 et MySQL 5.1.34 avec, dans le fichier my.ini les valeurs ci-dessus :

SHOW VARIABLES LIKE 'char%';
character_set_client utf8
character_set_connection utf8
character_set_database latin1
character_set_filesystem binary
character_set_results utf8
character_set_server latin1
character_set_system utf8

SHOW VARIABLES LIKE 'colla%';
collation_connection utf8_unicode_ci
collation_database latin1_swedish_ci
collation_server latin1_swedish_ci

--- Éventuels problèmes avec la console MySQL
L'utilisation de la console MySQL texte sous Windows peut être "vicieux" et réserver des surprises !
Le jeu de caractère du client texte, tout en étant déclaré latin1 est en fait cp850 (Enfin, pas toujours, ça dépend des API).

Pour s'en convaincre, il suffit de lancer dans une console MySQL :
SHOW VARIABLES LIKE 'char%';
USE test;
Puis choisir une champ d'une table CHARSET=latin1 et comportant des caractères accentués.
Pour cela j'utilise une table test avec un champ test (latin1) contenant "éèàù ÉÈÀÙ ç Ç" et rempli avec PhpMyAdmin, donc en "vrai" latin1.
SELECT test FROM test;
Les "é" sont transformés en "ù" et les autres caractères en ÚÞÓ¨ ++++ þ Ã
Si le jeu de caractères de la console était bien latin1, cela ne devrait pas arriver.
SET NAMES cp850;
Et refaire le select. Les caractères accentués sont bons.

Un bon moyen de voir quel est le jeu de caractères de la console est de lancer une requête est d'indiquer à MySQL quel est le jeu de caractère d'une chaîne littérale en la faisont précéder d'un introducteur :

SELECT _latin1'été', _utf8'été', _cp850'été';

Une chaîne littérale précédée d'un introducteur est envoyée telle quelle à MySQL, quelles que soient les variables @@character_set_client et @@character_set_connexion, MySQl l'interprète selon le jeu indiqué par l'introducteur, puis la renvoie.

--- Règles relatives aux noms des « objets » MySQL : bases, tables, colonnes, etc.
- Longueur de 64 caractères maximum.
- Certains caractères (en particulier l'espace) y sont soit interdits, soit déconseillés ; pour éviter tous les problèmes, n'utilisez que les lettres sans accent, les chiffres et le tiret de soulignement ou underscore (_) ; ne commencez pas par un chiffre et adoptez une politique de casse cohérente et commune à tous vos objets. (À mon humble avis, le plus simple est le « tout minuscules », mais vous pouvez adopter le type « Nom Propre », c'est-à-dire la première lettre en majuscule).
- Ils ne doivent pas être identiques â des termes du langage SQL, comme Create, Use, Select, Join, etc.

--- Majuscules, minuscules ---
Les règles relatives à la casse (c'est-à-dire le choix entre majuscules et minuscules) changent avec le système d'exploitation :
- Les mots-clés du langage SQL et les noms de colonnes sont insensibles à la casse, c'est-à-dire qu'ils peuvent s'écrire indifféremment en majuscules ou en minuscules.
- Les noms des tables et des bases de données sont :
-- sensibles à la casse si MySQL est installé sur Linux
-- insensibles si MySQL est installé sur Windows
Cette différence est due au fait que MySQL enregistre bases et tables sous forme de fichiers ; or, Windows est insensible à la casse des noms de fichiers, tandis que Linux y est sensible.

Comme on peut changer d'hébergeur et donc, changer de système d'exploitation, il est préférable de toujours considérer les noms des objets MySQL comme sensibles, afin que les requêtes fonctionnent quel que soit le système d'exploitation.

En employant les mêmes règles pour les noms de variables et fichiers PHP, on s'affranchit d'erreurs potentielles.

MySQL permet de déclarer explicitement les jeux de caractères utilisés pour les bases, tables et colonnes. Différents jeux peuvent très bien cohabiter au sein d'une même base de données ou d'une table :
DROP TABLE IF EXISTS table_test;
CREATE TABLE IF NOT EXISTS table_test (
champ1 varchar(50) COLLATE latin1_general_ci NOT NULL,
champ2 varchar(50) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
champ3 varchar(50) CHARACTER SET latin2 NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci;

Il est tout-à-fait possible et même recommandé, tout en ayant des bases et tables déclarées latin1 (iso-8859-1) d'utiliser, pour les exportations et importations, des fichiers avec jeu de caractère utf-8 ; c'est d'ailleurs, (presque) toujours, le jeu de caractère par défaut des connexions MySQL.

icath · 01-10-2009 11:56:23

ok...

Ba je ne comprend plus rien, tout se contredit...

donc:

Sauf erreur, j'ai mis tout en latin1_general_ci. Je suis aller dans ma BDD et je suis allé dans chaque champs de chaque table, et j'ai fait "modifier" pour passe en latin_x.
J'ai lu sur internet: "Si la base est en utf8 et que la table est en latin1, la base sera en iso"... En gros je dois passer en latin7_x ?

Clairement, mes champs doivent être en latin7_x avec une base en iso?

?

Dernière modification par icath (01-10-2009 11:56:44)

Otomatic · 01-10-2009 12:13:08

Bonjour,

Relisez bien, calmement, lentement, tout ce que j'ai écrit.

Tout mettre en latin1_general_ci ne réglera, en rien, le problème des accents ; ça ne modifie QUE le classement (ORDER BY).

Toutes les tables doivent être avec DEFAULT CHARSET=latin1. Par exemple :

-- Structure de la table `punbb_posts`
--
DROP TABLE IF EXISTS `punbb_posts`;
CREATE TABLE IF NOT EXISTS `punbb_posts` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `poster` varchar(200) COLLATE latin1_general_ci NOT NULL DEFAULT '',
  `poster_id` int(10) unsigned NOT NULL DEFAULT '1',
  `poster_ip` varchar(15) COLLATE latin1_general_ci DEFAULT NULL,
  `poster_email` varchar(50) COLLATE latin1_general_ci DEFAULT NULL,
  `message` text COLLATE latin1_general_ci NOT NULL,
  `hide_smilies` tinyint(1) NOT NULL DEFAULT '0',
  `posted` int(10) unsigned NOT NULL DEFAULT '0',
  `edited` int(10) unsigned DEFAULT NULL,
  `edited_by` varchar(200) COLLATE latin1_general_ci DEFAULT NULL,
  `topic_id` int(10) unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `punbb_posts_topic_id_idx` (`topic_id`),
  KEY `punbb_posts_multi_idx` (`poster_id`,`topic_id`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci;

icath · 01-10-2009 12:55:05

Salut,

j'ai bien tout lu, mais étant un méga noob la dedans, je patauge total happy .

Donc si je fait copié/collé de ton script dans mon fichier punbb_posts, ca règle mon problème?

Otomatic · 01-10-2009 16:06:36

icath a écrit :

Donc si je fait copié/collé de ton script dans mon fichier punbb_posts, ca règle mon problème?

Bonjour,

Non... Comme je l'ai écrit (Merci de lire !) ce n'est qu'un exemple de ce que devrait être la structure d'une table de la base de données pour FluxBB.

Pour vérifier et, éventuellement modifier la structure des tables, il faut les exporter au format SQL.

Export des tables FluxBB
--- À suivre méthodiquement pas à pas --- C'est en allant doucement qu'on va le plus vite ---
Lancer PhpMyAdmin
Nota : Suivant les hébergeurs, cela ne s'appelle pas toujours PhpMyAdmin ; ce peut être Gestion des bases de données, Administration SQL, etc.

Vérifier dans l'Accueil (Home - Petite Maison)
-- Jeu de caractères pour MySQL : UTF-8 Unicode (utf8) - Impératif
-- Interclassement pour la connexion MySQL : utf8_unicode_ci

Choisir la Base de données à exporter
(Mysql et information_schema sont deux bases indispensables au fonctionnement de MySql et auxquelles on ne doit pas toucher).

Onglet Exporter

- Cadre de gauche Exporter
-- Choisir la ou les tables à exporter
-- Choisir le format :
Pour une sauvegarde permettant une éventuelle future restauration, le format SQL est le plus approprié.
De plus, c'est un format purement texte qui peut donc être édité et éventuellement découpé en plusieurs parties.

- Cadre de droite Options
-- Commentaires mis en en-tête : vide, mais on peut mettre un commentaire
-- Pas coché : Utiliser le mode transactionnel
-- Pas coché : Désactiver la vérification des clés étrangères
-- Mode de compatibilité SQL : NONE

- Cadre Structure : Cocher Structure
-- Coché : Ajouter DROP TABLE / VIEW / PROCEDURE / FUNCTION
-- Coché : Ajouter IF NOT EXISTS
-- Coché : Inclure la valeur courante de l'AUTO_INCREMENT
-- Coché : Protéger les noms des tables et des champs par des "`"
-- Pas coché : Ajouter CREATE PROCEDURE / FUNCTION (Sauf si vous avez des procédures stockées)

- Cadre Inclure sous forme de commentaires
-- Au choix, coché ou non coché : Dates de création/modification/vérification

- Cadre Données : Cocher Données
-- Coché : Insertions complètes
-- Coché : Insertions étendues
-- Taille maximum de la requête générée : 50000
-- Pas coché : Insertions avec délais (DELAYED)
-- Pas coché : Ignorer les erreurs de doublons (INSERT IGNORE)
-- Coché : Utiliser l'hexadécimal pour les BLOB
-- Type d'exportation : INSERT

- Cocher Transmettre
-- Modèle de nom de fichier : __DB__
-- Jeu de caractères du fichier: utf-8 (Impératif)
-- Compression : Valider aucune

Valider le bouton Exécuter puis choisir l'endroit de la sauvegarde et éventuellement le nom du fichier.
Personnellement : nom_base_(préfixe_tables ou nom_table ou totale)_année-mois-jour.sql

Voilà, votre base (ou vos tables) sont sauvegardées.

Le fichier étant au format texte, avec un éditeur de texte (Notepad++, gratuit, est recommandé, mais surtout pas un traitement de texte comme Word ou Open Office), vous pourrez éditer le fichier, modifier des valeurs (Attention, quand même à ce que vous faites...), extraire et sauvegarder une seule table, etc.

Vous allez donc vérifier que le charset par défaut de toutes les tables est bien latin1 et éventuellement le modifier en ouvrant le fichier sauvegardé avec Notepad++ et en regardant que la ligne de fin de toutes les structures comprend bien :

) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci

avec, éventuellement, en plus et selon les tables :

AUTO_INCREMENT=xxxxx ;

Donc, si il n'y a pas "DEFAULT CHARSET=latin1" sur la dernière ligne de création des structures pour TOUTES les tables, vous modifiez ou ajoutez.

Pour l'exemple, la structure de la table posts doit être - à la valeur de l'auto incrément près :

--
-- Structure de la table `punbb_posts`
--

DROP TABLE IF EXISTS `punbb_posts`;
CREATE TABLE IF NOT EXISTS `punbb_posts` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `poster` varchar(200) collate latin1_general_ci NOT NULL default '',
  `poster_id` int(10) unsigned NOT NULL default '1',
  `poster_ip` varchar(15) collate latin1_general_ci default NULL,
  `poster_email` varchar(50) collate latin1_general_ci default NULL,
  `message` text collate latin1_general_ci NOT NULL,
  `hide_smilies` tinyint(1) NOT NULL default '0',
  `posted` int(10) unsigned NOT NULL default '0',
  `edited` int(10) unsigned default NULL,
  `edited_by` varchar(200) collate latin1_general_ci default NULL,
  `topic_id` int(10) unsigned NOT NULL default '0',
  PRIMARY KEY  (`id`),
  KEY `punbb_posts_topic_id_idx` (`topic_id`),
  KEY `punbb_posts_multi_idx` (`poster_id`,`topic_id`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci AUTO_INCREMENT=1955 ;

-- --------------------------------------------------------

Une fois toutes les vérifications/modifications effectuées, vous sauvegardez le fichier modifié pour vous allez procéder à l'importation dudit fichier toujours via PhpMyAdmin ou ce qui en tient lieu :

Lancer PhpMyadmin

Choisir la Base de données à restaurer (Même pour une seule table de cette base)
Onglet Importer
(Pour certaine versions limitées de PhpMyadmin, il faudra choisir l'onglet SQL)
- À l'aide du bouton Parcourir, choisir le fichier précédemment sauvegardé.
- Jeu de caractères du fichier : utf8 (Impératif)
- Coché ou pas coché : Importation partielle
-- Nombre d'enregistrements (requêtes) à ignorer à partir du début : 0
- Format du fichier d'importation : SQL
- Options
-- Mode de compatibilité SQL : NONE
- Valider le bouton Exécuter

Attendre la fin des opérations et le message de bonne excution du genre :
L'importation s'est terminée avec succès, xxx requêtes exécutées.

Otomatic · 02-10-2009 10:09:05

Bonjour,

Oui, mais à faire pour TOUTES les tables.

icath · 02-10-2009 19:27:04

Bonsoir,

désolé du retard, mais j'ai eu un empéchement hier. Merci beaucoup Otomatic!

mais...

Erreur
requête SQL:
-- phpMyAdmin SQL Dump
-- version 2.7.0-pl1
-- http://www.phpmyadmin.net
--
-- Serveur: 10.0.5.165
-- Généré le : Vendredi 02 Octobre 2009 à 16:50
-- Version du serveur: 4.99.99
-- Version de PHP: 4.4.1
--
-- Base de données: `i62***19`
--
CREATE DATABASE `i62***19` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci;
MySQL a répondu:Documentation
#1007 - Can't create database 'i62***19'; database exists

J'ai bien vérifié dans le fichier exporté de ma BDD, et je suis bien en Charset: Latin1

Le fait qu'il mette, latin1_swedish_ci (vu que les suedois n'utilise pas les accent), pourrais poser problème?
Normalement non, car tu m'as dit que passer tout en latin1 ne sert à rien...

Otomatic · 02-10-2009 19:34:49

icath a écrit :

CREATE DATABASE `i62***19` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci;

Supprimez la ligne dans le fichier sql avant d'effectuer l'importation.

icath a écrit :

Le fait qu'il mette, latin1_swedish_ci (vu que les suedois n'utilise pas les accent), pourrais poser problème ?

Ceci est la COLLATION, c'est-à-dire l'interclassement qui joue pour les instructions ORDER BY et n'a strictement rien à voir avec le charset.

Relire une de mes précédentes contributions :
MySQL, jeux de caractères et collation

Dernière modification par Otomatic (02-10-2009 19:35:18)

icath · 02-10-2009 19:42:55

J'ai bien supprimer la ligne, mais maintenant j'ai:

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'ï»¿
DROP TABLE IF EXISTS `bdd_bans`' at line 1

J'ai trop supprimé ou pas assez?

A savoir que quand j'ouver sous bloc note, la ce met les ligne bout à bout, donc pas évident de suppr une ligne correctement happy

EDIT: Moi y'en a débile, je viens d'ouvrir avec Word pad, et ca me le met en ligne... boulet...

Dernière modification par icath (02-10-2009 19:43:37)

icath · 02-10-2009 19:51:06

Bon... j'ai fait tout ce qu'il falait, l'importation a réussi (j'ai refait un export). Mais je n'ai toujours pas mes accents...

Otomatic · 02-10-2009 20:03:43

icath a écrit :

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'ï»¿

Tu remarques les trois caractères [large]ï»¿[/large].

Typique d'un fichier utf-8 enregistré avec BOM (Byte Mark Order).
L'option BOM - Marque d'ordre des octets, en anglais Byte Order Mark - est une séquence d'octets, généralement EF BB BF, qui apparaît en codage ISO-8859-1 comme "ï»¿" dans les éditeurs de textes et navigateurs. Ces trois octets étant présents avant même la lecture des instructions du fichier sont envoyés tels quels au décodeur PHP et, comme ils ne correspondent à aucune instruction, ils génèrent une erreur.

Le BOM sert à indiquer, pour le fichier considéré, quel est l'ordre des octets de codage des caractères sur 16 bits ou 32 bits : little endian (Octet de poids fort au début) ou big endian (Octet de poids fort à la fin).

La norme unicode n'impose pas toujours la marque d'ordre des octets en début de flux de données unicode et, en particulier pour UTF-8, où le BOM est non seulement facultatif, mais non recommandé puisque UTF-8 n'est lié à aucune problématique d'ordre des octets.

D'autre part, je n'ai parlé ni du bloc-note, ni de Word Pad, mais de Notepad++ qui sait très bien gérer les charset.

Néanmoins, avec Notepad++ - mais c'est valable avec d'autres éditeurs de texte - lorsque l'on recode ou édite un fichier en utf-8, par exemple avec l'option Format Convertir en UTF-8, il faut IMPÉRATIVEMENT utiliser l'option sans BOM.

icath · 02-10-2009 20:19:07

ok, j'ai tout refait et je suis passé par Notepad, mais ca ne marche toujorus pas.

ca me dit import reussi, mais mon fofo rejete toujours les accents

Otomatic · 03-10-2009 09:44:38

icath a écrit :

CREATE DATABASE `i62***19` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci;

Je parierais bien qu'à 99,99% ton problème vient de là.
Chez mes deux hébergeurs (Free et 1and1) ainsi qu'en local (Wampserver, Apache 2.2.13, PHP 5.3.0, MySQL 5.1.39) la base de données utilisée pour les tables FluxBB est déclarée :

CREATE DATABASE `ma_base` DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;

icath · 04-10-2009 20:30:07

Ce qui veut dire?

icath · 06-10-2009 17:59:06

Up, dsl de mon ignorance, mais quand on ne connait pas, on ne peut pas faire semblant...

Otomatic · 06-10-2009 18:25:08

Bonsoir,

Il semblerait que ta base de données ait été créée avec charset latin1 alors qu'elle devrait être utf-8

Archives FluxBB.fr

#1 30-09-2009 23:33:58

Problème d'accent

#2 01-10-2009 00:04:49

Re : Problème d'accent

#3 01-10-2009 06:37:50

Re : Problème d'accent

#4 01-10-2009 07:53:44

Re : Problème d'accent

#5 01-10-2009 08:13:59

Re : Problème d'accent

#6 01-10-2009 09:33:51

Re : Problème d'accent

#7 01-10-2009 09:36:28

Re : Problème d'accent

#8 01-10-2009 11:02:41

Re : Problème d'accent

#9 01-10-2009 11:13:39

Re : Problème d'accent

#10 01-10-2009 11:56:23

Re : Problème d'accent

#11 01-10-2009 12:13:08

Re : Problème d'accent

#12 01-10-2009 12:55:05

Re : Problème d'accent

#13 01-10-2009 16:06:36

Re : Problème d'accent

#14 02-10-2009 10:09:05

Re : Problème d'accent

#15 02-10-2009 19:27:04

Re : Problème d'accent

#16 02-10-2009 19:34:49

Re : Problème d'accent

#17 02-10-2009 19:42:55

Re : Problème d'accent

#18 02-10-2009 19:51:06

Re : Problème d'accent

#19 02-10-2009 20:03:43

Re : Problème d'accent

#20 02-10-2009 20:19:07

Re : Problème d'accent

#21 03-10-2009 09:44:38

Re : Problème d'accent

#22 04-10-2009 20:30:07

Re : Problème d'accent

#23 06-10-2009 17:59:06

Re : Problème d'accent

#24 06-10-2009 18:25:08

Re : Problème d'accent

Pied de page des forums