Hardcore

Stéphane Rodriguez publicou um artigo no codeproject sobre o formato dos novos ficheiros de documentos do MS Office 2007. Salvaguarda que o exposto no artigo não tem qualquer suporte por apoio da MS. O artigo tem anexados programas para leitura de contentores ole. De acordo com o que ele alguns dos formatos internos para serem reproduzidos:

need native API calls represented by IStream for streams, and IStorage for containers. As a sidenote, the mandatory reliance on native API calls makes any client code unable to execute in a partial trust environment

.

Porreirinho, não é!

O artigo separa informação sobre os contentores ole e o Binary Interchange File Format abreviadamente BIFF (sendo que passou à versão 12), depois concentra-se na sua especialidade que são os formatos de ficheiros (de excel e outros), e explora o conteúdo dos ficheiros nas suas versões baseadas em xml e nativas e descobre o seguinte:

The example clearly shows that the person who wrote the workbook BIN part serializer knows more than the person who developed the workbook XML part serializer. Unfortunately, the opposite is also true since the XML markup contains namespaces and associated semantics that is for obvious reasons nowhere to be found in the BIN part. Where are we going?

Ou seja um verdadeiro embróglio...

Stephane não está nada contente...E assim há alguns dias gastou algum tempo a ver um cenários de utilização o oo(que me...)xml entre os quais estava um primeiro cenário muito simples de tentar actualizar de modo simples uma célula que tinha tido uma fórmula e passava a ter um valor literal e o que encontrou foi isto:

- If I were a programmer, the question would be : Microsoft gives no library that I can use, at least not a library that I could use no matter the execution environment. Microsoft provides an API which works in a recent .NET run-time, and installs on Windows XP SP2 and Windows Vista. There goes the platform independence.

Passa a um segundo cenário o que é que é gravado quando uma pessoa insere valores númericos no excel e o que sucede no oo(que me...)xml

he spreadsheet does not reflect the proper values, and you can easily see where it goes. Imagine non-Microsoft applications used in healthcare and critical systems relying on the spreadsheet data. Not only the rounding error seems arbitrary (one would have to go back and study the artefacts of IEEE floating-point values, several decades of work), but it changes. There is no way we can possibly take advantage of this, with one notable exception : if we are able to be in an execution environment for which reading those floating-point values does not produce those artefacts, and returns the proper entered values, then we are good. Problem : Microsoft does not document the execution environment. We can fairly assume its Windows, but what else? And if I am using Linux, how do I work with this?

E claro somos todos ingleses ou com língua materna inglesa:

As an aside, the stored value does not use the locale (it always uses the dot as decimal separator), therefore we have to assume this is all US English.

Mas o horror não acaba aqui os marcadores por exemplo para a formatação do texto é no mínimo complexa:

The extensiveness of the ECMA 376 documentation, over 6000 pages, is telling how much legacy Microsoft is willing to bring into the future. Taking an example of such legacy clarifies what it takes to implement even a portion of the documentation. The example is text formatting. Any of the 3 applications, Word, Excel and Powerpoint uses its own text formatting markup. Worse, the shared libraries themselves (VML, DrawingML, MathML, ...) also use separate text formattings, each different. Even worse, if that's possible, Word has many own ways to do text formatting. Excel has many own ways to do text formatting. Powerpoint has many own ways to do text formatting.

Outra situação interessante sucede quando se cifra um documento:

And the password-protection mechanism is undocumented as a whole.

Bom mesmo é ler o artigo até ao fim muito instrutivo. Gory, gory details indeed