ٹیکسٹ اصل میں کیا ہے، اور ٹولز اس پر متفق کیوں نہیں ہوتے
ٹیکسٹ فائل بائٹس اور ایک انکوڈنگ کا مجموعہ ہے، اور انکوڈنگ فائل میں محفوظ نہیں ہوتی۔ صرف ایک رواج پروگرام کو بتاتا ہے کہ فلاں بائٹ کا مطلب "é" ہے — اسی لیے ایک ہی فائل ایک جگہ صحیح کھلتی ہے اور دوسری جگہ "é" بن کر۔ UTF-8 جدید حل ہے: یہ عام لاطینی حروف ایک بائٹ میں، اعراب والے حروف دو میں، اور زیادہ تر چینی، جاپانی، عربی اور ہر ایموجی تین یا چار بائٹس میں رکھتا ہے۔ UTF-16 وہ ہے جو Windows اور JavaScript اندرونی طور پر استعمال کرتے ہیں، اور یہ تقریباً ہر چیز دو بائٹس میں اور باقی چار میں رکھتا ہے۔ Windows-1252 اور Latin-1 وہ سنگل بائٹ انکوڈنگز ہیں جو پرانے سسٹم اب بھی بناتے ہیں، اور گڈمڈ حروف (mojibake) کا عام ذریعہ یہی ہیں۔ ان صفحات کے بارے میں جاننا مفید ہے: CSV ویور ڈراپ کی گئی فائل کی انکوڈنگ پہچان لیتا ہے، UTF-16 اور Windows-1252 سمیت، اور آپ کو اسے بدلنے بھی دیتا ہے۔ سادہ ٹیکسٹ باکس ایسا نہیں کرتے — ڈراپ کی گئی فائل UTF-8 کے طور پر پڑھی جاتی ہے، اس لیے Latin-1 ایکسپورٹ کے اعراب والے حروف غلط دکھیں گے اور حل یہ ہے کہ پہلے اسے تبدیل کریں۔
“حرف” کے چار معنی ہیں اور آپ کو کون سا چاہیے، یہ اس پر منحصر ہے کہ حد کون لگا رہا ہے۔ جسے انسان ایک حرف کے طور پر دیکھتا ہے وہ grapheme cluster ہے۔ ریگولر ایکسپریشن جسے میچ کرتا ہے وہ code point ہے۔ JavaScript کا string.length جو بتاتا ہے وہ UTF-16 یونٹس ہیں۔ ڈیٹا بیس کالم یا HTTP ہیڈر جو ناپتا ہے وہ UTF-8 بائٹس ہیں۔ سادہ انگریزی کے لیے چاروں ایک جیسے ہوتے ہیں، اسی لیے کسی کو پتا نہیں چلتا — اور پھر فیملی ایموجی ایک grapheme، سات code points، گیارہ UTF-16 یونٹس اور پچیس بائٹس نکلتا ہے، اور 200 حروف کا پیغام 255 حروف والی فیلڈ رد کر دیتی ہے۔ حروف گنیں ٹول بالکل اسی وجہ سے چاروں دکھاتا ہے۔
غیر مرئی حروف بھی اصل حروف ہیں۔ نان بریکنگ اسپیس بالکل عام اسپیس جیسی دکھتی ہے مگر مکمل طور پر الگ حرف ہے — یہ ویب پیج یا ورڈ پروسیسر سے کاپی کیے گئے ٹیکسٹ میں مسلسل آتی ہے، اور سرچ، CSV پارسنگ اور اسپیس پر تقسیم کرنے والے کوڈ کو خراب کر دیتی ہے۔ Zero-width joiners ہی کئی افراد والے ایموجی کو جوڑے رکھتے ہیں۔ سافٹ ہائفن، ڈائریکشن مارکس اور بائٹ آرڈر مارکس سب پیسٹ کیے گئے ٹیکسٹ کے ساتھ چلے آتے ہیں۔ ان میں سے کوئی اسکرین پر نظر نہیں آتا، اس لیے واحد اشارہ یہ ہوتا ہے کہ گنتی اس سے میل نہیں کھاتی جو آپ دیکھ رہے ہیں — اور حروف گننے والے ٹول کا ایک ایماندارانہ استعمال یہی ہے۔ نوٹ کریں کہ ٹیکسٹ کا موازنہ کریں میں اسپیسنگ نظر انداز کرنے کا آپشن عام اسپیسز اور ٹیبز کو سمیٹتا ہے؛ یہ نان بریکنگ اسپیس کو اسپیس نہیں سمجھتا، کیونکہ وہ ایک چیز نہیں۔
لائن اینڈنگز ہی وجہ ہیں کہ diff کبھی کبھی ہر لائن کو بدلا ہوا دکھاتا ہے۔ Windows لائن کو carriage return اور line feed سے ختم کرتا ہے؛ باقی سب صرف line feed استعمال کرتے ہیں۔ LF فائل کو Windows ایڈیٹر سے محفوظ کریں تو اس کی ہر لائن ایک غیر مرئی بائٹ سے مختلف ہو جاتی ہے، اس لیے بائٹ لیول کا موازنہ — git diff، diff(1) — پوری فائل کو دوبارہ لکھی ہوئی بتاتا ہے اور وہ ایک تبدیلی چھپا دیتا ہے جو آپ نے اصل میں کی تھی۔ ہمارے ٹیکسٹ کا موازنہ کریں اور ڈپلیکیٹ لائنیں ہٹائیں ٹولز موازنے سے پہلے تینوں طریقوں پر لائنیں تقسیم کرتے ہیں، اس لیے جس فائل کی صرف لائن اینڈنگز بدلی ہوں وہ یہاں سرخ دیوار بن کر نظر نہیں آتی۔ پڑھنے کے ٹول میں یہ سہولت ہے اور ریپوزٹری میں ایک جال: اسے جڑ سے ٹھیک کریں، اپنے ایڈیٹر یا git کی اپنی لائن اینڈنگ سیٹنگز سے۔
بالکل ایک جیسی دکھنے والی دو اسٹرنگز موازنے میں مختلف نکل سکتی ہیں، اور عموماً اس کی وجہ نارملائزیشن ہوتی ہے۔ یونیکوڈ "é" کو دو طرح لکھ سکتا ہے: ایک code point کے طور پر، یا سادہ "e" کے بعد ایک combining acute accent۔ دونوں ایک جیسے دکھتے ہیں مگر بائٹس کی ترتیب الگ ہے، اس لیے موازنہ، ڈپلیکیٹس ہٹانا یا ڈیٹا بیس لک اپ انہیں دو الگ ویلیوز سمجھتا ہے۔ macOS اور Windows فائل ناموں کے لیے کون سی شکل استعمال ہو، اس پر تاریخی طور پر متفق نہیں رہے، اور یوں دو مشینوں سے جمع کی گئی فہرست میں ایسی چیزیں آ جاتی ہیں جو بالکل ڈپلیکیٹ لگتی ہیں مگر ہٹتی نہیں۔ حروف گنیں سے آپ اسے پکڑ سکتے ہیں — دونوں شکلوں کی grapheme گنتی ایک اور code point گنتی الگ ہوتی ہے۔ ان میں سے کوئی ٹول ان شکلوں کے درمیان تبدیلی نہیں کرتا؛ یہ کسی یونیکوڈ لائبریری والے اسکرپٹ کا ایک لائن کا کام ہے، جیسے Python کا unicodedata.normalize۔
“الفاظ کی گنتی” ایک فیصلہ ہے، پیمائش نہیں۔ وائٹ اسپیس پر تقسیم کرنا انگریزی کا اصول ہے، اور اسے چینی، جاپانی یا تھائی پر لاگو کرنا — جو الفاظ کے درمیان اسپیس نہیں ڈالتیں — لمبے مضمون کو ایک لفظ بتاتا ہے۔ ہمارا کاؤنٹر اس کے بجائے براؤزر کی یونیکوڈ ورڈ سیگمنٹیشن استعمال کرتا ہے، جو ہر رسم الخط میں جانتی ہے کہ لفظ کہاں سے شروع ہوتے ہیں۔ باقی اختلافات ہائفن ("well-known" یہاں اور Word میں ایک لفظ ہے، کچھ ٹولز میں دو)، اکیلے نمبرز، اور اس بارے میں ہیں کہ جملہ کسے کہتے ہیں — "We met Dr. Smith" ایک جملہ ہے اور سادہ اسپلٹر اسے دو بتاتا ہے۔ پڑھنے کا وقت اس کے اوپر ایک مزید اندازہ ہے: خاموش مطالعے کے لیے 238 الفاظ فی منٹ، ایک میٹا اینالیسس سے، نہ کہ وہ گول عدد جو بلاگ پوسٹس میں ایک دوسرے سے نقل ہوتا رہتا ہے۔
جہاں براؤزر واقعی غلط ٹول ہے
اس ماڈیول میں کچھ بھی کبھی بھیجا یا محفوظ نہیں کیا جاتا، اسی لیے اس میں غیر شائع شدہ ڈرافٹ یا ملکیتی سورس کوڈ پیسٹ کرنا محفوظ ہے۔ یہی بات اس کی حد بھی طے کرتی ہے، اور ہم بتانا بہتر سمجھتے ہیں کہ وہ حد کہاں ہے بجائے اس کے کہ آپ کو کام کے بیچ میں پتا چلے۔
بڑی فائلیں۔ پورا ٹیکسٹ ٹیب کی میموری میں رکھا جاتا ہے اور آپ کے ٹائپ کرتے ہی دوبارہ جانچا جاتا ہے۔ چند میگابائٹ آرام سے چلتے ہیں؛ کئی سو میگابائٹ کی لاگ فائل نہیں، اور فون لیپ ٹاپ سے پہلے ہمت ہار دیتا ہے۔ کمانڈ لائن کو یہ مسئلہ نہیں کیونکہ وہ اسٹریم کرتی ہے: grep اور ripgrep آپ کی میموری سے بڑی فائلیں سرچ کرتے ہیں، sed اور awk انہیں لائن بہ لائن بدلتے ہیں، اور unique فلیگ کے ساتھ sort کروڑوں لائنوں کی فہرست سے ڈسک پر ڈیٹا منتقل کر کے ڈپلیکیٹس ہٹا دیتا ہے۔ یہ سب مفت ہیں اور macOS اور Linux پر پہلے سے انسٹال ہیں۔
بہت مختلف دستاویزات۔ ٹیکسٹ کا موازنہ کریں 8,000 فرق پر رک جاتا ہے، کیونکہ اس کے بعد الگورتھم کی میموری کی لاگت اتنی تیزی سے بڑھتی ہے کہ ٹیب جم جائے، اور اتنا بڑا diff ویسے بھی پڑھا نہیں جا سکتا۔ ایک ہی دستاویز کے دو ورژنز تقریباً کبھی اس حد تک نہیں پہنچتے؛ دو غیر متعلقہ دستاویزات فوراً پہنچ جاتی ہیں۔ کوڈ ریویو کے لیے diff اور git diff کسی بھی سائز کو سنبھال لیتے ہیں، اور ایک مناسب تھری وے مرج ٹول وہ کام کرتا ہے جو یہ صفحہ بالکل نہیں کر سکتا۔
انکوڈنگ بدلنا، یا یونیکوڈ کو نارملائز کرنا۔ یہ صفحات پڑھتے اور بتاتے ہیں؛ انکوڈنگز کے درمیان تبدیلی نہیں کرتے۔ iconv ہر موجود انکوڈنگ کے درمیان تبدیلی کرتا ہے، file کمانڈ اندازہ لگاتی ہے کہ آپ کے پاس کیا ہے، اور یونیکوڈ نارملائزیشن Python کی ایک لائن یا ICU کے uconv کی ایک کال ہے۔ اگر آپ گڈمڈ حروف والی ایکسپورٹ ٹھیک کر رہے ہیں تو یہی ٹول چین ہے۔
کوئی بھی بار بار ہونے والا کام۔ یہ ٹولز تب چلتے ہیں جب کوئی شخص کلک کرے۔ چار سو دستاویزات کے الفاظ گننا، یا ہر commit پر کسی ڈائریکٹری کو منیفائی کرنا، اسکرپٹ یا بلڈ اسٹیپ کا کام ہے — اور خاص طور پر منیفائی کرنے کے لیے آپ کا بلڈ ٹول یہی منیفائی کرتا ہے، ساتھ میں سورس میپس، واچ موڈ اور کیشنگ کے ساتھ جو پیسٹ باکس نہیں دے سکتا۔ یہ صفحہ اس ایک فائل کے لیے ہے جو اس وقت آپ کے سامنے ہے۔
جدید CSS۔ CSS منیفائر نیٹو nesting اور جدید media range syntax کو منیفائی کرنے کے بجائے رد کر دیتا ہے، کیونکہ اس کے پیچھے کا منیفائر دونوں سے پرانا ہے اور جو نہیں سمجھتا اسے خاموشی سے حذف کر دیتا ہے۔ یہ کوئی فیچر نہیں بلکہ ایماندارانہ انکار ہے، اور حل یہ ہے کہ پہلے Sass، PostCSS یا Lightning CSS سے nesting کو کمپائل کر کے ختم کریں — جو آپ کا بلڈ ٹول تقریباً یقیناً پہلے سے کرتا ہے۔
ملتے جلتے ناموں والے ٹولز میں انتخاب
الفاظ گنیں بمقابلہ حروف گنیں۔ گنتی ایک جیسی، نمایاں نمبرز الگ۔ الفاظ گنیں الفاظ، جملوں، پیراگرافس اور پڑھنے کے وقت کو سامنے رکھتا ہے، جن میں مضمون، آرٹیکل یا تقریر ناپی جاتی ہے۔ حروف گنیں حروف، اسپیس کے بغیر حروف اور UTF-8 بائٹس کو سامنے رکھتا ہے، جن میں میٹا ڈسکرپشن، SMS سیگمنٹ یا ڈیٹا بیس فیلڈ ناپی جاتی ہے۔ اگر کسی چیز نے آپ کا ٹیکسٹ بہت لمبا ہونے کی وجہ سے رد کیا ہے تو آپ کو حروف والا ٹول چاہیے، اور خاص طور پر اس کی بائٹ گنتی۔
ٹیکسٹ کا موازنہ کریں بمقابلہ ڈپلیکیٹ لائنیں ہٹائیں۔ موازنہ “ان دو ورژنز کے درمیان کیا بدلا” کا جواب دیتا ہے اور اسے دو ٹیکسٹ چاہییں۔ ڈپلیکیٹ ہٹانے والا ٹول ایک فہرست پر کام کرتا ہے اور “اس میں کیا ایک سے زیادہ بار آیا ہے” کا جواب دیتا ہے، اور یہ بھی بتاتا ہے کہ کون سی اندراجات دہرائی گئیں اور کتنی بار، قدرتی ترتیب دیتا ہے تاکہ item2 پہلے آئے اور item10 بعد میں، یا صرف وہ لائنیں رکھتا ہے جو بالکل ایک بار آئیں۔ دو فہرستوں میں سے کسی ایک میں منفرد اندراجات تلاش کرنا ڈپلیکیٹ ہٹانے والے کا کام ہے، موازنہ کرنے والے کا نہیں۔
HTML منیفائر بمقابلہ CSS منیفائر بمقابلہ JavaScript منیفائر۔ تین زبانیں، تین منیفائرز، اور ایک اوورلیپ جو جاننا مفید ہے: HTML منیفائر style بلاکس کے اندر کی CSS اور script بلاکس کے اندر کی JavaScript کو بھی اسی طرح منیفائی کرتا ہے جیسے باقی دو صفحات۔ اس لیے ایک HTML فائل کے لیے ایک ٹول کافی ہے، تین نہیں۔ الگ .css اور .js فائلوں کے لیے ان کے اپنے صفحات چاہییں۔
XML ویور بمقابلہ XML فارمیٹر اور XML ویلیڈیٹر۔ یہاں کا ویور آپ کو دیکھنے کے لیے ایک سمیٹنے والا ٹری دیتا ہے، اور جب دستاویز بڑی ہو اور آپ کچھ ڈھونڈ رہے ہوں تو یہی چاہیے۔ فارمیٹر اور ویلیڈیٹر، جو ڈویلپر ٹولز میں ہیں، آپ کو فائل میں واپس پیسٹ کرنے کے لیے انڈینٹ کیا ہوا ٹیکسٹ اور خرابی کی بالکل درست لائن اور کالم دیتے ہیں۔ پڑھنا، بمقابلہ ایڈٹ کرنا اور ٹھیک کرنا۔
CSV ویور بمقابلہ فائل Excel میں کھولنا۔ یہ کوئی حریف ٹول نہیں، مگر لوگ اصل میں یہی موازنہ کر رہے ہوتے ہیں۔ Excel کھولتے ہی بغیر پوچھے چیزیں بدل دیتا ہے: 00123 جیسا پروڈکٹ کوڈ 123 بن جاتا ہے، 5-3 جیسا پارٹ نمبر 5 مارچ بن جاتا ہے، لمبا آرڈر نمبر سائنٹیفک نوٹیشن بن جاتا ہے، اور جرمن سسٹم سے سیمی کولن سے الگ کی گئی ایکسپورٹ پوری کی پوری کالم A میں آ جاتی ہے۔ ویور ہر ویلیو کو ٹیکسٹ کے طور پر، بالکل ویسے دکھاتا ہے جیسی محفوظ ہے، تاکہ آپ دیکھ سکیں کہ آپ کو اصل میں کیا بھیجا گیا۔
Markdown پیش نظارہ بمقابلہ Markdown سے PDF۔ پیش نظارہ یہ چیک کرنے کے لیے ہے کہ README ویسا ہی دکھے گا جیسا GitHub دکھائے گا، ٹائپ کرتے ہوئے لائیو۔ Markdown سے PDF، جو دستاویزات کے ٹولز میں ہے، صفحات کی تقسیم کے ساتھ مکمل دستاویز تیار کرنے کے لیے ہے۔ یہاں چیک کریں، وہاں شائع کریں۔