Une histoire de caractères accentués déformés

Version imprimable

30/07/2011, 15h45
bvsud

Une histoire de caractères accentués déformés

Bonjour à tous :)

Voici un aperçu du problème :

http://hfr-rehost.net/http://self/pi...c66ddfa651.png

et là :

http://hfr-rehost.net/http://self/pi...2058ac16e7.png

Grosso modo, je sais quelles sont les procédures incriminées ds mon prog, donc là où il faudrait intervenir. Mais comment rectifier, pour Windows et pour Delphi (7), le jeu de caractères afin que, ni l'un ni l'autre ne les déforment ?

Merci :)
01/08/2011, 10h47
ShaiLeTroll

La confusion é et Ú, c'est typique d'un conflit Windows-1252 et CP863 !

Essaye CharToEOM et EOMToChar
02/08/2011, 05h29
bvsud

Citation:

Envoyé par ShaiLeTroll

La confusion é et Ú, c'est typique d'un conflit Windows-1252 et CP863 !

Essaye CharToEOM et EOMToChar

Et le L' : l'apostrophe fait tousser, elle aussi.

Je vais tester tout ça.

Merci :)

Citation:

Envoyé par ShaiLeTroll

La confusion é et Ú, c'est typique d'un conflit Windows-1252 et CP863 !

Essaye CharToEOM et EOMToChar

CharToOEM() en élimine pas mal, mais il en reste. Je fais l'opération inverse ( OEMToChar() pour plus de sûreté : idem.

Photo :
http://hfr-rehost.net/http://self/pi...8c6ca12bee.png

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
Procedure Epurer_Caracteres_Deformes;
Var   i : integer;
 
begin
      Ptr_Tab_Char_Source := @Tab_Char_Source_OEM[0];  // type Pointer
      Ptr_Tab_Char_Dest := @Tab_Char_Dest_OEM[0];			 // type Pointer
 
      For i := 0 TO Nb_F_Ds_Base DO  // Nb de titres de fiches dans la base
           begin
                  StrCopy( @Tab_Char_Source_OEM, PChar (Lst_Noms_Courts_F_Ds_Base[i]) );  // LST..etc = TStringList
                  CharToOEM(Ptr_Tab_Char_Source, Ptr_Tab_Char_Dest);
                  StrCopy( PChar( Lst_Noms_Courts_F_Ds_Base[i]), Ptr_Tab_Char_Dest);
           end;
 
end;

16/08/2011, 23h07
CapJack

D'où viennent ces citations ? De l'internet, I presume ?

C'est peut-être un problème lié au fait que certains sites sont en Unicode, il faudrait dans ce cas voir du côté des "WideString", mais je n'ai aucune idée de ce que Delphi 7 sait faire à ce sujet.
17/08/2011, 05h22
bvsud

Citation:

Envoyé par CapJack

D'où viennent ces citations ? De l'internet, I presume ?

C'est peut-être un problème lié au fait que certains sites sont en Unicode, il faudrait dans ce cas voir du côté des "WideString", mais je n'ai aucune idée de ce que Delphi 7 sait faire à ce sujet.

1/ Quelles citations ? Le code ci-dessus ? C'est le mien.
17/08/2011, 08h11
CapJack

Citation:

Envoyé par bvsud

1/ Quelles citations ? Le code ci-dessus ? C'est le mien.

Je voulais parler de ce qui est sur le fond vert. Les chaînes à traiter.
16/09/2011, 18h06
bvsud

Citation:

Envoyé par CapJack

Je voulais parler de ce qui est sur le fond vert. Les chaînes à traiter.

Oui, oui : c'est bien du Net. Des articles de presse et de revues. Mais certains, pur des raisons diverses, sont intégralement copiés/collés sous Word, et enregistrés sur dd au format RTF. Donc, là, ce n'est pas le Net : je copie l'article, je colle dans UltraEdit, puis copier/coller de UltraEdit vers Word (j'élimine les formatages un peu lourds, etc). Donc, la source n'est pas systématiquement une page Web : parfois simplement UltraEdit.

Il y a des RTF, d'ailleurs dans la liste suivante.

Voici ce que ça donne, pour l'exemple : tous les titres foireux ne sont pas listés, heureusement) :

http://data.imagup.com/11/1130854512.png
16/09/2011, 18h32
ShaiLeTroll

Citation:

Envoyé par bvsud

CharToOEM() en élimine pas mal, mais il en reste. Je fais l'opération inverse ( OEMToChar() pour plus de sûreté : idem.

C'est que ce n'est pas ce CharSet !
A la limite, tu peux coder la fonction de décodage par tatonnement !
Si OEMToChar ne commet pas d'erreur, tu l'utilise, puis tu corriges ce qui traine avec un for et un case

Voir aussi UTF8Encode ou WideCharToString, mais je ne suis pas convaincu, tu semble avoir un codage sur un simple octet et non multi-octet !
12/10/2011, 14h06
bvsud

Citation:

Envoyé par ShaiLeTroll

C'est que ce n'est pas ce CharSet !
A la limite, tu peux coder la fonction de décodage par tatonnement !
Si OEMToChar ne commet pas d'erreur, tu l'utilise, puis tu corriges ce qui traine avec un for et un case

Voir aussi UTF8Encode ou WideCharToString, mais je ne suis pas convaincu, tu semble avoir un codage sur un simple octet et non multi-octet !

Donc, il me faudrai :
1/ Détecter le CharSet actif dans mon application
2/ Affecter à mon appli le CharSet correspondant à "863 MS-DOS Canadian French"

Les API ChatToOEM et OemToChar (avec ou sans pointeur sur un buffer) ne résolvent rien. Mon prog (D7 sous Win32) écrit dans une autre page de code que celle OEM 863.

Je cherche les API pour ça.

Je vois arriver le moment où il ne me restera plus qu'à écriure ça en assembleur en ligne, comme ds les années 80-90 qd je programmais en C. Mais charger les DS:SI et ES: DI , ça ne se fait plus de la même façon en Win32...

:koi:
Je n'ai rien compris à ce que tu viens de dire !

D'où vient les noms de fichiers ?
C'est FindFirst qui les renvois ?

Le problème ce n'est pas le CharSet de l'application quoi doit être probablement Windows-1252 mais celui de ta liste, tu es sûr que ta liste est en "863 MS-DOS Canadian French"

Citation:

La confusion é et Ú, c'est typique d'un conflit Windows-1252 et CP863 !

Est-ce mes propos qui t'ont induit en erreur, j'ai vu tout de suite é et Ú par qu'il est connu (je l'ai souvent eu celui là lorsque je générais des fichiers BAT à la volée)

Si l'on étudie Æ et ´ qui ont théoriquement la même valeur l'un en Windows-152 et l'autre en OEM
1252 = ... = OEM = CP863
Æ = 00C6 = 198 = ã = ╞
¡ = 00B4 = 161 = ┤ = ´
' = 0027 = 39 = ' = '

Bizarre, OEM et CP863 sont différents, je pensais que le DOS était en 863, ne cherchons pas (utilise la console CMD et lance EDIT, tu verras en faisant ALT+...) ou UltraEdit et son option OEM

Cela ne colle pas, il faudrait que 00C6 (Æ) soit l'équivalent d'un ´ ou ' dans l'encodage qui n'est manifestement pas du OEM mais un autre CharSet, le trouver ne sera pas facile par contre trouver manuellement les correspondances et de faire une fonction de substitution

grosso modo
Code:

1 2 3 4 5 6 7 8 9 10 11 12 function Convert(const S: AnsiString): AnsiString; const MAP: array[AnsiChar] of AnsiChar = (#0, #1, #2, ..., '´', ...); // un LONG tableau de 256 caractères, la position étant en 1252, par exemple 198 contient '´' ... var I: integer; begin SetLength(Result, Length(S)); for I := 1 to Length(S) do Result := Map[S[I]]; end;

Citation:
Envoyé par ShaiLeTroll
:koi:
Je n'ai rien compris à ce que tu viens de dire !

D'où vient les noms de fichiers ?
C'est FindFirst qui les renvois ?

Le problème ce n'est pas le CharSet de l'application quoi doit être probablement Windows-1252 mais celui de ta liste, tu es sûr que ta liste est en "863 MS-DOS Canadian French"

Est-ce mes propos qui t'ont induit en erreur, j'ai vu tout de suite é et Ú par qu'il est connu (je l'ai souvent eu celui là lorsque je générais des fichiers BAT à la volée)

Si l'on étudie Æ et ´ qui ont théoriquement la même valeur l'un en Windows-152 et l'autre en OEM
1252 = ... = OEM = CP863
Æ = 00C6 = 198 = ã = ╞
¡ = 00B4 = 161 = ┤ = ´
' = 0027 = 39 = ' = '

Bizarre, OEM et CP863 sont différents, je pensais que le DOS était en 863, ne cherchons pas (utilise la console CMD et lance EDIT, tu verras en faisant ALT+...) ou UltraEdit et son option OEM

Cela ne colle pas, il faudrait que 00C6 (Æ) soit l'équivalent d'un ´ ou ' dans l'encodage qui n'est manifestement pas du OEM mais un autre CharSet, le trouver ne sera pas facile par contre trouver manuellement les correspondances et de faire une fonction de substitution

grosso modo
Code:

1 2 3 4 5 6 7 8 9 10 11 12 function Convert(const S: AnsiString): AnsiString; const MAP: array[AnsiChar] of AnsiChar = (#0, #1, #2, ..., '´', ...); // un LONG tableau de 256 caractères, la position étant en 1252, par exemple 198 contient '´' ... var I: integer; begin SetLength(Result, Length(S)); for I := 1 to Length(S) do Result := Map[S[I]]; end;
"(...) il faudrait que 00C6 (Æ) soit l'équivalent d'un ´ ou ' dans l'encodage qui n'est manifestement pas du OEM mais un autre CharSet. (...)" : exactement !

Ce qui est lu est transformé en autre chose que du CharSet "863 MS-DOS Canadian French". Ce sont les caractères spéciaux ci-dessous qui ne passent pas et sont transformés.

Mon but est précisément de translater en 863 ce qui est lu en Dieu sait quoi, mais parfaitement écrit sur le disque dur ! Les titres des fichiers
sont absolument rigoureux, et respectent à la lettre le jeu de caractères français.

Ici : http://www.codeshttp.com/iso88591.htm la table des caractères que je veux utiliser. Il décrit parfaitement la correspondance entre ce qui est lu
par mon prog, et ce qu'il affiche en le déformant.

1/ le premier fichier est une concaténation de fichiers HTML et RTF. Rien d'autres. (Des articles, en l'occurrence).

2/ Le second fichier est un index. Chacun de ses enregistrements (structures) est de ce type :
type
Code:

1 2 3 4 5 6 7 Struct_Base = record Num_Fichier : integer; Nom_F : array [0..255] of char; Position_Fichier : LongInt; Longueur_Fichier : LongInt; end; // Struct
C'est en remplissant le tableau Nom_F que s'effectue la translation non voulue. Alors que sur le disque, il n'y a pas une erreur ! Mystère, là...

Merci pour la routine. Elle doit (à ce jour) être lancée sur 4285 titres. D'où l'intérêt de l'assembleur en ligne ;) Ce serait incomparablement plus rapide.

13/10/2011, 10h43
ShaiLeTroll

ISO 8859-1 Character Set ( Latin - 1) - Western / West European
C'est ce que je dis depuis le début, tu es sous Windows en Delphi7, par défaut en Français tu utilises du Window-1252 qui est un Latin1 modifié (œ ajouté par exemple)

oublie le "863 MS-DOS Canadian French", tu te mélanges les pinceaux !
Tu as un fichier dans un Charset inconnu mais tu le lit en Windows-1252, Delphi prend ce qu'il a ! Delphi 7 ne traduit rien tout seul !

Citation:

Envoyé par bvsud

C'est en remplissant le tableau Nom_F que s'effectue la translation non voulue. Alors que sur le disque, il n'y a pas une erreur ! Mystère, là...

Le problème c'est le Charset de ta liste, tu n'as toujours pas dit d'où ça vient, comment tu as obtenu cette liste, en plus, ne me dit pas que tu as des é ou ' qui passe bien !
Cela voudrait dire que tu as un mélange de CharSet au sein du même fichier ! La c'est mort !
Tu lit le fichier avec quoi ?
NotePad ? UltraEdit ? Word ?
Tu lit avec le fichier avec un TStream ? WriteBuffer ? un file of Rec ???
Tu as vérifié si le fichier avait un BOM ?

Avec un UltraEdit, n'active pas l'option "View | OEM Character Set" !
Veille à ce que ton fichier soit en ANSI (sous windows français, c'est le Windows-1252)
J'ai l'impression que tu génères toi même les erreurs lorsque tu manipules ton fichier d'index

Citation:

Envoyé par bvsud

Merci pour la routine. Elle doit (à ce jour) être lancée sur 4285 titres. D'où l'intérêt de l'assembleur en ligne ;) Ce serait incomparablement plus rapide.

Un Assembleur mal écrit peut-être plus lent qu'un code Delphi optimisé, fait moi confiance, je l'ai souvent vu !
Dans mon exemple, en utilisant du PAnsiChar, on pourrait améliorer les performances pour éviter que Delphi joue avec UniqueString

Sinon, une telle fonction sur 4285 fait moi rire, ça prendra pas plus de 10ms !
On écrit des codes sur le forum qui traitaient des listes d'un million de Strings en moins d'une seconde !

Tient toi traitement de conversion c'est proche (en plus SIMPLE) de
Y-a-t-il plus rapide pour enlever les accents ?
On avait fini avec un code Delphi à traiter 20 000 chaines en 13ms, et celui en ASM, environ 9ms (mais un code illisible, le gain vaut-il l'effort ?)
Surtout que le même code en D7 et D2007, serait plus rapide en 2007, car le SetLength de FastMM est 100 plus rapide que celui de BorlandMM
Dans ton code, la chaine ne changeant pas de taille, cela n'a pas d'importance !
13/10/2011, 18h56
bvsud

Citation:

Envoyé par ShaiLeTroll

ISO 8859-1 Character Set ( Latin - 1) - Western / West European
C'est ce que je dis depuis le début, tu es sous Windows en Delphi7, par défaut en Français tu utilises du Window-1252 qui est un Latin1 modifié (œ ajouté par exemple)

oublie le "863 MS-DOS Canadian French", tu te mélanges les pinceaux !
Tu as un fichier dans un Charset inconnu mais tu le lit en Windows-1252, Delphi prend ce qu'il a ! Delphi 7 ne traduit rien tout seul !

Le problème c'est le Charset de ta liste, tu n'as toujours pas dit d'où ça vient, comment tu as obtenu cette liste, en plus, ne me dit pas que tu as des é ou ' qui passe bien !
Cela voudrait dire que tu as un mélange de CharSet au sein du même fichier ! La c'est mort !
Tu lit le fichier avec quoi ?
NotePad ? UltraEdit ? Word ?
Tu lit avec le fichier avec un TStream ? WriteBuffer ? un file of Rec ???
Tu as vérifié si le fichier avait un BOM ?

Avec un UltraEdit, n'active pas l'option "View | OEM Character Set" !
Veille à ce que ton fichier soit en ANSI (sous windows français, c'est le Windows-1252)
J'ai l'impression que tu génères toi même les erreurs lorsque tu manipules ton fichier d'index

Un Assembleur mal écrit peut-être plus lent qu'un code Delphi optimisé, fait moi confiance, je l'ai souvent vu !
Dans mon exemple, en utilisant du PAnsiChar, on pourrait améliorer les performances pour éviter que Delphi joue avec UniqueString

Sinon, une telle fonction sur 4285 fait moi rire, ça prendra pas plus de 10ms !
On écrit des codes sur le forum qui traitaient des listes d'un million de Strings en moins d'une seconde !

Tient toi traitement de conversion c'est proche (en plus SIMPLE) de
Y-a-t-il plus rapide pour enlever les accents ?
On avait fini avec un code Delphi à traiter 20 000 chaines en 13ms, et celui en ASM, environ 9ms (mais un code illisible, le gain vaut-il l'effort ?)
Surtout que le même code en D7 et D2007, serait plus rapide en 2007, car le SetLength de FastMM est 100 plus rapide que celui de BorlandMM
Dans ton code, la chaine ne changeant pas de taille, cela n'a pas d'importance !

Tu as trouvé !

Oui : le é passe bien. De même que l'apostrophe. MAIS pas systématiquement.

Mon prog concatène des fichiers (RTF et HTML) dont le nom, sur le dd, est parfois bien écrit, parfois non !!

C'est bien un pb de CharSet. Je pense que Windows soit :

- mélange les Charset

- ne définit pas le bon Charset

Comment lui IMPOSER un Charset précis, en l'occurrence celui du Français "normal" ? Il doit bien y avoir une API pour ça...

J'ai testé la fonction vers laquelle pointe ton lien. Je ne peux pas m'en servir. Il me faudrait imposer à Windows le Charset "ISO 8859-1 Character Set ( Latin - 1)" (v. mon lien vers lui, plus haut). Ce que je ne sais pas faire (sans doute au lancement de l'OS, une commande à envoyer : qqch comme ça).

Tantôt un «j apostrophe» ou «L apostrophe» provoque le #$C6 (A maj.lié au E) et tantôt autre chose.

Purée, le casse-tête !
13/10/2011, 19h33
ShaiLeTroll

Si tu as du mélange, ... tu es mal barré !
Si déjà sur les noms de fichier sur le DD tu as des erreurs et parfois pas !
Comment savoir si il faut appliquer la traduction du CharSet !
Après tout, seul le sens du mot permet de savoir si le caractère est le bon ou pas, ça c'est facile pour un cerveau humain, pour un ordinateur, il lui faut un dictionnaire comme les correcteurs orthographiques !

Je ne pense pas que Windows soit en tord, c'est plutôt le serveur Web et ton client de Download qui n'ont pas été en phase pour le CharSet des noms de fichiers !