Excel آپ کی CSV کیوں خراب کرتا ہے
پوسٹ کوڈز کا پہلا صفر غائب ہو جاتا ہے، پروڈکٹ کوڈز تاریخیں بن جاتے ہیں، اور لمبے شناختی نمبر خاموشی سے راؤنڈ ہو جاتے ہیں۔ یہ محفوظ کرتے وقت نہیں بلکہ کھولتے وقت ہوتا ہے — اسی لیے بہت سے لوگ کبھی سمجھ ہی نہیں پاتے کہ گڑبڑ کہاں ہوئی۔
آخری جائزہ
نقصان فائل کھولتے وقت ہوتا ہے
یہی وہ حصہ ہے جو مسئلے کی تشخیص کو اتنا مشکل بناتا ہے۔ CSV ایک ٹیکسٹ فائل ہے: اس کی ہر ویلیو محض حروف ہے، اور فائل میں کہیں نہیں لکھا کہ ان کا مطلب کیا ہے۔ Excel جب اسے کھولتا ہے تو ہر کالم کی قسم کا اندازہ لگاتا ہے، ویلیوز کو اس کے مطابق بدل دیتا ہے، اور اسی لمحے سے بدلا ہوا ورژن رکھتا ہے۔ فائل محفوظ کریں تو یہ تبدیلیاں واپس لکھ دی جاتی ہیں۔
یعنی فائل ٹھیک تھی، جو فائل آپ نے محفوظ کی وہ ٹھیک نہیں، اور کسی بھی مرحلے پر کسی چیز نے آپ کو خبردار نہیں کیا۔ لوگ سمجھتے ہیں کہ ایکسپورٹ خراب تھا، دوبارہ ایکسپورٹ کرتے ہیں، اور وہی نتیجہ پاتے ہیں — کیونکہ خرابی ڈاؤن لوڈ کے بعد ان کی اپنی مشین پر ہو رہی ہوتی ہے۔
وہ چار تبدیلیاں جو نقصان کرتی ہیں
شروع کے صفر ہٹا دیے جاتے ہیں۔ 01234 جیسا پوسٹ کوڈ، فرانسیسی ڈیپارٹمنٹ کوڈ، اکاؤنٹ نمبر، صفر سے شروع ہونے والا فون نمبر — سب عددی لگتے ہیں، اس لیے صفر کو بے معنی سمجھ کر ہٹا دیا جاتا ہے۔ وہ بے معنی نہیں؛ وہ شناختی نمبر کا حصہ ہے۔
لمبے نمبر راؤنڈ ہو جاتے ہیں۔ اسپریڈشیٹ نمبروں کو تقریباً پندرہ اہم ہندسوں والے فلوٹنگ پوائنٹ کے طور پر رکھتی ہے، اس لیے آرڈر ریفرنس، کریڈٹ کارڈ نمبر، IMEI یا 64-bit شناختی نمبر خاموشی سے راؤنڈ ہو جاتا ہے — آخری ہندسے صفر بن جاتے ہیں۔ سیل نمبر جیسا دکھتا ہے اور نمبر غلط ہوتا ہے۔
جو کچھ بھی تاریخ جیسا لگے اسے مقامی طریقے کے مطابق دوبارہ فارمیٹ کر دیا جاتا ہے۔ 03/05 ایک ملک میں مارچ اور دوسرے میں مئی ہے، اس لیے ایک ہی فائل دو دفاتر میں کھولی جائے تو دو مختلف ڈیٹا سیٹ بنتے ہیں۔ اس سے بھی بدتر، جو ویلیوز کبھی تاریخ تھیں ہی نہیں وہ بھی بدل جاتی ہیں: SEPT1 جیسا جین کا نام تاریخ بن جاتا ہے، اور یہ مسئلہ اتنا ضدی تھا کہ آخرکار ماہرینِ جینیات نے اس سے لڑتے رہنے کی بجائے جینز کے نام ہی بدل دیے۔
لہجے والے حروف بے معنی علامتوں (mojibake) میں بدل جاتے ہیں۔ CSV میں اس کی کیریکٹر انکوڈنگ کا کوئی ریکارڈ نہیں ہوتا، اس لیے UTF-8 میں محفوظ کی گئی فائل کو پرانے کوڈ پیج کے طور پر پڑھا جائے — یا اس کا الٹ — تو ٹھیک وہی رو خراب ہوتی ہیں جن میں لہجے والے حروف کے نام ہوں۔
حل: کھولیں نہیں، امپورٹ کریں
جو CSV آپ کے لیے اہم ہو اس پر کبھی ڈبل کلک نہ کریں۔ ڈبل کلک Excel کو اندازہ لگانے کی اجازت دے دیتا ہے، اور وہ پورے اعتماد سے اندازہ لگاتا ہے۔
اس کی بجائے Data → From Text/CSV استعمال کریں۔ امپورٹ ڈائیلاگ آپ کو کچھ بھی پارس ہونے سے پہلے ہر کالم کی قسم طے کرنے دیتا ہے — پوسٹ کوڈ والے کالم اور شناختی نمبر والے کالم کو Text مارک کریں، اور وہ بالکل ویسے ہی آئیں گے جیسے فائل میں ہیں۔ یہ آپ کو انکوڈنگ اور ڈیلیمیٹر خود بتانے دیتا ہے بجائے اس کے کہ ان کا اندازہ لگایا جائے۔ اس میں بیس سیکنڈ لگتے ہیں اور یہی پورا حل ہے۔
Google Sheets میں بھی یہی ہے: File → Import، اور “Convert text to numbers, dates and formulas” بند کر دیں۔ LibreOffice Calc کالم ٹائپ کا ڈائیلاگ بطورِ ڈیفالٹ دکھاتا ہے، اور یہ ان چند معاملات میں سے ایک ہے جہاں وہ صاف طور پر بہتر رویہ رکھتا ہے۔
امپورٹ سے پہلے جانچ لیں
جب کچھ پہلے ہی خراب ہو چکا ہو تو پہلا مفید قدم یہ ہے کہ فائل کو کسی اسپریڈشیٹ کے چھوئے بغیر دیکھیں۔ CSV دیکھنا ویلیوز کو بالکل ویسے دکھاتا ہے جیسے بائٹس میں ہیں — شروع کے صفر موجود، لمبے نمبر مکمل، تاریخیں اسی ٹیکسٹ کی صورت میں جیسے لکھی گئی تھیں۔ اس سے فوراً پتا چل جاتا ہے کہ غلطی ایکسپورٹ میں تھی یا امپورٹ میں۔
یہ آپ کو وہ دو چیزیں بھی دکھاتا ہے جو CSV اپنے بارے میں کبھی نہیں بتاتی: ڈیلیمیٹر — کوما، سیمی کولن یا ٹیب، اور یورپی لوکیلز سیمی کولن ایکسپورٹ کرتے ہیں کیونکہ وہاں کوما اعشاریہ کی علامت ہے — اور انکوڈنگ۔ امپورٹ سے پہلے دونوں معلوم ہوں تو باقی زیادہ تر اندازے ختم ہو جاتے ہیں۔
اگر CSV آپ خود بنا رہے ہیں
ایکسپورٹ کی طرف چند فیصلے آگے چل کر یہ سب کچھ روک دیتے ہیں۔
اگر فائل Windows پر Excel میں جانی ہے تو اسے byte order mark کے ساتھ UTF-8 میں لکھیں۔ Excel اسی نشان سے UTF-8 پہچانتا ہے اور اس کے بغیر لہجے والے حروف خراب کر دیتا ہے — یہ ان نایاب صورتوں میں سے ایک ہے جہاں BOM شامل کرنا پریشانی نہیں بلکہ درست فیصلہ ہے۔
ہر اس فیلڈ کو کوٹ کریں جسے غلط پڑھا جا سکتا ہو، اور شناختی نمبر والے کالمز کو ہمیشہ کوٹ کریں۔ کوٹ کرنے سے Excel کھولتے وقت تبدیلی کرنے سے نہیں رکتا، مگر ہر دوسرے استعمال کرنے والے کے لیے ارادہ بالکل واضح ہو جاتا ہے۔
CSV بالکل استعمال نہ کرنے پر غور کریں۔ اگر وصول کرنے والا JSON یا اصل اسپریڈشیٹ لے سکتا ہے تو دونوں ڈیٹا کی قسمیں واضح طور پر ساتھ رکھتے ہیں اور ان میں ان میں سے کوئی خرابی نہیں ہوتی۔ CSV کی خوبی یہ ہے کہ ہر چیز اسے پڑھ لیتی ہے؛ اس کی کمزوری یہ ہے کہ کوئی اس پر متفق نہیں کہ اس میں لکھا کیا ہے۔
اکثر پوچھے جانے والے سوالات
کیا محفوظ کرنے کے بعد نقصان واپس ہو سکتا ہے؟
قابلِ اعتماد طریقے سے نہیں۔ ہٹایا گیا شروع کا صفر اور راؤنڈ کیا گیا ہندسہ جا چکے — فائل میں کچھ نہیں جس سے انہیں بحال کیا جا سکے۔ اصل سورس سے دوبارہ ایکسپورٹ کریں؛ اسی لیے اصل ایکسپورٹ کو بغیر چھیڑے رکھنا ڈسک کی جگہ کے قابل ہے۔
میری CSV ایک لمبے کالم کی صورت میں کیوں کھلتی ہے؟
ڈیلیمیٹر اس سے میل نہیں کھاتا جس کی اسپریڈشیٹ توقع کرتی ہے — عموماً سیمی کولن والی فائل کوما والے لوکیل میں کھولی گئی ہو، یا اس کا الٹ۔ امپورٹ ڈائیلاگ آپ کو اسے خود بتانے دیتا ہے، جو سسٹم کی ریجنل سیٹنگز بدلنے سے زیادہ تیز ہے۔
میرے پہلے کالم کے نام کے شروع میں یہ عجیب سا حرف کیا ہے؟
یہ byte order mark ہے، جسے انکوڈنگ کے اشارے کی بجائے ٹیکسٹ کے طور پر پڑھ لیا گیا۔ یہ وہی نشان ہے جو Excel میں لہجے والے حروف ٹھیک کرتا ہے، اسی لیے یہ مفید بھی ہے اور پریشان کن بھی — زیادہ تر معیاری CSV پارسرز اسے خود بخود ہٹا دیتے ہیں۔
کیا CSV کا کوئی معیار ہے؟
صرف 2005 کی ایک مشاورتی تفصیل جو بتاتی ہے کہ زیادہ تر ٹولز کیا کرتے ہیں، اور بہت سا سافٹ ویئر اس سے مختلف کرتا ہے۔ اسی لیے ڈیلیمیٹرز، کوٹنگ، لائن اینڈنگز اور انکوڈنگز سب مختلف ہوتی ہیں — اور اسی لیے اصل فائلوں پر واحد کارگر طریقہ انہیں فرض کرنے کی بجائے پہچاننا ہے۔
میرے ٹیکسٹ ایڈیٹر میں ایک رو کئی لائنوں میں کیوں ٹوٹ جاتی ہے؟
کیونکہ کوٹ کی گئی فیلڈ میں جائز طور پر لائن بریکس ہو سکتی ہیں — عموماً پتے والی فیلڈ میں۔ ریکارڈ پھر بھی ایک ہی رو ہے؛ جو بھی چیز فائل کو نئی لائنوں پر تقسیم کرے گی وہ ٹھیک انہی رو کو خراب کر دے گی، اسی لیے کوما یا نئی لائنوں پر تقسیم کرنا CSV پڑھنے کا غلط طریقہ ہے۔