menu

• résum? : Delphi 2009 a introduit Unicode comme le type String par Défaut. Cet article présente Unicode, les types String Delphi avant et après Delphi 2009, et présente les instructions qui devront être modifiées pour migrer un projet Delphi vers les versions 2009 et suivantes
  
• mots cl? : Unicode - Ansi - Oem - Utf-8 - Utf-16 - composites - surrogate - tCharacter - tEncoding
  
• logiciel utilis? : Windows XP personnel, Delphi 2010
  
• matériel utilis? : Pentium 2.800 Mhz, 512 Meg de mémoire, 250 Giga disque dur
  
• champ d'application : Delphi 1 ? 5, Delphi 6, Delphi 7, Delphi 2006, Turbo Delphi, Delphi 2007 sur Windows, Delphi 2009, 2010, Delphi XE
  
• niveau : développeur Delphi
  
• plan :
  
  • Migration vers Delphi 2009, Delphi 2010, Delphi XE
    
  • Définition UNICODE
    
  • Les caractères avant Delphi 2009
    
  • Les type String Delphi 2009 et suivants
    
  • Migration Unicode en Delphi
    
  • Télécharger le code source Delphi
    
  • Glossaire Unicode
    

---

1 - Migration vers Delphi 2009, Migration Delphi 2010, Migration Delphi XE

Delphi 2009 a introduit une utilisation systématique d'Unicode, au niveau de la librairie, des composants, de l'Interface.

Ce basculement offre des avantages certains:

• facilit? d'internationalisation des applications
  
• meilleure adéquation avec Windows
  

Mais il a aussi introduit des ruptures dans l'évolution d'une version de Delphi vers la suivante. C'est la première fois qu'un changement de version est "breaking": du code antérieur ? Delphi 2009 peut ne pas compiler, ou, une fois compil?, ne pas fonctionner comme escompt?

Compte tenu des missions de migration que nous ont confi? nos clients, nous pouvons considérer trois cas:

• votre code ne comporte pas d'instructions qui sont traitées différemment avant et après Unicode. Une simple compilation suffit. C'est le cas de 70 % des applications
  
• votre code utilise des instructions qui ne sont plus correctes en unicode. En particulier toutes les instructions qui supposent qu'un caractère occupe un octet. Des modifications sont alors ? prévoir. Environ 25 % des cas.
  
• votre code est déj? internationalis?, et utilise les fonctionnalités Unicode qui étaient disponibles avec les versions Delphi antérieures ? Delphi 2009. Il faudra alors changer est adapter toutes ces instructions pour qu'elles fonctionnent correctement sous Delphi 2009 ou suivant. 5 % des cas
  

Et quand nous parlons de "votre code", il s'agit bien s?r des lignes que vous avez écrites, mais concerne aussi les composants que vous avez sous-traités, achetés, récupérés sur le Web, en source, voire en Open Source.

En résum?

• si, après avoir sauvegard? vos sources, vous les compilez et qu'il passent les tests de validation, bravo, cet article ne vous concerne guère.
  
• si ce n'est pas le cas, nous vous proposons
  
  • tout d'abord d'expliquer ce qu'est Unicode. Une connaissance minimale est obligatoire, d'autant qu'un jargon particulier a ét? défini
    
  • nous présenterons alors les types Delphi tels qu'ils existaient avant Delphi 2009
    
  • suivent les types Unicode Delphi 2009, ainsi que les types maintenus pour des raisons de compatibilit? arrière
    
  • puis un descriptif des principaux points ? examiner
    
  • et enfin les utilitaires et les stratégies pour effectuer de telles migrations
    

Bien entendu, nous restons ? votre disposition pour assurer les missions de migrations, qu'elles concernent Unicode, ou d'autres évolutions des vos projets (type base de données ou composant d'accès, architecture légère, Internet, mécaniques de plugin etc)

---

2 - Définition UNICODE

2.1 - Les caractères sous DOS

Sous Dos, nous utilisions tous le jeu de caractères ASCII: 26 lettres minuscules, 26 majuscules, les chiffres, quelques ponctuations: en moins de 127 caractères, tout texte anglais standard pouvait être représent?

• chaque caractère avait un code Ascii: 65 pour le "A", 66 pour le "B", 97 pour le "a", 48 pour le "0" etc
  
• les 32 premiers codes étaient utilisés pour des caractères "de contr?le": retour chariot, la sonnette etc
  

Comme l'ensemble tenait en moins de 128 codes, IBM décida d'utiliser les codes restants, entre 128 et 255 pour représenter

• la plupart des accents européens
  
• des caractères "semi-graphiques", comme des barres horizontales ou verticales, pour dessiner des tableaux
  
• des symboles divers, comme sigma, le trèfle etc
  

ce qui donna naissance au code OEM :

Toutefois, les pays non latins (les grecs, les arrabes, les russes, sans parler des japonais ou des chinois) souhaitaient utiliser les 128 caractères disponibles pour coder leurs jeux de caractères ? eux.

De ce fait

• les 128 premiers codes ont ét? figés par la norme ANSI
  
• les 128 codes suivants ont ét? définis par chaque pays. Chaque codification a reçu un numéro appel? code page. Ainsi, les Grecs utilisaient le code page 737, les Français le code page 850 (OEM Multilingual Latin 1; Western European)
  

La page Msdn - Code Page Identifiers décrit les différents codes utilisés, et, pour info, en voici quelques uns;

• 737 OEM Greek (formerly 437G); Greek (DOS)
  
• 850 OEM Multilingual Latin 1; Western European (DOS)
  
• 855 OEM Cyrillic (primarily Russian)
  
• 1251 ANSI Cyrillic; Cyrillic (Windows)
  
• 1252 ANSI Latin 1; Western European (Windows)
  
• 1253 ANSI Greek; Greek (Windows)
  
• 1254 ANSI Turkish; Turkish (Windows)
  
• 1255 ANSI Hebrew; Hebrew (Windows)
  
• 1256 ANSI Arabic; Arabic (Windows)
  

Mais, ? part quelques tentatives, il n'était pas possible de présenter ? l'écran ? la fois du cyrillique et de l'hébreu.

2.2 - Unicode

Pour permettre l'affichage de TOUS les caractères existant, in the world, plus quelques autres, la norme UNICODE fut créée:

• fondamentalement, chaque caractères se voit attribuer un numéro unique, cod? sur 4 octets, appel? code point. Ainsi, la lettre "A" (a majuscule) se voit attribuer le code 0041,ƒhƒ‹ qui est le même pour cette lettre quelle que soit la police de caractère, la taille ou le style :
  A A A A

  En revanche, le "a minuscule", "? accent grave", "? circonflexe" etc ont chacun leur propre code point

  • 00ƒhƒ‹E0 pour "?"
    
  • 00ƒhƒ‹E2 pour "?"
    
  etc

  Le code est officiellement not? avec un préfixe "U+" suivi de la valeur en hexadécimal

  U+0041

• chaque code point a un nom officiel. Pour le A c'est

  LATIN CAPITAL LETTER A

  et pour le "a" (code point U+0061) :

  LATIN SMALL LETTER A

  La page Nom des code points vous donnera une idée des codes et des noms utilisés
  

Chaque caractère a donc un code point sur 4 octets. Bien s?r, les premiers codes tiennent sur un octet. Mais certains caractères on besoin de 2 ou plus de 2 octets. Et donc, fondamentallement, le code point est défini sur 4 octets.

Et le dessin (appel? script) de chaque caractère est présent? dans des fichier .PDF, répartis en langue, type de symbole etc.

2.3 - Les catégories de code points

Le code Ascii contenait ? la fois des lettres et des chiffres, mais aussi des caractères de contr?le, des semi-graphiques etc.

De la même façon, les codes points Unicode ont ét? classés en 7 catégories fondamentales: Graphic, Format, Control, Private-Use, Surrogate, Noncharacter, Reserved.

Les catégories autres que les lettres étendent Unicode pour écrire des documents scientifiques, des pages de musique, des illustrations symboliques (POLICE OFFICER U+1F46E, PRINCESS U+1F478, RAT U+1F400 !). Plus le Braille, les dominos, le mahjong, l'alchimie ...

2.4 - Basic Multilingual Plane - BMP

La plage des valeurs possibles a ét? organisée par zones. Des documents précisent ce que contiennent chaque zones, les valeurs utilisées, réservées, garanties vides etc. La table Code Point Names montre que sur les $FFFF.FFFF valeurs possibles, environ seuls les 0002ƒhƒ‹.FFFF premières valeurs sont utilisées (plus quelques rares valeurs en fin de table).

Pour la plage des 64 K premières valeurs la décomposition se présente ainsi:

Vous constaterez que la plupart des caractères que nous utilisons couramment (lettres latines et des principaux alphabets) sont au début de la plage des valeurs.

Et les codes dont la valeur est inférieure ? 64 K est appel? le Basic Multilingual Plane (plan multilingue de base), ou BMP. Les code points que nous utiliserons couremment seront dans la plage du BMP. Mais il n'en demeure pas moins que les code points sont définis sur 4 octets.

Les autres "plans" dont nous parlerons fort peu, contiennent, par exemple

• le plan 1, Supplementary Multilingual Plane pour les caractères historiques (gothique etc) et musicaux
  
• le plan 2, Supplementary Ideographic Plane, pour des caractères asiatiques
  

et ceci a naturellement vari? au fil de l'évolution de la norme Unicode.

Nous nous limiterons essentiellement au plan 0, BMP.

2.5 - Caractères composites

Certains caractères, parmi lesquels nos caractères accentu?, ont une double représentation

• une version "pr?-composée" avec un seul code point :

  U+00E2 LATIN SMALL LETTER A WITH CIRCUMFLEX (donc "?")

• une version comportant le code point du "a" et un code point pour le circonflexe

  0061 0302

  C'est la version "décomposée" ou "composite"
  

Ceci peut se représenter ainsi:

Et cela peut se corser avec des compositions multiples:

qui est, comme chacun sait, différent de

Le problème se pose alors pour gérer les cha?nes contenant ces caractères composites

• sont-ils affichés comme un caractère précompos?, ou comme une suite de code points ?
  
• lorsque nous comparons dex cha?nes, U+00E2 est-il égal ? 061 0302 ?
  

Windows a introduit des procédures de normalisation utilisables

• pour XP seulement si nous avons install? IDN (Microsoft International Domain Names Migration API 1.1)
  
• directement pour Vista, Windows Server 2008 et Windows 7
  

2.6 - Les représentations compactes Unicode

L'utilisation de 4 octets pour représenter chaque caractère a ét? jugée excessive. Et de ce fait il a ét? mis sur pied plusieurs systèmes permettant de compacter le stockage des code points.

Les 3 méthodes de codage le plus fréquemment utilisées sont UTF-8, UTF-16 et UTF-32 (UTF: Unicode Transformation Standard). Il en existe d'autres tels que UCS-2 ou UCS-4 (Universal Character Set), moins utilisées actuellement.

2.6.1 - UTF-8

Dans cette représentation, les code points sont stockés en utilisant 1, 2 ou 4 octets :

• les caractères les plus utilisés (les lettres non accentuées) sont codées sur les premiers 7 bits d'un octet.
  
• au del? de 7 bits, UTF-8 utilise 2 ou 4 octets
  

Cette représentation

• est naturellement plus compacte que les 4 octets des code points
  
• a l'inconvénient que la ne nombre de caractères d'une cha?ne ne peut se déduire de la taille de la cha?ne en octets
  
• est néanmoins très utilisée pour les pages .HTML et beaucoup de fichiers .XML ou certains protocoles TCP/IP.
  

2.6.2 - UTF-16

Lorsque la vitesse de traitement est plus importante que la place mémoire, c'est la représentation UTF-16 qui est utilisée

Dans cette représentation :

• tous les caractères de la BMP (les caractères les plus utilisés) sont codés sur 2 octets. Ces deux octets sont appelés une code unit
  
• pour les caractères dépassant un code point de 64 K, et qui ne peuvent donc pas être représentés sur 2 octets, UTF 16 utilise deux "code units". Donc 4 octets aussi. Et ces 4 octets, deux code units sont appelés une surrogate pair (paires de substitution)
  

Les surrogate pairs sont cantonnées :

• dans la plage U+D800 ? U+DBFF pour la première code unit ("high surrogate" ou "leading surrogate")
  
• et la plage U+DC00 ? U+DFFF pour la seconde ("low surrogate")
  

Cette partie réservée est visible sur l'image présentant le découpage des code points présentée ci dessus.

A titre d'exemple

• les valeurs autour de $D840 $DC01 sont des idéogrammes d'extrême orient
  
• les caractères gothiques, comme la lettre KU sont codés au voisinage de $D800 $DF12
  

Le format UTF-16 est particulièrement intéressant

• car il correspond au format du système d'exploitation sous-jacent. Il permet donc de meilleures performances lors de l'appel de l'API Windows.
  
• dans la vaste majorit? des cas, les caractères que nous utilisons sont dans la BMP, et nous n'avons pas besoin de codage sur 2 code units (4 octets)
  

2.6.3 - UTF-32

UTF-32 utilise 4 octets pour représenter chaque code point

2.6.4 - Quelques Exemples

Un point important est que même si vous avez en mémoire un caractère Unicode, vous le verrez pas nécessairement son image correcte ? l'écran. Ansi je n'ai pu apercevoir de symboles gothiques, faute de police Windows sur mon PC.

En revanche, j'ai pu afficher:

• des caractères chinois, dans la plage des 20000ƒhƒ‹ (CJK Unified Ideographs Extension B). Par exemple
  • U+20000, "GKX075" etc
    
  • en UTF-16, surrogate $D840, $DC01
    
  • qui se présente ainsi :
    surrogates.png
• des caractères grecs:
  
  • un oméga avec des accents
    
    • U+1FA7 : greek small letter omega with dasia and perispomeni and ypojegrammeni
      
    • UTF-16, composite 1F67 0345
      
  • un epsilon avec quelques accents
    
    • U+1F13 greek letter epsilon with dasia and varia
      
    • UTF-16 : composite 1F11 0300
      

2.6.5 - UCS-2

UCS-2 est toujours cod? sur 2 octets, et ne peut représenter que les caractères de la BMP. De plus les "surrogate pairs" de UTF-16 ne sont pas reconnus.

2.6.6 - UCS-4

UCS-4 est toujours cod? sur 4 octets, et permet de représenter les mêmes caractères que UTF-32, mais a ét? supplant? par UTF-32.

2.6.7 - Big Endian, Little Endian - Byte Order Mark - BOM

Pour les représentations utilisant plus de 1 octet, il est aussi possible de préciser dans quel ordre les octets sont organisés: poids le plus faible au début ou ? la fin:

• en LE, 1234ƒhƒ‹ est stock? 34ƒhƒ‹ 12ƒhƒ‹
  
• en BE, 1234ƒhƒ‹ est stock? 12ƒhƒ‹ 34ƒhƒ‹
  

Pour Windows, c'est le mode LE qui est utilis?

La spécification de cet ordre est importante pour stocker les données dans des fichiers. En fait les fichiers peuvent optionnellement comporter une signature, en début de fichier, qui précise cet ordre. Cette signature, et est appellée BOM (Byte Order Mark) et a les valeurs suivantes:

• FF FE : UTF-16, little endian

• FE FF : UTF-16, big endian
  
• FF FE 00 00 : UTF-32 little endian
  
• 00 00 FE FF : UTF-32 big endian
  
• EF BB BF : UTF-8
  

---

3 - Les caractères avant Delphi 2009

De Delphi 2 ou 3 ? Delphi 2007, nous pouvions utiliser les types suivants:

• les caractères Char ont une taille de 1 octet :
  Var my_char: Char;
  

• les cha?nes compatibles Apple ][, définies par
  Var my_string= String[5];
  my_string_max: ShortString; // équivalent ?

  Et

  • la taille occupée par la variable est toujours la même, l'octet 0 est utilis? pour gérer la taille actuelle des caractères utilisés ('joe': 3 caractères), le premier indice commence ? 1
    
• les cha?nes par défaut, de type String, correspondent ? AnsiString, ont les propriétés suivantes
  • chaque variable est un pointeur vers un prologue suivi des caractères
    
  • elles comportent un prologue avec
    
    • sur 4 octets le nombre de références vers cette valeur
      
    • sur 4 octets la taille, en caractères (donc en octets)
      
    Le schéma est donc le suivant:
    string_reference_count

  • elle utilise la sémantique "copy on write":
    
    • si plusieurs variables String ont la même valeur, elles pointent vers la même adresse
      
    • si nous modifions la valeur d'une des variables, une copie de la valeur précédente est effectuées, et la nouvelle zone mémoire est modifiée
      
    Donc, si nous changeons le surnom 'JOE' en 'JOEL' :
    string_copy_on_write

  • finalement, pour des raisons historiques, le premier caractère ? l'indice 1 (et pas 0)
    
• WideChar sont des caractères Unicode sur 2 octets
  
• WideString sont des pointeurs de cha?nes de caractères Unicode sur 2 octets, compatibles avec le type BSTR COM, donc utilisable pour les appels OLE

• pChar est un pointeur vers un tableau de caractères (Char : 1 octet par caractère).

  Lorsque le pChar pointe vers une "StringZ" Windows, la suite des caractères est terminée par un zéro. Mais nous pouvons faire pointer un pChar vers n'importe quoi (c'est un pointeur de type ^Char, avec des fonctionalités de traitement de cha?nes, comme la longueur, utilisables si nous pointons vers une véritable "StringZ", et dot? d'une sémantique de pointeur C, donc avec possibilit? de recalculer d'adresse par "+")

  Ce type était ? l'origine utilis?

  • pour de nombreux appels des API Windows
    
  • pour effectuer de "l'arithmétique des pointeurs" :
    
    • une variable pChar était initialisée pour pointer vers une zone mémoire
      
    • une addition permettait de déplacer le pointeur (si p pointe vers 1234,ƒhƒ‹ p +3 pointe vers 1237ƒhƒ‹)
      

Voici un bout de programme Delphi 6 qui affiche le contenu d'une String:

soit (la référence d'usage est -1 car la String est locale)

01_string_delphi_6

Et voici un exemple d'affichage Unicode en Delphi 6

et le résultat:

02_widestring_delphi_6

Les librairie d'importation des API Windows (comme WINDOWS.PAS) comportaient en général 3 versions pour chaque procédure ou fonction

• une version Unicode avec un suffixe W
  
• une version Ansi, avec un suffixe A
  
• une version sans suffixe, qui correspondait exactement ? la version Ansi
  

Par exemple

Dans cet exemple, comme pChar et pAnsiChar sont des alias, la version par défaut est la même que la version Ansi.

Finalement, les types String et WideString sont compatibles en affectation, mais l'affectation d'une WideString ? une String peut provoquer une perte d'information.

En résum?, nous constatons donc

• String est l'alias qui désigne le type string préfér?, correspondant ? AnsiString
  
• pour AnsiString, 1 caractère = 1 octet
  
• les WideString sont codés sur 2 octets (ce n'est pas de l'UTF-8 ou de l'UTF-16, il n'y a pas de surrogates). La RTL nous fournissait de nombreuses procédures pour gérer peu ou prou manuellement Unicode, en particulier vers UTF-8 ou pour la gestion des caractères Multi-Byte. Pour les caractères utilisant plusieurs Octets (MBCS), les librairies comme SYSUTILS.PAS contenaient des procédures et fonctions spécifiques, comme IsLeadByte.
  

---

4 - Les types String Delphi 2009 et suivants

4.1 - Résum? de la gestion des caractères

Pour les versions Delphi 2009 et suivantes, l'accent est mis sur Unicode:

• pour la partie Unicode
  
  • l'alias String correspond ? un une cha?ne Unicode codée en UTF-16
    
  • l'alias Char correspond ? un caractère Unicode cod? sur 2 octets, et correspond au type WideChar
    
  • pChar correspond ? un pWideChar
    
  • WideString se comporte comme auparavant, et correspond ? une BSTR COM
    
  • le type Usc4Char est un LongInt, correspondant ? un code point (4 octets)
    
• pour la partie Ansi:
  
  • il existe toujours les types AnsiChar et AnsiString, o? un caractère occupe un octet, ansi que pAnsiChar qui pointe vers un tableau de caractères Ansi (1 caractères= 1 octet)
    
  • AnsiString gère le code page
    
  • String[nn] ou ShortString gèrent des cha?nes de taille mémoire fixe, avec des caractères Ansi sur 1 octet
    
• les procédures et fonctions des librairies (RTL) contiennent toujours des versions suffixées "W" et "A", mais les versions sans suffixe correspondent ? présent ? des cha?nes Unicode
  
• des nouvelles unités (CHARACTER.PAS, ANSISTRING.PAS) et de nombreuses procédures ont ét? ajoutées (dans SYSTEM.PAS et SYSUTILS.PAS) pour faciliter la gestion Unicode et les conversions
  

4.2 - String et UnicodeString

Le type String correspond maintenant ? un une cha?ne UnicodeString qui est une cha?ne Unicode codée en UTF-16

Donc

• les caractères non composites utilisent une "code unit", donc 2 octets
  
• les caractères composites et les surrogates utilisent 2 "code units", donc 4 octets
  

4.2.1 - Format mémoire des String (UnicodeString)

En mémoire, les cha?nes utilisent ? présent un prologue de 12 octets:

• 2 octets pour le code page
  
• 2 octets pour la taille de l'élément (appel? "élément size" par Delphi)
  
• 4 octets pour le compte de référence
  
• 4 octets pour la le nombre de code units (appelés "élément count" par Delphi)
  
• le tableau des code units, donc de 2 octets par "élément", index? ? partir de 1
  

4.2.2 - Longueur de la Cha?ne

Très important:

• la longueur de la cha?ne retournée par Length est le nombre de code units (donc le nombre de mots de 2 octets, ou encore la taille en octets divisée par 2).
  
• En revanche, le nombre de caractères doit être diminu? du nombre de caractères surrogates et de composites.
  
• ma_cha?ne[indice] retournera la code unit ? cette position. Cette valeur sera donc une valeur sur 2 octets, qui PEUT NE PAS pas être un code point
  

Prenons un premier exemple simple.

Nous avons tout d'abord créé une toute petite unit? qui nous permet d'analyser le contenu mémoire et disque:

Et voici un programme qui manipule des String (donc UnicodeString)

• nous avons placés différents contr?les de visualisation
  
  • notre tMemo, en police "Courrier New" pour les explications
    
  • un tRichEdit, une tListbox, un tEdit et un tMemo, qui, par défaut, sont tous en police "Tahoma"
    
• deux procédures nous permettent d'afficher le contenu de cha?nes :
  Procedure display(p_text: String);
  Begin
  Form1.Memo1.Lines.Add(p_text);
  End; // display
  

  Procedure do_display(p_string: String);
  Var l_index: Integer;
  Begin
  With Form1 Do
  Begin
  display('[len='+ IntToStr(Length(p_string))+ '] '+ p_string);
  ListBox1.Items.Add(p_string);
  RichEdit1.Text:= RichEdit1.Text+ p_string;
  Memo2.Lines.Add(p_string);
  Edit1.Text:= Edit1.Text+ p_string;
  

  display(p_string+ ' '+ f_display_unicode_string(p_string));
  For l_index:= 1 To Length(p_string) Do
  display(Format('%2d ', [l_index])+ p_string[l_index]);
  End;
  End; // do_display
  

• et, ? titre d'exemple, un tButton qui affiche la cha?ne "abc éî" (e aigu, i circonflexe) :
  Procedure TForm1.display_unicode_string_Click(Sender: TObject);
  Var l_string: String;
  Begin
  do_display('abc éî');
  End; // display_unicode_string_Click
  

• voici le résultat:

  10_display_unicode_string
  

Comme notre cha?ne ne comporte que des "code unit"s normaux

• Length est égal au nombre d'éléments
  
• la taille en octet est égale ? 2* Length
  
• chaque indice retourne bien un caractère ? la position attendue
  
• le code page est de 1200, qui est un code attribu? arbitrairement aux cha?nes UnicodeString
  

Notez aussi que SYSTEM.PAS contient des méthodes qui vous permettent de récupérer les informations du prologue des String :

4.2.3 - Cha?nes avec surrogates

Les cha?nes contenant des surrogates représentent donc des caractères dont le code point est au del? de 64 K.

Y figure, par exemple

U+1D6C0 MATHEMATICAL BOLD CAPITAL OMEGA

qui est, semble-t-il une sorte d'alias de

U+03A9 GREEK CAPITAL LETTER OMEGA

Pour afficher ce symbole, nous pouvons utiliser plusieurs techniques:

• appeler une fonction qui convertit le code point en String. Nous utilisons une fonction située dans CHARACTER.PAS:
  Type UCS4Char = Type LongWord;
  Function ConvertFromUtf32(C: UCS4Char): String; Inline

  et

  • UCS4Char est défini dans SYSTEM.PAS comme un entier sur 4 octets
    
  • ConvertFromUtf32 convertit le code point en 2 code units
    
• nous pouvons directement affecter directement #1ƒhƒ‹D6C0 ? une String. Delphi fait automatiquement la conversion
  
• nous pouvons stocker les deux code units séparément par stocker #$D835#$DEC0 (nous avons trouv? ces deux valeurs par nos routines d'affichage présentées plus haut)
  
• nous pouvons initialiser la taille de la cha?ne ? 2 par SetLength et y stocker séparément #$D835 et #$DEC0
  

Voici le code correspondant:

Et

11_surrogate_omega

En fait:

• les analyse mémoire sont conformes ? nos attentes :
  
  • Length retourne le nombre de code units (2), qui est aussi la valeur du nombre d'éléments
    
  • les deux codes units sont $D835 et $DEC0 (c'est par ce dump que nous les avons trouvées), et, en mémoire, le code est bien stock? en "little endian"
    
  • la taille est 4 octets
    
• MAIS nous ne voyons pas le "omega" attendu, ? part le dernier qui a ét? affich? par la valeur non-surrogate U+O3A9
  

La raison est que sur ce PC, l'ancienne mécanique XP n'est pas capable, avec les polices sur mon PC d'afficher le surrogate.

Le même .EXE a ét? envoy? sur Windows 7 qui est sur le PC que nous avions du acheter fin 2009 pour gérer notre site internet, et voici le résultat :

surrogage_omega_windows_7.png

et:

• le surrogate oméga appara?t correctement (en Tahoma, et même en Courrier New), sauf dans le tRichEdit, qui ne consent ? afficher que le oméga non-surrogate
  
• nous constatons de plus que le dessin du "omega surrogate mathématique" est légèrement différent du "omega non surrogage"
  

Pour conna?tre la le nombre de "glyphes", nous pouvons utiliser (SYSUTILS.PAS):

qui retournera bien 1 pour notre surrogate omega.

Pour le fun, voici l'affichage des surrogates "CJK" présentés plus haut :

• le code:
  Procedure TForm1.cjk_extension_b_Click(Sender: TObject);
  Var l_string: String;
  l_index: Integer;
  Begin
  // 20000 CJK Unified Ideographs Extension B
  l_string:= '';
  For l_index := 0 To 9 Do
  Begin
  l_low_surrogate:= $DC00+ l_index;
  l_string:= l_string+ #$D840+ Chr(l_low_surrogate);
  End;
  do_display('10 cjk ', l_string);
  End; // cjk_extension_b_Click
  

• le résultat (Windows 7):

  surrogage_cjk_windows_7.png
  

CHARACTER.PAS contient toute une série de fonctions pour tester si un caractère est un surrogate, la partie haute ou basse du surrogate etc.

4.2.4 - Cha?nes avec des composites

Rappelons que les composites sont des caractères "assemblés" avec des code points séparés. Par exemple le "e" et l'accent aigu, pour afficher un "?".

Voici un projet qui affiche la version composite et la version non composite de quelques caractères :

Nous constatons que :

• sur XP, selon les contr?les, l'affichage de composite est plus ou moins réussi
  
• le même .EXE sous Windows 7 affiche bien, dans notre exemple, les mêmes caractères
  

Pour les cha?nes avec des composites

• ElementToCharLen ne calculera PAS le nombre de caractères affichés, mais le nombre de code points. Et pour notre caractère composite, la fonction retournera 2, le nombre de code points
  
• la RTL ne gère PAS actuellement les caractères composites (pas de version Delphi de NormalizeString).
  

Sur XP (avec l'API IDN installée) ou Vista, Windows 7, nous pouvons appeler les API Windows directement.

Voici un exemple l'affichage de "?" et "?" en caractère compos? ou sépar?:

• le code:
  Var g_string: String= '';
  

  Procedure TForm1.display_composite_Click(Sender: TObject);
  Begin
  g_string:= '|éî|'+ '|'+ #0065ƒhƒ‹+ #0301ƒhƒ‹+ #0069ƒhƒ‹+#0302ƒhƒ‹+ '|';
  do_display(g_string);
  End; // display_composite_Click
  

• le résultat (Windows XP) o? vous noterez que le "^" est affich? A COTE du "i":

  39_composite_xp

• le résultat (Windows 7) o? l'affichage de "?" est correct:

  composite_windows_7
  

Comme pour les surrogate,

• le résultat au niveau de l'affichage dépend donc ici aussi de la version de Windows (.DLLs de conversions, taille de la police: ? titre de comparaison, la .DLL TAHOMA fait environ 340 K sur XP 2003 et plus de 700 K sur Windows 7)
  

Mentionnons que ces caractères composites sont peu fréquents dans nos textes usuels. Seules les personnes intéressées par traiter les accents séparément du "e" qu'il y a en dessous seront concernées. Bref, très peu de gens.

4.2.5 - Conclusion String (== UnicodeString)

UnicodeString offre les avantages suivants :

• utilise le comptage de références et la sémantique "copy on write"
  
• ce type correspond au type de Windows.
  

4.3 - Char, WideChar

Le type Char est un alias de WideChar, et correspond ? un caractère Unicode cod? sur 2 octets. Il contient donc une seule code unit UTF-16. Un Char ne peut pas contenir de surrogate (le oméga ou le CFJ extension B). Il peut contenir de composites ("?", soit U+00C9, mais pas #0065ƒhƒ‹+ #0301ƒhƒ‹)

En gros, le type se comporte comme le WideChar sous les versions antérieures ? Delphi 2009.

Un Char est donc toujours une valeur ordinale, qui peut être utilisée dans For, Inc, Dec, High(Char) etc

Pour créer un caractère ? partir de son code unit, nous pouvons utiliser :

• la fonction Chr qui accepte un entier, et retourne le caractère (contrairement ? ce que dit l'aide, le paramètre n'est pas un Byte mais in Integer)
  
• l'opérateur #, qui est une abréviation pour Chr
  
• un surtypage par Char qui provoque la conversion
  

En revanche nous ne pouvons PLUS utiliser un Char dans des ensembles (Set Of), puisque la valeur d'un caractère est codée sur 2 octets, et dépasse donc 255 qui est la limite Pascal pour un élément d'un Set Of. Nous devrons modifier les instructions utilisant IN.

4.4 - pChar et pWideChar

• pChar est un alias pour un pWideChar, et pointe donc sur un tableau de WideChar (2 octets chacun)
  

4.5 - Usc4Char

Ce type correspond ? un LongInt pour pouvoir gérer directement des code points. Il est utilis? dans des primitives de conversion code point <-> Utf-16, comme le montre nos exemples précédents

Pour mémoire, UCS4String est défini comme un Array of UCS4Char (Length retourne donc le nombre de caractères Usc4Char).

4.6 - AnsiString

Si nous souhaitons utiliser les anciens types pour lesquels 1 caractère occupe 1 octet, nous pouvons utiliser AnsiString.

Le type AnsiString

• utilise le même format que les String
  
  • 2 octets pour le code page
    
  • 2 octets pour la taille de l'élément (appel? "élément size" par Delphi)
    
  • 4 octets pour le compte de référence
    
  • 4 octets pour la le nombre de code units (appelés "élément count" par Delphi)
    
  • le tableau des caractères Ansi suit
    
• naturellement
  
  • le code page détermine ? présent le véritable code page Ansi (et pas le code 1200 attribu? ? Unicode).
    
  • la taille de chaque élément est de 1
    
  • le tableau est un tableau de caractères codés chacun sur 1 octet
    

Comme le prologue a la même structure, nous utiliserons le même type t_new_string_header pour afficher le contenu mémoire :

• le code pour explorer une AnsiString
  Procedure do_display_ansi_string(p_ansi_string: AnsiString);
  Var l_index: Integer;
  Begin
  With Form1 Do
  Begin
  ListBox1.Items.Add(p_ansi_string);
  RichEdit1.Text:= RichEdit1.Text+ p_ansi_string;
  Memo2.Lines.Add(p_ansi_string);
  Edit1.Text:= Edit1.Text+ p_ansi_string;
  

  display(p_ansi_string+ ' '+ f_display_ansi_string(p_ansi_string));
  For l_index:= 1 To Length(p_ansi_string) Do
  display(Format('%2d ', [l_index])+ p_ansi_string[l_index]);
  End; // with Form1
  End; // do_display_ansi_string
  

  Var g_ansi_string: AnsiString;
  

  Procedure TForm1.ansistring_Click(Sender: TObject);
  Begin
  g_ansi_string:= 'abc éî';
  do_display_ansi_string(g_ansi_string);
  End; // ansistring_Click
  

• et le résultat:

  31_ansistring
  

4.6.1 - Code page

Par défaut, le code page est celui défini dans le panneau de configuration. Dans notre cas, c'est le code 1252.

Nous pouvons imposer un autre code page, en le spécifiant comme paramètre de AnsiString:

• le code est le suivant:
  Type t_cyrillic_string= Type Ansistring(1251);
  

  Procedure TForm1.generate_cyrillic_Click(Sender: TObject);
  Var l_cyrillic_string: t_cyrillic_string;
  l_index: Integer;
  l_string: String;
  Begin
  l_cyrillic_string:= '';
  For l_index := 127+ 65 To 127+ 65+ 7 Do
  l_cyrillic_string := l_cyrillic_string + t_cyrillic_string(AnsiChar(l_index));
  

  ListBox1.Items.Add(l_cyrillic_string);
  RichEdit1.Text:= RichEdit1.Text+ l_cyrillic_string;
  Memo2.Lines.Add(l_cyrillic_string);
  Edit1.Text:= Edit1.Text+ l_cyrillic_string;
  Memo1.Lines.Add(l_cyrillic_string);
  

  display('');
  display(f_display_ansi_string(AnsiString(l_cyrillic_string)));
  For l_index:= 1 To Length(l_cyrillic_string) Do
  display(
  Format('%2d %1x ', [l_index, Ord(l_cyrillic_string[l_index])])
  + l_cyrillic_string[l_index]);
  End; // generate_cyrillic_Click
  

• et le résultat:

  32_ansi_cyrillic
  

et:

• les tables Unicode.Org indiquent que les majuscules cyrilliques commencent ? 127+ 65
  
• notre cha?ne cyrillique a ét? construite. C'est une cha?ne de 8 caractères, de 1 octet chacun
  
• cette cha?ne est affichée correctement en cyrillique dans les tMemo, tEdit, tRichEdit, car Delphi effectue une conversion implicite en UTF-16 lorsque nous affectons notre AnsiString aux propriétés Text ou Lines
  
• notre analyse du contenu de cette AnsiString montre bien les données mémoire attendues (code page 1251, taille de l'élément 1, 8 éléments, et les codes attendus)
  En revanche
  • l'affichage de la cha?ne dans la fonction f_display_ansi_string ne présente pas les caractères escompt?: comme le paramètre est un paramètre VAR, la conversion implicite n'a pu avoir lieu
    
  • l'affichage caractère ? caractère présente bien le code escompt?, mais le caractère affich? n'est pas cyrillique, car l_cha?ne_cyrillique[indice] est un AnsiChar et son affichage n'est pas converti en Char
    
• nous avons du surtyper le paramètre de f_display_ansi_string par AnsiString, sinon le contenu des octets aurait ét? différent
  

En fait, pour être être absolument certains que nous affichons les caractères mémoire, il est plus simple de surtype par des types non String, comme un Byte^, ce qui évite toute conversion implicite. Par exemple, nous pouvons afficher le contenu de la AnsiString par:

qui fournit:

33_ansi_cyrillic_hex

Et si nous souhaitons afficher ou gérer la cha?ne cyrillique, il aurait ét? plus simple de la convertire explicitement par une affectation ? une String :

qui fournit:

34_ansi_cyrillic_convert

Ici, nous avons construit la cha?ne en utilisant un string AnsiString ayant le code page cyrillique, puis l'avons convertie en UnicodeString pour analyse et affichage

Notez que les conversions entre code page peuvent provoquer des pertes d'information. Voici un exemple o? nous convertissons entre le code page 437 et 1252:

et voici le résultat, qui démontre que 437 -> 1252 -> 427 provoque une perte d'information:

35_convert_code_pages

Si nous avions utilis? une cha?ne UnicodeString, cela ne serait pas arriv?:

et voici le résultat, qui démontre que 437 -> 1252 -> 427 provoque une perte d'information:

36_convert_code_pages_unicode

4.6.2 - RawByteString

Delphi a défini un type RawByteString dont le code page initial est $FFFF:

Ce type a la propriét? de prendre le code page de la cha?ne Ansi qui lui est affect?:

et voici le résultat, qui démontre que 437 -> 1252 -> 427 provoque une perte d'information:

38_convert_code_pages_raw_byte

4.6.3 - Utf8String

Ce type est défini par

Une nouvelle unit? ANSISTRINGS.PAS contient la plupart des procédures et fonctions que nous utilisions jadis pour manipuler les cha?nes Ansi, comportant les noms utilisés avant 2009, ainsi qu'une version spécifiant le préfixe "ansi" explicitement:

Notez que SYSUTILS.PAS comportait aussi des fonctions Ansi_xxx, comme AnsiUpperCase:

toutefois

• les méthodes de SYSUTILS utilisent un paramètre String, et pourront être utilisée sur des String ou des AnsiString (portage plus facile)
  
• ANSISTRING.AnsiUpperCase en revanche force une valeur AnsiString, et est plus efficace sur les cha?nes AnsiString, car elle n'effectue pas de conversion implicite :
  

4.7 - AnsiChar

Ce type correspond ? un caractère sur 1 octet

4.8 - pAnsiChar

Ce type correspond ? un pointeur ^AnsiChar

4.9 - String[nn] et ShortString

De même les anciens types Pascal String[nn] ou ShortString sont toujours disponibles, et correspondent ? des cha?nes dont la taille maximale est figée par la déclaration, l'octet 0 contient la taille, et les caractères sont des caractères Ansi

4.10 - WideString

WideString était auparavant utilis? pour les données caractères Unicode. Son format est essentiellement le même qu'un BSTR Windows.
WideString est toujours appropri? dans les applications COM.

4.11 - Nouvelles Unités, nouvelles primitives

4.11.1 - WINDOWS.PAS et les autres Api Windows

Cette unit? contient toujours les versions "A", et "W", mais ? présent la version non suffixée correspond ? de String, donc des UnicodeString, ou encore les pointeurs de caractères par défaut sont des pWideChar:

4.11.2 - L'Unit? CHARACTER.PAS

Cette unit? contient de nombreuses procédures et fonctions de gestion des cha?nes UnicodeString ansi que des fonctions de conversion (dont nous avons déj? utilis? quelques unes ci-dessus).

Cette unit? offre deux versions

• une version sous forme de méthode de classe de la classe tCharacter
  Type tCharacter=
  Class sealed
  Public
  Class Function ConvertFromUtf32(C: UCS4Char): String; Static;
  End; // tCharacter
  

  Var ma_chaine: String;
  ma_chaine:= tCharacter.ConvertFromUtf32(#1ƒhƒ‹D6C0);
  

• une version globale.
  Function ConvertFromUtf32(C: UCS4Char): String; Inline;
  

  Var ma_chaine: String;
  ma_chaine:= ConvertFromUtf32(#1ƒhƒ‹D6C0);
  

  
  

Cette unit? comporte des procédure extrèmement importantes pour la gestion des cha?nes unicode, comme par exemple (liste partielle):

• des fonctions de conversion:
  Function ConvertFromUtf32(C: UCS4Char): String; Inline;
  Function ConvertToUtf32(Const S: String; Index: Integer): UCS4Char; overload; Inline;
  Function ToLower(C: Char): Char; overload; Inline;
  

  Function GetNumericValue(C: Char): Double; overload; Inline

• des fonctions de test:
  Function GetUnicodeCategory(C: Char): TUnicodeCategory; overload; Inline;
  

  Function IsControl(C: Char): Boolean; overload; Inline;
  Function IsDigit(C: Char): Boolean; overload; Inline;
  Function IsLetter(C: Char): Boolean; overload; Inline;
  Function IsLetter(Const S: String; Index: Integer): Boolean; overload; Inline;
  Function IsLetterOrDigit(C: Char): Boolean; overload; Inline;
  Function IsLetterOrDigit(Const S: String; Index: Integer): Boolean; overload; Inline;
  Function IsLower(C: Char): Boolean; overload; Inline;
  Function IsLowSurrogate(C: Char): Boolean; overload; Inline;
  Function IsNumber(C: Char): Boolean; overload; Inline;
  Function IsPunctuation(C: Char): Boolean; overload; Inline;
  Function IsSeparator(C: Char): Boolean; overload; Inline;
  Function IsSymbol(C: Char): Boolean; overload; Inline;
  Function IsWhiteSpace(C: Char): Boolean; overload; Inline;
  Function IsUpper(C: Char): Boolean; overload; Inline;
  

  Function IsSurrogate(Surrogate: Char): Boolean; overload; Inline;
  Function IsHighSurrogate(C: Char): Boolean; overload; Inline;
  

  
  

Nous avons présent? les versions avec un paramètre Char, mais il existe les versions String de ces procédures et fonctions.

4.12 - La Bibliothèque d'exécution (la RTL)

Quelques précisions sur le comportement de la Rtl

• tStrings : stocke des UnicodeString en interne (reste déclar? comme string).
  
• tWideStrings est inchang? et utilise WideString (BSTR) en interne. Est donc moins efficace que tStrings
  
• tStringStream
  
  • a ét? réécrit
    
  • stocke les cha?nes en interne avec un encodage ANSI par défaut
    
  • cet encodage peut être chang?
    
  • peut être supplant? par tStringBuilder pour la construction de cha?nes
    
• gestion des textes .DFM:
  
  • Delphi 2009 lit toutes les versions de fichiers .DFM précédentes
    
  • le texte pass au format UTF-8 SEULEMENT SI les noms de type des composants, des propriétés ou des composants contiennent des caractères non-ASCII-7
    
  • les cha?nes littérales sont codées (comme auparavant) en utilisant #nnn pour les caractères non-ASCII-7. Par exemple ? est stock? come #233
    
  • les valeurs littérales pourraient éventuellement être codées en UTF-8
    
  • le format binaire du .DFM pourrait passer en UTF-8 pour les noms de type des composants, des propriétés ou des composants
    
• gestion des textes .PAS
  
  • les sources peuvent rester en ANSI, tant qu'ils ne contiennent pas (identificateur ou cha?nes littérales) de caractères qui ne peuvent être utiliser le code page courant
    
  • l'éditeur gère le BOM. Si vous utilisez un gestionnaire de version, assurez-vous qu'il gère aussi UTF-8 et le BOM
    

4.13 - Conclusion

Pour résumer la situation

• c'est le type UnicodeString, cod? en Utf-16 qui est ? présent le type String par défaut
  
• pour ce type, dans l'écrasante majorit? des cas, 1 caractère= 2 octets. Les cas de caractères surrogates ou composite semble plus relever de l'anecdote que de l'industrie. Mais, naturellement, nous pouvons rencontrer ces cas
  
• les principaux problèmes surviendront plus au niveau des conversions entre les différents types de caractères o? des incompatibilités ou des pertes d'informations pourront survenir
  
• les autres problèmes provenant de l'utilisation erronnée de pChar au lieu de pByte relèvent plus de code mal écrit que de problèmes sémantiques
  

---

5 - Migration Unicode en Delphi

5.1 - Migrer vers Delphi 2009, 2010, XE

Les explications précédentes montrent que la compilation de projets antérieurs ? Delphi 2009 peuvent poser quelques problèmes lorsque nous les compilerons et exécuterons avec les versions Delphi 2009 et suivantes.

Nous pouvons rencontrer des problèmes partout o?, par exemple

• du code suppose qu'un caractères occupe 1 octet
  
• des valeurs caractère littérales utilisent un code page précis
  
• des instructions utilisent des primitives applicables que pour les scalaires dont la valeur ne dépasse pas 255 (Set Of)
  

Comme la RTL et la VCL ont ét? entièrement converties un Unicode, il est hélas impossible de demander au compilateur, par une option, un $IFDEF, une directive, un dialogue de l'IDE, de fonctionner "comme avant". Unicode est enracin? trop profondément dans les librairies pour pouvoir être remplac? ? pied lev? pour un projet particulier.

Nous sommes donc forcés d'utiliser Unicode.

Si votre code n'est pas en porte ? faux par rapport aux spécificités Unicode, tout fonctionnera comme avant. C'est, d'après notre expérience, le cas pour 70 % des applications. Dans les autre cas, il faudra

• localiser les parties ? modifier
  
• évaluer l'ampleur des modifications ? apporter
  
• adopter une stratégie général de migration
  
• sélectionner les techniques d'adaptation
  

Nous allons d'abord

• présenter les points isolés qui posent problème
  
• décrire les stratégies de migrations possibles
  

5.2 - Les problèmes potentiels

Les points ? surveiller

• les parties du code qui supposent qu'un caractère occupe 1 octet
  
• l'utilisation de Set Of Char
  
• l'utilisation de pChar
  
• les fichiers et flux
  
• les conversions implicites et explicites
  
• les appels de Dll, les interfaces d'unités
  

5.3 - L'hypothèse 1 caractère= 1 octet

Les traitements usuels n'ont pas besoin de faire une hypothèse sur la taille mémoire des caractères. Les concaténation, insertions, suppressions, indexations, les comparaisons, les fonctions Length, Pos, CompareStr() fonctionnent parfaitement bien quelle que soit la taille. C'est le compilateur que se préoccupe de ce type de considérations.

En revanche, notre code pouvait utiliser, pour accélérer certains traitements, de primitives qui travaillaient fondamentalement sur des caractères de 1 octet. En réalit?, ces primitives nous viennent de l'Apple ][. Pour fournir un traitement de texte pleine page sur un ordinateur avec 30 K de mémoire, une horloge ? 4 KHz et un langage interpréter, pour initialiser le tampon du traitement de texte, le Pascal UCSD avait introduit la primitive FillChar :

depuis une adresse mémoire (paramètre Var sans type) nous remplissions une zone de taille donnée avec un octet. De façon similaires, nous avions Move pour déplacer des octets plus rapidement que ne l'aurait fait une boucle For.

Nous pouvions utiliser ces primitives sous Delphi 6:

ou encore, pour extraire une cha?ne ne contenant que des lettres minuscules (Delphi 6) :

Comme les paramètres "nombre" de FillChar et Move sont des octets, si nous faisons fonctionner ce code sous Delphi 2009

• pour FillChar
  
  • nous n'initialiserons que la moiti? du tampon (Length fournit le nombre de code units Utf-16, pas le nombre d'octets
    
  • si nous ajustons Length en multipliant par 2 (ou ElementSize), nous remplirons bien le tampon, mais avec des octets ' ', donc 32,ƒhƒ‹ et chaque code unit contiendra le code unit 3232,ƒhƒ‹ ce qui n'est PAS l'espace (il faudrait remplir avec des mots égaux ? 0032,ƒhƒ‹ ce que ne sait pas faire FillChar)
    
  • la fonction StringOfChar retourne une String remplie avec un caractère donn?, et devrait remplacer FillChar pour les String
    
• pour Move
  
  • les indices, le nombre de code units ? copier, la taille finale de la cha?ne résultat sont corrects, mais le Move ne copie ici aussi que la moiti? des caractères
    
  • si nous multiplions par 2 le nombre d'octets ? copier, le résultat sera ici correct
    
  • en revanche IN sera refus?, parce que les caractères WideString peuvent dépasser 255.
    

Mentionnons au passage la fonction SizeOf qui retourne la taille en OCTETS d'un type ou d'une variable. Pour les cha?nes Unicode, le résultat ne sera naturellement pas le nombre de caractères. Il faudrait pour cela utiliser Length.

Et pour créer une cha?ne ayant une longueur donnée, c'est SetLength qu'il faut utiliser (depuis longtemps déj?), plut?t que GetMem qui ne gère naturellement pas le prologue des String.

En résum?, seul l'emploi de FillChar ou Move devront être examinés de près lorsque ces primitives sont utilisés sur des String.

5.4 - Utilisation de Set Of Char

Ces instructions sont obsolètes, du fait de la limite ? 255 des valeurs autorisées ? un Set Of.

Si les caractères que nous testons ont un code inférieur ? 128 (ou que leur code unit est la même que le code de notre code page), le test fonctionnera. 'A', ou '?' seront testés correctement. En revanche le test de l'euro ne sera pas correct, car son code unit est 20ƒhƒ‹AC, alors que sont code ansi est 80ƒhƒ‹:

fournira:

56_set_of_char

Plusieures solution

• utiliser des comparaisons, qui, elles, ne sont pas limitées du tout
  
• si les tests Set Of sont destinés ? un analyseur lexical, la solution est bien souvent la refonte de la mécanique de test, en utilisant, par exemple
  • un automate d'état
    
  • des expressions régulières (pour lesquelles une librairie a ét? inclue dans Delphi XE)
    
• utiliser des Set Of AnsiChar
  
• utiliser des primitives telles que CharInSet :
  Type TSysCharSet = Set Of AnsiChar;
  

  Function CharInSet(C: AnsiChar; Const CharSet: TSysCharSet): Boolean;
  overload; Inline;
  Function CharInSet(C: WideChar; Const CharSet: TSysCharSet): Boolean;
  overload; Inline;
  

Procedure TForm1.char_in_set_Click(Sender: TObject);

Procedure check(p_text: String; p_result: Boolean);
Var l_result: String;
Begin
If p_result
Then l_result:= ' OK'
Else l_result:= ' NO';
display(Format('%-30s ', [p_text])+ l_result);
End; // check

Var l_char: Char;
l_ansi_char: AnsiChar;
l_string: String;
l_ansi_string: AnsiString;

Begin // char_in_set_Click
check('CharInSet(''?'', [''?''])', CharInSet('?', ['?']));
check('l_char:= ''?; ''CharInSet(l_char, [''?''])', CharInSet(l_char, ['?']));

l_ansi_char:= AnsiChar(l_char);
check('l_ansi_char:= AnsiChar(l_char); ''CharInSet(l_ansi_char, [''?''])',
CharInSet(l_ansi_char, ['?']));

l_string:= '?';
l_ansi_string:= l_string;
check('l_string:= ''?''; l_ansi_string:= l_string; ''CharInSet(l_ansi_string[1], [''?''])',
CharInSet(l_ansi_string[1], ['?']));
End; // generate_cyrillic_Click