Lecture d'un fichier mixant du char * et de l'unicode
16 réponses
vdaanen
Bonjour,
j'ai besoin de permettre a un programme (sous windows XP) de parler
n'importe quelle langue.
Actuellement, nous pouvons gerer facilement les langues
'classiques' (francais, anglais, allemand, espagnol, etc..) enfin
toute celle dont les caracteres peuvent se coder sur 8 bits.
Or voila qu'on nous demande de supporter ... les chinois, l'h=E9breu,
l'indien etc..
voila ce que nous aimerions faire :
[NomDuChamp]
Valeur du Champ
ou nom du champ est en char 'std' (sur 8 bits quoi) et valeur du champ
est en unicode (pour supporter toutes les langues).
L'objectif etant d'afficher ces messages sur une interface
utilisateur.
C'est encore envisageable pour les langues occidentales, dans lesquelles peu de caractères sortent des 7 bits d'US-ASCII, mais pas du tout pour du japonais où tout ressemblerait à « 日本語版 »
Pour moi, c'est largement aussi lisible que des kanjis.
D'accord, mais ce n'est pas toi qui dois le saisir. Par ailleurs, je suppose que tu dois savoir distinguer au premier coup d'½il entre des kanjis japonais et de l'arabe ou de l'hébreu, par exemple, mais c'est beaucoup moins évident quand ils sont écrits sous forme numérique comme ci-dessus.
Par ailleurs, si le Japonais qui tape, utilise un éditeur capable de pondre ce genre de code, il peut facilement vérifier que le code est bon avec un navigateur.
Ah mais *si* il existe un éditeur capable de pondre ce genre de code, j'espère que le même éditeur sera tout aussi capable de le lire, et de montrer les kanji au Japonais qui fait la saisie. Dans ce cas, oui, pourquoi pas.
Malgré tout, d'une part je ne suis pas sûr qu'un tel éditeur existe, et d'autre part les fichiers pondus seraient trois fois plus gros que ceux écrits en UTF-8, et même quatre fois plus gros que ceux écrits en Shift_JIS. Je ne suis pas sûr que les utilisateurs soient vraiment convaincus du bien fondé de cette écriture.
Ensuite, une fois que j'ai ce code imbuvable, comme c'est du ASCII pur (32-127), je peux le faire passer par tous les filtres que je veux (SMTP, MySQL, etc.) sans problèmes.
Le faire passer, oui. Mais pas le rendre lisible à l'autre bout sans une grosse manipulation bien compliquée : je veux bien te payer une caisse du vin que tu veux si tu peux m'exhiber un courrielleur en mode texte et un visionneur MySQL (style PHPmyadmin) capables de transformer simplement ce texte en caractères lisibles par un japonais (sans même compter tous les autres outils que tu as laissés dans ton « etc. »).
C'est encore envisageable pour les langues occidentales, dans lesquelles
peu de caractères sortent des 7 bits d'US-ASCII, mais pas du tout pour
du japonais où tout ressemblerait à « 日本語版 »
Pour moi, c'est largement aussi lisible que des kanjis.
D'accord, mais ce n'est pas toi qui dois le saisir. Par ailleurs, je
suppose que tu dois savoir distinguer au premier coup d'½il entre des
kanjis japonais et de l'arabe ou de l'hébreu, par exemple, mais c'est
beaucoup moins évident quand ils sont écrits sous forme numérique comme
ci-dessus.
Par ailleurs, si le Japonais qui tape, utilise un éditeur capable de
pondre ce genre de code, il peut facilement vérifier que le code est
bon avec un navigateur.
Ah mais *si* il existe un éditeur capable de pondre ce genre de code,
j'espère que le même éditeur sera tout aussi capable de le lire, et de
montrer les kanji au Japonais qui fait la saisie. Dans ce cas, oui,
pourquoi pas.
Malgré tout, d'une part je ne suis pas sûr qu'un tel éditeur existe,
et d'autre part les fichiers pondus seraient trois fois plus gros que
ceux écrits en UTF-8, et même quatre fois plus gros que ceux écrits en
Shift_JIS. Je ne suis pas sûr que les utilisateurs soient vraiment
convaincus du bien fondé de cette écriture.
Ensuite, une fois que j'ai ce code imbuvable,
comme c'est du ASCII pur (32-127), je peux le faire passer par tous
les filtres que je veux (SMTP, MySQL, etc.) sans problèmes.
Le faire passer, oui. Mais pas le rendre lisible à l'autre bout sans une
grosse manipulation bien compliquée : je veux bien te payer une caisse
du vin que tu veux si tu peux m'exhiber un courrielleur en mode texte
et un visionneur MySQL (style PHPmyadmin) capables de transformer
simplement ce texte en caractères lisibles par un japonais (sans même
compter tous les autres outils que tu as laissés dans ton « etc. »).
C'est encore envisageable pour les langues occidentales, dans lesquelles peu de caractères sortent des 7 bits d'US-ASCII, mais pas du tout pour du japonais où tout ressemblerait à « 日本語版 »
Pour moi, c'est largement aussi lisible que des kanjis.
D'accord, mais ce n'est pas toi qui dois le saisir. Par ailleurs, je suppose que tu dois savoir distinguer au premier coup d'½il entre des kanjis japonais et de l'arabe ou de l'hébreu, par exemple, mais c'est beaucoup moins évident quand ils sont écrits sous forme numérique comme ci-dessus.
Par ailleurs, si le Japonais qui tape, utilise un éditeur capable de pondre ce genre de code, il peut facilement vérifier que le code est bon avec un navigateur.
Ah mais *si* il existe un éditeur capable de pondre ce genre de code, j'espère que le même éditeur sera tout aussi capable de le lire, et de montrer les kanji au Japonais qui fait la saisie. Dans ce cas, oui, pourquoi pas.
Malgré tout, d'une part je ne suis pas sûr qu'un tel éditeur existe, et d'autre part les fichiers pondus seraient trois fois plus gros que ceux écrits en UTF-8, et même quatre fois plus gros que ceux écrits en Shift_JIS. Je ne suis pas sûr que les utilisateurs soient vraiment convaincus du bien fondé de cette écriture.
Ensuite, une fois que j'ai ce code imbuvable, comme c'est du ASCII pur (32-127), je peux le faire passer par tous les filtres que je veux (SMTP, MySQL, etc.) sans problèmes.
Le faire passer, oui. Mais pas le rendre lisible à l'autre bout sans une grosse manipulation bien compliquée : je veux bien te payer une caisse du vin que tu veux si tu peux m'exhiber un courrielleur en mode texte et un visionneur MySQL (style PHPmyadmin) capables de transformer simplement ce texte en caractères lisibles par un japonais (sans même compter tous les autres outils que tu as laissés dans ton « etc. »).
espie
In article , Fabien LE LEZ wrote:
On Tue, 17 Jul 2007 02:28:21 -0700, :
ca ne me parait pas simple !
Je confirme.
<HS> Je développe une application web en ce moment, et pour contourner les problèmes style "UTF-8 vs ISO-Latin1", j'ai décidé d'employer une méthode bourrin : je convertis tout en entités HTML ("&eactute;" et compagnie), et je laisse le navigateur se démerder avec ça.
C'est completement cretin et monstrueusement inefficace si tu as vraiment des clients qui s'en servent pour des langues asiatiques. Leurs entites vont etre moches, et ca va ramer de la folie: 7 ou octets par caractere, alors que le codage utf8 est vachement plus compact.
Je deconseille totalement pour toute appli qui a de *vraies* exigences d'internationalisation...
En plus, de maniere standard aujourd'hui, et raisonnablement supportee sur la plupart des navigateurs, tu te contentes de sortir du xhtml conforme, et hop, ca marche...
Pour le reste, c'est pas comme si il n'y avait pas une enorme tripatouillee de bibliotheques qui savent prendre du utf8 et le convertir en n'importe quoi... qt en tete, pour rester dans le domaine C++.
- cote smtp, tout ce qui est mime sait tres bien te digerer de l'unicode, te le transmettre sur une liaison 7 bits, et te le ressortir a l'arrivee. - cote base de donnees, toutes les bd recentes savent gerer de l'unicode. Tu *peux* etre amene a modifier leur config, mais ca fonctionne...
In article <qdbp93ph3te6mc7saavr943pjcqqemt290@4ax.com>,
Fabien LE LEZ <usenet13@edulang.com> wrote:
On Tue, 17 Jul 2007 02:28:21 -0700, vdaanen@gmail.com:
ca ne me parait pas simple !
Je confirme.
<HS>
Je développe une application web en ce moment, et pour contourner les
problèmes style "UTF-8 vs ISO-Latin1", j'ai décidé d'employer une
méthode bourrin : je convertis tout en entités HTML ("&eactute;" et
compagnie), et je laisse le navigateur se démerder avec ça.
C'est completement cretin et monstrueusement inefficace si tu as vraiment
des clients qui s'en servent pour des langues asiatiques. Leurs entites
vont etre moches, et ca va ramer de la folie: 7 ou octets par caractere,
alors que le codage utf8 est vachement plus compact.
Je deconseille totalement pour toute appli qui a de *vraies* exigences
d'internationalisation...
En plus, de maniere standard aujourd'hui, et raisonnablement supportee sur la
plupart des navigateurs, tu te contentes de sortir du xhtml conforme,
et hop, ca marche...
Pour le reste, c'est pas comme si il n'y avait pas une enorme tripatouillee
de bibliotheques qui savent prendre du utf8 et le convertir en n'importe
quoi... qt en tete, pour rester dans le domaine C++.
- cote smtp, tout ce qui est mime sait tres bien te digerer de l'unicode,
te le transmettre sur une liaison 7 bits, et te le ressortir a l'arrivee.
- cote base de donnees, toutes les bd recentes savent gerer de l'unicode.
Tu *peux* etre amene a modifier leur config, mais ca fonctionne...
<HS> Je développe une application web en ce moment, et pour contourner les problèmes style "UTF-8 vs ISO-Latin1", j'ai décidé d'employer une méthode bourrin : je convertis tout en entités HTML ("&eactute;" et compagnie), et je laisse le navigateur se démerder avec ça.
C'est completement cretin et monstrueusement inefficace si tu as vraiment des clients qui s'en servent pour des langues asiatiques. Leurs entites vont etre moches, et ca va ramer de la folie: 7 ou octets par caractere, alors que le codage utf8 est vachement plus compact.
Je deconseille totalement pour toute appli qui a de *vraies* exigences d'internationalisation...
En plus, de maniere standard aujourd'hui, et raisonnablement supportee sur la plupart des navigateurs, tu te contentes de sortir du xhtml conforme, et hop, ca marche...
Pour le reste, c'est pas comme si il n'y avait pas une enorme tripatouillee de bibliotheques qui savent prendre du utf8 et le convertir en n'importe quoi... qt en tete, pour rester dans le domaine C++.
- cote smtp, tout ce qui est mime sait tres bien te digerer de l'unicode, te le transmettre sur une liaison 7 bits, et te le ressortir a l'arrivee. - cote base de donnees, toutes les bd recentes savent gerer de l'unicode. Tu *peux* etre amene a modifier leur config, mais ca fonctionne...
Fabien LE LEZ
On Tue, 17 Jul 2007 15:56:42 +0000 (UTC), (Marc Espie):
Je deconseille totalement pour toute appli qui a de *vraies* exigences d'internationalisation...
En fait, j'aimerais déjà que le français fonctionne. Et comme mon appli doit s'intégrer dans des pages qui peuvent être en ISO-Latin-1, en UTF-8, voire en autre chose, au moins avec les entités HTML j'ai de bonnes chances que mon texte s'affiche correctement.
Quand on veut être sûr que ça marche chez le client, l'ASCII, c'est vachement pratique.
Je deconseille totalement pour toute appli qui a de *vraies* exigences
d'internationalisation...
En fait, j'aimerais déjà que le français fonctionne.
Et comme mon appli doit s'intégrer dans des pages qui peuvent être en
ISO-Latin-1, en UTF-8, voire en autre chose, au moins avec les entités
HTML j'ai de bonnes chances que mon texte s'affiche correctement.
Quand on veut être sûr que ça marche chez le client, l'ASCII, c'est
vachement pratique.
On Tue, 17 Jul 2007 15:56:42 +0000 (UTC), (Marc Espie):
Je deconseille totalement pour toute appli qui a de *vraies* exigences d'internationalisation...
En fait, j'aimerais déjà que le français fonctionne. Et comme mon appli doit s'intégrer dans des pages qui peuvent être en ISO-Latin-1, en UTF-8, voire en autre chose, au moins avec les entités HTML j'ai de bonnes chances que mon texte s'affiche correctement.
Quand on veut être sûr que ça marche chez le client, l'ASCII, c'est vachement pratique.
espie
In article , Fabien LE LEZ wrote:
On Tue, 17 Jul 2007 15:56:42 +0000 (UTC), (Marc Espie):
Je deconseille totalement pour toute appli qui a de *vraies* exigences d'internationalisation...
En fait, j'aimerais déjà que le français fonctionne. Et comme mon appli doit s'intégrer dans des pages qui peuvent être en ISO-Latin-1, en UTF-8, voire en autre chose, au moins avec les entités HTML j'ai de bonnes chances que mon texte s'affiche correctement.
Ah oui, si tu dois faire du bugware avec des applis qui n'ont pas une couche de presentation moderne et bien definie, tu es un peu dans la merde...
In article <0bsp93tc983l2so5pipnius3bdrjb59vl0@4ax.com>,
Fabien LE LEZ <usenet13@edulang.com> wrote:
Je deconseille totalement pour toute appli qui a de *vraies* exigences
d'internationalisation...
En fait, j'aimerais déjà que le français fonctionne.
Et comme mon appli doit s'intégrer dans des pages qui peuvent être en
ISO-Latin-1, en UTF-8, voire en autre chose, au moins avec les entités
HTML j'ai de bonnes chances que mon texte s'affiche correctement.
Ah oui, si tu dois faire du bugware avec des applis qui n'ont pas une
couche de presentation moderne et bien definie, tu es un peu dans la
merde...
On Tue, 17 Jul 2007 15:56:42 +0000 (UTC), (Marc Espie):
Je deconseille totalement pour toute appli qui a de *vraies* exigences d'internationalisation...
En fait, j'aimerais déjà que le français fonctionne. Et comme mon appli doit s'intégrer dans des pages qui peuvent être en ISO-Latin-1, en UTF-8, voire en autre chose, au moins avec les entités HTML j'ai de bonnes chances que mon texte s'affiche correctement.
Ah oui, si tu dois faire du bugware avec des applis qui n'ont pas une couche de presentation moderne et bien definie, tu es un peu dans la merde...
vdaanen
Bonjour a tous,
apres quelques jours d'absence, je trouve 15 messages a lire ! Woh ...
Bien, entre temps, nous sommes parvenus a lire le fichier et a l'afficher (sur Windows) grâce a une classe trouvée sur le oueb (CStdioFileEx) qui permet de lire de l'UTF-8 (le fichier que j'avais été en UTF-8)
Le problème vient du fait que pour lire de l'utf, il faut compiler avec _UNICODE et UNICODE defini et que nous sommes tenu d'utiliser des libraires externes (que nous ne pouvons recompiler :( ) qui sont compiler avec _MBCS défini !
Du coup,on ne peut afficher de caractères japonais, russe ou chinois pour l'instant.
Merci de vos messages
Vincent
Bonjour a tous,
apres quelques jours d'absence, je trouve 15 messages a lire ! Woh ...
Bien, entre temps, nous sommes parvenus a lire le fichier et a
l'afficher (sur Windows) grâce a une classe trouvée sur le oueb
(CStdioFileEx) qui permet de lire de l'UTF-8 (le fichier que j'avais
été en UTF-8)
Le problème vient du fait que pour lire de l'utf, il faut compiler
avec _UNICODE et UNICODE defini et que nous sommes tenu d'utiliser des
libraires externes (que nous ne pouvons recompiler :( ) qui sont
compiler avec _MBCS défini !
Du coup,on ne peut afficher de caractères japonais, russe ou chinois
pour l'instant.
apres quelques jours d'absence, je trouve 15 messages a lire ! Woh ...
Bien, entre temps, nous sommes parvenus a lire le fichier et a l'afficher (sur Windows) grâce a une classe trouvée sur le oueb (CStdioFileEx) qui permet de lire de l'UTF-8 (le fichier que j'avais été en UTF-8)
Le problème vient du fait que pour lire de l'utf, il faut compiler avec _UNICODE et UNICODE defini et que nous sommes tenu d'utiliser des libraires externes (que nous ne pouvons recompiler :( ) qui sont compiler avec _MBCS défini !
Du coup,on ne peut afficher de caractères japonais, russe ou chinois pour l'instant.
Merci de vos messages
Vincent
Michael DOUBEZ
Bonjour a tous,
apres quelques jours d'absence, je trouve 15 messages a lire ! Woh ...
Bien, entre temps, nous sommes parvenus a lire le fichier et a l'afficher (sur Windows) grâce a une classe trouvée sur le oueb (CStdioFileEx) qui permet de lire de l'UTF-8 (le fichier que j'avais été en UTF-8)
Le problème vient du fait que pour lire de l'utf, il faut compiler avec _UNICODE et UNICODE defini et que nous sommes tenu d'utiliser des libraires externes (que nous ne pouvons recompiler :( ) qui sont compiler avec _MBCS défini !
Du coup,on ne peut afficher de caractères japonais, russe ou chinois pour l'instant.
Est ce qu'il ne serait pas possible de transformer vos caractères de MBCS vers SBCS avec des tables de correspondance ?
Ce serait un peut fastidieux mais si vous vous limitez à quelques langages, ça doit être faisable et/ou automatisable.
Michael
Bonjour a tous,
apres quelques jours d'absence, je trouve 15 messages a lire ! Woh ...
Bien, entre temps, nous sommes parvenus a lire le fichier et a
l'afficher (sur Windows) grâce a une classe trouvée sur le oueb
(CStdioFileEx) qui permet de lire de l'UTF-8 (le fichier que j'avais
été en UTF-8)
Le problème vient du fait que pour lire de l'utf, il faut compiler
avec _UNICODE et UNICODE defini et que nous sommes tenu d'utiliser des
libraires externes (que nous ne pouvons recompiler :( ) qui sont
compiler avec _MBCS défini !
Du coup,on ne peut afficher de caractères japonais, russe ou chinois
pour l'instant.
Est ce qu'il ne serait pas possible de transformer vos caractères de
MBCS vers SBCS avec des tables de correspondance ?
Ce serait un peut fastidieux mais si vous vous limitez à quelques
langages, ça doit être faisable et/ou automatisable.
apres quelques jours d'absence, je trouve 15 messages a lire ! Woh ...
Bien, entre temps, nous sommes parvenus a lire le fichier et a l'afficher (sur Windows) grâce a une classe trouvée sur le oueb (CStdioFileEx) qui permet de lire de l'UTF-8 (le fichier que j'avais été en UTF-8)
Le problème vient du fait que pour lire de l'utf, il faut compiler avec _UNICODE et UNICODE defini et que nous sommes tenu d'utiliser des libraires externes (que nous ne pouvons recompiler :( ) qui sont compiler avec _MBCS défini !
Du coup,on ne peut afficher de caractères japonais, russe ou chinois pour l'instant.
Est ce qu'il ne serait pas possible de transformer vos caractères de MBCS vers SBCS avec des tables de correspondance ?
Ce serait un peut fastidieux mais si vous vous limitez à quelques langages, ça doit être faisable et/ou automatisable.
