remplacer caractère

par **Invité** » 01 avr. 2007, 09:37

précision, la requête n'est pas générée par du php. Elle est dans un fichier qui est créé à l'exporation depuis phpmyadmin.

par **Invité** » 31 mars 2007, 15:45

AAAch, une bonne âme! G viens de faire une nuit blanche à copier coller des dizaines de rubriques en passant par l' éditeur de mon CMS.

Mon code :

$fichier = fopen('monfichier.sql', 'r+');
$data = fread($fichier, filesize('monfichier.sql'));
$query  = mysql_real_escape_string($data);
$result = mysql_query($query);

ça marche parfaitement, sauf s'il y a du html dans la requete. Le html est "brut" dans le fichier ouvert, çàd sans traitement des "" qui entourent les atributs de balises. Il y a aussi des apostrophes dans le texte qui est entouré de balises.

par **Hubert Roksor** » 31 mars 2007, 09:31

Normalement c'est mysql_real_escape_string() que l'on doit utiliser (et par "normalement" je veux dire "absolument tout le temps") mais quelque chose me dit que tu utilises une surcouche pour communiquer avec la base de données. Montre les 5 lignes de PHP qui génèrent/exécutent la requête pour voir ?

par **Invité** » 31 mars 2007, 01:44

comment un éditeur wysiwyg fait pour enregistrer du html dans une bdd?

par **Invité** » 31 mars 2007, 01:28

je précise que toutes les requetes fonctionnent sauf celles qui contiennent du html...

par **Invité** » 31 mars 2007, 01:24

et quand j'affiche mon fichier .sql avec php, j'ai ceci

CREATE TABLE `jos_content` (\n `id` int(11) unsigned NOT NULL auto_increment,\n `title` varchar(100) NOT NULL default \'\',\n `

On voit des \n en plein milieu de la requete. Pourtant cette requete vient directement d'un export phpmyadmin zippé, g pas touché.

J'ai vraiment besoin d'aide, déjà 8 heures que j'appuie sur enter en testant toutes les fonctions imaginables:
addslashes, stripslashes, mysql_escape_string, mysql_real_escape_string, nl2br...sans compter les combinaisons imbriquées de toutes ces fonctions.

ça devrait pas être tout simple de passer d'une bdd à l'autre, surout si c'est la même vesoin de mysql en ligne et en local?

par **Invité** » 31 mars 2007, 00:04

Bon je confirme, il n'ya que les requetes contenant du html qui buggent.
Comment dois-je traiter du html brut avant de l'insérer dans mysql?

par **Invité** » 30 mars 2007, 22:39

dans mon message d'erreur, mysql tente de localiser le passage qui gêne. Je remarque que les clauses INSERT INTO et VALUES de ma requête sont en gras, pas de pb.

Mais dans mon contenu, il y a du texte en anglais, contenant le mot "to".
Il est formaté comme les deux instructions citées précédemment.
Se pourrait-il que mysql considère ce mot comme une instruction, alors que c'est juste du texte?

par **Expreg** » 30 mars 2007, 20:47

Le remplacement des caractères spéciaux est de l'ordre de l'affichage, pas de la mémorisation.

Je plussoies cette remarque remplie de bon sens !
Cette remarque qui devrait être affichée partout comme règle générale sur tous les sites traitant de Php/Mysql

par **Invité** » 30 mars 2007, 19:37

voici l'essentiel de l'erreur:

Il semble qu'il y ait une erreur dans votre requête SQL. Le message ci-bas peut vous aider à en trouver la cause.

ERROR: Ponctuation invalide @ 1
STR: \\
SQL: \\r\\n\', 1, 0, \'0000-00-00 00:00:00\', NULL, 6, 0, 0, \'\'); INSERT INTO `jos_categories` (`id`, `parent_id`, ....................

#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 '\\r\\n\', 1, 0, \'0000-00-00 00:00:00\', NULL, 6, 0, 0, \'\');

Ce que vous voyez ci dessus est passé dans un stripslashes(), qui ne marche pas mieux qu'addslashes().

par **Invité** » 30 mars 2007, 19:33

j'ai tenté addslashes() qui me renvoie des erreurs de syntaxe. C'est tout le contenu d'une bdd joomla que j'essaye d'importer en une fois.

ça marchait bien en local, mais pas moyen d'exporter. Pourtant c'est une exportation zippée de ma bdd, j'y ai pas touché.

par **Invité** » 30 mars 2007, 19:30

super, ça marche bien. Tu viens de m'enlever un poteau de l'orteil. Et que dois-je utiliser comme fonction de traitement pour importer du code et html et des caractères comme { } dans une bdd mysql?

par **Hubert Roksor** » 30 mars 2007, 18:33

Codage de caractères. Ton "Ã©" c'est un "é" encodé en UTF-8 mais visualisé en ISO-8859-1 (ou assimilé). Si tu déclares le bon codage dans la page web tes problèmes disparaissent. Pareil pour MySQL, il faut lui préciser quel codage tu utilises, sinon tu as ce genre de problèmes. Je n'ai pas de lien sous la main, si quelqu'un a quelque chose qu'il se dénonce.

Pour résumer, dans la page HTML

Code : Tout sélectionner

meta http-equiv="Content-Type" content="text/html;charset=utf-8" />

ET/OU en PHP (y'a même une option dans php.ini)

header('Content-Type: text/html;charset=utf-8');

Et dans my.ini,

Code : Tout sélectionner

[client]
default-character-set=utf8

[mysql]
default-character-set=utf8

[mysqld]
default-character-set=utf8

Félicitations, maintenant tout ton système est en UTF-8. Mauvaise nouvelle, strtolower(), substr() et d'autres fonctions ne fonctionneront plus correctement...* voir mb_substr() ou iconv_substr() pour plus d'infos.

* jusqu'à ce que tu upgrades vers PHP 6 l'année prochaine

par **Invité** » 30 mars 2007, 18:20

ben mon pb est que lorsque j'insère du contenu brut, les caractères spéciaux deviennent illisibles, commme
"Ã©" pour "é",
"Ãª" pour "ê",
"Ã¯" pour "Ï",...

Ce que je ne comprends pas, c'est que ma version du site en local n'a pas ce pb. Pourtant pour la mise en ligne, je fais un transfert par copier/coller du sql, d'une bdd à l'autre.

Encore plus étrange, quand je suis sur hotmail, mes caractères spéciaux sont illisibles de la même manière.

Je sais pas d'ou vien ce pb de bdd mais ça m'est arrivé juste avant une présentation de site et j'ai du me taper tous les caractères à la mano. Arrgh.

par **zeus** » 30 mars 2007, 10:02

La base de données ne devrait pas contenir de données encodées, seulement des données brutes, c'est à dire avec accents.

J'imagine que le but de cette opération est d'avoir des données prêtes à l'affichage, non ? Imagine que tu veuilles désormais les enregistrer dans un fichier, cet encodage va te poser des soucis.

Le remplacement des caractères spéciaux est de l'ordre de l'affichage, pas de la mémorisation.

remplacer caractère

Répondre

Étendre la vue Revue du sujet : remplacer caractère