Rust Office Document Processing Library | Dweve Bindery
Bindery is a Rust document runtime for Word, Excel, PowerPoint, PDF and iWork. Apache-2.0 terms; the repository publishes in the seventh release round.
Groupes d'algorithmes par type de données
Gouvernance des connaissances fondée sur des documents analysés.
Indexer les documents analysés pour la récupération.
Analyser et adresser par contenu le texte et le code.
Ajoutez Bindery à votre projet. Ouvrez tout document pris en charge avec une seule API.
Un seul analyseur, tous les formats bureautiques
Bindery pour les opérations documentaires
Formats bureautiques et documentaires mixtes
Contenu des fichiers, pas seulement les noms
Interroger et transformer de manière cohérente
Laissez Fabric ouvrir les documents que vous avez déjà
Bindery travaille sous Fabric pour identifier et lire les documents que vous choisissez, afin que Fabric puisse utiliser leur contenu réel sans vous demander de gérer les formats ou les lecteurs.
Donnez à chaque document une voie claire
Commencez avec le mélange de documents que votre équipe gère déjà. Faites-les passer par un seul parcours d'entrée, un modèle structuré et un transfert contrôlé, tout en gardant le travail spécifique au format à la frontière.
Espace de travail où les utilisateurs déposent des documents.
Gouvernance des connaissances sur les documents extraits par Bindery.
Analyser le code, la configuration et les documents en arbres de Merkle.
bindery convert / query / inspect. Composable avec des pipelines shell.
Liaisons Python. Même moteur, API Python idiomatique.
API native pour l'intégration dans les services. Zéro copie lorsque les formats le permettent.
Bindery extrait le contenu structuré des documents. Associez-le aux couches de récupération et de gouvernance pour construire un pipeline de connaissances complet.
Moins de 100 Mo. Rapports annuels et gros PDF.
Moins de 10 Mo. Classeurs volumineux et présentations.
Moins de 100 Ko. La plupart des feuilles de calcul et fichiers Word.
Les budgets d'analyse documentés sont classés par taille : petit sous la milliseconde, moyen sous cinquante, grand sous cinq cents. L'analyse en flux continu maintient la mémoire bornée par la structure, et SIMD accélère le chemin critique. Aucun GPU.
Type SQL sur le modèle de document unifié.
docx, xlsx, pptx, pdf, iWork, ODF, RTF plus chiffré.
Une seule crate, 17 formats, 300+ formules, DocQL, lecture et écriture complètes. Rapide sur CPU standard. La couche documentaire de la pile Dweve.
L'ingestion de connaissances, l'analyse réglementaire, le traitement de documents financiers, la découverte électronique, l'archivage et les outils de documentation de code commencent tous par des formats bureautiques en entrée et des données structurées en sortie. Chaque document s'ouvre avec les mêmes trois lignes de Rust.
docx, xlsx, pptx, pdf, iWork, ODF, RTF plus chiffré
API Rust native pour l'incorporation. Liaisons PyO3 pour les pipelines Python. Une CLI pour l'inspection, la conversion et les requêtes ponctuelles. Le même moteur derrière les trois.
Un modèle de document, toutes les surfaces
Une bibliothèque, 17 formats. OOXML et ODF sont des surfaces de lecture, d'écriture et de requête de première classe. PDF et RTF sont lus intégralement et écrits au mieux. EPUB, LaTeX et Markdown sont des sorties d'écriture. La matrice indique ce que chaque format promet.
SUM, AVG, STDEV, fonctions matricielles.
Le moteur de formules évalue plus de 300 fonctions compatibles Excel. DocQL est un langage de requête de type SQL pour le modèle de document unifié : trouver des références, évaluer des formules, parcourir des tableaux, filtrer des formes.
Bindery remplace le portefeuille par une seule crate Rust : une API, un langage de requête et un rythme de mise à jour pour 17 formats.
Un analyseur par format, une API par format, un cycle de mise à jour par format. La surface de maintenance s'étend plus vite que le produit n'est livré.
L'écrivain émet vers un format pris en charge.
DocQL, requêtes de type SQL sur DocModel.
Renifler les octets, choisir le lecteur, ignorer les mensonges d'extension.
La détection de format choisit le bon lecteur. Les analyseurs normalisent tout en un modèle de document unifié. DocQL interroge ce modèle avec une syntaxe de type SQL. Les écrivains émettent vers OOXML, ODF, LaTeX, EPUB et Markdown.
La plupart des analyseurs lisent. Peu font l'aller-retour.
Impossible de poser une question à travers les formats.
Les fichiers mentent sur leurs extensions. La détection automatique est nécessaire.
Une crate différente par format, une API différente.
La plupart des pipelines Rust et Python cousent ensemble une bibliothèque différente par format, chacune avec sa propre API, ses propres bugs, sa propre fenêtre de maintenance. La couche de colle devient le projet.
La détection de format lit les octets magiques et les indices structurels. L'extension est un indice, pas la vérité.
Sheet1!B4, Sheet1!D12, Sheet3!A1 (3 résultats)
bindery query 'SELECT cells WHERE refs CONTAINS "Sheet2.A1"'
DocQL : trouver chaque cellule référençant Sheet2.A1
feuilles : 3, lignes : 12847, formules : 4193
ouvrir n'importe quel fichier. Format détecté à partir des octets, pas de l'extension
bindery : ouvrir n'importe quel document
Déchiffrement à la frontière de lecture.
La plupart des feuilles de calcul et fichiers Word.
Ajoutez la crate, appelez open et lisez le modèle de document. Les mêmes trois lignes fonctionnent sur Word, Excel, PDF et tous les autres formats pris en charge. La détection commence par la signature du fichier plutôt que de se fier à l'extension.
Écrivez une sortie prise en charge ou transmettez le modèle structuré.
Détectez, lisez, interrogez et transformez dans l'environnement choisi.
Les fichiers entrent par la limite de document que vous gérez.
Bindery peut fonctionner là où les documents arrivent déjà et où le système suivant les attend. La détection, la lecture, l'interrogation et la transformation restent proches du flux de travail, tandis que la remise finale produit un contenu structuré ou un format de sortie pris en charge.
Les documents sensibles s'ouvrent sur votre propre matériel, ils ne sont donc jamais lus ailleurs.
Les fichiers Legacy, Apple et OpenDocument s'ouvrent tous, les anciennes archives restent donc lisibles.
Les fichiers sont identifiés par leur contenu, un fichier mal nommé ne bloque donc plus la file d'attente.
Le même flux de documents prend en charge la réception mixte, la conversion d'archives et l'examen contrôlé. Les fichiers sont détectés et ouverts de manière cohérente, puis exposés comme informations structurées pour la tâche en cours. Le modèle d'exploitation reste familier même lorsque le mélange de documents change.
Les systèmes en aval héritent d'une structure différente pour chaque famille de fichiers.
Un chemin en lecture seule crée une étape supplémentaire lorsqu'une nouvelle sortie est nécessaire.
La même tâche se comporte différemment selon les intégrations de formats distinctes.
Le routage par extension peut sélectionner le mauvais chemin de document.
Petites différences qui se propagent en aval
Une mauvaise extension, un lecteur séparé ou une conversion à sens unique peuvent introduire une autre branche dans les opérations documentaires. Bindery détecte à partir du contenu, expose un modèle interrogeable unique et écrit via des chemins de sortie pris en charge, laissant moins de cas spécifiques au format à tester et à exploiter.
Faites en sorte que les différences de format
Les systèmes en aval reçoivent une structure cohérente.
Les questions s'exécutent sur un modèle de document unique.
Les formats pris en charge s'ouvrent via une interface unique.
Les chemins spécifiques au format deviennent un seul
Les documents Word, les feuilles de calcul, les présentations, les PDF et autres fichiers pris en charge commencent avec des structures internes différentes. Bindery les normalise en un modèle de document unique, afin que les requêtes, les transformations et les intégrations en aval puissent utiliser une structure cohérente.
Le contenu devient un modèle documentaire structuré.
Les signatures de fichier et les indices structurels sélectionnent le lecteur approprié.
Les fichiers bureautiques mixtes entrent par la même frontière documentaire.
Les documents entrent rarement dans les opérations sous une forme nette et uniforme. Bindery identifie les formats pris en charge à partir du contenu des fichiers et les ouvre via une seule interface. Le résultat est un modèle documentaire structuré prêt pour la tâche suivante.
un seul chemin de réception prend le relais
Le lecteur s'exécute dans l'application, sans compte séparé ni service documentaire externe.
Il lit près de vos fichiers, de votre côté.
Il ouvre lettres, feuilles, formulaires et diapositives indifféremment.
La même réponse sur chaque ordinateur, aujourd'hui comme demain.
Vous n'avez pas besoin de comprendre comment cela fonctionne pour ressentir ce que cela fait pour vous. Cela donne la même réponse sur chaque ordinateur, ouvre des documents quel que soit leur créateur et lit en privé de votre côté. Une fois Bindery publié au septième tour, vous pourrez inspecter l'implémentation vous-même.
Cela vient de votre vrai papier, de la même manière à chaque fois.