Unterstützung für Free Pascal und Lazarus

HotXLS unterstützt Free Pascal 3.2.2 mit Lazarus/LCL unter Windows Win32 und Win64, einschließlich XLS-/XLSX-Arbeitsmappen-APIs, Formeln, Formatierung, direktem Streaming, den Exportkomponenten TDataToXLS und TGridToXLS sowie Rendering-Helfern

Nativer Linux- und macOS-Arbeitsmappen-Kern

Siehe Compound-File-Speicher für geltungsbereichsbezogene Verzeichnis-APIs, explizites Eigentum am nativen Speicher, Zeitstempel und kanonische Classic-Bezeichnerschlüssel

Das Opt-in-Profil LX_PORTABLE_CORE stellt TXLSWorkbook und TXLSXWorkbook ohne LCL unter Linux und macOS bereit. Native Linux-x64- und macOS-ARM64-Builds wurden mit Free Pascal 3.3.1 kompiliert und ausgeführt; die Quellversions-Sperre verlangt mindestens 3.2.2, aber dieses Minimum behauptet nicht, dass jede native Compiler-/Ziel-Kombination validiert wurde

Setzen Sie cthreads und cwstring vor die HotXLS-Units, fügen Sie Lib zu Unit- und Include-Pfaden hinzu und definieren Sie LX_PORTABLE_CORE für den gesamten Build. Eine native Konsolenanwendung benötigt weder Interfaces noch ein LCL-Widgetset

Wählen Sie eine installierte UTF-8-Locale in der Anwendungsumgebung, wenn Sie mit Unicode-Dateisystempfaden arbeiten. Eine ungültige oder Nicht-UTF-8-Locale kann die native RTL-Dateinamenkonvertierung verlustbehaftet machen; der Validierungshelfer weist eine solche Umgebung explizit zurück, statt die Locale zu ändern oder eine Codepage zu raten

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.

Open- und Save-Methoden behalten ihre normalen Ergebniscode- und Diagnoseverträge. Direkte Aufrufe an Plattformgrenzen können EXLSPlatformUnsupported auslösen; behandeln Sie diese Ausnahme, wenn Sie einen nur unter Windows verfügbaren Dienst aus gemeinsam genutztem Anwendungscode aufrufen

Reproduzierbare native Validierung

Führen Sie den Validierungshelfer auf dem nativen Gast mit einer vorhandenen Free-Pascal-Toolchain, Python 3 und einem nativen C-Compiler aus. Wählen Sie ein neues oder leeres Ausgabeverzeichnis außerhalb des Quell-Checkouts im Gast-Dateisystem

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

Der Helfer kopiert und hasht die Quelleingaben, normalisiert Pascal-Unit-Dateinamen in der privaten Build-Kopie für FPCs Case-sensitiver Dateinamensuche, baut PCRE2 lokal und führt Kern-, AES-, Kompressions-, REGEX-, öffentliche Arbeitsmappen- und Integrationszeugen aus. Er bewahrt Quellmanifeste, Compiler-Logs, Artefakte und Fehler, ohne das Checkout zu ändern, Tools zu installieren oder die Compiler-Konfiguration zu bearbeiten; macOS-ARM64-Builds zielen explizit auf macOS 11 oder neuer

Zu den Integrationszeugen gehören Unicode-Pfade, von Excel erstellte XLSB-Fixtures, Formel-Caches und Neuberechnung, wiederholtes Öffnen, sparsame ODS-Notizen und Schutz, die Zurückweisung geprüfter Konvertierung, Abbruch, der Aufruferziele bewahrt, invariante geltungsbereichsbezogene Namenssuche, echte Worker-Fehlerkapselung und kryptografische Zufallsbytes

Native Classic-XLS-Verträge

Verwenden Sie lxHandle für Classic-TXLSWorkbook und lxHandleX für TXLSXWorkbook. Klassisches Recalculate liefert eine Fehlerzahl — null bedeutet Erfolg —, seine Calculate-Methode liefert ein Formelergebnis. Klassische Formula-Zuweisungen an Zellen benötigen ein führendes =. Die Open- und Save-Methoden der Arbeitsmappe behalten ihren etablierten Erfolgswert 1

Die native Classic-Speicherimplementierung verwendet echte Compound-File-Hierarchie und Stream-Identitäten und bewahrt verschachtelte Geltungsbereiche, MiniFAT-Daten und erweiterte DIFAT-Ketten. Stream-Payloads werden materialisiert, und der Writer weist aggregierte Ausgabe jenseits seiner unterstützten signed-32-Bit-Puffer-/Sektorgrenzen zurück, bevor er sie emittiert; dies ist keine Multi-Gigabyte-Streaming-Speicherimplementierung

Nativer Compound-Speicher bietet direkte Stream-Operationen, Enumeration, Metadaten und Kopieroperationen. Transaktions-Rollback, Regionssperrung, Verschieben und nicht unterstützte Ausschlussmodi liefern explizite Speicherfehler. Er emuliert keine Windows-COM-, Clipboard- oder GDI-Dienste

Klassische native Dateispeicherungen serialisieren, bevor sie eine registrierte Geschwisterdatei atomar ersetzen. Stream-Speicherungen des Aufrufers staffeln die vollständige Compound-Datei, bevor sie an der ursprünglichen Position kopiert wird, und bewahren Präfixe und Abbruchfehler vor dem Commit. Die letzte Fortschrittsmeldung bleibt nicht abbrechbar. Direkte Compound-Speicher-Helper-Schreibvorgänge folgen ihrem gewöhnlichen Direktschreibvertrag statt der öffentlichen Arbeitsmappen-Speichertransaktion

Gewöhnliche Summary- und Document-Summary-Eigenschaften verwenden begrenzte Standard-OLE-Property-Sets mit Unicode-Text und UTC-FILETIME-Zeitstempeln. Diese Eigenschaftsstreams bleiben Klartext, wenn Classic-Arbeitsmappendaten verschlüsselt sind, und der RC4-CryptoAPI-Header zeichnet diese Wahl explizit auf. Definierte Namen teilen die angepinnten kanonischen Bezeichnerschlüssel der XLSX-Fassade, behalten aber ihre ursprüngliche Schreibweise und ihren expliziten Arbeitsblattgeltungsbereich. Kodierte PNG/JPEG-Zeichnungsdaten bleiben dem Modell verfügbar; die native Bitmap-/Metafile-Konvertierung erfordert einen separaten unterstützten Renderer und löst sonst EXLSPlatformUnsupported aus

Kompilieren Sie Tests/Lazarus/HotXLSNativeClassicWorkbookSmoke.lpr mit denselben nativen Kern-Optionen und übergeben Sie dann Tests/Fixtures/classic-native/native-classic.xls, einen wegwerfbaren gastlokalen Ausgabepfad und Tests/Fixtures/classic-native/native-classic-encrypted.xls. Die Kontrollen decken von Excel erstellte Caches, Neuberechnung, exakte Unicode-Namen, klare und verschlüsselte Roundtrips, unabhängig dekodierte Eigenschafts-Zeitstempel, wiederholtes Öffnen, mehr als 16 MB SST-Daten und die Bewahrung der Aufruferausgabe ab

Legacy-BIFF-Bytekodierung

TXLSWorkbook.SetCodePage wählt die explizite Bytekodierung, die SaveAs(..., xlExcel5) verwendet, mit CP1252 als Standard; der Import einer BIFF2–BIFF5-Datei mit nutzbarem, nonzero CODEPAGE-Datensatz wählt diese Seite auch für spätere Legacy-Speicherungen

Legacy-Zellbeschriftungen, Formeltextkonstanten und -arrays, gecachte Formel-Strings, definierte Namen, Arbeitsblattnamen und -referenzen, Schriftartnamen, Zahlenformate, Stilnamen, Kopf- und Fußzeilen sowie gewöhnlicher Kommentartext verwenden diese deklarierte Seite statt der Betriebssystem-Locale oder UTF-8

Datensatzlängen und Arbeitsblatt-Stream-Offsets zählen kodierte Bytes; die vorhandenen 255-Byte-Limits für Legacy-Labels und Formalliterale schneiden nur an ganzen Zeichengrenzen ab, sodass ein CP932-Doppelbyte-Zeichen nie geteilt wird; Namen und Metadaten mit Ein-Byte-Länge weisen kodierten Text zurück, der länger als ihre darstellbare Länge ist, statt eine ungültige Länge zu emittieren

Text, der durch die gewählte Codepage nicht round-trippt, löst EConvertError aus, bevor er stillschweigend zu einem Ersatz- oder Best-Fit-Zeichen werden kann; wählen Sie eine Seite, die den Dokumenttext repräsentiert, oder speichern Sie als BIFF8 für Unicode-Strings

Formel-Cache-Strings über CONTINUE-Datensätze hinweg werden als Bytes zusammengesetzt, bevor sie dekodiert werden, sodass eine Datensatzgrenze ein Doppelbyte-Zeichen teilen kann, ohne den gecachten Wert zu beschädigen

Ein Wechsel der gewählten Seite baut typisierte Legacy-Formel- und definierte-Namen-Bytes aus ihrem Unicode-Modell neu auf; BIFF8-Speicherungen verwenden weiterhin Unicode, und ihr CODEPAGE-Wert auf der Festplatte bleibt 1200

Importierte BIFF5-Diagrammdatensätze behalten ihre ursprüngliche Codepage für die Inspektion typisierter Serien und angehängter Titel, auch nach einer Codepage-Bearbeitung der Arbeitsmappe oder einer Diagrammkopie; das Speichern auf eine andere Seite transkodiert explizit unterstützte SeriesText, einfache gecachte Labels und Formel-Strings, Kopf- und Fußzeilen sowie externe Blattnamen der aktuellen Arbeitsmappe, statt bewahrte Bytes unter der neuen Deklaration neu zu interpretieren

Fortgesetzter Diagrammtext, nicht modellierte Legacy-Encodings externer Blätter und opake Legacy-Byte-Text-Datensätze weisen eine Codepage-Migration mit EConvertError zurück; nicht darstellbarer unterstützter Text wird ebenfalls zurückgewiesen, und das öffentliche Arbeitsmappen-Speichern bewahrt das Aufruferziel vor dem Commit; dieser Textvertrag verspricht keine vollständige Konvertierung der nativen Diagrammdarstellung

Benutzerdefinierte BIFF5-Stilnamen beginnen direkt nach der Ein-Byte-kodierten Länge, während BIFF5-SeriesText einen Bezeichner und eine Ein-Byte-kodierte Länge ohne Unicode-Flag hat; BIFF8-SeriesText ergänzt sein Unicode-Flag, und die Konvertierung unterstützten Diagrammtexts aktualisiert diesen Datensatz und die Diagramm-BOF-Version gemeinsam

Nichtleere BIFF5-Diagramm-Kopf- und Fußzeilen verwenden eine Ein-Byte-kodierte Länge mit einem Maximum von 255 Bytes; gecachte LABEL- und STRING-Datensätze verwenden Zwei-Byte-Längen, während BIFF8-Kopf- und Fußzeilen eine Zwei-Byte-UTF-16-Länge plus ihr Unicode-Flag verwenden; die Migration prüft das tatsächliche Layout jedes Datensatzes und weist eine überdimensionale Legacy-Kopf- oder Fußzeile mit ERangeError zurück, bevor sie angehängt wird

HotXLS interpretiert Legacy-Bytes anhand ihrer deklarierten Seite unter Windows, Linux und macOS; der installierte Excel-16.0-Build 20430 zeigte unabhängig eine Empfänger-Einschränkung: Er interpretierte Legacy-Bytes anhand seines lokalen Windows-CP936, selbst nachdem nur der CODEPAGE-Datensatz einer nativen Datei auf CP1252 oder CP932 geändert wurde — korrekt deklarierte Bytes garantieren also keinen passenden Text in dieser Empfängerkonfiguration

Bewahren Sie die tatsächliche Encoding-Deklaration des Dokuments und testen Sie die empfangende Anwendung, wenn Sie BIFF5 über verschiedene Locale-Konfigurationen hinweg verteilen; Unicode-BIFF8 vermeidet diese besondere Legacy-Byte-Interoperabilitätsgrenze

Diese Bytekodierungs-Korrektur behält das vorhandene Größenlimit des BIFF5-Datensatzes für gewöhnliche Kommentare bei; sie fügt dem Legacy-Datensatz keine Felder für Kommentar-Autoren, Rich-Text-Formatierung oder Shape-Geometrie hinzu

Die Bearbeitung von VBA-Modulquellen verwendet die deklarierte Byte-Codepage des Projekts und bewahrt den Binärpräfix vor dem Quelloffset, einschließlich eingebetteter Null-Bytes; dies ändert gespeicherten Quelltext und führt keine Makros aus

BIFF8-komprimiertes Unicode mit fHighByte = 0 mappt jedes Byte direkt auf eine UTF-16-Codeeinheit von U+0000 bis U+00FF; es ist nicht CP1252, UTF-8 oder die Legacy-Codepage der Datei, selbst wenn ein nichtstandardmäßiger CODEPAGE-Datensatz in einer ansonsten BIFF8-Datei auftaucht

Native Textformeln behalten UTF-16-Längen und -Positionen, einschließlich Surrogat-Paar-Codeeinheiten; Unicode-LOWER, -UPPER, -SEARCH, TEXTBEFORE/TEXTAFTER mit Groß-/Kleinschreibungs-unempfindlichen Trennern, Datenbank-Feldköpfe, Case-insensitive Kriterien und dynamische Textschlüssel verwenden die Unicode-Zeichendaten des nativen Compilers statt der ASCII-only-Casing-Funktionen der Host-C-Locale, während die gewöhnliche Arbeitsblattsortierung ihren vorhandenen Locale-Vergleich behält

Natives LET/LAMBDA-Local-Name-Matching und die Klassifikation lokaler Array-Speicherung verwenden dieselbe Unicode-bewusste Groß-/Kleinschreibungsbehandlung, sodass Case-Gegenstücke die korrekte erfasste Bindung auflösen und deren Arrayform behalten; dies ändert den angepinnten öffentlichen Vertrag zur Identität definierter Namen nicht

Klassisches Case-insensitives FindText und ReplaceText behält den Unicode-Zeichenabgleich für Literal- und Excel-Wildcard-Suchen auf nativem FPC; MatchCase unterscheidet weiterhin Groß-/Kleinschreibung, literale Ersetzung behält ihr Replace-All-Verhalten, Wildcard-Ersetzung behält ihr vorhandenes Leftmost-Span-Verhalten, und Formelzellen bleiben ausgeschlossen

Kompilieren Sie Tests/Lazarus/HotXLSNativeLegacyEncodingSmoke.lpr mit den nativen Kern-Optionen und übergeben Sie ein wegwerfbares Ausgabeverzeichnis gefolgt von Tests/Fixtures/legacy-encoding/native-biff5-cp936-chart.xls; der Zeuge prüft deklarierte CP1252-, CP932- und CP936-Bytes unabhängig, jeden Arbeitsblatt-Offset, Codepage-Wechsel, Doppelbyte-Fortsetzungsgrenzen, komprimierten BIFF8-Import, Formelberechnung, nativ erstellten Diagrammtext und die Bewahrung des Ziels bei fehlgeschlagenem Speichern

Voll-Installer

Der Voll-Installer erkennt Lazarus und unterstützt die Installation ohne RAD Studio. Wählen Sie auf der Seite IDE-Integration Lazarus / Free Pascal, um das Laufzeitpaket, Kompatibilitäts-Einheiten und Build-Skripte zu installieren; diese Option ist vorausgewählt, wenn Lazarus die einzige erkannte IDE ist

Wählen Sie auf der Seite Post-install Compilation das Free-Pascal-Laufzeitpaket für Win32 oder Win64. Ein Ziel ist verfügbar, wenn sein Compiler sowie die RTL-, LCL- und LazUtils-Einheiten erkannt werden; Sie können die Paketquellen auch dann installieren, wenn ein Ziel nicht verfügbar ist, und später kompilieren

Das Paket ist ein reines Laufzeitpaket und wird in Lazarus als Projektabhängigkeit hinzugefügt. Der Installer kompiliert die VCL-Demos nicht mit Free Pascal

Erstellen und Testen

Öffnen Sie Lib/FPC/HotXLSLaz.lpk in Lazarus und kompilieren Sie das Laufzeitpaket, oder führen Sie diese Befehle aus dem HotXLS-Verzeichnis heraus aus

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

Setzen Sie LAZARUS_DIR, um eine Installation auszuwählen; FPC_EXE und LAZBUILD_EXE können bei Bedarf explizite Compiler- bzw. Package-Builder-Programme auswählen

Die ausgewählte Installation muss FPC sowie kompilierte LCL-/LazUtils-Einheiten für die Zielarchitektur enthalten; Ausgaben und Package-Builder-Konfiguration werden in separaten Architekturverzeichnissen gehalten

Einrichtung der Anwendung

Fügen Sie Lib und Lib/FPC zum Unit-Suchpfad und Lib zum Include-Suchpfad hinzu, oder nehmen Sie das Laufzeitpaket als Abhängigkeit des Lazarus-Projekts auf

Stellen Sie Interfaces in der Uses-Liste der Anwendung vor die HotXLS-Einheiten, auch bei Konsolenanwendungen; damit werden das LCL-Widgetset und die UTF-8-Konvertierung an den RTL/LCL-Grenzen initialisiert

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.

Die HotXLS-Quelleinheiten wählen intern Delphi-Unicode-Semantik, sodass Zeichenfolgen, Zeichen und Formeltext ihr UTF-16-Verhalten behalten; Anwendungscode kann seinen bevorzugten Pascal-Modus verwenden

Kompatibilitätsdetails

• Das Laufzeitpaket erfordert Windows und die LCL; TDataToXLS exportiert LCL-Datenmengen und TGridToXLS exportiert ein TDBGrid, mit oder ohne explizite Spalten, während Linux, macOS, VCL-Demoformulare, der VCL-Arbeitsmappen-Viewer und der DevExpress-Grid-Adapter außerhalb dieses Pakets liegen
• ZIP- und Kompressionsstreams verwenden das gebündelte Pascal-Backend und benötigen keine separate zlib-DLL
• AES verwendet für beide Architekturen ein Pascal-Backend, einschließlich passwortgeschützter XLSX-Dateien
• PNG behält seinen Alphakanal, EMF verwendet Aufzeichnung und Wiedergabe von Windows-Metadateien, und mehrseitiges TIFF nutzt die Windows-GDI+-Laufzeit
• Das direkte Textlesen akzeptiert UTF-8 und BOM-markiertes UTF-16/UTF-32, verarbeitet gestreamte Eingaben und belässt das Stream-Eigentum beim Aufrufer
• Initialisieren Sie TXlsCsvImportOptions mit TXlsCsvImportOptions.Default, bevor Sie einzelne Felder ändern
• FPC-Berichtsausdrücke und Importmuster verwenden die Unicode-Syntax von URegExpr statt dem PCRE-Backend von Delphi. Eine leere Eingabe wird so beantwortet, wie TRegEx sie beantwortet: Ein Muster, das eine leere Zeichenfolge akzeptiert, wie ^$ oder .*, trifft sie, während [0-9]+ sie nicht trifft, und das Ersetzen einer leeren Zeichenfolge ergibt nur dann den Ersetzungstext, wenn das Muster sie akzeptiert; nicht unterstützte und leere Muster lösen ERegularExpressionError aus, den Berichtsausdrücke als REPORT_EXPRESSION_INVALID_REGEX offenlegen