=?koi8-r?B?y8/N0MnM0cPJ0Q==?=
C++ library for creating XLSX files for MS Excel 2007 and above.
Brought to you by:
oxod,
programmeralex
Добрый день!
После включения дефайнов UNICODE и _UNICODE
появилась ошибка при компиляции:
Ошибка 1 error C3861: strcasecmp: идентификатор не найден D:\Projects\WENGINE\Sources\SimpleXLSX\Zip\zip.cpp 2174 WEngine
Сергей.
Добрый день!
Уточните, пожалуйста, версию компилятора и его разрядность, а также среду разработки.
среда: MSVS 2010
компилятор - тот который в этой студии.
проект нас с++ на win32 API
после подключения SimpleXlsxWriter - всё работало, но созданные файлы Excel'ем не открывались, т.к. данные в sharedStrings.xml были не unicode.
включил дефайны UNICODE и _UNICODE - перестала компилироваться библиотека SimpleXlsxWriter. Список ошибок прилагаю
Свой проект перевести на юникод - не можем, может только конвертить строки в юникод (что и делали в пред.версии)
Использовали одну из ранних версий, но созданные ею файлы перестали открываться в новых версиях excel.
Last edit: Sergey 2018-03-27
Спасибо за развёрнутую информацию, надеюсь, что правильно всё понял.
Небольшое замечание: макросы UNICODE и _UNICODE нужно использовать для всего проекта, а не в конкретном cpp файле.
Это убрало бы ошибки вида "инициализация: невозможно преобразовать "const wchart [5]" в "tstring"".
Но, поскольку целиком проект на Юникод не перевести, то это не поможет.
Правильно я понял, что ранее вы конвертировали строки с сиволами Юникода в представление UTF-8 и передавали их в библиотеку?
В принципе, этот подход должен работать и сейчас, правда с одним нюансом.
Дело в том, что в Excel есть ограничение на длину названия листа - 31 символ.
И библиотека это проверяет, обрезая строку названия листа.
Как правило, такая обрезка названия "ломает" переданный UTF-8 и, соотвественно, XML-файл, в который она записывается.
Поэтому рекомендую попробовать ограничить названия листов таким образом, чтобы их представление в UTF-8 было короче 31 символа.
Также необходимо проверять, что в названии листа отсутствуют символы "/[]*:?" (начиная с версии 0.24 библиотека проверяет самостоятельно).
Если проблема сохранится, то приложите сгенерированный нерабочий xlsx-файл для анализа.
И, желательно, минимальный проект на MSVS с проявляющейся проблемой.
Пришлось переписать некоторые моменты.
правда в результате всё равно Excel ругается при открытии файла.
прикрепляю модифицированный движок и сгененерированный файл.
К сожалению, сегодня не было достаточно времени для полной проверки присланного xlsx-файла. Но кое-что удалось найти. В файле Workbook.cpp в функции SaveWorkbook есть код вида (7 штук):
Похоже, что ваша версия MSVS не понимает спецификатор "zu" и выводит его как текст...
Попробуйте заменить все 7 мест кодом вида (замена спецификатора и явное преобразование типа):
Если это не исправит до конца проблему, то, пожалуйста, пришлите новый xlsx-файл, созданный после этих изменений.
Добрый день, Александр!
Замена спецификаторов помогла. Файлы генерируются корректно.
Спасибо.
Была бы интересна UNICODE версия (или какой-то свой) библиотеки, без включения дефайнов UNICODE.
Тем более, что данные в Excel надо подавать только в юникоде.
Добрый день, Сергей!
Пожалуйста! Был рад помочь :-)
У меня есть намерение отказаться от макросов _UNICODE и UNICODE, но для этого нужно хорошенько переработать zip.cpp. Надеюсь, что найду для этого время.
Во вложении обновлённая версия библиотеки с изменённым спецификатором и доступным методом CWorksheet::AddCell для std::wstring без использования макросов, что должно избавить от самостоятельного конвертирования в UTF-8.
Если вас не затруднит, проверьте обновлённую версию.
"хорошенько переработать zip.cpp" - may be zlib? https://zlib.net/ Standard library...
In general, you're right, zlib - it is the right way, I've already thought about it.
The only thing I do not like this option - external dependence on zlib.
At this moment SimpleXlsxWriter is completely independent. It is enough to append its source code to the project and you can create your xlsx-files. This helps to novice/inexperienced programmers to easily begin to solve their main tasks.
Maybe I'm not setting the right priorities. Perhaps it is necessary to make transition to zlib in the second iteration.
In any case, quite a lot of changes are required to rid the library from _UNICODE, _T (), _tstring and _tstringstream.
Apropos, concernign UTF: there is not bad, also +/- standard lib: http://utfcpp.sourceforge.net/
Thanks for the information, I think I did not know about this library.
The library already contains the class UTF8Encoder. So far, no one has reported an incorrect conversion of Unicode strings.
I tried to get rid of _UNICODE, _T(), _tstring and _tstringstream. It seems I succeeded. The attachment contains an updated library for testing.
However, I had to add a new UniString class for simultaneous work with std::string and std::wstring. Perhaps there is an easier way, but I have not come up with yet.
I will be glad to hear comments and suggestions.