anydoc کے ذریعے آفس دستاویزات کو Markdown میں تبدیل کریں

anydoc کیا ہے؟

anydoc ایک تیز رفتار Rust لائبریری ہے جو دستاویزات کو صاف ستھرے GitHub-Flavored Markdown میں تبدیل کرتی ہے۔ یہ Word، PowerPoint، Excel، OpenDocument، RTF، EPUB، CSV اور متن پر مبنی PDF فائلوں کو سپورٹ کرتی ہے۔ یہ پروجیکٹ کمانڈ لائن انٹرفیس کے علاوہ Node.js، Python اور براؤزر پر مبنی WebAssembly کے لیے bindings بھی فراہم کرتا ہے۔

یہ لائبریری ان پائپ لائنز کے لیے بنائی گئی ہے جو متعدد دستاویزی فارمیٹس وصول کرتی ہیں، مگر انہیں Markdown کی ایک مستقل نمائندگی درکار ہوتی ہے۔ ہر سپورٹ شدہ آفس فارمیٹ کو ایک مشترکہ دستاویزی ماڈل میں پارس کیا جاتا ہے اور اسی Markdown serializer سے گزارا جاتا ہے۔ اس سے مختلف فارمیٹس میں جدول، escaping، سرخیاں، حاشیے، روابط، فہرستیں اور دیگر ساختیں یکساں رہتی ہیں۔

تبدیلیاں مقامی طور پر، مشین لرننگ ماڈلز یا بیرونی سروسز کے بغیر، چلتی ہیں۔ README کے benchmark کے مطابق فی دستاویز تبدیلی کا درمیانی وقت پانچ ملی سیکنڈ سے کم ہے۔ متن پر مبنی PDFs کو مقامی طور پر pdf-inspector کے ذریعے سنبھالا جاتا ہے۔

anydoc OCR انجام نہیں دیتا۔ صرف تصاویر پر مشتمل یا اسکین شدہ PDFs، جن میں پڑھنے کے قابل متن موجود نہ ہو، unsupported کے طور پر رپورٹ کی جا سکتی ہیں۔ Firecrawl Parse کو پروجیکٹ نے ان workflows کے لیے hosted متبادل کے طور پر ذکر کیا ہے جنہیں OCR بھی درکار ہو۔

اہم خصوصیات

• یکساں Markdown: تمام آفس فارمیٹس مشترکہ دستاویزی ماڈل اور serializer استعمال کرتے ہیں۔
• ساختی آؤٹ پٹ: سپورٹ شدہ ساختوں میں سرخیاں اور anchors، روابط، اندرونی references، فہرستیں، جدولیں، block quotes، حاشیے، اختتامی حواشی، مقرر کے نوٹس، inline code اور code blocks شامل ہیں۔
• فارمیٹنگ کا تحفظ: بولڈ، اٹالک، strikethrough، task lists، nested lists، source numbering، merged table cells اور header rows کی نمائندگی کی جا سکتی ہے۔
• شامل شدہ assets: شامل شدہ تصاویر اور objects Markdown میں alt text کے طور پر ظاہر ہوتے ہیں، جبکہ ان کے خام bytes اور media types دستاویزی ماڈل کے ذریعے دستیاب رہتے ہیں۔
• مواد پر مبنی شناخت: PDF، RTF، OLE اور ZIP پر مبنی دستاویزی فارمیٹس کی شناخت صرف file extensions پر انحصار کرنے کے بجائے ان کے bytes سے کی جاتی ہے۔
• Nonblocking bindings: Node.js تبدیلی کے لیے libuv thread pool استعمال کرتا ہے، جبکہ Python تبدیلی کے دوران Global Interpreter Lock جاری کر دیتا ہے۔
• Typed packages: TypeScript types اور Python stubs شامل ہیں۔
• Agent integration: اس پروجیکٹ میں ایک Agent Skill شامل ہے جو compatible coding agents کو anydoc CLI استعمال کرنا سکھاتا ہے۔

سپورٹ شدہ فائل فارمیٹس

• Word: .doc، .docx اور .docm
• PowerPoint: .ppt، .pps، .pot، .pptx، .pptm، .ppsx اور .ppsm
• Excel: .xls، .xlsx، .xlsm اور .xlsb
• OpenDocument: .odt، .ods اور .odp
• دیگر فارمیٹس: .rtf، .epub، .csv اور .pdf

انسٹالیشن کا طریقہ منتخب کریں

Shell scripts اور کبھی کبھار کی جانے والی تبدیلیوں کے لیے CLI استعمال کریں۔ جب دستاویز کی تبدیلی کسی application کا حصہ ہو تو Node.js یا Python، native integration کے لیے Rust، یا فائلوں کو براہ راست browser میں تبدیل کرنے کے لیے WebAssembly منتخب کریں۔

CLI انسٹال کریں

آپ npx استعمال کر کے prebuilt CLI کو مستقل انسٹالیشن کے بغیر چلا سکتے ہیں:

npx @firecrawl/anydoc report.docx

آپ کے platform کے لیے prebuilt binary پہلی مرتبہ چلنے پر ڈاؤن لوڈ ہو جاتی ہے۔ anydoc کو مستقل command کے طور پر دستیاب کرنے کے لیے اسے globally انسٹال کریں:

npm install -g @firecrawl/anydoc
anydoc --help

Node.js کے لیے انسٹال کریں

npm install @firecrawl/anydoc

Python کے لیے انسٹال کریں

pip install firecrawl-anydoc

Browser WebAssembly کے لیے انسٹال کریں

npm install @firecrawl/anydoc-wasm

آپ browser demo بھی آزما سکتے ہیں۔ یہ demo WebAssembly library کو مقامی طور پر چلاتا ہے، اس لیے منتخب فائلیں machine سے باہر نہیں جاتیں۔

Rust کے لیے انسٹال کریں

cargo add anydoc

Agent Skill انسٹال کریں

کسی compatible agent کو anydoc CLI کے ذریعے دستاویزات تبدیل کرنا سکھانے کے لیے شامل شدہ skill انسٹال کریں:

npx skills add firecrawl/anydoc

README میں Claude Code، Codex، Cursor اور OpenCode کو compatible clients میں شمار کیا گیا ہے۔

CLI کے ذریعے فائلیں تبدیل کریں

Markdown کو standard output میں لکھیں

source document کو پہلی argument کے طور پر دیں۔ تیار کردہ Markdown standard output پر پرنٹ ہو گا:

npx @firecrawl/anydoc report.docx

یہ اس وقت مفید ہے جب آپ نتیجہ دیکھنا یا اسے کسی دوسرے command میں pipe کرنا چاہتے ہوں۔

Markdown کو فائل میں محفوظ کریں

output file منتخب کرنے کے لیے -o استعمال کریں:

npx @firecrawl/anydoc slides.pptx -o slides.md

standard input سے data تبدیل کریں

standard input سے bytes پڑھنے کے لیے input path کے طور پر - استعمال کریں۔ CSV کے content میں کوئی قابلِ اعتماد signature نہیں ہوتی، اس لیے اس کا format واضح طور پر بتائیں:

npx @firecrawl/anydoc - --format csv < data.csv

Node.js میں anydoc استعمال کریں

Node.js package file paths، byte arrays اور مشترکہ دستاویزی model کے لیے الگ الگ functions فراہم کرتا ہے۔

فائل path تبدیل کریں

import { toMarkdown } from '@firecrawl/anydoc';

const markdown = await toMarkdown('report.docx');
console.log(markdown);

bytes تبدیل کریں

جب فائل پہلے ہی upload، download یا memory میں read ہو چکی ہو تو toMarkdownBytes استعمال کریں:

import { toMarkdownBytes } from '@firecrawl/anydoc';

const markdown = await toMarkdownBytes(bytes);

جن فارمیٹس کے دستخط قابل شناخت ہوں، anydoc مواد سے فارمیٹ کا پتا چلا لیتا ہے۔ CSV میں ایسا دستخط نہیں ہوتا، اس لیے فارمیٹ کا نام فراہم کریں:

const markdown = await toMarkdownBytes(bytes, 'csv');

دستاویز کا ماڈل اور اثاثے برقرار رکھیں

اگر آپ کو حتمی Markdown سٹرنگ سے زیادہ کچھ درکار ہو تو toDocument کے ذریعے مشترکہ دستاویز ماڈل پر رک جائیں:

import { toDocument } from '@firecrawl/anydoc';

const document = await toDocument(bytes);

دستاویز ماڈل میں پارس شدہ ساخت اور سرایت شدہ اثاثے شامل ہوتے ہیں۔ سرایت شدہ اثاثوں کے بائٹس ان کی میڈیا اقسام کے ساتھ دستیاب رہتے ہیں، اگرچہ Markdown نمائندگی میں ان کا متبادل متن استعمال ہوتا ہے۔

Python میں anydoc استعمال کریں

فائل پاتھ تبدیل کریں

import anydoc

markdown = anydoc.to_markdown("report.docx")
print(markdown)

میموری میں موجود بائٹس تبدیل کریں

import anydoc

markdown = anydoc.to_markdown_bytes(data)

CSV جیسے ایسے اِن پٹ کا نام واضح طور پر دیں جس کا کوئی دستخط نہیں ہوتا:

markdown = anydoc.to_markdown_bytes(data, "csv")

دستاویز ماڈل تک رسائی حاصل کریں

document = anydoc.to_document(data)

یہ طریقہ اس وقت مفید ہے جب آپ کی ایپلیکیشن کو صرف سیریلائز شدہ Markdown کے بجائے پارس شدہ دستاویز اور اس کے سرایت شدہ اثاثوں کی ضرورت ہو۔

براؤزر میں دستاویزات تبدیل کریں

WebAssembly پیکیج بائٹ ارے کو براؤزر میں مقامی طور پر تبدیل کرتا ہے۔ تبدیلی کے فنکشنز کال کرنے سے پہلے ماڈیول کو شروع کریں:

import init, { toMarkdownBytes, toDocument } from '@firecrawl/anydoc-wasm';

await init();

const markdown = toMarkdownBytes(bytes);

دیگر bindings کی طرح، CSV کے لیے فارمیٹ فراہم کریں:

const markdown = toMarkdownBytes(bytes, 'csv');

دستاویز ماڈل اور سرایت شدہ اثاثے برقرار رکھنے کے لیے toDocument استعمال کریں:

const document = toDocument(bytes);

اوپر دکھائے گئے Node.js API کے برعکس، README میں WebAssembly کی تبدیلی کی کالز شروع کیے جانے کے بعد ہم وقت ہوتی ہیں۔

Rust سے anydoc استعمال کریں

فائل پاتھ تبدیل کریں

let markdown = anydoc::to_markdown("report.docx")?;

خودکار شناخت کے ساتھ بائٹس تبدیل کریں

let markdown = anydoc::to_markdown_bytes(&bytes, None)?;

CSV واضح طور پر مخصوص کریں

let markdown = anydoc::to_markdown_bytes(
    &bytes,
    anydoc::Format::Csv,
)?;

دستاویز ماڈل واپس کریں

let document = anydoc::to_document(&bytes, None)?;

فارمیٹ کی شناخت کو سمجھیں

anydoc مواد کے ایسے نشانات کا معائنہ کرتا ہے جیسے PDF ہیڈر، RTF کا ابتدائی گروپ، OLE اسٹریم کے نام، اور ZIP پیکیج کا میٹا ڈیٹا۔ اس کا مطلب ہے کہ غلط نام والی فائل بھی تبدیل کی جا سکتی ہے، اگر اس کے بائٹس سے اصل فارمیٹ کی شناخت ممکن ہو۔

Rust بائٹس، ایکسٹینشنز اور پاتھز کی جانچ کے لیے مددگار فنکشنز فراہم کرتا ہے:

Format::from_bytes(&bytes);
Format::from_extension("pptm");
Format::from_path(Path::new("report.odt"));

پہلی کال کسی شناخت شدہ فارمیٹ کو واپس کرتی ہے، جیسے Some(Format::Docx)، یا اس وقت None واپس کرتی ہے جب مواد کا کوئی معلوم نشان مطابقت نہ رکھتا ہو۔ Node.js میں formatFromBytes اور Python میں anydoc.format_from_bytes جیسے ناموں سے مساوی مددگار فنکشنز دستیاب ہیں۔

CSV کو خصوصی طریقے سے کیوں سنبھالنا ضروری ہے

CSV سادہ متن ہے اور اس میں کوئی ایسا معیاری بائٹ دستخط نہیں جو منفرد طور پر اس کی شناخت کر سکے۔ بے نام CSV بائٹس یا معیاری اِن پٹ تبدیل کرتے وقت csv واضح طور پر فراہم کریں۔ اگر فائل پاتھ میں .csv ایکسٹینشن شامل ہو تو ایکسٹینشن اس کی شناخت کر سکتی ہے۔

تبدیلی کی خرابیوں کو سنبھالیں

جب کوئی بامعنی Markdown تیار نہ ہو سکے تو تبدیلی خرابی واپس کرتی ہے۔ Rust ان صورتوں کو ConvertError کے ذریعے ظاہر کرتا ہے:

• Unsupported: فارمیٹ نامعلوم ہے یا اسے تبدیل نہیں کیا جا سکتا، جس میں صرف تصویر پر مشتمل PDF بھی شامل ہے۔
• Malformed: فائل کی ساخت ناقابل استعمال ہے اور بامعنی مواد حاصل نہیں کیا جا سکتا۔
• Encrypted: دستاویز خفیہ کردہ یا پاس ورڈ سے محفوظ ہے۔
• ResourceLimit: تبدیلی decompression، nesting یا node count سے متعلق مقررہ حفاظتی حد سے تجاوز کر گئی۔
• MissingPart: دستاویز کا مطلوبہ جزو موجود نہیں ہے۔
• Io: to_markdown کو دی گئی فائل پڑھی نہیں جا سکی۔

بیچ پراسیسنگ پائپ لائن خفیہ کردہ یا غیر معاون فائلوں کا ریکارڈ رکھ کر باقی اِن پٹس کے ساتھ کام جاری رکھ سکتی ہے:

match anydoc::to_markdown(path) {
    Ok(markdown) => Some(markdown),
    Err(error @ (ConvertError::Encrypted | ConvertError::Unsupported(_))) => {
        unconverted.push((path, error));
        None
    }
    Err(error) => return Err(error),
}

Node.js اور WebAssembly میں خرابی کی قسم کا نام error.code کے ذریعے دستیاب ہوتا ہے۔ Python ہر تبدیلی کی قسم کے لیے مخصوص anydoc.ConvertError ذیلی کلاس استعمال کرتا ہے، اور فائل نہ پڑھے جانے کی صورت میں OSError اٹھاتا ہے۔

جدید انضمام کے نکات

اپ لوڈ پائپ لائنز کے لیے بائٹ تبدیلی کو ترجیح دیں

اگر آپ کی ایپلیکیشن کو پہلے ہی اپ لوڈ، آبجیکٹ اسٹور یا HTTP جواب سے دستاویز کے بائٹس موصول ہوتے ہیں تو toMarkdownBytes یا to_markdown_bytes استعمال کریں۔ اس سے فائل پاتھ کی ضرورت ختم ہو جاتی ہے اور anydoc صارف کے فراہم کردہ فائل نام پر بھروسا کرنے کے بجائے اصل مواد کا معائنہ کر سکتا ہے۔

جب اثاثے اہم ہوں تو دستاویز ماڈل استعمال کریں

صرف Markdown میں سرایت شدہ آبجیکٹس کے خام بائٹس شامل نہیں ہوتے۔ جب آپ کو سرایت شدہ اثاثوں اور ان کی میڈیا اقسام کو محفوظ، جانچ یا الگ سے پراسیس کرنا ہو تو toDocument یا to_document استعمال کریں۔

اسکین شدہ PDFs کو الگ سے سنبھالیں

anydoc کی بلٹ اِن PDF سپورٹ متن پر مبنی PDFs کے لیے ہے اور اس میں OCR شامل نہیں۔ صرف تصاویر پر مشتمل PDFs کو OCR کی صلاحیت رکھنے والے ورک فلو کی طرف بھیجیں، بجائے اس کے کہ مقامی تبدیلی کی بار بار کوشش کی جائے۔

CSV فارمیٹ کا انتخاب واضح رکھیں

میموری میں موجود مختلف اقسام کے ان پٹس پر کارروائی کرتے وقت CSV بائٹس کو واضح فارمیٹ میٹا ڈیٹا کے ساتھ منسلک کریں۔ دیگر معاون فارمیٹس کا اکثر ان کے مواد سے پتا چل سکتا ہے، لیکن CSV کے لیے نام، ایکسٹینشن، یا واضح فارمیٹ آرگیومنٹ ضروری ہے۔

رن ٹائم کے رویے سے فائدہ اٹھائیں

Node.js میں تبدیلی ایونٹ لوپ کو بلاک کرنے کے بجائے libuv تھریڈ پول پر چلتی ہے۔ Python میں تبدیلی کے دوران GIL ریلیز ہو جاتا ہے، جس سے دیگر Python تھریڈز چلتے رہ سکتے ہیں۔ یہ خصوصیات تبدیلی کو ہم وقت چلنے والی ایپلیکیشنز میں شامل کرتے وقت مفید ہیں۔

بعد کے مراحل میں یکساں آؤٹ پٹ استعمال کریں

چونکہ آفس فارمیٹس ایک ہی سیریئلائزر کا اشتراک کرتے ہیں، اس لیے بعد کے سسٹمز Word، PowerPoint، Excel، RTF، اور OpenDocument ان پٹس کے لیے الگ الگ صفائی کے قواعد برقرار رکھنے کے بجائے ایک ہی Markdown ساخت استعمال کر سکتے ہیں۔ اس طرح anydoc سرچ انڈیکسنگ، ایکسٹریکشن پائپ لائنز، اور لینگویج ماڈلز کے لیے منظم متن کی تیاری کے لیے خاص طور پر موزوں ہے۔

تبدیلی کی پائپ لائن کیسے کام کرتی ہے

1. anydoc فارمیٹ معلوم کرنے کے لیے دستاویز کی بائٹس یا دستیاب فائل نام کی معلومات کا جائزہ لیتا ہے۔
2. فارمیٹ کے مطابق پارسر Word، PowerPoint، Excel، OpenDocument، RTF، EPUB، یا CSV مواد پڑھتا ہے۔
3. پارسر ایک مشترکہ دستاویزی ماڈل بناتا ہے جس میں بلاکس، اِن لائن عناصر، جدولیں، حواشی، اور اثاثے شامل ہوتے ہیں۔
4. ایک مشترکہ سیریئلائزر اس ماڈل کو GitHub-Flavored Markdown میں تبدیل کرتا ہے۔
5. PDF کو pdf-inspector کے ذریعے ہینڈل کرکے براہِ راست Markdown میں تبدیل کیا جاتا ہے۔

اس فنِ تعمیر کا مطلب ہے کہ سیریئلائزر میں ہونے والی بہتری بیک وقت کئی فارمیٹس کو فائدہ پہنچا سکتی ہے۔ مثال کے طور پر جدولوں میں خصوصی حروف کو درست طریقے سے ایسکیپ کرنے کی اصلاح صرف ایک ان پٹ پارسر تک محدود نہیں رہتی۔

کارکردگی اور موزوں استعمال

ریپوزٹری چودہ آزمودہ فارمیٹس پر مشتمل 100 حقیقی دنیا کی دستاویزات کے بینچ مارک کی اطلاع دیتی ہے۔ anydoc نے تمام چودہ فارمیٹس کو کور کیا، تبدیلی کا درمیانی وقت 4.4 ملی سیکنڈ حاصل کیا، اور اس موازنے میں مجموعی معیار کا اسکور 81 حاصل کیا۔ معیار کا جائزہ تکمیل، ساخت، فارمیٹنگ، اور صفائی کی بنیاد پر لیا گیا۔

بینچ مارک کے نتائج ڈیٹا سیٹ، ہارڈویئر، اور طریقۂ کار پر منحصر ہوتے ہیں، اس لیے شامل کردہ بینچ مارک کو ہر ورک لوڈ کی ضمانت کے بجائے منصوبے سے متعلق ثبوت سمجھیں۔ منصوبے کے مطابق اس کا بہترین استعمال ایسی پائپ لائن ہے جو آفس دستاویزات کا مختلف مجموعہ وصول کرے اور تیز، منظم، یکساں Markdown کی ضرورت رکھتی ہو۔

نتیجہ

anydoc Rust، Node.js، Python، براؤزر، اور کمانڈ لائن میں تبدیلی کا ایک ہی ورک فلو فراہم کرتا ہے۔ فوری آزمائش کے لیے CLI سے شروع کریں، پھر اپنی ایپلیکیشن کے مطابق بائنڈنگ منتخب کریں۔ اپ لوڈ کی گئی فائلوں کے لیے بائٹ پر مبنی تبدیلی استعمال کریں، CSV کو واضح طور پر متعین کریں، ایمبیڈ شدہ اثاثوں کی اہمیت ہو تو دستاویزی ماڈل برقرار رکھیں، اور خفیہ کردہ، خراب، غیر معاون، یا اسکین شدہ دستاویزات کو الگ معاملات کے طور پر ہینڈل کریں۔