Consideramos o processamento de documentos garantido em uma escala individual: clique duas vezes no arquivo (ou use uma frase de linha de comando simples) e o conteúdo do arquivo será exibido. Mas fica mais complicado em escala. Imagine que você é um recrutador pesquisando currículos por palavras-chave ou um paralegal procurando nomes em milhares de páginas de documentos de descoberta. Os formatos, versões e plataformas que os geraram podem ser totalmente diferentes. O desafio é ainda maior quando é urgente, por exemplo, se você tiver que digitalizar todos os e-mails de saída para vazamentos de informações de identificação pessoal (PII), ou dar aos pacientes um único arquivo que contenha todos os seus acordos de divulgação, documentos digitalizados e Relatórios de ressonância magnética / raios-X / teste, independentemente do formato do arquivo original. 

Na Hyland, produzimos um kit de ferramentas de processamento de documentos que fornecedores de software independentes podem implementar para identificar arquivos, extrair texto, renderizar conteúdo de arquivo, converter formatos e fazer anotações em documentos em mais de 550 formatos. Estes são Filtros de Documentos, e qualquer software que interaja com documentos precisará de Filtros de Documentos.

Uma biblioteca para 550 formatos pode parecer um exagero, mas imagine juntar dezenas de bibliotecas de código aberto, testando cada uma dessas bibliotecas cada vez que um novo lançamento chega ao mercado. Oferecemos uma dependência, um ponto de contato se algo der errado e uma biblioteca para implantar em vez de dezenas. 

Começamos como uma empresa que vendia um software de pesquisa de desktop chamado ISYS. O aplicativo foi desenvolvido em Pascal para MS-DOS e fornecia pesquisa em nível de mainframe em PCs. Eventualmente, outras empresas, como Microsoft e Google, começaram a fornecer aplicativos de pesquisa de desktop de graça, e é difícil competir com o grátis. 

Isso nos levou a perceber que a soma das partes era maior do que o todo; retirar texto de arquivos e entregar a localização exata é mais difícil do que parece e relevante para outros aplicativos que não a pesquisa. Nossos clientes perceberam nossa força na extração de texto e queriam isso como algo que pudessem integrar ou incorporar em seu software e em várias plataformas.

Identificando que Pascal não atenderia às nossas necessidades, orientamos nossos engenheiros para reconstruir o aplicativo em C ++ no próximo ano para cerca de meia dúzia de plataformas de computação. Desde então, aprendemos muito sobre processamento de conteúdo em escala e como fazê-lo funcionar em qualquer plataforma.

Em qualquer plataforma

Quando reescrevemos nosso software, um dos principais fatores foi o suporte à plataforma. Na época, Pascal suportava apenas Windows e, embora agora suporte Mac e Linux, era e ainda é uma linguagem de nicho. Isso não funcionaria para nós, pois queríamos oferecer suporte a grandes servidores de processamento de back-end, como Solaris e HP-UX. Pensamos em escrevê-lo em C, mas teríamos que inventar muito do clichê que o C ++ nos deu gratuitamente.  

Conseguimos portar cerca de 80% do código do Pascal. Os outros 20% eram abstrações de novos sistemas operacionais, principalmente para suportar as funções da API do Windows que perdemos em outras plataformas e as várias peculiaridades de cada plataforma. Cada compilador faz suposições diferentes sobre como implementar o código C ++, portanto, usamos vários compiladores para ver quais são essas suposições. 

Para complicar as coisas, não tínhamos que considerar apenas os sistemas operacionais, mas também as CPUs. CPUs diferentes processam bytes em ordens diferentes, chamadas de endianness de byte. Todos os chips Intel e ARM usam little-endian, onde o byte menos significativo é armazenado primeiro. Os chips SPARC usados ​​historicamente em máquinas Solaris usavam armazenamento big-endian, onde o byte mais significativo era armazenado primeiro. Ao ler um arquivo, você precisa saber qual chipset o produziu, caso contrário, você pode ler as coisas ao contrário. Nós nos certificamos de abstrair isso para que ninguém precise descobrir o chipset de origem antes de processar um arquivo. 

Em última análise, o objetivo é que o software seja executado exatamente da mesma forma em todas as 27 plataformas. Parte da solução para esse problema é escrever tudo o mais genericamente possível, sem código especial para cada plataforma. A outra solução é o teste. Com a conversão para C ++, escrevemos muitos novos testes para exercitar o máximo de código em todas as plataformas. Hoje, expandimos esses testes e tornamos a detecção de erros muito mais rígida. Muitos arquivos e formatos passam durante os testes e precisam ser limpos.

Pesquise e extraia texto em escala

O primeiro passo para localizar ou extrair texto de um arquivo é descobrir em que formato o arquivo está. Se você tiver sorte de obter um arquivo de texto simples, então é fácil. Infelizmente, as coisas raramente são fáceis. Não existem muitos padrões disponíveis para a forma como os arquivos são estruturados; o que existe pode estar incompleto ou desatualizado. As coisas mudaram muito ao longo dos anos; A Microsoft está realmente na vanguarda dos padrões de publicação. Atualmente, eles publicam padrões para a maioria dos tipos de arquivo, principalmente os mais novos. 

Muitos tipos de arquivo podem ser identificados por um conjunto inicial de quatro bytes. Depois de fazer isso, você pode analisar o arquivo rapidamente. Todos os arquivos mais antigos do MS Office tinham os mesmos quatro bytes, o que apresentava complicações, especialmente porque tantos arquivos estavam em um dos quatro formatos do Office. Você teve que fazer um pouco mais de trabalho de detetive. Todos os arquivos do Office mais recentes são identificados como arquivos ZIP - são todos XML compactados - então, depois de extrair o XML, você começa a aplicar heurísticas conhecidas e os seguintes marcadores. A maior parte do XML é autodescritiva, portanto, esses marcadores podem ser fáceis de seguir. Outros não têm muito caminho.

Os tipos de arquivos binários são mais difíceis. Parte do trabalho aqui é engenharia reversa e garantir que você tenha arquivos suficientes que sejam um conjunto de amostra representativo. Mas, uma vez que você conhece o padrão, detectar o arquivo é absolutamente previsível. Por causa disso, não usamos nenhuma técnica de aprendizado de máquina ou IA para identificar arquivos. O desafio é descobrir qual é o padrão e em que padrão um determinado arquivo se encaixa. 

Identificar arquivos é a primeira coisa que fazemos, por isso tem que ser rápido. Uma detecção lenta pode afetar tudo e nos levar de submilissegundos por documento a 15 milissegundos por documento. Quando você está tentando processar quarenta mil documentos em um minuto, é muito.

Ganhamos muita velocidade com a especialização em pesquisa e extração de texto como um sistema de back-end puro. Métodos alternativos têm usado algo como o LibreOffice para processar documentos como um processador de texto sem comando. Os aplicativos do usuário final têm elementos gráficos e outros recursos com os quais você não se importa. Em um ambiente de alto tráfego, isso pode significar 50 cópias do LibreOffice sendo executadas como processos separados em várias máquinas, cada uma consumindo centenas de MB. Se isso falhar, poderá prejudicar processos vitais de negócios com ele. Não é incomum ver farms de servidores executando o LibreOffice para conversões que podem ser substituídas por um único processo de back-end, como Filtros de Documentos. Isso antes de considerar outras soluções alternativas para processar todos os outros tipos de arquivo de que você pode precisar, como planilhas, imagens e PDFs. 

Ao focar no processamento de texto em alto volume, podemos ajudar os clientes que precisam processar e-mails, recebidos e enviados, em busca de perda de dados e vazamentos acidentais de PII. Esses produtos precisam fazer a varredura de tudo que entra ou sai. Chamamos isso de inspeção profunda. Separamos todos os níveis de um e-mail que pudesse conter texto. Compactar algo e renomear a extensão não é suficiente para tentar enganá-lo. Anexar um PDF dentro de um documento do Word dentro de um documento do Excel também não é suficiente. Todos esses são arquivos que contêm texto e a segurança precisa verificar tudo sem atrasar o envio. Não tentaremos quebrar um arquivo criptografado, mas podemos sinalizá-lo para revisão humana. Tudo isso é feito tão rapidamente que você não perceberá atrasos na entrega de e-mails importantes.

Podemos processar texto tão rapidamente porque construímos em C ++ e executamos nativamente no hardware; almejar binários nativos também nos dá a maior flexibilidade, onde podemos ser incorporados em aplicativos escritos em uma ampla variedade de idiomas. Além disso, todo o trabalho de identificação de formatos de arquivo compensa. Ao digitalizar um arquivo, carregamos o mínimo possível na memória, apenas o suficiente para identificar o formato. Em seguida, passamos para o processamento, onde ignoramos todas as informações de que não precisamos para localizar o texto - não precisamos carregar formulários do Acrobat e quebrar essas coisas. Além disso, permitimos que você use o máximo de hardware para resolver o problema. Digamos que você esteja executando uma máquina POWER8 com 200 núcleos, você pode executar 400 threads e isso não vai quebrar um suor. Você precisa de muita memória se estiver fazendo essa quantidade de documentos em paralelo.

Faça com que pareça bom

Nossos clientes não se contentavam apenas em pesquisar e extrair texto; eles também queriam exibi-lo em navegadores da web. Por volta de 2009, as pessoas queriam converter documentos em HTML. Ao extrair texto, o software não se preocupa se algo está em negrito ou paginado - nós apenas queremos o texto. 

Felizmente, todo o trabalho que fizemos para entender os tipos de arquivo valeu a pena aqui. Sabíamos como localizar o texto, os marcadores que indicavam cada tipo, mas agora precisávamos entender a estrutura completa do arquivo. De repente, negrito, itálico, tabelas, quebras de página e tabulações versus espaços tornam-se muito mais importantes. Nossa primeira iteração de renderização de HTML, agora chamada de HTML clássico, criou uma versão de fluxo livre não paginada do arquivo com o máximo de formatação que podíamos extrair. Se você já olhou para o HTML gerado pelo MS Word, sabe que é complicado criar um HTML que reflita um documento com precisão. 

Há sete bilhões de pessoas no planeta e todas elas criam um documento do Word de forma diferente. Mesmo dentro do Word ou editores de .docx de código aberto como o OpenOffice, você move um elemento e, de repente, a formatação desaparece. Tivemos que testar todos os comportamentos possíveis nas especificações e, ainda assim, descobrimos alguns bugs por tentativa e erro. 

Tínhamos um bug em que as versões do Windows e do Mac produziam diferentes tons de azul. Era consistente em todos os documentos do Office - todos os documentos do PowerPoint e Excel exibiam os mesmos dois tons de azul. Às vezes, tudo se resume a diferentes padrões do sistema e fontes em diferentes plataformas. Às vezes, a resposta é completamente subjetiva quanto a qual é a definição de azul ou se uma linha envolve antes ou depois de uma palavra. Em casos como esse, você deve escolher um dos casos para propagar; um deles está certo, mas é difícil saber exatamente qual. Não há absolutos. 

As especificações de formato de arquivo, geralmente publicadas pelo fornecedor, nem sempre ajudam aqui também. Vimos uma alteração de propriedade, enquanto a especificação não esclarece como isso afeta a formatação do documento. Então, ao testar um documento de mil páginas, encontramos um bug na página 342, e nossos corações coletivos afundam um pouco. Em casos como esses, sabemos que vai demorar um pouco para descobrir o que está causando isso e, em seguida, provar ao longo de milhões de iterações. 

Apesar de todos os problemas que os documentos do Word nos dão, pelo menos há estrutura; você sabe que uma mesa é uma mesa. PDFs não têm nada disso. Eles são provavelmente os mais difíceis de lidar porque se concentram em como um documento é desenhado em uma tela. Tecnicamente, os caracteres podem ser colocados individualmente em qualquer lugar em uma página, portanto, determinar quebras de coluna, tabelas e outros recursos de formatação requer olhar para sua posição renderizada em uma tela. 

Antes da internet, todos tinham que criar tudo sozinhos. Eles fizeram seus próprios formatos no escuro. Todo mundo escreveu binários de forma diferente. E os PDFs, enquanto estão melhorando, sempre podem revelar um novo bug, não importa o tamanho do corpus de dados de teste que tenhamos.

O software de código aberto e um maior foco nas questões de acessibilidade mudaram muito os formatos. Os PDFs começaram a incluir mais informações de formatação para acomodar leitores de tela. O software de código-fonte aberto precisa entender os formatos de arquivo, portanto, mais informações são publicadas e os produtores de arquivos começaram a tornar seus arquivos mais fáceis de entender. 

A próxima etapa após entender o formato do documento era ser capaz de pegar esses arquivos e produzir uma saída paginada que parecesse quase um pixel perfeito para o aplicativo de origem. Com todas as informações que aprendemos sobre formatos de arquivo, vamos criar o que chamamos de renderizações HD paginadas. A saída paginada significa que a saída é semelhante a se você fosse imprimir o documento. Isso é ler e extrair texto de 550 formatos e criar renderizações HD totalmente formatadas e paginadas para mais de 100 formatos. Combinado com uma marcação completa e API de anotação que pode criar anotações nativas e exportar para um de mais de 20 formatos. 

Falamos muito sobre documentos Word e PDF, porque é o que a maioria das pessoas usa. Mas também podemos ler em formatos de arquivo exóticos, como arquivos de ressonância magnética e tomografia computadorizada. Isso tem uma aplicação significativa em situações médicas em que você pode querer concatená-los com outros formulários médicos e, em seguida, gerar um PDF completo com as anotações do médico. Quer nos enviar vários documentos de diferentes formatos de arquivo? Vá em frente, não estamos limitados a 1: 1 de entrada para saída, vamos ingerir os dados, entendê-los e retorná-los como um único tipo de arquivo de sua escolha.

Não se esqueça de segurança

Conforme mudamos nosso produto de um aplicativo de pesquisa de desktop, tivemos que aumentar nosso foco na segurança. Se um produto para o consumidor travar, isso afetará um único usuário. Mas se um pedaço de software embutido travar, pode levar o resto do programa - possivelmente o servidor inteiro - para baixo com ele. Essas falhas e explorações podem abri-los para mais travessuras. Ao longo dos anos, fomos atingidos por algumas surpresas e nos queimamos.

O que pode ser comum hoje certamente não era no início dos anos 2000. Análise estática, testes de unidade com alta cobertura de código, higienizadores de compilador, varreduras CVE e teste de difusão são essenciais.

Processamos arquivos de origem e qualidade desconhecidas. Esses arquivos podem vir de terceiros que não seguem estritamente as especificações, portanto, podem estar corrompidos ou podem ter sido criados com códigos maliciosos para disparar vulnerabilidades.

A adesão estrita às melhores práticas de codificação e segurança só leva você até aqui. O teste, tanto ativo quanto passivo, é uma tarefa em segundo plano em execução constante que nos ajuda em nossos esforços para detectar e lidar com o inesperado.

Cada versão é verificada com 100K + arquivos para garantir que não haja regressões ou degradações de desempenho. Cada compilação noturna executa mais de 40 mil testes de unidade. O número dos testes de difusão está na casa dos 10s de milhões. E, claro, bibliotecas de terceiros são verificadas em busca de vulnerabilidades todas as noites.

Conclusão

Vivemos e respiramos tipos de arquivo por décadas e vimos as complexidades que envolvem simplesmente localizar e extrair texto. Algumas das maiores empresas de software do mundo utilizam Filtros de Documentos para suas necessidades de processamento de documentos, processando terabytes de informações por hora. Nossa equipe de engenheiros está sempre monitorando novos e variáveis ​​tipos de arquivos para que os consumidores de Filtros de Documentos estejam bem preparados para o futuro.

Se você está iniciando um novo projeto, sente que há espaço para melhorias com suas ferramentas atuais ou não quer se preocupar com as complexidades do processamento de documentos, você sempre pode aprender mais verificando nossos exemplos de código ou solicitando uma avaliação em DocumentFilters.com.