ایک حرف کسے گنا جاتا ہے؟

ایک ایموجی، چار جواب

اسکن ٹون والا انگوٹھے کا نشان، یا خاندان والا ایموجی لیں۔ اسے چار طریقوں سے گنیں تو چار نمبر آتے ہیں، اور ان میں سے کوئی بھی غلط نہیں۔

پڑھنے والا ایک حرف دیکھتا ہے۔ ایک چیز، جسے مٹانے کے لیے بیک اسپیس ایک بار دبانا پڑتا ہے۔

ریگولر ایکسپریشن کو سات نظر آ سکتے ہیں۔ یہ کئی کوڈ پوائنٹس سے بنا ہوتا ہے جنہیں نظر نہ آنے والے کنیکٹرز جوڑتے ہیں — ایک بنیادی ایموجی، ایک موڈیفائر، ایک جوائنر، ایک اور ایموجی، وغیرہ۔

JavaScript گیارہ بتاتا ہے۔ یہ ٹیکسٹ کو 16-bit یونٹس میں رکھتا ہے، اور بنیادی رینج سے باہر کی ہر چیز ان میں سے دو لیتی ہے، اس لیے ان میں سے ہر کوڈ پوائنٹ دوگنا گنا جا سکتا ہے۔

ڈیٹا بیس کالم کو پچیس بائٹس نظر آتے ہیں۔ محفوظ کرنے کے لیے UTF-8 میں انکوڈ کیا جائے تو ہر کوڈ پوائنٹ چار بائٹس تک لیتا ہے۔

عام انگریزی تحریر کے لیے چاروں نمبر ایک جیسے ہوتے ہیں۔ یہی وجہ ہے کہ یہ مسئلہ تب تک نظر نہیں آتا جب تک کوئی لہجے والے حرف کا نام، جاپانی زبان کا جملہ یا ایک ایموجی نہ ڈال دے — اور تین سال سے ٹھیک چلنے والی فیلڈ ڈیٹا کاٹنے لگتی ہے۔

آپ کی حد کون سا نمبر گنتی ہے

عملی سوال کبھی یہ نہیں ہوتا کہ “یہ ٹیکسٹ کتنا لمبا ہے”۔ سوال یہ ہوتا ہے کہ “حد لگا کون رہا ہے”، اور اس کے چار عام جواب ہیں۔

ڈیٹا بیس کالم جسے VARCHAR کہا گیا ہو، زیادہ تر انجنز میں بائٹس گنتا ہے۔ اسی لیے جو فیلڈ 255 انگریزی حروف آرام سے لے لیتی ہے وہ اس سے کہیں کم جاپانی حروف رد کر دیتی ہے — ہر ایک تین بائٹس کا — اور اسی لیے لہجے والا نام کبھی کبھار فٹ نہیں ہوتا حالانکہ اس کا سادہ ورژن ہو گیا تھا۔

SMS اپنی سات بٹ والی حروفِ تہجی میں 160 حروف کا ہوتا ہے، اور جیسے ہی ایک حرف بھی اس سے باہر ہو، یہ فی پیغام 70 رہ جاتا ہے۔ ورڈ پروسیسر سے پیسٹ کیا گیا ایک گول کوٹ، یا ایک ایموجی، ایک حصے والے پیغام کو تین حصوں میں بدل کر آپ کا خرچ تین گنا کر سکتا ہے۔

JavaScript میں فارم ویلیڈیٹر تقریباً ہمیشہ UTF-16 یونٹس گنتا ہے، اسی لیے جو فیلڈ 280 حروف کہتی ہے وہ ایموجی سے بھری ایسی اسٹرنگ رد کر سکتی ہے جو دیکھنے میں کہیں چھوٹی ہو۔

انسان وہ گنتا ہے جو اسے نظر آتا ہے، اور ہیڈ لائن، ٹائٹل ٹیگ یا کسی بھی ایسی چیز کے لیے جس کی بصری حد ہو، صرف یہی تعریف معنی رکھتی ہے۔

گنتیاں کہاں الگ ہو جاتی ہیں

کون سے ان پٹ مسئلہ پیدا کرتے ہیں، یہ جاننا نظریہ جاننے سے زیادہ مفید ہے، کیونکہ ایسے ان پٹ پہلے سے پہچانے جا سکتے ہیں۔

ایموجی، خاص طور پر جوڑ کر بنائے گئے — اسکن ٹونز، خاندان، جھنڈے، پیشے۔ جھنڈا دو ریجنل انڈیکیٹر حروف سے بنتا ہے؛ پیشہ عموماً ایک شخص، ایک جوائنر اور ایک چیز ہوتا ہے۔

لہجے والے اور جوڑنے والے حروف۔ é کو ایک کوڈ پوائنٹ کے طور پر بھی لکھا جا سکتا ہے، یا e کے بعد جوڑنے والے acute لہجے کے ساتھ۔ دونوں ایک جیسے دکھتے ہیں، مگر الگ ترتیب پاتے ہیں، برابر نہیں مانے جاتے، اور الگ گنے جاتے ہیں — اور دونوں صورتیں اصل ڈیٹا میں ملتی ہیں، اکثر ایک ہی کالم میں۔

غیر لاطینی رسم الخط۔ چینی، جاپانی اور کوریائی حروف UTF-8 میں تین تین بائٹس کے ہوتے ہیں۔ ہندی، تھائی، تامل اور عربی ایسے گروپ بناتے ہیں جنہیں پڑھنے والا ایک اکائی سمجھتا ہے اور جو کئی کوڈ پوائنٹس لمبے ہوتے ہیں۔

ریاضی اور موسیقی کی علامات، جو بنیادی رینج سے باہر ہیں اور اس لیے UTF-16 میں دوگنا گنی جاتی ہیں۔

اس کا کیا کریں

وہی چیز گنیں جو آپ کی حد گنتی ہے۔ چاروں نمبر دکھانے والا کاؤنٹر سیدھا جواب دے دیتا ہے، جو اس پر سوچ بچار کرنے سے زیادہ تیز ہے۔ کوڈ میں وہ فنکشن استعمال کریں جو میل کھاتا ہو: JavaScript میں Intl.Segmenter وہ گنتا ہے جو پڑھنے والا دیکھتا ہے، Python میں len(s.encode("utf-8")) بائٹس گنتا ہے، اور PHP میں strlen کی بجائے mb_strlen۔

فارم کی بجائے کالم ٹھیک کریں۔ اگر رکاوٹ ڈیٹا بیس فیلڈ ہے تو پائیدار حل اس سے پہلے ہے: MySQL میں اسے utf8mb4 یا PostgreSQL میں text ڈکلیئر کریں۔ MySQL کا پرانا “utf8” مشہور طور پر فی حرف صرف تین بائٹس کا ہے اور ایموجی بالکل محفوظ نہیں کر سکتا — یہ ایک پرانا جال ہے جس نے بہت سا اصل ڈیٹا خاموشی سے کاٹ دیا ہے۔ فارم پر احتیاط سے گننا اس کالم کا عارضی حل ہے جسے مختلف طریقے سے ڈکلیئر ہونا چاہیے تھا۔

داخل ہوتے وقت نارملائز کریں۔ اندراج کے مقام پر ٹیکسٹ کو ایک ہی نارمل فارم میں بدلنے سے é کی دونوں صورتیں ایک ہو جاتی ہیں، اور موازنہ، ترتیب اور گنتی سب متفق ہونے لگتے ہیں۔ ہر زبان میں اس کا فنکشن موجود ہے، اور سرحد پر ایک بار یہ کرنا ہر جگہ دونوں صورتیں سنبھالنے سے کہیں آسان ہے۔

متعلقہ معاملہ: base64

اس کا ذکر اس لیے ضروری ہے کہ یہ بھی ویسی ہی حیرت پیدا کرتا ہے۔ ڈیٹا کو base64 میں انکوڈ کرنا ایک وقت میں تین بائٹس لے کر انہیں چار حروف کے طور پر لکھتا ہے، اس لیے نتیجہ تقریباً ایک تہائی بڑا ہوتا ہے — یہ حساب ہے، ناکارکردگی نہیں۔ 6 MB کا اٹیچمنٹ تقریباً 8 MB ٹیکسٹ بن جاتا ہے، اسی لیے سائز کی حد سے آرام سے کم فائل بھی بھیجنے کے لیے انکوڈ ہونے کے بعد رد ہو سکتی ہے۔

یہی حساب بتاتا ہے کہ ای میل اٹیچمنٹس ان حدوں پر کیوں واپس آ جاتے ہیں جن پر وہ پورے اترتے دکھائی دیتے ہیں۔ اگر آپ کسی چیز کا سائز کسی حد کے مقابلے میں ناپ رہے ہیں تو انکوڈ شدہ صورت کا سائز ناپیں۔