Bonjour,
J'essaye de lire et d'écrire avec PHP dnas une base unicode (SQL Server) et
je n'y arrive pas.
J'ai ajouté la dll MbString qui est censée faire les conversions, mais il ne
se passe rien. J'ai toujours ???? ??? à la place de la chaîne de caractères
russe que j'ai saisi dans ma base.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
loufoque
Eric a dit le 25/10/2005 à 14:54:
J'essaye de lire et d'écrire avec PHP dnas une base unicode (SQL Server) et je n'y arrive pas.
Ce n'est pas une bonne description du problème.
J'ai ajouté la dll MbString qui est censée faire les conversions
Quel est l'intérêt de faire des conversions ?
, mais il ne se passe rien.
S'il ne se passe rien, c'est que tu n'as pas mis de code pour qu'il se passe quelque chose.
J'ai toujours ???? ??? à la place de la chaîne de caractères russe que j'ai saisi dans ma base.
Tu as indiqué au client utiliser le même charset que celui dans lequel sont les données ? Encore faudrait-il que tu sois certain du charset dans lequel sont ces données, et si tu commences à faire des conversions c'est pas bon du tout d'autant plus que tu auras forcément des pertes.
Quelqu'un aurait-il une solution ?
Appliquer le bon sens, comme dans la plupart des problèmes triviaux.
Eric a dit le 25/10/2005 à 14:54:
J'essaye de lire et d'écrire avec PHP dnas une base unicode (SQL Server) et
je n'y arrive pas.
Ce n'est pas une bonne description du problème.
J'ai ajouté la dll MbString qui est censée faire les conversions
Quel est l'intérêt de faire des conversions ?
, mais il ne
se passe rien.
S'il ne se passe rien, c'est que tu n'as pas mis de code pour qu'il se
passe quelque chose.
J'ai toujours ???? ??? à la place de la chaîne de caractères
russe que j'ai saisi dans ma base.
Tu as indiqué au client utiliser le même charset que celui dans lequel
sont les données ?
Encore faudrait-il que tu sois certain du charset dans lequel sont ces
données, et si tu commences à faire des conversions c'est pas bon du
tout d'autant plus que tu auras forcément des pertes.
Quelqu'un aurait-il une solution ?
Appliquer le bon sens, comme dans la plupart des problèmes triviaux.
J'essaye de lire et d'écrire avec PHP dnas une base unicode (SQL Server) et je n'y arrive pas.
Ce n'est pas une bonne description du problème.
J'ai ajouté la dll MbString qui est censée faire les conversions
Quel est l'intérêt de faire des conversions ?
, mais il ne se passe rien.
S'il ne se passe rien, c'est que tu n'as pas mis de code pour qu'il se passe quelque chose.
J'ai toujours ???? ??? à la place de la chaîne de caractères russe que j'ai saisi dans ma base.
Tu as indiqué au client utiliser le même charset que celui dans lequel sont les données ? Encore faudrait-il que tu sois certain du charset dans lequel sont ces données, et si tu commences à faire des conversions c'est pas bon du tout d'autant plus que tu auras forcément des pertes.
Quelqu'un aurait-il une solution ?
Appliquer le bon sens, comme dans la plupart des problèmes triviaux.
dmetzler
J'essaye de lire et d'écrire avec PHP dnas une base unicode (SQL Server) et je n'y arrive pas.
OK, c'est une base unicode, mais quel encodage utilise-tu ?
Ensuite, PHP ne gère pas unicode en natif. Pour convertir ces chaines, j'utilise la fonction iconv.
Ce qu'il faut savoir aussi, c'est quel encodage tu envoies au navigateur. Si tu dis au navigateur d'utiliser IS0-8859-1 il n'affichera pas les caractères UTF-8 par exemple. Pour spécifier l'encodage d'une page web, il suffit d'ajouter dans l'entête :
Ensuite il faut que tu sois sur d'envoyer de l'UTF-8 à ton client.
En gros, si tu a besoin de caractères russe, le mieux est de tout faire en UTF-8. Tu rappatrie les données de ta base SQL-Server. Si elles sont dans autre chose que UTF-8, il faut les convertir avec iconv.
Ensuite quant tu génère ta page HTML, il faut la générer en UTF-8 et placer le petit entête pour dire au navigateur qu'on lui envoit de l'UTF-8
Petit rappel : http://french.joelonsoftware.com/Articles/Unicode.html (non je n'ai pas d'action chez lui, mais c'est le premier article qui m'a vraiment fait comprendre unicode)
J'essaye de lire et d'écrire avec PHP dnas une base unicode (SQL Server) et
je n'y arrive pas.
OK, c'est une base unicode, mais quel encodage utilise-tu ?
Ensuite, PHP ne gère pas unicode en natif. Pour convertir ces chaines,
j'utilise la fonction iconv.
Ce qu'il faut savoir aussi, c'est quel encodage tu envoies au
navigateur. Si tu dis au navigateur d'utiliser IS0-8859-1 il
n'affichera pas les caractères UTF-8 par exemple. Pour spécifier
l'encodage d'une page web, il suffit d'ajouter dans l'entête :
Ensuite il faut que tu sois sur d'envoyer de l'UTF-8 à ton client.
En gros, si tu a besoin de caractères russe, le mieux est de tout
faire en UTF-8.
Tu rappatrie les données de ta base SQL-Server. Si elles sont dans
autre chose que UTF-8, il faut les convertir avec iconv.
Ensuite quant tu génère ta page HTML, il faut la générer en UTF-8
et placer le petit entête pour dire au navigateur qu'on lui envoit de
l'UTF-8
Petit rappel : http://french.joelonsoftware.com/Articles/Unicode.html
(non je n'ai pas d'action chez lui, mais c'est le premier article qui
m'a vraiment fait comprendre unicode)
J'essaye de lire et d'écrire avec PHP dnas une base unicode (SQL Server) et je n'y arrive pas.
OK, c'est une base unicode, mais quel encodage utilise-tu ?
Ensuite, PHP ne gère pas unicode en natif. Pour convertir ces chaines, j'utilise la fonction iconv.
Ce qu'il faut savoir aussi, c'est quel encodage tu envoies au navigateur. Si tu dis au navigateur d'utiliser IS0-8859-1 il n'affichera pas les caractères UTF-8 par exemple. Pour spécifier l'encodage d'une page web, il suffit d'ajouter dans l'entête :
Ensuite il faut que tu sois sur d'envoyer de l'UTF-8 à ton client.
En gros, si tu a besoin de caractères russe, le mieux est de tout faire en UTF-8. Tu rappatrie les données de ta base SQL-Server. Si elles sont dans autre chose que UTF-8, il faut les convertir avec iconv.
Ensuite quant tu génère ta page HTML, il faut la générer en UTF-8 et placer le petit entête pour dire au navigateur qu'on lui envoit de l'UTF-8
Petit rappel : http://french.joelonsoftware.com/Articles/Unicode.html (non je n'ai pas d'action chez lui, mais c'est le premier article qui m'a vraiment fait comprendre unicode)
Patrick Mevzek
Le Thu, 03 Nov 2005 13:09:29 +0000, a écrit :
n'affichera pas les caractères UTF-8 par exemple. Pour spécifier l'encodage d'une page web, il suffit d'ajouter dans l'entête :
Non. Pour spécifier l'encodage des pages Web, on génére le bon entête Content-Type, et c'est tout. (oui en mettant dans le meta ca marche ``en gros'', mais cela ne fera que créer des problèmes, et ce n'est pas la bonne façon de faire)
Ensuite quant tu génère ta page HTML, il faut la générer en UTF-8 et placer le petit entête pour dire au navigateur qu'on lui envoit de l'UTF-8
Et cet en-tête se situe au niveau HTTP (c'est bien pour cela qu'il s'appelle en-tête d'ailleurs) et pas au niveau HTML et sa balise META.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le Thu, 03 Nov 2005 13:09:29 +0000, dmetzler@myaccountingmail.com a écrit
:
n'affichera pas les caractères UTF-8 par exemple. Pour spécifier
l'encodage d'une page web, il suffit d'ajouter dans l'entête :
Non.
Pour spécifier l'encodage des pages Web, on génére le bon entête
Content-Type, et c'est tout.
(oui en mettant dans le meta ca marche ``en gros'', mais cela ne fera que
créer des problèmes, et ce n'est pas la bonne façon de faire)
Ensuite quant tu génère ta page HTML, il faut la générer en UTF-8
et placer le petit entête pour dire au navigateur qu'on lui envoit de
l'UTF-8
Et cet en-tête se situe au niveau HTTP (c'est bien pour cela qu'il
s'appelle en-tête d'ailleurs) et pas au niveau HTML et sa balise META.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Non. Pour spécifier l'encodage des pages Web, on génére le bon entête Content-Type, et c'est tout. (oui en mettant dans le meta ca marche ``en gros'', mais cela ne fera que créer des problèmes, et ce n'est pas la bonne façon de faire)
Ensuite quant tu génère ta page HTML, il faut la générer en UTF-8 et placer le petit entête pour dire au navigateur qu'on lui envoit de l'UTF-8
Et cet en-tête se situe au niveau HTTP (c'est bien pour cela qu'il s'appelle en-tête d'ailleurs) et pas au niveau HTML et sa balise META.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
dmetzler
Merci pour cette petite clarification....
Quels peuvent être les problèmes à utiliser la balise meta plutot qu'un entête HTTP ? Pour ma part j'évite les entêtes HTTP à part pour le cache.... (je sais pas pourquoi... surement la fainéantise...). Tu dis que ça marche "en gros", mais moi j'ai jamais vu où ça marchait pas.... Je suis intéressé pour des cas où ça marche pas !
En tout cas, pour des pages statiques, on peut pas envoyer de header comme ça. Donc soit c'est Apache qui se charge d'envoyer le header (et souvent il se plante), soit on met la balise meta de toute façon.
Merci pour cette petite clarification....
Quels peuvent être les problèmes à utiliser la balise meta plutot
qu'un entête HTTP ? Pour ma part j'évite les entêtes HTTP à part
pour le cache.... (je sais pas pourquoi... surement la
fainéantise...). Tu dis que ça marche "en gros", mais moi j'ai jamais
vu où ça marchait pas.... Je suis intéressé pour des cas où ça
marche pas !
En tout cas, pour des pages statiques, on peut pas envoyer de header
comme ça. Donc soit c'est Apache qui se charge d'envoyer le header (et
souvent il se plante), soit on met la balise meta de toute façon.
Quels peuvent être les problèmes à utiliser la balise meta plutot qu'un entête HTTP ? Pour ma part j'évite les entêtes HTTP à part pour le cache.... (je sais pas pourquoi... surement la fainéantise...). Tu dis que ça marche "en gros", mais moi j'ai jamais vu où ça marchait pas.... Je suis intéressé pour des cas où ça marche pas !
En tout cas, pour des pages statiques, on peut pas envoyer de header comme ça. Donc soit c'est Apache qui se charge d'envoyer le header (et souvent il se plante), soit on met la balise meta de toute façon.
loufoque
Ensuite, PHP ne gère pas unicode en natif. Pour convertir ces chaines, j'utilise la fonction iconv.
Il n'y a rien à convertir. Les chaînes de PHP peuvent parfaitement contenir de l'utf-8. Le seul problème, c'est que les fontions substr(), strpos() etc. ne sont pas "unicode aware".
A priori Unicode pour Microsoft c'est UCS-2, SQL Server ne devrait pas être une exception. Enfin peut-être tout de même utilise-t-il utf-8 pour la transmission des données.
Ensuite, PHP ne gère pas unicode en natif. Pour convertir ces chaines,
j'utilise la fonction iconv.
Il n'y a rien à convertir. Les chaînes de PHP peuvent parfaitement
contenir de l'utf-8.
Le seul problème, c'est que les fontions substr(), strpos() etc. ne sont
pas "unicode aware".
A priori Unicode pour Microsoft c'est UCS-2, SQL Server ne devrait pas
être une exception.
Enfin peut-être tout de même utilise-t-il utf-8 pour la transmission des
données.
Ensuite, PHP ne gère pas unicode en natif. Pour convertir ces chaines, j'utilise la fonction iconv.
Il n'y a rien à convertir. Les chaînes de PHP peuvent parfaitement contenir de l'utf-8. Le seul problème, c'est que les fontions substr(), strpos() etc. ne sont pas "unicode aware".
A priori Unicode pour Microsoft c'est UCS-2, SQL Server ne devrait pas être une exception. Enfin peut-être tout de même utilise-t-il utf-8 pour la transmission des données.
dmetzler
Oui c'est vrai que si t'es en full unicode du début à la fin, ya rien à convertir. Dans mon cas, ma base est en CP850 et ma sortie en UTF-8 donc il faut que je convertisse ce qui vient de la base.
sinon il parait que la version 6 de php devrait gérer unicode en natif (il y avait une info là dessus il y a qq temps sur le newsgroup)
Oui c'est vrai que si t'es en full unicode du début à la fin, ya rien
à convertir. Dans mon cas, ma base est en CP850 et ma sortie en UTF-8
donc il faut que je convertisse ce qui vient de la base.
sinon il parait que la version 6 de php devrait gérer unicode en natif
(il y avait une info là dessus il y a qq temps sur le newsgroup)
Oui c'est vrai que si t'es en full unicode du début à la fin, ya rien à convertir. Dans mon cas, ma base est en CP850 et ma sortie en UTF-8 donc il faut que je convertisse ce qui vient de la base.
sinon il parait que la version 6 de php devrait gérer unicode en natif (il y avait une info là dessus il y a qq temps sur le newsgroup)
Patrick Mevzek
Le Fri, 04 Nov 2005 14:30:06 +0000, a écrit :
Quels peuvent être les problèmes à utiliser la balise meta plutot qu'un entête HTTP ?
Ce sont les en-têtes qui l'emportent (ils sont prioritaires), et si donc ce n'est pas la même information de codage dans les deux, on va avoir des surprises.
Comme un serveur web bien configuré ne doit jamais laisser partir de page sans codage dans l'entête HTTP, une application doit prendre du temps pour le remplir plutôt que pour générer un en-tête meta, sinon ca n'ira pas bien si le choix par défaut du serveur n'est pas celui prévu par l'application.
fainéantise...). Tu dis que ça marche "en gros", mais moi j'ai jamais vu où ça marchait pas.... Je suis intéressé pour des cas où ça marche pas !
Cf plus haut, tiré directement de mon expérience : une vieille version de SPIP (mais je ne sais pas si c'est corrigé depuis) générait les meta mais pas l'en-tête HTTP. Le serveur ajoutait isolatin1 dans l'en-tête (s'il n'y avait pas déjà quelque chose). SPIP mettait utf8 dans les meta.
Dommage...
En tout cas, pour des pages statiques, on peut pas envoyer de header comme ça. Donc soit c'est Apache qui se charge d'envoyer le header (et souvent il se plante), soit on met la balise meta de toute façon.
Non. On configure Apache pour envoyer le bon en-tête.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le Fri, 04 Nov 2005 14:30:06 +0000, dmetzler@myaccountingmail.com a écrit
:
Quels peuvent être les problèmes à utiliser la balise meta plutot
qu'un entête HTTP ?
Ce sont les en-têtes qui l'emportent (ils sont prioritaires), et si donc
ce n'est pas la même information de codage dans les deux, on va avoir des
surprises.
Comme un serveur web bien configuré ne doit jamais laisser partir de page
sans codage dans l'entête HTTP, une application doit prendre du temps
pour le remplir plutôt que pour générer un en-tête meta, sinon ca
n'ira pas bien si le choix par défaut du serveur n'est pas celui prévu
par l'application.
fainéantise...). Tu dis que ça marche "en gros", mais moi j'ai jamais
vu où ça marchait pas.... Je suis intéressé pour des cas où ça
marche pas !
Cf plus haut, tiré directement de mon expérience : une vieille version
de SPIP (mais je ne sais pas si c'est corrigé depuis) générait les meta
mais pas l'en-tête HTTP.
Le serveur ajoutait isolatin1 dans l'en-tête (s'il n'y avait pas déjà
quelque chose).
SPIP mettait utf8 dans les meta.
Dommage...
En tout cas, pour des pages statiques, on peut pas envoyer de header
comme ça. Donc soit c'est Apache qui se charge d'envoyer le header (et
souvent il se plante), soit on met la balise meta de toute façon.
Non. On configure Apache pour envoyer le bon en-tête.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Quels peuvent être les problèmes à utiliser la balise meta plutot qu'un entête HTTP ?
Ce sont les en-têtes qui l'emportent (ils sont prioritaires), et si donc ce n'est pas la même information de codage dans les deux, on va avoir des surprises.
Comme un serveur web bien configuré ne doit jamais laisser partir de page sans codage dans l'entête HTTP, une application doit prendre du temps pour le remplir plutôt que pour générer un en-tête meta, sinon ca n'ira pas bien si le choix par défaut du serveur n'est pas celui prévu par l'application.
fainéantise...). Tu dis que ça marche "en gros", mais moi j'ai jamais vu où ça marchait pas.... Je suis intéressé pour des cas où ça marche pas !
Cf plus haut, tiré directement de mon expérience : une vieille version de SPIP (mais je ne sais pas si c'est corrigé depuis) générait les meta mais pas l'en-tête HTTP. Le serveur ajoutait isolatin1 dans l'en-tête (s'il n'y avait pas déjà quelque chose). SPIP mettait utf8 dans les meta.
Dommage...
En tout cas, pour des pages statiques, on peut pas envoyer de header comme ça. Donc soit c'est Apache qui se charge d'envoyer le header (et souvent il se plante), soit on met la balise meta de toute façon.
Non. On configure Apache pour envoyer le bon en-tête.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
loufoque
a écrit à :
sinon il parait que la version 6 de php devrait gérer unicode en natif (il y avait une info là dessus il y a qq temps sur le newsgroup)
Effectivement.
dmetzler@myaccountingmail.com a écrit à :
sinon il parait que la version 6 de php devrait gérer unicode en natif
(il y avait une info là dessus il y a qq temps sur le newsgroup)
