Introduction

Jusqu'à la version 2.6.x inclus, la RTL est basée sur ceux de Turbo Pascal et Delphi 7. Cela signifie qu'elle était au départ basé sur les types shortstring, ansistring et pchar. Aucun de ces types n'avait d'information d'encodage associé avec eux, mais ils étaient supposés être implicitement encodés dans l'"encodage système par défaut" et étaient passés aux API système sans aucune conversion.

Dans Delphi 2009, Embarcadero a basculé l'ensemble de la RTL vers le type UnicodeString, qui représente des chaînes utilisant UTF-16. En plus, ils sont rendu le type AnsiString "sensible (aware) à la page de code". Cela signifie que les AnsiStrings dès lors contiennent la page de code selon lequel les données doivent être interprétées.

Le support au niveau du langage de FPC est déjà disponible dans les versions en cours de développement du compilateur (FPC 2.7.1/trunk). Le support au niveau RTL n'est pas encore complet. Cette page donne une vue d'ensemble des comportements relatifs à la page de code pour ces types de chaînes, le niveau actuel du support par la RTL et des possibles voies d'amélioration futures pour ce support.

Compatibilité ascendante

Si vous avez du code existant qui marche d'une façon connue (*) avec une version antérieure de FPC et que vous ne faites aucun changement, il devrait continuer à fonctionner non modifié avec la nouvelle verison de FPC. Garantir tel est le but principal de la multitude de variables de page de code et leurs valeurs par défaut, comme décrit ci-dessous.

(*) cela veut dire this principalement : vous ne stockez pas de donnée dans une AnsiString qui a été encodée par autre chose que la page de code par défaut du système et par la suite passe cette chaîne tel quelle à une routine RTL de FPC. Par exemple, le code actuel de Lazarus est bien en général, comme vous êtes censés appeler UTF8ToAnsi() avant de passer ses chaînes aux routines RTL de FPC.

Code pages

Une page de code définit comment les octets individuels d'une chaînes sont interprétés i.e. quelle lettre, quel symbole ou autre caractère graphique correspond à chaque octet ou séquence d'octets.

Identificateurs de page de code

Un identificateur de page de code est toujours enregistré comme un TSystemCodePage, qui est un alias pour Word. La valeur représente la page de code correspondante telle que définie par [http://msdn.microsoft.com/en-us/library/windows/desktop/dd317756(v=vs.85).aspx Microsoft Windows]. En plus, il y a 3 valeurs spéciales de code de page :

• CP_ACP: cette valeur représente la "page de code par défaut" en cours. Voir #Réglage de la page de code pour plus d'information.
• CP_OEM: cette valeur représente la page de code OEM. Sur les plates-formes Windows, ceci correspond à la page de code utilisée par la console (par exemple les fenêtres cmd.exe). Sur d'autres plates-formes, cette valeur est interprétée de la même façon que CP_ACP.
• CP_NONE: cette valeur indique qu'aucune information de page de code n'a été associée avec la donnée chaîne. Le résultat de toute opération explicite ou implicite qui convertit cette donnée en une autre page de code est indéfinie

Note: les identificateurs de page de code sont différent des noms de page de code tels qu'ils sont utilisés dans la directive {$codepage xxx} (qui est déjà disponible dans la version stable de FPC). Les noms de page de code sont des noms d'unités individuelles de page de code exposés dans l'unité de jeu de caractères, qui ont des noms tels que cp866 et cp1251 et utf8.

Réglage de la page de code

L'unité system contient plusieurs variables globales qui indiquent la page de code par défaut utilisée par certaines opérations.

DefaultSystemCodePage

• Usage: détermine comment CP_ACP est interprété
• Valeur initiale:
  • Windows: C'est le résultat de l'appel système à GetACP, qui retourne la page de code ANSI de Windows.
  • iOS: UTF-8
  • Unix (sauf iOS): Basé sur le réglage actuel des variables d'environnement LANG ou LC_CTYPE. C'est en général UTF-8, mais il n'est pas garanti que cela soit le cas.
  • Autres plates-formes: CP_ACP (ces plates-formes ne supportent actuellement pas les pages de code multiples, et sont codés en dur pour utiliser la page de code spécifique au système dans tous les cas)
• Modifications: vous pouvez modifier cette valeur en appelant SetMultiByteConversionCodePage(CodePage: TSystemCodePage)
• Notes: Depuis que cette variable peut être modifiée, ce n'est plus une bonne idée d'utiliser cette valeur pour déterminer la "page de code par défaut" réelle du système (à moins de le faire au démarrage du programme et d'être certain qu'aucune autre unité ne l'a changé dans son code d'initialisation).

DefaultFileSystemCodePage

• Usage: Définit la page de code vers laquelle les noms de chemin/fichier sont traduits avant d'être passé lors d'un appel à une API système, si la RTL utilise une API système à simple octet pour cette usage sur la plate-forme courante. Ce page de code est aussi utilisée pour les opérations intermédiaires sur les chemins d'accès dans la RTL avant de faire des appels aux API système. Cette variable n'existe pas dans Delphi et a été introduite dans FPC pour rendre possible le changement de valeur de DefaultSystemCodePage sans casser les interfaces RTL avec les appels du système de fichier du système d'exploitation.
• Valeur initiale:
  • Windows: UTF-8, parce que la RTL utilise des appels aux API système UTF-16 (donc aucune donnée n'est perdue dans les opérations intermédiaires).
  • OS X and iOS: UTF-8 (comme défini par Apple)
  • Unix (mis à part OS X et iOS): DefaultSystemCodePage, parce que l'encodage des fichiers est indéfini sur les plates-formes Unix (c'est un tableau non typé d'octets qui peut être interprété comme on veut ; il n'est pas garanti d'être de l'UTF-8 valide)
  • Autres plates-formes: identique à DefaultSystemCodePage
• Modifications: vous pouvez modifier cette valeur en appelant SetMultiByteFileSystemCodePage(CodePage: TSystemCodePage)
• Notes: Les réglages Unix/OS X/iOS s'appliquent seulement dans le cas où le gestionnaire de widestring cwstring est installé, sinon DefaultFileSystemCodePage aura la même valeur que DefaultSystemCodePage après le démarrage du programme.

DefaultRTLFileSystemCodePage

• Usage: définit la page de code vers laquelle les noms de fichier/chemin sont traduits avant d'être retournées par les routines RTL pour les fichier/chemin RawByteString. Des exemples sont dans les noms de fichier/chemin retournés par les versions RawbyteString de SysUtils.FindFirst et System.GetDir. La principale raison de son existence est de rendre la RTL capable de fournir la compatibilité ascendante avec les versions antérieures de FPC, comme celles-ci retournaient toujours des chaînes encodées pour les API système en simple octet utilisées (qui étaient habituellement ce qui est connu maintenant comme DefaultSystemCodePage).
• Valeur initiale
  • Windows: DefaultSystemCodePage, pour compatibilité ascendante.
  • OS X and iOS: UTF-8, pour compatibilité ascendante (c'était déjà toujours UTF-8 dans le passé, puisque c'est ce que les API de fichiers de l'OS retourne et nous ne convertissions pas cette donnée).
  • Unix (mis à part OS X et iOS): DefaultSystemCodePage, pour la même raison qu'avec DefaultFileSystemCodePage. Régler celle-ci à une autre valeur que DefaultFileSystemCodePage est une mauvaise idées sur ces plates-formes, puisque toute conversion peut corrompre ces chaînes car leur encodage initial est inconnu.
  • Autres plates-formes: comme pour DefaultSystemCodePage
• Modifications: Vous pouvez modifier cette valeur en appelant SetMultiByteRTLFileSystemCodePage(CodePage: TSystemCodePage)
• Notes: les mêmes que pour DefaultFileSystemCodePage.

Page de code du fichier source

La page de code du fichier sourcedétermine comment les constantes de chaîne sont interprétées et où le compilateur insèrera l'opération de conversion de la page de code à l'affectation d'un type de chaîne vers un autre.

La page de code du fichier source est déterminée de la façon suivante:

• Si le fichier contient une directive {$codepage xxx} (p.ex. {$codepage UTF8}), alors le page de code du fichier source est cette page de code, sinon
• Si le fichier commence par un UTF-8 BOM, alors la page de code du fichier source est UTF-8, sinon
• Si {$modeswitch systemcodepage} est active, la page de code du fichier source est la DefaultSystemCodePage de l'ordinateur sur lequel le compilateur lui-même s'exécute (i.e., la compilation du code source peut créer un programme qui se comporte différemment sur un autre système; cette bascule est disponible pour la compatibilité avec Delphi et est activée par défaut avec {$mode delphiunicode}), sinon
• la page de code du fichiers source est définie comme CP_ACP (pour compatibilité ascendante avec les versions antéreures de FPC)

Strings

String/character types

Shortstring

La page de code d'une shortstring est implicitement CP_ACP d'où elle sera toujours égale à la valeur courante de DefaultSystemCodePage.

PAnsiChar/AnsiChar

Ces types sont les mêmes que les anciens types PChar/Char. Dans tous les modes du compilateur sauf pour {$mode delphiunicode}, PChar/Char sont aussi encore des alias pour PAnsiChar/AnsiChar. Leur page de code est implicitement CP_ACP et donc toujours égale à la valeur courante de DefaultSystemCodePage.

PWideChar/PUnicodeChar et WideChar/UnicodeChar

Ces types demeurent inchangés. WideChar/UnicodeChar peuvent contenir une simple unité de code UTF-16, alors que PWideChar/PUnicodeChar pointe sur une simple unité de code ou un tableau d'unités de code en UTF-16.

En {$mode delphiunicode}, PChar devient un alias de PWideChar/PUnicodeChar et Char devient un alias de WideChar/UnicodeChar.

UnicodeString/WideString

Ces types se comporte comme dans les versions précédentes:

• Widestring est le même qu'un "COM BSTR" dans Windows et un alias de UnicodeString sur toutes les autres plates-formes. Sa chaîne de données est encodée avec de l'UTF-16.
• UnicodeString est une chaîne à comptage de référence avec une longueur maximale de high(SizeInt) en unités de code UTF-16.

Ansistring

Les AnsiStrings sont des chaînes à comptage de références avec une longueur maximal de high(SizeInt) octets. En plus, une information de code de page peut maintenant leur être associée.

La chose la plus importante à comprendre sur le nouveau type AnsiString est qu'il a à la fois une page de code déclarée/statique/préférée/par défaut (appelée page de code declarée à partir de maintenant), et une page de code dynamique. La page de code declarée dit au compilateur que lorsqu'on affecte quelque chose à cet AnsiString, il devrait d'abord convertir cette donnée vers cette page de code (sauf si c'est CP_NONE, voir RawByteString plus bas). La page de code dynamique est une propriété de l'AnsiString qui, tels la longueur et le compteur de référence, définit la page de code en cours des données actuellement tenues par cette AnsiString.

Page de code declarée

La page de code declarée d'une AnsiString peut seulement être définie en déclarant un nouveau type comme suit:

type
  CP866String = type AnsiString(866); // note the extra "type"

La page de code declarée d'une variable déclarée comme pure AnsiString est CP_ACP. En effet, le type AnsiString est maintenant sémantiquement défini dans l'unité System comme:

type
  AnsiString = type AnsiString(CP_ACP);

Un autre type AnsiString(X) prédéfini dans l'unité System est UTF8String:

type
  UTF8String = type AnsiString(CP_UTF8);

Une fois que vous avez défini tel type AnsiString(X), vous pouvez l'utiliser pour déclarer des variables, des paramètres, champs etc comme d'habitude.

Notez que CP_UTF16 et CP_UTF16BE ne sont pas valides comme page de code pour les AnsiStrings. Ce qui peut résulter d'une telle définition est indéfini.

Page de code dynamique

Si une chaîne d'une page de code declarée X1 est affectée par une chaîne d'une pafe de code X2, alors:

• si (X1 = CP_NONE) ou (X2 = CP_NONE), voir RawByteString, sinon
• si (la page de code du source <> CP_ACP), alors si (X2 = CP_ACP) et (X1 = page de code du fichier source) ou vice-versa, aucune conversion ne sera faite (même si à l'exécution, DefaultSystemCodePage a une valeur différente de la page de code du fichier source). La raison pour la condition (page de code du source <> CP_ACP) est la compatibilité ascendante avec les versions antérieures de FPC (alors qu'elles ne prennent pas en charge AnsiStrings avec des pages de codes arbitraires, elles réinterprètaient toujours AnsiStrings en fonction de la valeur actuelle de la page de code du système). Sinon
• si (X1 <> X2), la donnée chaîne sera convertie de la page de code X1 vers la page de code X2 avant affectation, par laquelle CP_ACP sera interprétée comme la valeur actuelle de DefaultSystemCodePage. Sinon,
• Si (X1 = X2), aucune coversion de page de code ne sera réalisée.

Ces règles signifient qu'il est parfaitement possible pour une variable AnsiString d'avoir une page de code dynamique qui diffère de sa page de code declarée. P.ex. dans le troisième cas, X1 pourrait être CP_ACP, alors qu'après affectation, il pourrait avoir un page de code dynamique égale à DefaultSystemCodePage.

Note: comme mentionné au-dessus, qu'une conversion potentielle de page de code survienne ou pas dépend seulement de la page de code declarée des chaînes impliquées. Cela signifie que si vous affectez une AnsiString(X) à une autre AnsiString(X) et que l'ancienne page de code dynamique était différente de X, la chaîne ne sera pas convertie vers la page de code X par l'affectation.

RawByteString

Le type RawByteString est défini comme

type
  RawByteString = type AnsiString(CP_NONE);

Comme mentionné avant, les résultats de conversions de/vers la page de code CP_NONE sont indéfinis. Comme cela n'a pas de sens de définir un type dans la RTL dont le comportement est indéfini, le comportement de RawByteString est quelque peu différent des autres types AnsiString(X).

Comme première approximation, RawByteString paut être considéré comme un "AnsiString non typé": affecter une AnsiString(X) vers une RawByteString a exactement le même comportement que d'affecter cet AnsiString(X) vers une autre variable AnsiString(X) avec la même valeur de X: aucune conversion de page de code ou copie ne se passe, seul le compteur de référence est incrémenté.

Moins intuitif est probablement le fait que lorsqu'une RawByteString est affectée vers une AnsiString(X), la meêm chose se produit: pas de conversion de page de code ni de copie, seulment une incrémentation du compteur. Notez que cela signifie que les résultats de fonctions retourant une RawByteString ne seront jamais converties vers la page de code de destination. C'est une autre manière par laquelle la page de code dynamique d'une AnsiString(X) peut devenir différente de sa page de code declarée.

Ce type est principalement utilisé pour déclarer des const, constref et des paramètres par valeur qui acceptent toute valeur AnsiString(X) sans la convertir vers une page de code prédéfinie. Notez que si vous faites cela, la routine acceptant ces paramètres devrait être capable de manipuler des chaînes avec n'importe quelle page de code dynamique.

Les paramètres var et out peuvent être aussi déclarés comme RawByteString, mais dans ce cas, le compilateur donnera une erreur si une AnsiString(X) dont le page de code declarée est différente de CP_NONE est passé dedans. C'est consistant avec les paramètres var et out en général: ils nécessitent une exacte correspondance de type à passer dedans. Vous pouvez ajouter une conversion explicite de type vers RawByteString() pour supprimer l'erreur, mais vous devez être préparé à traiter le fait que la chaîne retournée peut avoir aucune page de code dynamique.

Concaténation de chaîne

Normalement, en Pascal le type du résultat d'une expression est indépendant de comment son résultat est utilisé après. P.ex. multiplier 2 longints sur une plate-forme 32-bit et affecter le résultat vers un Int64 réalisera encore la multiplication en utilisant l'artithmétique 32-bit, et seulement après le résultat is converti en 64 bit.

Les chaînes sensibles à la page de code sont la seule exception à la règle: concaténer deux chaînes ou plus se produit toujours sans perte de données, bien qu'après la chaîne résultante sera bien sûr convertie vers la page de code declarée de la destination (une perte de donnée peut alors en résulter).

Affecter le résultat d'une concaténation vers une RawByteString est aussi particulier:

• si toutes les chaînes concaténées ont la même page de code dynamique, le résultat aura la même page de code aussi
• dans les autres cas le résultat sera converti vers CP_ACP (nous pouvons ajouter une option dans le futur pour changer ce comportement de RawByteString, qui n'est pas très pratique).

String constants

Le compilateur doit connaître la page de code selon laquelle il devra interprété les constantes de chaîne car il peut avoir à les convertir au moment de la compilation. Normalement, une constante de chaîne est interprétée selon la page de code du fichier source. Si la page de code du fichier source est ACP_CP, une valeur par défaut est utilisée à la place: dans ce cas, pendant les conversions, la constante de chaîne est supposée avoir la page de code 28591 (ISO 8859-1 Latin 1; Western European).

Quand une constante de chaîne est affectée dans une AnsiString(X) soit par code ou comme partie d'une constante typée ou d'une initialisation de variable alors :

• si X = CP_NONE (i.e., la cible est une RawByteString), le résultat est le même que si la constante String était affectée vers une AnsiString(CP_ACP)
• si X = CP_ACP et que la page de code de la constante String est différente de CP_ACP, alors la constante est convertie, lors de la compilation, vers la page de code du fichier source. Si la page de code du fichier source est aussi CP_ACP, alors elle sera copiée sans changement avec la page de code CP_ACP et donc sa signification/interprétation dépendra de la valeur en cours de DefaultSystemCodePage à l'exécution. Ceci garantit la compatibilité avec les anciennes versions de FPC lors de l'affectation des constantes String sans employer une directive {$codepage xxx} un BOM UTF-8.
• Pour les autres valeurs de X, la constante String est convertie, à la compilation, vers la page de code X.

Similairement, si une constante String est affectée dans une UnicodeString, la constante String est convertie, à la compilation, de la page de code du fichier source vers UTF-16.

Pour les ShortString et PChar, la même règle que pour AnsiString(CP_ACP) est suivie.

Notez que les constantes String symboliques seront converties à la compilation vers le type String et la page de code appropriés chaque fois qu'ils sont utilisés. Cela signifie qu'il n'y a pas de charge sur la vitesse en utilisant une constante simple chaîne dans des contextes de pages de code et types de chaîne multiples, seulement quelque charge sur la taille de donnée.

Il s'ensuit de tout ceci que pour garantir une interprétation prédictible des constantes String dans votre code source, il est mieux soit inclure une directive explicite {$codepage xxx} (ou d'utiliser l'option en ligne de commande -Fc), ou enregistrer le code source en UTF-8 avec un BOM.

Indexation de chaîne

Rien ne change dans l'indexation de chaînes. Chaque élément d'une chaîne UnicodeString/WideString est à 2 octets et chaque élément de tout autre type de chaîne est à 1 octet. Le mécanisme d'indexation de chaîne ignore totalement les pages de code et les points de code composites.

Changements dans la RTL

En vue de garantir pleinement l'intégrité de donnée en présence de chaîne sensible à la page de code, toutes les routines dans la RTL et les paquets qui acceptent des paramètres AnsiString doivent être adaptées. La raison en est que si leurs paramètres restent des purs AnsiString alors toute chaîne avec un code de page statique sera convertie vers DefaultSystemCodePage quand elle sera passée dedans. Il en résultera une perte de donnée.

Jusqu'à maintenant, les routines traitant de l'accès au système de fichier ont été mise à jour pour préserver toute la donnée caractère. Ci se trouve une liste exhaustive de toutes les routines qui préservent l'encodage des chaînes dans FPC 2.7.1 et postérieur. Sauf mention explicitement contraire, ces routines ont également toutes des surcharges qui acceptent des paramètres UnicodeString.

• System: FExpand, LowerCase, UpperCase, GetDir, MKDir, ChDir, RMDir, Assign, Erase, Rename, standard I/O (Read/Write/Readln/Writeln/Readstr/Writestr), Insert, Copy, Delete, SetString
• ObjPas (used automatically in Delphi and ObjFPC modes): AssignFile
• SysUtils: FileCreate, FileOpen, FileExists, DirectoryExists, FileSetDate, FileGetAttr, FileSetAttr, DeleteFile, RenameFile, FileSearch, ExeSearch, FindFirst, FindNext, FindClose, FileIsReadOnly, GetCurrentDir, SetCurrentDir, ChangeFileExt, ExtractFilePath, ExtractFileDrive, ExtractFileName, ExtractFileExt, ExtractFileDir, ExtractShortPathName, ExpandFileName, ExpandFileNameCase, ExpandUNCFileName, ExtractRelativepath, IncludeTrailingPathDelimiter, IncludeTrailingBackslash, ExcludeTrailingBackslash, ExcludeTrailingPathDelimiter, IncludeLeadingPathDelimiter, ExcludeLeadingPathDelimiter, IsPathDelimiter, DoDirSeparators, SetDirSeparators, GetDirs, ConcatPaths, GetEnvironmentVariable
• Unix: fp*() routines related to file system operations (no UnicodeString overloads), POpen
• DynLibs: all routines

A faire dans la RTL

Comme la liste ci-dessus est exhaustive, aucune autre routine RTL ne supporte encore des pages de code arbitraire. Cette section contient une liste des pièges que certaines personnes ont identifiés et, si possible, des solutions de contournement. Notez que les routines non mentionnés ici ni ci-dessus sont aussi peu sûres que celles qui sont explicitement mentionnées.

TFormatSettings et DefaultFormatSettings

Le type de ThousandSeparatoretDecimalSeparatorest AnsiChar. Cela veut dire que siDefaultSystemCodePage'' vaut UTF-8 et que le séparateur de locale fait plus d'un caractère de longueur dans cet encodage, ces champs ne seront pas assez grands. Des exemples sont le blancs insécables français et russes utilisés pour représenter le séparateur des milliers.

Sections anciennes/obsolètes

Warning: Ces sections sont conservées à titre historique - SVP, mettez à jour les sections du dessus avec cette information si elle est toujours applicable. Depuis FPC 2.7, (version en cours de développement), le support intensif d'Unicode a été implémenté.

Changements visibles par l'utilisateur

(*** non traduit car obsolète ***)

Full support of code page aware strings is not possible without breaking some existing code. The following list tries to summarize the most important user visible changes.

• The string header has two new fields: encoding and element size. On 32 Bit platforms this increases the header size by 4 and on 64 bit platforms by 8 bytes.
• WideCharLenToString, UnicodeCharLenToString, WideCharToString, UnicodeCharToString and OleStrToString return an UnicodeString instead of an Ansistring before.
• the type of the dest parameter of WideCharLenToString and UnicodeCharLenToString has been changed from Ansistring to Unicodestring
• UTF8ToAnsi and AnsiToUTF8 take a RawByteString now

Voir aussi

• Types caractère et chaîne
• Cas d'utilisation d'Unicode
• Support d'Unicode par la LCL
• Suggestion: not Delphi compatible enhancement for Unicode Support

From the Free Pascal wiki, page "FPC Unicode support/fr", as it stood on 2020-02-16 after a change by GAN, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's Licensing page. If you have concerns about this material, message the admin.