[Php/SqlServer] Pb unicode

Logiciel & apps Programmation
1

Je suis habitué à .NET, là jai quelque problème en php :

  • Sous sql server, une table contenant un champ ntext ou nvarchar (donc unicode)
  • Php semble incapable de lire ce type de champs correctement. Donc : SELECT CAST(champ AS text)
  • Sous l’analyseur de requete de SqlServer, un enreg avec “é” s’affiche correctement.
  • Sous php, il lit, mais n’affiche pas correctement le “é”

D’où ces quelques questions :

  • Nativement, php fonctionne en ascii ? en unicode ?
  • Existe-t-il un moyen de lui dire de générer de l’unicode, de spécifier le charset de sortie ? Encode-t-il tout seul ? Si non, comment encoder correctement les buffers renvoyés ?
  • Comment lire correctement un champ ntext / nvarchar ? Comment l’afficher correctement ? Pourquoi le support de ce genre de champs ne semble encore implémenté ?
  • Question subsidiaire : y-a-t-il un moyen quelconque de faire du debug pas à pas dans un script php ?
2

Up :slight_smile:

Y-a-personne qui connait bien php ?

3

php gère l’unicode nativement pour la lecture et le parsing des pages php. Mais ça doit être tes chaînes qui sont multibyte.

http://fr.php.net/manual/fr/ref.mbstring.php

Sinon as tu songé à mettre un petit
header( ‘Content-Type: …; charset=utf-8’ );

?

4

Oui mes chaines sont multibyte.

Ton lien confirme mes craintes, php est nativement 8 bits (donc ASCII ou equivalent). Ca m’étonne quand même et c’est “un peu” ennuyeux lol.

5

Oui enfin, avec mbstring, ça devrait aller. (même si bon, l’utf… si tu ne parles qu’une langue dans tout ton site, ça sert à rien)

[edit] sinon, peut être que SQL Server autorise les Collations, du genre transformer ton champ utf en latin1?

6

Ouais bon, c’est peut etre une solution mais cest pas natif, faut installer des trucs en plus, et surtout, php est incapable de lire du nvarchar ou du ntext sous sql server.

Les champs unicode étant justement là pour éviter de se prendre la tête avec des conversion débiles. Sous .NET, c’est natif, les string sont unicodes en interne, tu lit la base, tu balances et c’est fini. Et les conversion unicode/ut8/ascii sont nativement disponibles aussi.

Pour les collations jamais testé, mais si ca joue sur la structure même des tables c’est pas possible, les sites sont multi-langue, il faut l’unicode, pas le choix.

C’est pas que je dénigre php, bien au contraire, chacun a ses avantages et ses inconvénients, mais ca m’étonne quand même que les développeurs aient loupé un truc pareil pour un language aussi répandu…

On va tester le mbstring, je vous tiendrai au courant…