Discussion :

[ghismo]

Bonjour,

J'ai une application web constituée des éléments suivants :
- Ms SQL Server Enterprise Edition (8.00)
- un ensemble de composants enregistrés dans la console COM+ écrits en VB6
- un ensemble de pages ASP 3.0 encodées en UTF-8

Mon problème : je ne peux pas écrire dans ma base SQL de caractères japonais depuis mon interface web (formulaires web, qui s'adressent à une page ASP, qui instancie les composants COM+, qui à l'aide du provider sqloledb D'ADO écrivent en base). SQL Server ne prend que des '?'

A l'inverse, lorsque dans enterprise manager, je fait un copier-collé de mes caractères japonais, ils sont bien stockés, et le site les affiche correctement.

Petit détail : lorsque je substitue à ma base SQL server une base Access, ça marche correctement.

Où ai-je fait une boulette ? Des astuces, solutions ?

note : mes champs de BD son en NText, NVarchar.

[Fabien Celaia]

mauvaise conversion par rapport a l'Ansi.
Installez Unicode ...

[ghismo]

Je ne pense pas que le problème soit là.

Je n'ai pas - que je sâches, mais il se peut que je me trompes - de caractères ANSI dans ma chaîne de traitement.

Mes pages ASP sont utf-8 sur toute la ligne (encodées utf-8 avec le BOM, la directive ASP @codePage=65001, le tag meta html charset=utf-8),

Ces pages lorsqu'elle écrivent dans une base access, aucun pb, mes caractères sont stockés correctement et récupérés idem. Dans ce cas, j'utilise le provider ADO : Microsoft.Jet.OLEDB.4.0

Il n'y a que lorsque je pousse mes données dans une base sql que le pb survient. Mes champs sont déclarés en nvarchar, ntext, j'utilise le provider ADO : sqloledb

Lorsque je rempli mes champs en utilisant la MMC Enterprise Manager, mes caractères japonais sont stockés correctement, et récupérés sur mes pages ASP correctement, ce n'est que lorsque je fais une insert à partir des données saisies dans les formulaires html, que ça se gâte

J'ai l'impression que c'est la conversion utf-8 -> unicode qui se fait mal...

[SQLpro]

a ma connaissance ce n'est pas de l'UTF 8 qu'il faut utiliser mais plutôt de l'iso 1452 (de tête).

Les colonnes des tables sont-elles en unicode ?
Sinon, voir aussi du côté des collations.

A +

[ghismo]

Les colonnes des tables sont bien déclarées NText ou NVarchar.

L'application web en question est une application générique, et doit pouvoir permettre d'afficher n'importe quel caractère (arabe, thai, japonais, français, chinois, ...). D'où l'utilisation d'unicode, et d'UTF-8 sur les pages web (pour un gain en poids et donc en temps de transfert).

Je réalise mes tests en japonais, mais je dois être capable de tout afficher.

Coté collation, je suis pas très à l'aise (je connais mal), sur mes tables j'ai "database default", au niveau de la base, j'ai SQL_Latin1_General_CP1_CI_AS. j'avais regardé ça au début de mes problèmes mais n'avais pas trouvé de collation qui me paraisse mieux adaptée. Puisque comme, je viens de l'indiquer, ma table doit pouvoir stocker tout caractère de toutes langues, ce qui tourne depuis longtemps sans probleme avec une base access.

[ghismo]

J'ai trouvé ma solution.

Il faut prefixer les chaîne d'un N dans les requetes d'insertion et de modification.

Par exemple :

UPDATE MaTable SET monChamps= N'Mes caractères japonais' WHERE monId=1