Calamine: Excel file reader, written in Rust
github.com
github.com
Here's a little Excel-file writer in PHP; Excel will read these files, but this library won't:
<?php echo '<?xml version="1.0" encoding="utf-8"?>'; ?>
<?php echo '<?mso-application progid="Excel.Sheet"?>'; ?>
<Workbook xmlns="urn:schemas-microsoft-com:office:spreadsheet"
xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:x="urn:schemas-microsoft-com:office:excel"
xmlns:html="http://www.w3.org/TR/REC-html40">
<Worksheet ss:Name="Sheet1">
<?php $data = array(array(4,5,6),array("dude","whatever","m<om")); ?>
<Table>
<?php foreach($data as $row): ?>
<Row>
<?php foreach($row as $cell): ?>
<Cell>
<Data ss:Type="String"><?= htmlentities($cell) ?></Data>
</Cell>
<?php endforeach; ?>
</Row>
<?php endforeach; ?>
</Table>
</Worksheet>
</Workbook>
[1]: https://en.wikipedia.org/wiki/Microsoft_Office_XML_formats
(edit: well the good part of the xml-files were that they could be streamed. this is / was huge for data processing and exporting a la csv)
"Be flexible in what you accept" seems especially apt here.
application/vnd.ms-excel
Does this work with libreoffice? Do you have a sample on hand that I can test?
It works with libreoffice. It also works with gnumeric.
The output of the program is:
https://www.dropbox.com/s/9joeudijfav3pe7/a.xls?dl=1
(although it was short enough to fit in a comment, so you might just have tried running it!)
A format that's trivial to generate in a single pass with no special packing and zipping requirements is a godsend. It supports Word documents too!
(While it is true that users will toss anything at you, it's quite pointless to expect one library to handle all of it: we used one to sniff the content, another to parse CSVs, yet another to parse XLSX, and in-house code for this obscure abomination which sadly still gets about 10% of use)
Libraries don't just come with implementation, but also a use model. Perl, for example has:
Spreadsheet::XLSX
Spreadsheet::ParseExcel
These have very different user (programmer) interfaces -- so different that now there's a Spreadsheet::ParseXLSX which just allows programmers (and programs) used to one interface, consume the new files with very little changes.
This rust library has it's own model, and if it's a good model it makes sense to implement other file formats with this model -- and indeed this is a good way to test if it's a good model.
Other things like CSV are so fundamentally different from XLS/XLSX that they're going to have a different model, and so it makes sense that these require different libraries.
Disclaimer: I'm a current ClosedXML contributor.
What followed, even though it was almost 1:1 port, was an inevitable loss of huge part of my life, I'll never get back. However, I learned a lot about what a mess that format is. Since then ANY xml format Microsoft uses is godsent.
The reason was Excel’s lack of an API. The formulas themselves were too complicated for existing solutions, and kept breaking them. I only built what was necessary so it worked out quicker.
No idea if that’s the same as the original use case, but it this kind of library looks like it does the same kind of thing on a more general level.
https://github.com/OfficeDev/Open-Xml-Sdk
They also support being used on .NET Core.
Is the situation different in 2017?
Disclaimer: I'm a current ClosedXML contributor.
e.g. importable data using real spreadsheet files is much more reliable than CSV, and easier for clients to generate.
It can also be more a pita since cells can have different formats.