یونیکوڈ ڈی کوڈر

یونیکوڈ ایسکیپ اور ٹیکسٹ کے درمیان تبدیل کریں، کوڈ پوائنٹس تلاش کریں، اور خراب ٹیکسٹ (mojibake) ٹھیک کریں۔ \uXXXX, \UXXXXXXXX اور &#XXXX; انٹیٹیز معاون ہیں۔ تمام پروسیسنگ آپ کے براؤزر میں ہوتی ہے۔

انکوڈ اور ڈی کوڈ کریکٹر کی معلومات کلائنٹ سائیڈ پروسیسنگ
نتیجہ یہاں نظر آئے گا...

یونیکوڈ ڈی کوڈر استعمال کا طریقہ

1

موڈ منتخب کریں

ڈی کوڈ (ایسکیپ سے ٹیکسٹ) یا انکوڈ (ٹیکسٹ سے ایسکیپ) موڈ چنیں۔

2

ان پٹ دیں

موڈ کے مطابق یونیکوڈ ایسکیپ یا سادہ ٹیکسٹ پیسٹ کریں۔

3

تبدیل کریں

تبدیل کریں پر کلک کریں اور نتیجہ و کریکٹر کی تفصیل دیکھیں۔

یونیکوڈ انکوڈنگ کیا ہے؟

یونیکوڈ انکوڈنگ سے کسی بھی زبان یا علامتی نظام کے کریکٹرز مختلف فارمیٹس میں ظاہر کیے جا سکتے ہیں۔ عام فارمیٹس: \uXXXX (JavaScript/JSON), &#NNNNN; (HTML انٹیٹیز), اور U+XXXX (یونیکوڈ کوڈ پوائنٹس)۔ یہ انکوڈنگ یقینی بناتی ہے کہ ٹیکسٹ مختلف سسٹمز کے درمیان محفوظ طریقے سے منتقل اور دکھایا جا سکے۔

انکوڈنگ فارمیٹس

JavaScript (\uXXXX)

JSON اور JavaScript سٹرنگز میں استعمال

HTML انٹیٹیز (&#XXXX;)

HTML میں خاص کریکٹرز دکھانے کے لیے

CSS ایسکیپ (\XXXXXX)

CSS content اور شناختکاروں میں استعمال

خراب ٹیکسٹ ٹھیک کریں (Mojibake مرمت)

ایک کریکٹر سیٹ میں انکوڈ شدہ ٹیکسٹ دوسرے سیٹ سے ڈی کوڈ ہونے پر خراب ٹیکسٹ (mojibake) بن جاتا ہے۔ عام ترین صورت: UTF-8 بائٹس کو Windows-1252 یا Latin-1 کے طور پر پڑھا جاتا ہے، تو "café" بن جاتا ہے "café" اور "张三" بن جاتا ہے "å¼ ä¸‰"۔ اوپر خراب ٹیکسٹ ٹھیک کریں موڈ پر جائیں، ٹوٹا ٹیکسٹ پیسٹ کریں - ڈی کوڈر ہر کریکٹر کو خام بائٹ مان کر نتیجے کو دوبارہ UTF-8 کے طور پر ڈی کوڈ کرے گا اور اصل کریکٹرز دوبارہ بنائے گا۔

عام خراب ٹیکسٹ کی مثالیں

خراب مرمت شدہ سبب
café café UTF-8 → Latin-1
å¼ ä¸‰ 张三 UTF-8 → Latin-1
“hi†“hi” UTF-8 → double-encoded
ü ö ñ ü ö ñ UTF-8 → Windows-1252
�� � � بائٹس پہلے ہی ضائع (U+FFFD)

اپنی ایپس میں mojibake روکنے کے لیے انکوڈنگ ہمیشہ واضح بتائیں: HTML کو <meta charset="UTF-8"> کے ساتھ پیش کریں، Content-Type: text/html; charset=utf-8 جیسے HTTP ہیڈرز سیٹ کریں، اور ڈیٹابیس و کنکشنز میں مسلسل UTF-8 استعمال کریں۔

UTF-8 بمقابلہ UTF-16 بمقابلہ UTF-32

UTF-8 UTF-16 UTF-32
انکوڈنگ یونٹ 8 bit 16 bit 32 bit
A (U+0041) 41 00 41 00 00 00 41
é (U+00E9) C3 A9 00 E9 00 00 00 E9
中 (U+4E2D) E4 B8 AD 4E 2D 00 00 4E 2D
🎉 (U+1F389) F0 9F 8E 89 D8 3C DF 89 00 01 F3 89
سب سے موزوں برائے ویب، JSON، APIs — ASCII ہم آہنگ اور کمپیکٹ Java, JavaScript, C# میں میموری کا ٹیکسٹ براہ راست کوڈ پوائنٹ رسائی، عملاً نایاب

عام یونیکوڈ کوڈ پوائنٹس

اکثر تلاش کیے جانے والے کریکٹرز کا فوری حوالہ: رموز اوقاف، کرنسی علامات، لہجوں والے حروف اور ریاضی کی علامات، ان کے U+XXXX کوڈ پوائنٹس کے ساتھ۔

رموز اوقاف اور علامات

“U+201C ”U+201D ‘U+2018 ’U+2019
–U+2013 —U+2014 …U+2026  U+A0
©U+A9 ®U+AE ™U+2122 °U+B0

کرنسی کی علامات

€U+20AC £U+A3 ¥U+A5 ₹U+20B9
¢U+A2 ₽U+20BD ₩U+20A9 ฿U+E3F

لہجوں والے حروف

éU+E9 èU+E8 êU+EA üU+FC
öU+F6 ñU+F1 åU+E5 øU+F8
çU+E7 ßU+DF ąU+105 žU+17E

ریاضی اور تیر

±U+B1 ×U+D7 ÷U+F7 ≈U+2248
≠U+2260 ≤U+2264 ≥U+2265 →U+2192
∞U+221E ∑U+2211 √U+221A µU+B5

عام سوالات

کون سے یونیکوڈ ایسکیپ فارمیٹس معاون ہیں؟

یہ ٹول ڈی کوڈنگ کے لیے \uXXXX (BMP), \UXXXXXXXX (مکمل یونیکوڈ), &#DDDD; (اعشاریہ HTML انٹیٹی), &#xHHHH; (ہیکس HTML انٹیٹی), اور U+XXXX (کوڈ پوائنٹ نوریشن) معاون ہے۔

UTF-8 انکوڈنگ کیسے کام کرتی ہے؟

UTF-8 ہر یونیکوڈ کوڈ پوائنٹ کو 1 سے 4 بائٹس میں انکوڈ کرتا ہے۔ ASCII کریکٹرز (U+0000 تا U+007F) 1 بائٹ، لاطینی اور دیگر عام کریکٹرز 2 بائٹس، بیشتر CJK کریکٹرز 3 بائٹس، اور ایموجی و نایاب کریکٹرز 4 بائٹس لیتے ہیں۔

\u اور \U میں کیا فرق ہے؟

\uXXXX چار ہیکس ہندسے استعمال کرتا ہے اور Basic Multilingual Plane کے کریکٹرز (U+0000 تا U+FFFF) ظاہر کر سکتا ہے۔ \UXXXXXXXX آٹھ ہیکس ہندسے استعمال کرتا ہے اور BMP سے آگے والوں سمیت کوئی بھی یونیکوڈ کریکٹر ظاہر کر سکتا ہے۔

میرے ٹیکسٹ میں "é" یا "�" جیسے کریکٹرز کیوں دکھتے ہیں اور کیسے ٹھیک کروں؟

یہ mojibake کی نشانیاں ہیں: UTF-8 بائٹس Windows-1252/Latin-1 کے طور پر ڈی کوڈ ہوئیں۔ "é" کا مطلب ہے "é" کی دو UTF-8 بائٹس (0xC3 0xA9) دو الگ کریکٹرز کے طور پر دکھائی گئیں - ٹھیک کرنے کے لیے خراب ٹیکسٹ ٹھیک کریں موڈ استعمال کریں۔ "�" یعنی U+FFFD، متبادل کریکٹر جو بائٹس پہلے ہی غلط ہونے پر بنتا ہے - وہ معلومات ضائع ہو چکی ہیں، لوٹائی نہیں جا سکتیں۔

UTF-8 اور UTF-16 میں کیا فرق ہے؟

UTF-8 کریکٹرز کو 1–4 بائٹس میں انکوڈ کرتا ہے اور مکمل ASCII ہم آہنگ ہے، اسی لیے ویب، JSON اور بیشتر APIs کا ڈیفالٹ ہے۔ UTF-16 کریکٹرز کو 2 یا 4 بائٹس میں انکوڈ کرتا ہے (U+FFFF سے آگے کے لیے سروگیٹ جوڑے) اور JavaScript, Java اور Windows اندرونی طور پر اسے استعمال کرتے ہیں۔ ویب کے بیشتر ٹیکسٹ کے لیے UTF-8 چھوٹا اور محفوظ ہے۔

کوڈ پوائنٹ اور کوڈ یونٹ میں کیا فرق ہے؟

کوڈ پوائنٹ یونیکوڈ معیار میں کسی کریکٹر کو دی گئی عدد ہے (e-کی تیز آواز کے لیے U+00E9)؛ کوڈ یونٹ وہ اسٹوریج یونٹ ہے جو کوئی انکوڈنگ استعمال کرتی ہے۔ UTF-8 کوڈ یونٹس 8 بٹ بائٹس ہیں - U+00E9 دو لیتا ہے - جبکہ UTF-16 کوڈ یونٹس 16 بٹ ہیں، اور U+FFFF سے آگے کے کریکٹرز دو مانگتے ہیں (سروگیٹ جوڑا)۔ JavaScript سٹرنگز UTF-16 ہیں، اس لیے 'hello'.length ہے 5 مگر ایموجی کا .length ہے 2۔

یونیکوڈ نارملائزیشن فارم کیا ہیں اور کب اہم ہوتے ہیں؟

ایک ہی دکھنے والے کریکٹر کی کئی بائٹ ترتیبیں ہو سکتی ہیں: e-تیز آواز ایک پہلے سے مرکب کریکٹر (NFC) یا e ایک جوڑنے والے لہجے کے ساتھ (NFD)۔ NFC جوڑتا ہے، NFD توڑتا ہے، اور NFKC/NFKD مزید ہم آہنگی کریکٹرز سمیٹتے ہیں (فل-وڈتھ شکلیں، ligature)۔ پہلے نارملائز کیے بغیر صارف ان پٹ کا موازنہ یا hash کرنا ڈپلیکیٹ اکاؤنٹس اور ناکام تلاش کا کلاسیک ذریعہ ہے - fi ligature بمقابلہ f+i۔

BOM کیا ہے اور میری فائلیں کیوں توڑتا ہے؟

بائٹ آرڈر مارک اسٹریم کے شروع میں انکوڈ شدہ U+FEFF ہے (UTF-8 میں EF BB BF) جو انکوڈنگ بتاتا ہے۔ ایڈیٹرز عام طور پر اسے چھپاتے ہیں، مگر آگے جا کر یہ ایک نادیدہ پہلا کریکٹر بن جاتا ہے: CSV ہیڈر میں ایک فرضی key آ جاتی ہے، JSON پارسنگ اجنبی token پر ناکام ہوتی ہے، اور PHP سیشنز ہیڈرز سے پہلے اسے بھیج دیتے ہیں۔ UTF-8 کی بائٹ آرڈر ابہم نہیں، اس لیے BOM ضروری نہیں - اس کے بغیر محفوظ کریں۔

{-- * External Resources Component(#18 Phase 3b 内容佐证工程) * 工具页「权威引用」区块:RFC / W3C / WHATWG / ECMA / IANA / 官方规范站 / Wikipedia。 * * - 接受 :slug 属性 → 经 config/tool-sources.php 家族矩阵渲染该工具的权威引用 * - slug 未命中映射时不渲染(无权威来源的工具静默跳过) * - 链接 title 保持英文(引用源专名);description 经 * common.resources.descriptions.{key} 本地化,lang 未命中回退英文(线上不裸奔) * - 链接保持 dofollow(rel="noopener noreferrer") * * @param string|null $slug --}}