OpenXLSX
v0.3.2
OpenXLSX是一個C ++庫，可使用.XLSX格式閱讀，寫作，創建和修改MicrosoftExcel®文件。
正如標題所說，在https://github.com/troldal/openxlsx/releases上顯示的最新“發行版”來自2021-11-06，並且已過時 - 請直接從目前的存儲庫中拉/下載最新的SW版本。那些不想使用git人的鏈接：https：//github.com/troldal/openxlsx/archive/refs/heads/heads/master.zip.zip
響應＃299審查了XldateTime代碼，並修復了一個我認為自己可能介紹的錯誤。抱歉，日期現在應正確構建double ， struct tm和time_t ，然後轉換回struct tm 。
更改歷史記錄在詳細的更改日誌中找到。
如今，開發分支的功能最終使它進入了主要分支:)有關詳細信息，請參閱下面的詳細更改日誌。
總之：
OpenXLSX/headers/XLStyles.hpp ：XlStyles類（和許多子類）已被添加，幾乎可以完全訪問所有Excel格式化功能。OpenXLSX/headers/XLMergeCells.hpp和XLSheet.hpp ：XLMergeCells類可通過XLWorksheet訪問，以創建/刪除單元格合併Examples/Demo10.cpp演示瞭如何使用樣式和合併注意：使用testBasics = false禁用的部分將破壞所得的Excel電子表格，如果啟用了，唯一的目的是演示對所有新類和方法的訪問。如果要使用它們，請確保正確使用它們Note on XLNumberFormat(s) : Contrary to all other XLStyles elements, these do not use an index within the XML as the referrable ID (XLCellFormat::setNumberFormatId), but instead a user-defined ID that can be set via XLNumberFormat::setNumberFormatId - and for an XLCellFormat, can be set to either a self-defined number format ID, or達到MS預定義的格式。通常，對於自定義格式，建議使用ID> 100。
在待辦事項列表中：
幾天前，我終於有時間學習足夠的GIT功能，能夠與分支機構合作。因此，我創建了一個開發分支，其中具有最新功能，這些功能在某些拉的請求 /問題中提到。隨意看看。這樣，您就不必等到主存儲庫更新。
關閉了2024年5月更新中實現的眾多拉動請求，並實施了PR＃246和＃253的另外兩個社論。
經過長時間的不活動，我決定恢復OpenXLSX的開發。該代碼已經清理，已修復了大量錯誤。該庫已在Windows，MacOS和Linux上進行了測試，應在所有平台上使用。
我要衷心感謝所有通過報告錯誤，建議功能或提交拉拉請求來為該項目做出貢獻的人。我還要感謝所有主演該項目並對該項目表現出興趣的人。
特別是，我要感謝Lars Uffmann（https://codeberg.org/lars_uffmann/）對該項目的貢獻。拉爾斯（Lars）花了大量時間和精力來清理代碼，修復錯誤並實施新功能。沒有他的幫助，該項目將不會在今天的國家。
許多編程語言具有本地或以開源庫的形式修改Excel文件的能力。這包括Python，Java和C＃。但是，對於C ++，情況更加分散。儘管有一些庫，但它們通常不那麼成熟，並且功能集較小，而不是其他語言。
由於沒有完全滿足我需求的開源庫，所以我決定開發OpenXLSX庫。
雄心勃勃的是OpenXLSX應該能夠讀取，編寫，創建和修改Excel文件（數據和格式化），並以盡可能少的依賴項進行讀取，創建和修改Excel文件（數據和格式化）。目前，OpenXLSX取決於以下第三方庫：
這些庫都是僅標題的，並且包含在存儲庫中，即不必單獨下載和構建。
同樣，焦點已經放在速度上，而不是內存使用（儘管有一些選擇以減少內存使用的選項，以速度為代價；稍後會詳細介紹）。
OpenXLSX已在以下平台/編譯器上進行了測試。請注意，“ - ”並不意味著OpenXLSX不起作用；這只是意味著它沒有經過測試：
| 海灣合作委員會 | 鐺 | MSVC | |
|---|---|---|---|
| 視窗 | 明格 | 明格 | + |
| cygwin | - | - | N/A。 |
| macos | + | + | N/A。 |
| Linux | + | + | N/A。 |
以下編譯器版本應該能夠在沒有錯誤的情況下編譯OpenXLSX：
clang 7應該能夠編譯OpenXLSX，但顯然在實現STD ::變體中有一個錯誤，這會導致編譯器錯誤。
Visual Studio 2017也應該有效，但尚未進行測試。
OpenXLSX使用CMAKE作為構建系統（或確切地說是構建系統發生器）。因此，您必須先安裝Cmake，以構建OpenXLSX。您可以在www.cmake.org上找到安裝說明。
OpenXLSX庫位於此存儲庫的OpenXLSX子目錄中。 OpenXLSX子目錄是一個獨立的CMAKE項目。如果您將CMAKE用於自己的項目，則可以將OpenXLSX文件夾添加到您自己的項目中。另外，您可以使用CMAKE生成您選擇的工具鏈的製作文件或項目文件。這兩種方法均在以下內容中進行描述。
到目前為止，在您自己的項目中使用OpenXLSX的最簡單方法是自己使用CMake，然後將OpenXLSX文件夾添加到您自己項目的源樹中。 IDE的幾個支持CMAKE項目，最著名的是Visual Studio 2019，Jetbrains Clion和QT Creator。如果使用Visual Studio，則必須在創建新項目時專門選擇“ CMAKE項目”。
將OpenXLSX庫作為源子文件夾的主要好處是，無需專門找到庫和標頭文件。 Cmake會為您照顧。另外，庫將使用與項目相同的配置（調試，發布等）構建。特別是，這是在Windows上的好處，當STL對象通過庫接口（在OpenXLSX中）傳遞時，不可能在Debug項目（反之亦然）中使用發布庫（反之亦然）。包括OpenXLSX源時，這將不是問題。
通過在cmakelists.txt文件中使用add_subdirectory()命令，您可以訪問OpenXLSX的標題和庫文件。 OpenXLSX可以生成共享庫或靜態庫。默認情況下，它將產生共享庫，但是您可以在openxlsx cmakelists.txt文件中更改該庫。該庫位於名為OpenXLSX的命名空間中；因此，庫的全名是OpenXLSX::OpenXLSX 。
以下片段是您自己項目的最小cmakelists.txt文件，其中包括OpenXLSX作為子目錄。請注意，二進製文件的輸出位置設置為公共目錄。在Linux和MacOS上，這並不是真正需要的，但是在Windows上，這將使您的生活更輕鬆，因為否則您必須將OpenXLSX共享庫文件複製到可執行文件的位置才能運行。
cmake_minimum_required ( VERSION 3.15)
project (MyProject)
set (CMAKE_CXX_STANDARD 17)
# Set the build output location to a common directory
set ( CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR} / output )
set ( CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR} / output )
set ( CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR} / output )
add_subdirectory (OpenXLSX)
add_executable (MyProject main.cpp)
target_link_libraries (MyProject OpenXLSX::OpenXLSX)使用以上內容，您應該能夠編譯和運行以下代碼，該代碼將生成一個名為“ everdysheet.xlsx”的新Excel文件：
# include < OpenXLSX.hpp >
using namespace OpenXLSX ;
int main () {
XLDocument doc;
doc. create ( " Spreadsheet.xlsx " );
auto wks = doc. workbook (). worksheet ( " Sheet1 " );
wks. cell ( " A1 " ). value () = " Hello, OpenXLSX! " ;
doc. save ();
return 0 ;
}如果您想生產OpenXLSX二進製文件並將其包含在項目中，則可以使用CMAKE和您選擇的編譯器工具鏈完成。
在命令行中，導航項目根的OpenXLSX子目錄，並執行以下命令：
mkdir build
cd build
cmake ..
最後一個命令將配置項目。這將使用默認工具鏈配置項目。如果要指定工具鏈，請鍵入cmake -G "<toolchain>" ..使用<toolchain>是您希望使用的工具鏈，例如“ Unix Makefiles”，“ Ninja”，“ Ninja”，“ Xcode”或“ Visual Studio 16 2019”。有關詳細信息，請參見CMAKE文檔。
最後，您可以使用命令構建庫：
cmake --build . --target OpenXLSX --config Release
您可以將--target和--config參數更改為您想要使用的任何內容。
構建時，您可以使用以下命令安裝它：
cmake --install .
此命令將將庫和標頭文件安裝到平台上的默認位置（通常是Linux和MacOS上的/usr/local/local/local/linak/linak/linak and MacOS，以及在Windows上的C： Program Files）。您可以使用-prefix參數設置其他位置。
請注意，根據平台，可能無法同時安裝調試和發布庫。在Linux和MacOS上，這不是一個大問題，因為發行庫可以用於調試和發布可執行文件。對於Windows而言，並非如此，其中庫的配置必須與鏈接到它的可執行文件相同。因此，在Windows上，只需將OpenXLSX源文件夾作為您的CMAKE項目的子目錄，要容易得多。這將為您節省很多頭痛。
OpenXLSX仍在進行中。以下是已實施並應正常工作的功能列表：
與格式，圖和數字有關的功能尚未實施，並且不計劃在不久的將來。
應該注意的是，創建const xldocument對象當前不起作用！
下表是來自基準的輸出（使用Google Benchmark庫），該輸出表明可以以每秒約4,000,000個單元格的速率完成閱讀/寫入訪問。由於轉換為.xml文件中的字符串，浮點數較低。
Run on (16 X 2300 MHz CPU s)
CPU Caches:
L1 Data 32 KiB (x8)
L1 Instruction 32 KiB (x8)
L2 Unified 256 KiB (x8)
L3 Unified 16384 KiB (x1)
Load Average: 2.46, 2.25, 2.19
---------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
---------------------------------------------------------------------------
BM_WriteStrings 2484 ms 2482 ms 1 items=8.38861M items_per_second=3.37956M/s
BM_WriteIntegers 1949 ms 1949 ms 1 items=8.38861M items_per_second=4.30485M/s
BM_WriteFloats 4720 ms 4719 ms 1 items=8.38861M items_per_second=1.77767M/s
BM_WriteBools 2167 ms 2166 ms 1 items=8.38861M items_per_second=3.87247M/s
BM_ReadStrings 1883 ms 1882 ms 1 items=8.38861M items_per_second=4.45776M/s
BM_ReadIntegers 1641 ms 1641 ms 1 items=8.38861M items_per_second=5.11252M/s
BM_ReadFloats 4173 ms 4172 ms 1 items=8.38861M items_per_second=2.01078M/s
BM_ReadBools 1898 ms 1898 ms 1 items=8.38861M items_per_second=4.4205M/s
.xlsx文件本質上是.zip存檔中的一堆.xml文件。在內部，OpenXLSX使用xiniz庫來壓縮/解壓縮.zip檔案，事實證明，Miniz對其可以處理的文件大小具有上限。
存檔中文件的最大允許文件大小（即.zip存檔中的條目，而不是存檔本身）為4 GB（未壓縮）。通常，.xlsx文件/存檔中的最大文件將是持有工作表數據的.xml文件。即，工作表數據可能不超過4 GB。這在行和列方面轉化為很大程度上取決於數據的類型，但是1,048,576行x 128列填充有4位整數的列將佔用約。 4GB。壓縮檔案的大小也取決於工作表中的數據以及所使用的壓縮算法，但是單個工作表的工作簿通常為4 GB，通常的壓縮尺寸為300-350 MB。
4 GB限制僅與存檔中的單個條目有關，而不是總存檔大小。這意味著，如果檔案存放多個條目的大小為4GB，則縮影仍然可以處理。對於OpenXLSX，這意味著仍然可以打開一個大型工作表的工作簿。
OpenXLSX使用Pugixml庫來解析和操縱.xlsx Archive中的.xml文件。 Pugixml是一個DOM解析器，它將整個.xml文檔讀取到內存中。這使得解析和操縱非常快。
但是，所有選擇都有後果，並且使用DOM解析器也需要大量內存。對於小電子表格，這應該不是問題，但是如果您需要操縱大型電子表格，則可能需要很多內存。
下表顯示了OpenXLSX可以處理多少列數據（假設1,048,576行）：
| 列 | |
|---|---|
| 8 GB RAM | 8-16 |
| 16 GB RAM | 32-64 |
| 32 GB RAM | 128-256 |
您的里程可能會有所不同。 OpenXLSX的性能將取決於電子表格中數據類型。
還請注意，建議在64位模式下使用OpenXLSX。儘管它可以在32位模式下輕鬆使用，但它只能訪問4 GB的RAM，這將在處理大型電子表格時嚴重限制有用性。
如果內存消耗是您的問題，則可以在緊湊的模式下構建OpenXLSX庫（在cmakelists.txt文件中查找enable_compact_mode），這將啟用Pugixml的緊湊模式。然後，OpenXLSX將使用較少的內存，但運行速度也較慢。在此處查看Pugixml文檔中的更多詳細信息。帶有8 GB RAM的Linux VM上運行的測試用例顯示，OpenXLSX可以處理以緊湊模式的1,048,576行x 32列的工作表，而1,048,576行x 16列以默認模式為單位。
到目前為止，我對GitHub上的OpenXLSX遇到的最多問題與Unicode有關。顯然（可以理解的是）對許多人來說是一個極大的混亂來源。
早期，我決定OpenXLSX應該專注於Excel部分，而不是編碼/轉換實用程序的文本。因此，所有對OpenXLSX的文本輸入/輸出都必須在UTF-8編碼中……否則它將無法正常工作。也可能有必要以UTF-8格式保存源代碼文件。例如，如果將源文件保存在UTF-16格式中，則任何字符串文字也將在UTF-16中。因此，如果您的源代碼中有任何硬編碼的字符串文字，則源文件也必須以UTF-8格式保存。
OpenXLSX中的所有字符串操作和用法都使用C ++ STD :: String，它是編碼不可知論的，但可以輕鬆地用於UTF-8編碼。另外，Excel在內部使用UTF-8編碼（實際上，可以使用其他編碼，但我不確定這一點）。
由於上述原因，如果您使用其他文本編碼，則必須自己轉換為UTF-8 。有許多選項（例如boost.nowide或boost.text）。在內部，OpenXLSX使用boost.nowide;它具有許多方便的功能，用於打開文件並在STD :: String和STD :: Wstring等之間進行轉換。我還建議您在CPPCON 2014上觀看James McNellis的演講，並閱讀Joel Spolsky的博客。
Windows上的Unicode特別具有挑戰性。雖然UTF-8在Linux和MacOS上得到了很好的支持，但Windows上的支持更加有限。例如，向終端窗口的非ASCII字符（例如中文或日本字符）的輸出看起來像Gibberish。如前所述，有時您還必須注意源文件本身的文本編碼。一些用戶在打開/創建具有非ASCII文件名的openxlsx崩潰的問題上遇到了問題，事實證明，測試程序的源代碼是在非UTF-8編碼中，因此，OpenXLSX的輸入字符串也是非UTF-8。要保持理智，我建議源代碼文件始終在UTF-8文件中；我知道的所有IDE都可以處理UTF-8編碼中的源代碼文件。歡迎來到Windows上的Unicode的美好世界？
Excel文件本質上只是包裹在.zip存檔中的一堆.xml文件。 OpenXLSX使用第三方庫來從.zip存檔中提取.xml文件。 OpenXLSX使用的默認庫是Zippy，它是一個面向對象的包裝器，圍繞Miniz。最小庫很快，僅標題，這是OpenXLSX的理想選擇。
但是，如果您願意，可以使用不同的Zip-library。在極少數情況下，您可能會遇到Miniz的穩定性問題。在這種情況下，嘗試不同的Zip-ubrary可能很有用。
使用Zippy/siniz庫不需要特殊的努力；它將直接起來。但是，使用不同的拉式圖書館將需要一些工作。
為了使用不同的Zip-library，您必須創建一個符合Iziparchive類指定的接口的包裝類類。請注意，這是使用類型擦除實現的，這意味著不需要繼承；這堂課只需要具有一個合格的界面，這就是全部。之後，提供類的對象並將其提供給OpenXLSX構造函數。
要查看如何完成此操作的示例，請查看示例文件夾中的demo1a。此示例使用一個名為CustomZip的類（使用libzip作為ZIP庫），可以在示例/外部/customzip下找到。為了構建示例程序，請確保在您的計算機上安裝了libzip（及其依賴項），並在openxlsx root中的cmakelists.txt文件中啟用OpenXLSX_ENABLE_LIBZIP選項。
如前所述，Demo1a示例程序使用libzip。 Libzip是一個非常穩定的庫，廣泛使用。但是，我的經驗是，大型ZIP文件（例如大型電子表格）非常慢。因此，libzip可能不是理想的解決方案，但對於顯示如何使用不同的郵政庫很有用。
在“示例”文件夾中，您會找到幾個示例程序，這些程序說明瞭如何使用OpenXLSX。研究這些示例程序是學習如何使用OpenXLSX的最佳方法。示例程序是註釋的，因此應該相對容易理解發生了什麼。
OpenXLSX現在可以使用默認的zippy/miniz庫以外的其他ZIP庫。請參見Demo1a作為如何完成的示例
此版本包括行範圍和迭代器。它還支持將單元格值的容器分配給Xlrow對象。這比使用細胞範圍或通過細胞參考訪問細胞的速度要快得多（高達x2）。
自從上一個版本以來，OpenXLSX的內部體系結構已得到顯著重新設計。原因是圖書館變成了一個大泥球，越來越難以添加功能並修復錯誤。借助新的體系結構，它將（希望）更容易管理和添加新功能。
由於架構的重新設計，公共接口有一些更改。但是，這些更改並不重要，應該很容易更新：
我意識到這些變化可能會給某些用戶帶來問題。因此，可以在此存儲庫的“遺產”分支中找到以前的OpenXLSX版本。但是，我強烈建議您過渡到新版本。
看來，MS Office在<mergeCells> XML節點之前不忍受任何格式化的XML節點 - 為了擺脫依次錯誤消息，最新的提交將修改XLSheet::merges函數以插入新創建的<mergeCells> node> node> node> node> node> node> node> node> node <sheetData> node。
當該單元格的任何樣式索引有效以通過索引訪問該樣式的任何樣式索引時，這些缺失的默認值可能會導致後續錯誤（如果索引不在有效範圍內）。現在以單元格式可用的所有樣式索引均已為零（沒有假設，索引0的樣式可能會被配置為通常是默認值 - 如果您想確定，請提供一個已知格式的單元格，該格式從模板到Xlcellformats to xlcellformats :: create）。
XLDocument.hpp ：添加showWarnings() （默認設置）和suppressWarnings()XLStyles.hpp ：添加了suppressWarnings參數到構造函數（默認： false ）XLDocument::open ：如果調用了suppressWarnings() ，請抑制有關忽略的評論XML文件和未手冊的項目的警告XLDocument::open ：將m_suppressWarnings設置轉發到Xlstyles constructorXLException.hpp ：添加了缺少#include <string>XLDocument::open將在_rels/.rels中創建缺少的工作簿關係，並且只有在存檔中存在默認路徑xl/workbook.xml的工作簿XLDocument::create create and XLDocument::saveAs函數接口，但將它們標記為[[deprecated]] 。新接口需要明確的XLForceOverwrite或XLDoNotOverwrite的規範。一旦刪除了不推薦的函數定義， XLDoNotOverwrite就可以成為新的默認行為OpenXLSX/external/nowide/nowideDemo0 /將其作為測試工具保存在Makefile中Notes夾xml-format.sh創建Scripts文件夾（XML linting，可用於分析文本編輯器中的XLSX zip內容）make-gnu.sh移至Scripts/make-gnu.shScripts/cmake-cleanup.sh以準備（而不是執行！）命令，以刪除CMAKE生成的所有臨時文件Scripts/demos-cleanup.sh以刪除演示創建的所有XLSX文件class XLXmlSavingDeclaration （XLXMLSAVINGDECLARATION（在XLXmlData.hpp中定義），可以使用可用於傳遞自定義XML版本的void setSavingDeclaration(XLXmlSavingDeclaration const& savingDeclaration)Notes/todo-list.txtXLWorksheet現在允許訪問管理工作表合併單元格範圍的對象
XLMergeCells XLWorksheet::merges() - 直接訪問工作表的XLMergeCells類void mergeCells(XLCellRange const& rangeToMerge, bool emptyHiddenCells = false) - rangetomerge定義的合併單元格void mergeCells(const std::string& rangeReference, bool emptyHiddenCells = false) - 由rangeReference定義的合併單元格void unmergeCells(XLCellRange const& rangeToUnmerge) - 拆卸細胞由rangetounmerge定義void unmergeCells(const std::string& rangeReference) - 解開rangeReference定義的單元格XLMergeCells ：添加的方法
int32_t XLMergeCells::findMerge(const std::string& reference) - 查找合併匹配參考bool mergeExists(const std::string& reference) - 測試是否存在與參考的合併int32_t XLMergeCells::findMergeByCell(const std::string& cellRef) - 查找包含std :: String cellRef的合併int32_t XLMergeCells::findMergeByCell(XLCellReference cellRef) - 查找包含xlcellReference cellref的合併size_t count() - 獲取工作表中定義的合併計數const char* merge(int32_t index) - 在索引處獲取合併參考字符串const char* operator[](int32_t index) - 運算符的過載[]作為:: Merge的快捷方式int32_t appendMerge(const std::string& reference) - 定義一個新合併，由xlworksheet調用:: mergecellsvoid deleteMerge(int32_t index) - 從工作表中刪除與給定索引的合併（= unmerge單元格），由xlworksheet :: umergeCells調用添加了此功能的示例用法中的Demo10.cpp
XLDocument::open現在將忽略未知的子文件夾（它們在記憶中的郵政編碼中仍然無法修改且無法訪問，並保存後將其留在存檔中）。這樣可以防止對“創意”應用程序編寫的任何XLSX文件的例外，該文件添加了該庫未知的項目const unsigned int pugi_parse_settings製作了一個constexpr ，並將其移至XLDocument.hpp ，以便const可用於xlstyles和xlsharedstringsXLStyles類中實現對工作表樣式的支持 - 界面可以在OpenXLSX/headers/XLStyles.hpp中找到Examples/Demo10.cpp演示了新的Xlstyles＆cell合併功能的使用XLCellIterator ：現在可以在範圍內迭代並在訪問它之前測試XLCellIterator::cellExists 。這允許跳過不存在的單元，而無需創建它們。workbook##.xml ，XML名稱空間和隨機64位（關係）標識符_rels/.rels中正確引用了一個非標準（==不是xl/workbook.xml ）XML名稱，則可以接受XML名稱。bool OpenXLSX::enable_xml_namespaces() <x:row r="1"> x ENABL<y:sheetData>節點中的insert_child_before("x:row", curRow )將剝離x:並插入一個名為<y:row>的行元素，使用父節點的命名空間OpenXLSX/headers/XLXmlParser.hpp ）作為可選的最後一個參數，即bool force_ns （如果為true）將尊重傳遞到node creation/access的函數中的名稱空間。助手const bool OpenXLSX::XLForceNamespace = true可用於代碼可讀性XMLNode::insert_child_before("x:row", curRow, XLForceNamespace)在<y:sheetData>上面的節點中，將插入一個名為x:row行元素id="rId##"其中##是序列編號，並且當將新組件添加到工作簿中時，通過在工作簿中取出最高現有值來確定新的關係ID，並將+1添加+1。在研究[＃254]的過程中，發現一個工作簿使用（看似）隨機64位整數，以r:id="Rxx"形式存儲， xx是64位整數的十六進製表示。OpenXLSX::UseRandomIDs()必須在打開此類文檔之前調用以切換ID功能OpenXLSX::UseSequentialIDs()可用於還原默認（順序）關係ID功能在enable_xml_namespaces上注意：名稱空間支持是透明的，可以與不使用此類名稱空間的文檔一起使用。但是，它可能會對大型工作簿產生很小的（<5％）的影響，因此可以選擇。
謹慎UseRandomIDs和態數：請注意，暫時不支持一個隨機ID支持的混合模式，其中一個文檔被隨機ID支持打開，而沒有順序關係ID的另一個文檔則不受支持。如果您必須使用不同類型的文檔，則應始終為下一個文檔配置所需的關係ID行為，使用該行為，將其關閉並在打開下一個文檔之前更改關係ID配置。
請忽略示例/demo0.cpp和示例/demo9.cpp（demo0是微不足道的，用於測試非標準的工作簿支持，並且demo9需要對更好的評論進行審查）。 Demo9展示瞭如何使用可複制分配單元格內容的新XlcellAssign（例如Excel Copy＆Paste）。
XLCellIterator不再僅創建空單元僅用於迭代它們，並提供::cellExists()來測試當前指向的單元格之前是否已經在工作表XML中XLStyles支持XLWorksheet現在提供XLMergeCells支持，以合併 /取消牢房範圍Demo10.cpp有很多有關如何使用新XLStyles功能的示例customXml等XLProperties.cpp XLAppProperties中重構，以創建<TitlesOfParts>和<HeadingPairs> nodes（和subnodes）如果缺失，則添加的方法alignWorksheets vly XLDocument::open ，以確保在工作本中列出的所有工作表XML列出的所有工作表XML都在docProps/app.xml中列出。XLProperties.cpp prettyInsertXmlNodeBefore中刪除混亂，也許這最終可以成為全球函數，並與TBW功能prettyInsertXmlNodeAfter配對，並且可以用所有類別用來清理所有範圍，從而為Whitepace Suppose nitepace Supposecose nater sublemine。pairCount pairCountValue一些令人<HeadingPairs> pairValue變量pairValueParent XLProperties.cpp代碼在XLDocument :: Open中重新分配以讀取共享字符串表，同時始終忽略語音標籤，而語音標籤以前僅在<si>標籤的第一個孩子是語音標籤時才被忽略。現在將在文本<t>和Rich Text <r>之間忽略任何地方，之後或之間。
包括XLRelationships.cpp GetTypeFromString中的“啞巴”後備解決方案，以支持以前未知的關係域，例如type="http://purl.oclc.org/ooxml/officeDocument/relationships/worksheet" 。改變的行為最初將針對硬編碼的關係域進行測試，如果該測試未能識別關係類型字符串，則將搜索類型字符串/relationships/的發生，如果找到了該子字符串，則類型檢測後備將嘗試根據/relationships/忽略域，試圖根據subsstring評估關係類型。在上面的示例中，這將導致typeString.substr( comparePos ) == "/relationships/worksheet"的測試，其中comparepos == 41（基因/relationships/開始的位置）。
預計未來對類似“愚蠢”的後備解決方案的潛在需求，還用弦樂常數替換了XLContentTypes.cpp GetTypeFromString 。
更新到更通用的版本，該版本不包括所有內容並明確重新包含所有所需的文件。
BinaryAsHexString ：用std :: string替換char陣列，因為ISO C ++標準不允許可變大小數組Rand64 ：添加了顯式類型的鑄件，因為位偏斜左左右不會在左操作數上延長整數促銷-Wpedantic -Wextra ，並在以下修補程序之後刪除了所有先前禁用的標誌f( param ) - > f(param) ， a[ index ] - > a[index]和if( condition ) if (condition) ）warning: enumerated and non-enumerated type in conditional expression [-Wextra]void ZipArchive::Save(std::ostream& stream)void ZipArchive::ExtractDir(const std::string& dir, const std::string& dest)void ZipArchive::ExtractAll(const std::string& dest)-Wunused-function for functions fileExists和isDirectoryuint32_t （ uint64_t ）。注意：基礎XML沒有有效性檢查（如果一個值與OpenXLSX :: max_rows不一致的情況，也沒有一個-Wsign-comparebool endReached()的返回值的const-降低以消除-Wignored-qualifiers （被忽略，因為在瑣碎的返回類型上的const無法完成任何工作）OpenXLSX::ignore模板，可用於抑制-Wunused-parameter和-Wunused-variable ： OpenXLSX::ignore(unusedValue)-Wunused-parameter#pragma warning線包裹在另一個巴格馬中，以禁用-Wunknown-pragmas （在GCC/G ++上）#pragma GCC diagnostic push#pragma GCC diagnostic ignored "-Wunknown-pragmas" // disable warning about below #pragma warning being unknown# pragma /* offending lines go here */#pragma GCC diagnostic popzippy.hppIZipArchive.hppXLCell.hppXLCellIterator.hppXLCellRange.hppXLCellReference.hppXLCellValue.hppXLColor.hppXLColumn.hppXLCommandQuery.hppXLContentTypes.hppXLDateTime.hppXLDocument.hppXLException.hppXLFormula.hppXLMergeCells.hppXLProperties.hppXLRelationships.hppXLRowData.hppXLRow.hppXLSharedStrings.hppXLSheet.hppXLStyles.hppXLWorkbook.hppXLXmlData.hppXLXmlFile.hppXLZipArchive.hppExamples/Demo5.cpp<Properties> （文檔）元素，以前被錯誤地插入了headingpairs/xl/worksheets/sheet* /xl/sharedStrings.xml /theme/theme/theme/theme/theme/theme/theme/theme /xl/styles.xml /xl/theme/theme* ），否則被忽略了。當工作簿包含/xl/pivotCache/和/xl/pivotTables/條目之前，這將解決一個問題（如果<cols>元素檢索給定列索引的列樣式std::vector< XLStyleIndex > m_columnStyles和一個方法fetchcolumnstyles，它將填充向量，以便可以將其傳遞給xlcelliterator constructorXLCellIterator::cellExists()而無需為單元格創建XML。<font><scheme val="major"/></font> ）<font><vertAlign val="subscript"/></font> ）<fills><fill><gradientFill>...</gradientFill></fill>...</fills>請參閱Demo10和Xlstyles.hpp有關如何設置單元格格式的。簡而言之：
