Prise en charge de Free Pascal et Lazarus

HotXLS prend en charge Free Pascal 3.2.2 avec Lazarus/LCL sous Windows Win32 et Win64, y compris les API de classeurs XLS/XLSX, les formules, la mise en forme, le streaming direct, les composants d'exportation TDataToXLS et TGridToXLS ainsi que les aides de rendu

Noyau de classeurs natif Linux et macOS

Voir le stockage de fichiers composés pour les API de répertoires à portée, la propriété native explicite du stockage, les horodatages et les clés canoniques d'identifiants classiques

Le profil sur option LX_PORTABLE_CORE expose TXLSWorkbook et TXLSXWorkbook sans LCL sous Linux et macOS. Linux x64 natif et macOS ARM64 ont été compilés et exécutés avec Free Pascal 3.3.1 ; le garde de version source exige au moins 3.2.2, mais ce minimum n'affirme pas que chaque combinaison de compilateur et de cible natives a été validée

Placez cthreads et cwstring avant les unités HotXLS, ajoutez Lib aux chemins d'unités et d'includes, et définissez LX_PORTABLE_CORE pour toute la construction. Une application console native n'exige ni Interfaces ni un widgetset LCL

Sélectionnez une locale UTF-8 installée dans l'environnement de l'application quand vous travaillez avec des chemins de fichiers Unicode. Une locale invalide ou non UTF-8 peut rendre la conversion de noms de fichiers de la RTL native avec perte ; l'aide de validation rejette explicitement cet environnement au lieu de changer la locale ou de deviner une page de codes

program NativeWorkbookExample;
{$mode delphiunicode}
uses
  cthreads, cwstring, SysUtils, lxHandleX;
var
  Workbook: TXLSXWorkbook;
begin
  Workbook:= TXLSXWorkbook.Create;
  try
    Workbook.Sheets.Add('Data').Cells[1, 1].Value:= 5;
    Workbook.Sheets[1].Cells[1, 2].Formula:= 'A1*2';
    if Workbook.Recalculate<> 1 then
      raise Exception.Create('Workbook calculation failed');
    if Workbook.SaveAs('native.xlsx')<> 1 then
      raise Exception.Create('Workbook save failed');
  finally
    Workbook.Free;
  end;
end.

Les méthodes d'ouverture et d'enregistrement conservent leurs contrats ordinaires de code de résultat et de diagnostics. Les appels directs aux frontières de plateforme peuvent lever EXLSPlatformUnsupported ; gérez cette exception quand vous invoquez un service réservé à Windows depuis du code applicatif partagé

Validation native reproductible

Exécutez l'aide de validation sur l'invité natif avec une toolchain Free Pascal existante, Python 3 et un compilateur C natif. Choisissez un répertoire de sortie nouveau ou vide hors du checkout source sur le système de fichiers de l'invité

python3 Tests/Lazarus/run_native_core.py --fpc /path/to/fpc --output /guest-local/hotxls-validation
python3 Tests/Lazarus/run_native_core.py --fpc /path/to/fpc --config /path/to/fpc.cfg --output /guest-local/hotxls-validation-2

L'aide copie et hache les entrées sources, normalise les noms de fichiers des unités Pascal dans la copie de construction privée pour la recherche de noms de fichiers sensible à la casse de FPC, construit PCRE2 localement, et exécute les témoins de noyau, AES, compression, REGEX, classeurs publics et intégration. Elle préserve manifestes de sources, journaux du compilateur, artefacts et échecs sans modifier le checkout, sans installer d'outils ni éditer la configuration du compilateur. Les builds macOS ARM64 ciblent explicitement macOS 11 ou ultérieur

Les témoins d'intégration comprennent chemins Unicode, fixtures XLSB créées par Excel, caches de formules et recalcul, ouvertures répétées, notes ODS éparses et protection, rejet de conversion contrôlée, annulation préservant les destinations de l'appelant, recherche invariante de noms à portée, confinement des échecs de vrais threads de travail et octets aléatoires cryptographiques

Contrats natifs XLS classique

Utilisez lxHandle pour le TXLSWorkbook classique et lxHandleX pour TXLSXWorkbook. Le Recalculate classique renvoie un nombre d'erreurs, donc zéro signifie succès ; sa méthode Calculate renvoie un résultat de formule. Les affectations classiques de Formula de cellule exigent un = de tête. Les méthodes d'ouverture et d'enregistrement du classeur gardent leur résultat de succès établi de 1

L'implémentation native de stockage classique utilise une vraie hiérarchie de fichiers composés et de vraies identités de flux, en préservant les portées imbriquées, les données MiniFAT et les chaînes DIFAT étendues. Les charges de flux sont matérialisées et l'écrivain rejette une sortie agrégée dépassant ses bornes signées 32 bits prises en charge de tampon/secteur avant de l'émettre ; ce n'est pas une implémentation de stockage en flux de plusieurs gigaoctets

Le stockage composé natif fournit des opérations directes de flux, d'énumération, de métadonnées et de copie. Le rollback de transaction, le verrouillage de régions, le déplacement et les modes d'exclusion non pris en charge renvoient des erreurs de stockage explicites. Il n'émule pas les services COM, presse-papiers ni GDI de Windows

Les enregistrements de fichiers classiques natifs sérialisent avant de remplacer atomiquement un fichier frère enregistré. Les enregistrements de flux de l'appelant mettent en scène le fichier composé complet avant de copier à la position d'origine, en préservant les préfixes et les échecs d'annulation avant le commit. La dernière notification de progression reste non annulable. Les écritures directes d'aides de stockage composé suivent leur contrat ordinaire d'écriture directe plutôt que la transaction d'enregistrement publique du classeur

Les propriétés de résumé et de résumé de document ordinaires utilisent des jeux de propriétés OLE standard bornés avec texte Unicode et horodatages UTC FILETIME. Ces flux de propriétés restent en texte clair quand les données du classeur classique sont chiffrées, et l'en-tête RC4 CryptoAPI enregistre explicitement ce choix. Les noms définis partagent les clés canoniques d'identifiants épinglées utilisées par la façade XLSX, tout en conservant leur orthographe d'origine et leur portée explicite de feuille. Les données de dessins PNG/JPEG encodées restent disponibles pour le modèle ; la conversion native bitmap/métafichier exige un renderer séparé pris en charge et lève sinon EXLSPlatformUnsupported

Compilez Tests/Lazarus/HotXLSNativeClassicWorkbookSmoke.lpr avec les mêmes options de noyau natif, puis passez Tests/Fixtures/classic-native/native-classic.xls, un chemin de sortie jetable local à l'invité et Tests/Fixtures/classic-native/native-classic-encrypted.xls. Les contrôles couvrent les caches créés par Excel, le recalcul, les noms Unicode exacts, les aller-retours simples et chiffrés, les horodatages de propriétés décodés indépendamment, les ouvertures répétées, plus de 16 Mo de données SST et la préservation de la sortie de l'appelant

Encodage d'octets BIFF historique

TXLSWorkbook.SetCodePage sélectionne l'encodage d'octets explicite utilisé par SaveAs(..., xlExcel5), avec CP1252 par défaut ; importer un fichier BIFF2–BIFF5 avec un enregistrement CODEPAGE non nul utilisable sélectionne aussi cette page pour les enregistrements historiques ultérieurs

Les étiquettes de cellules historiques, les constantes de texte de formules et les tableaux, les chaînes de formules en cache, les noms définis, les noms et références de feuilles, les noms de polices, les formats de nombres, les noms de styles, les en-têtes, les pieds de page et le texte de commentaires ordinaires utilisent cette page déclarée plutôt que la locale du système d'exploitation ou UTF-8

Les longueurs d'enregistrements et les décalages de flux de feuilles comptent les octets encodés ; les limites historiques existantes de 255 octets pour les étiquettes et littéraux de formules tronquent seulement à une frontière de caractère entier, si bien qu'un caractère double-octet CP932 n'est jamais coupé ; les noms et métadonnées avec une longueur d'un octet rejettent un texte encodé plus long que leur longueur représentable au lieu d'émettre une longueur invalide

Le texte qui ne peut pas faire l'aller-retour via la page de codes sélectionnée lève EConvertError avant de pouvoir devenir silencieusement un caractère de remplacement ou de meilleur ajustement ; sélectionnez une page qui représente le texte du document, ou enregistrez en BIFF8 pour des chaînes Unicode

Les chaînes de caches de formules s'étendant sur des enregistrements CONTINUE sont assemblées en octets avant décodage, si bien qu'une frontière d'enregistrement peut couper un caractère double-octet sans corrompre la valeur en cache

Changer la page sélectionnée reconstruit les octets typés historiques de formules et de noms définis depuis leur modèle Unicode ; les enregistrements BIFF8 continuent d'utiliser Unicode et leur valeur CODEPAGE sur disque reste 1200

Les enregistrements de graphiques BIFF5 importés conservent leur page de codes d'origine pour l'inspection typée des séries et des titres attachés, y compris après une édition de page de codes du classeur ou une copie de graphique ; enregistrer vers une autre page transcode explicitement les SeriesText pris en charge, les étiquettes en cache simples et les chaînes de formules, les en-têtes, les pieds de page et les noms de feuilles externes du classeur courant, plutôt que de réinterpréter les octets préservés sous la nouvelle déclaration

Le texte de graphiques continu, les encodages historiques de feuilles externes non modélisés et les enregistrements de texte octet opaques historiques rejettent une migration de page de codes avec EConvertError ; le texte pris en charge non représentable rejette aussi, et l'enregistrement public du classeur préserve la destination de l'appelant avant le commit ; ce contrat de texte ne promet pas une conversion complète de l'apparence native des graphiques

Les noms de styles personnalisés BIFF5 commencent immédiatement après la longueur encodée d'un octet, tandis que le SeriesText BIFF5 a un identifiant et une longueur encodée d'un octet sans indicateur Unicode ; le SeriesText BIFF8 ajoute son indicateur Unicode, et convertir du texte de graphiques pris en charge met à jour cet enregistrement et la version BOF du graphique ensemble

Les en-têtes et pieds de page BIFF5 de graphiques non vides utilisent une longueur encodée d'un octet avec un maximum de 255 octets ; les enregistrements en cache LABEL et STRING utilisent des longueurs de deux octets, tandis que les en-têtes et pieds de page BIFF8 utilisent une longueur UTF-16 de deux octets plus leur indicateur Unicode ; la migration vérifie la disposition réelle de chaque enregistrement et rejette un en-tête ou un pied de page historique trop grand avec ERangeError avant de l'ajouter

HotXLS interprète les octets historiques selon leur page déclarée sous Windows, Linux et macOS ; la build d'Excel 16.0 20430 installée a démontré indépendamment une limitation du destinataire : elle interprétait les octets historiques selon son CP936 Windows local même après que l'enregistrement CODEPAGE d'un fichier natif seul fut changé en CP1252 ou CP932, donc des octets déclarés corrects ne garantissent pas un texte correspondant dans cette configuration de destinataire

Préservez la déclaration d'encodage réelle du document et testez l'application destinataire lors de la distribution de BIFF5 entre différentes configurations de locale ; le BIFF8 Unicode évite cette frontière particulière d'interopérabilité d'octets historiques

Cette correction d'encodage d'octets conserve la limite existante de taille d'enregistrement de commentaires ordinaires BIFF5 ; elle n'ajoute pas d'auteur de commentaires, de mise en forme de texte enrichi ni de champs de géométrie de formes à l'enregistrement historique

L'édition de source de modules VBA utilise la page de codes d'octets déclarée du projet et préserve le préfixe binaire avant le décalage de la source, octets null incorporés compris ; cela change le texte de source stocké et n'exécute pas de macros

Le Unicode compressé BIFF8 avec fHighByte = 0 mappe chaque octet directement vers une unité de code UTF-16 de U+0000 à U+00FF ; ce n'est ni CP1252, ni UTF-8, ni la page de codes historique du fichier, même quand un enregistrement CODEPAGE non standard apparaît dans un fichier par ailleurs BIFF8

Les formules de texte natives conservent les longueurs et positions UTF-16, unités de code de paires de substitution comprises ; les délimiteurs insensibles à la casse des casse Unicode LOWER, UPPER, SEARCH, TEXTBEFORE/TEXTAFTER, les en-têtes de champs de bases de données, les critères insensibles à la casse et les clés de texte dynamiques utilisent les données de caractères Unicode du compilateur natif plutôt que les fonctions de casse ASCII de la locale C hôte, tandis que l'ordre ordinaire des feuilles conserve sa comparaison de locale existante

La correspondance de noms locaux LET/LAMBDA native et la classification de stockage de tableaux locaux utilisent la même casse consciente d'Unicode, si bien que les contreparties de casse résolvent la bonne liaison capturée et conservent la forme de son tableau ; cela ne change pas le contrat épinglé d'identité publique des noms définis

Le FindText et le ReplaceText classiques insensibles à la casse conservent la correspondance de caractères Unicode pour les recherches littérales et de jokers Excel sur FPC natif ; MatchCase distingue toujours la casse, le remplacement littéral garde son comportement remplacer-tout, le remplacement de jokers garde son comportement existant d'étendue la plus à gauche, et les cellules de formules restent exclues

Compilez Tests/Lazarus/HotXLSNativeLegacyEncodingSmoke.lpr avec les options de noyau natif et passez un répertoire de sortie jetable suivi de Tests/Fixtures/legacy-encoding/native-biff5-cp936-chart.xls ; le témoin vérifie indépendamment les octets déclarés CP1252, CP932 et CP936, chaque décalage de feuille, les changements de page de codes, les frontières de continuation double-octet, l'import BIFF8 compressé, le calcul de formules, le texte de graphiques créé nativement et la préservation de la destination en cas d'échec d'enregistrement

Programme d'installation complet

Le programme d'installation complet détecte Lazarus et prend en charge l'installation sans RAD Studio. Sélectionnez Lazarus / Free Pascal sur la page d'intégration IDE pour installer le package d'exécution, les unités de compatibilité et les scripts de build ; cette option est sélectionnée par défaut quand Lazarus est le seul IDE détecté

Sur la page Post-install Compilation, sélectionnez le package d'exécution Free Pascal pour Win32 ou Win64. Une cible est disponible quand son compilateur et ses unités RTL, LCL et LazUtils sont détectés ; vous pouvez quand même installer les sources du package quand une cible n'est pas disponible et les compiler plus tard

Le package ne contient que le code d'exécution et s'ajoute comme dépendance de projet dans Lazarus. Le programme d'installation ne compile pas les démos VCL avec Free Pascal

Compilation et tests

Ouvrez Lib/FPC/HotXLSLaz.lpk dans Lazarus et compilez le package d'exécution, ou exécutez ces commandes depuis le répertoire HotXLS

build-FPC-Lib.cmd Win64
Tests\Lazarus\Run-HotXLSLazarusSmoke.cmd Win64
build-FPC-Lib.cmd Win32
Tests\Lazarus\Run-HotXLSLazarusSmoke.cmd Win32

Définissez LAZARUS_DIR pour sélectionner une installation ; FPC_EXE et LAZBUILD_EXE permettent de choisir explicitement les exécutables du compilateur et du générateur de packages si nécessaire

L'installation sélectionnée doit contenir FPC ainsi que les unités LCL/LazUtils compilées pour l'architecture cible ; les sorties et la configuration du générateur de packages sont conservées dans des répertoires distincts par architecture

Configuration de l'application

Ajoutez Lib et Lib/FPC au chemin de recherche des unités et Lib au chemin de recherche des includes, ou ajoutez le package d'exécution comme dépendance du projet Lazarus

Placez Interfaces avant les unités HotXLS dans la clause uses de l'application, y compris pour les applications console ; cela initialise le widgetset LCL et la conversion UTF-8 aux frontières RTL/LCL

program WorkbookExample;
{$mode delphiunicode}
uses
  Interfaces, SysUtils, lxHandleX;
var
  Workbook: TXLSXWorkbook;
begin
  Workbook:= TXLSXWorkbook.Create;
  try
    Workbook.AddSheet('Data');
    Workbook.Sheets[1].Cells[1, 1].Value:= 'Hello';
    if Workbook.SaveAs('example.xlsx')<> 1 then
      raise Exception.Create('Workbook save failed');
  finally
    Workbook.Free;
  end;
end.

Les unités sources de HotXLS sélectionnent en interne la sémantique Unicode de Delphi afin que chaînes, caractères et texte de formules conservent le comportement UTF-16 ; le code applicatif peut utiliser son mode Pascal préféré

Détails de compatibilité

• Le package d'exécution requiert Windows et la LCL ; TDataToXLS exporte des datasets LCL et TGridToXLS exporte un TDBGrid, avec ou sans colonnes explicites, tandis que Linux, macOS, les fiches de démonstration VCL, la visionneuse de classeurs VCL et l'adaptateur de grille DevExpress sont hors de ce package
• Les flux ZIP et de compression utilisent le backend Pascal embarqué et ne nécessitent pas de DLL zlib distincte
• AES utilise un backend Pascal pour les deux architectures, y compris pour les fichiers XLSX protégés par mot de passe
• PNG conserve son canal alpha, EMF utilise l'enregistrement et la lecture des métafichiers Windows, et le TIFF multipage s'appuie sur le runtime GDI+ de Windows
• La lecture directe de texte accepte UTF-8 et UTF-16/UTF-32 avec BOM, gère les entrées diffusées en flux et laisse la propriété du flux à l'appelant
• Initialisez TXlsCsvImportOptions avec TXlsCsvImportOptions.Default avant de modifier des champs individuels
• Les expressions de rapports et les motifs d'importation FPC utilisent la syntaxe URegExpr Unicode plutôt que le backend PCRE de Delphi. Une entrée vide est traitée comme le fait TRegEx : un motif qui accepte une chaîne vide, comme ^$ ou .*, y correspond tandis que [0-9]+ ne le fait pas, et le remplacement d'une chaîne vide produit le texte de remplacement uniquement lorsque le motif l'accepte ; les motifs non pris en charge et les motifs vides lèvent ERegularExpressionError, que les expressions de rapports exposent sous la forme REPORT_EXPRESSION_INVALID_REGEX