बाइट काउंटर

टेक्स्ट पेस्ट करें और इसका बाइट आकार UTF-8, UTF-16 और ASCII में देखें। डेटाबेस कॉलम सीमा की जाँच के लिए बढ़िया।

परिणाम

टेक्स्ट दर्ज करें और बाइट्स गिनें पर क्लिक करें।

यह कैसे काम करता है

  1. टेक्स्ट दर्ज या पेस्ट करें: इनपुट फ़ील्ड में कोई भी टेक्स्ट टाइप या पेस्ट करें।
  2. बाइट गणना देखें: टूल तुरंत UTF-8, UTF-16, ASCII और अन्य एन्कोडिंग में बाइट गणना को साथ-साथ दिखाता है।
  3. सीमाएँ जाँचें: यह देखने के लिए कि आपकी सामग्री फिट है या नहीं, बाइट गणना की तुलना सामान्य सीमाओं (SMS: 160 वर्ण, HTTP headers: 8 KB, डेटाबेस फ़ील्ड आदि) से करें।

बाइट काउंटर क्यों उपयोग करें?

वर्ण गणना और बाइट गणना समान नहीं हैं। एक एकल इमोजी UTF-8 में 4 बाइट्स हो सकता है। चीनी और अरबी वर्ण प्रत्येक 2-3 बाइट्स लेते हैं। कई सिस्टम बाइट सीमा लागू करते हैं, वर्ण सीमा नहीं, जिसमें MySQL VARCHAR फ़ील्ड, Redis मान, HTTP headers, SMS संदेश और क्लाउड स्टोरेज ऑब्जेक्ट नाम शामिल हैं। बाइट काउंटर प्रत्येक एन्कोडिंग में आपके टेक्स्ट का वास्तविक बाइट आकार प्रकट करता है ताकि आप सिस्टम की बाधाओं के भीतर रह सकें।

विशेषताएँ

अक्सर पूछे जाने वाले प्रश्न

मेरी बाइट गणना मेरी वर्ण गणना से बड़ी क्यों है?

UTF-8 में कई वर्ण 1 बाइट से अधिक लेते हैं। ASCII वर्ण (A-Z, 0-9, विराम चिह्न) प्रत्येक 1 बाइट हैं। लैटिन-विस्तारित वर्ण (उच्चारण वाले अक्षर) 2 बाइट हैं। चीनी, जापानी, कोरियाई और अरबी वर्ण आमतौर पर 3 बाइट होते हैं। इमोजी आमतौर पर 4 बाइट होते हैं।

अधिकांश वेब सिस्टम किस एन्कोडिंग का उपयोग करते हैं?

UTF-8 वेब सामग्री, APIs, JSON और डेटाबेस के लिए प्रमुख एन्कोडिंग है। MySQL और PostgreSQL डिफ़ॉल्ट रूप से UTF-8 का उपयोग करते हैं। बाइट सीमाओं की जाँच करते समय, UTF-8 कॉलम का उपयोग करें जब तक कि आपका सिस्टम अन्यथा निर्दिष्ट न करे।

SMS संदेशों की 160-वर्ण सीमा क्यों है?

पारंपरिक SMS 7-bit GSM एन्कोडिंग का उपयोग करता है, जो प्रति सेगमेंट 160 वर्णों की अनुमति देता है। जब आप कोई गैर-GSM वर्ण (जैसे स्मार्ट उद्धरण, इमोजी, या गैर-लैटिन अक्षर) शामिल करते हैं, तो संदेश UCS-2 एन्कोडिंग में बदल जाता है, जो सीमा को प्रति सेगमेंट 70 वर्णों तक कम कर देता है।

बाइट वास्तव में क्या है?

एक बाइट 8 बिट होता है, जो 256 अलग-अलग मान धारण कर सकता है। टेक्स्ट में, ये 256 मान एक एन्कोडिंग के माध्यम से वर्णों से मैप होते हैं, एक नियम पुस्तक जो कहती है «यह बाइट अनुक्रम इस वर्ण के बराबर है»। एक ही बाइट स्ट्रिंग का अर्थ विभिन्न एन्कोडिंग के तहत पूरी तरह से अलग टेक्स्ट हो सकता है: बाइट 0xE9 Latin-1 में «é» है, UTF-8 में 3-बाइट अनुक्रम की शुरुआत, या UTF-16 कोड यूनिट का भाग। एन्कोडिंग ही पूरी कहानी है।

जब आप टेक्स्ट को डिस्क पर सहेजते हैं, नेटवर्क पर भेजते हैं, या डेटाबेस में संग्रहीत करते हैं, जो वास्तव में बना रहता है वह बाइट है, वर्ण नहीं। टेक्स्ट संपादक में आप जो वर्ण गणना देखते हैं वह प्रदर्शन समय पर गणना की जाती है, बाइट डिकोड होने के बाद। एक तरफ या दूसरी तरफ एन्कोडिंग मेल नहीं खाता है तो आपको मोजीबेक मिलता है: गलत एन्कोडिंग के साथ डिकोड किया गया टेक्स्ट बकवास के रूप में दिखाई देता है (क्लासिक é के बजाय é जब Windows-1252 बाइट को UTF-8 के रूप में पढ़ा जाता है)।

बाइट गिनती वह है जो डेटाबेस कॉलम सीमाएं, HTTP हेडर बफ़र, SMS पेलोड और क्लाउड स्टोरेज ऑब्जेक्ट कुंजियाँ सभी मापते हैं, चाहे टेक्स्ट «कैसा दिखता है» कुछ भी हो। यह काउंटर चार एन्कोडिंग में बाइट आकार की रिपोर्ट करता है जिनके बारे में आप सबसे अधिक चिंतित होंगे: UTF-8 (आधुनिक डिफ़ॉल्ट), UTF-16 (Windows / Java / JavaScript आंतरिक प्रारूप), ASCII (केवल अंग्रेजी लैटिन टेक्स्ट के लिए वैध), और Latin-1 (एक एकल-बाइट विरासत फ़ॉलबैक)। साइड पर वर्ण गणना संदर्भ के लिए दी गई है।

UTF-8: कहानी

UTF-8 को केन थॉम्पसन और रॉब पाइक ने बेल लैब्स में, 2 सितंबर 1992 की रात रेखांकित किया था, कथित तौर पर न्यू जर्सी के एक डिनर में एक प्लेसमैट पर, जब प्लान 9 टीम को Unicode के लिए ASCII-संगत परिवर्तनीय-लंबाई एन्कोडिंग की आवश्यकता थी। डिज़ाइन में तीन गुण हैं जो लगभग कुछ और एक साथ नहीं रखता: ASCII टेक्स्ट भी मान्य UTF-8 है (प्रति वर्ण 1 बाइट, समान बाइट), एन्कोडिंग स्व-सिंक्रनाइज़िंग है (किसी भी बाइट के उच्च बिट आपको बताते हैं कि यह एक नया वर्ण शुरू करता है या मौजूदा जारी रखता है), और कोई बाइट-क्रम अस्पष्टता नहीं है। ये तीन गुण मिलकर समझाते हैं कि वेब पर UTF-8 ने सभी प्रतिस्पर्धी एन्कोडिंग को क्यों विस्थापित कर दिया।

इसे पहली बार RFC 2044 अक्टूबर 1996 में मानकीकृत किया गया, जनवरी 1998 में RFC 2279 के रूप में संशोधित, और वर्तमान RFC 3629 (नवंबर 2003) से बदला, जिसने UTF-8 को प्रति वर्ण अधिकतम 4 बाइट तक सीमित कर दिया ताकि Unicode की अंतिम कोड-बिंदु छत U+10FFFF से मेल खाए। W3Techs ने 2010 से सार्वजनिक वेब पर एन्कोडिंग उपयोग को लगातार ट्रैक किया है; UTF-8 2011 में 56% वेबसाइटों से बढ़कर लगभग 2026 में 98% हो गया। HTML5 विनिर्देश नई सामग्री के लिए UTF-8 अनिवार्य करता है; HTTP/2 और HTTP/3 HPACK / QPACK के माध्यम से UTF-8 में हेडर भेजते हैं; RFC 8259 सिस्टम के बीच JSON आदान-प्रदान के लिए UTF-8 अनिवार्य करता है। यदि आपको हर चीज़ के लिए एक एन्कोडिंग चुननी है, तो पिछले 15 वर्षों का उत्तर UTF-8 रहा है और अगले 15 वर्षों का उत्तर भी वही होगा।

UTF-8 परिवर्तनीय-लंबाई है, प्रति वर्ण 1 से 4 बाइट तक:

कोड-बिंदु श्रेणी बाइट विशिष्ट सामग्री
U+0000 – U+007F1ASCII अक्षर, अंक, सामान्य विराम चिह्न
U+0080 – U+07FF2लैटिन-विस्तारित (é, ñ), ग्रीक, सिरिलिक, अरबी, हिब्रू
U+0800 – U+FFFF3अधिकांश CJK विचारलिपियाँ, देवनागरी, थाई, हंगुल, € प्रतीक
U+10000 – U+10FFFF4इमोजी, पूरक CJK, ऐतिहासिक लिपियाँ

व्यावहारिक परिणाम: UTF-8 में अंग्रेजी टेक्स्ट औसतन प्रति वर्ण ~1 बाइट; चीनी ~3 बाइट; इमोजी से भरा संदेश प्रति दृश्य वर्ण 4 बाइट तक पहुँच सकता है, और संयुक्त इमोजी (फ़ैमिली ZWJ अनुक्रम) आसानी से जो एक वर्ण जैसा दिखता है उसके लिए 20-30 बाइट तक पहुँच जाते हैं।

UTF-16 और सरोगेट जाल

UTF-16 Windows NT (1993), Java 1.0 (1996), JavaScript (1995), .NET और Mac OS X Cocoa NSString के लिए पसंदीदा एन्कोडिंग था। यह बेसिक मल्टीलिंगुअल प्लेन (U+0000 – U+FFFF) में प्रत्येक वर्ण के लिए 2 बाइट का उपयोग करता है, और इसके बाहर किसी भी चीज़ के लिए सरोगेट जोड़े: एक उच्च सरोगेट (D800–DBFF) प्लस एक निम्न सरोगेट (DC00–DFFF), कुल 4 बाइट। UTF-16 को डिस्क पर बिग-एंडियन (UTF-16BE, FE FF) और लिटिल-एंडियन (UTF-16LE, FF FE) के बीच अंतर करने के लिए बाइट-क्रम चिह्न (BOM) की आवश्यकता होती है; Windows डिफ़ॉल्ट रूप से लिटिल-एंडियन का उपयोग करता है।

जाल: JavaScript में, "😀".length === 2। MDN सीधे कहता है: length गुण «स्ट्रिंग की लंबाई UTF-16 कोड इकाइयों में रखता है»। यही कारण है कि 😄 जैसा एक एकल इमोजी 2 की लंबाई की रिपोर्ट करता है (यह पूरक प्लेन में रहता है और सरोगेट जोड़ी की आवश्यकता है), और फ़ैमिली ZWJ अनुक्रम 👨‍👩‍👧‍👦 11 की लंबाई की रिपोर्ट करता है (चार 2-कोड-इकाई इमोजी प्लस तीन शून्य-चौड़ाई जोड़ने वाले)। एक ही एकल-वर्ण फ़ैमिली इमोजी प्रत्येक भाषा के स्ट्रिंग मॉडल के आधार पर JavaScript में 11, Python 3 में 5, और Swift में 1 के रूप में गिना जाता है। JavaScript में सही दृश्य-वर्ण गणना के लिए, ग्राफीम ग्रैन्युलैरिटी के साथ Intl.Segmenter का उपयोग करें (2021 से प्रत्येक एवरग्रीन ब्राउज़र)।

ASCII, Latin-1 और Unicode-पूर्व अव्यवस्था

ASCII (American Standard Code for Information Interchange) को ASA X3.4-1963 के रूप में मानकीकृत किया गया था, X3.4-1968 के रूप में संशोधित और फिर ANSI X3.4-1986 के रूप में। 7-बिट कोड, 128 वर्ण: 95 मुद्रण योग्य प्लस 33 नियंत्रण। 33 नियंत्रण वर्णों में BEL, BS, CR, LF, DEL जैसी टेलीटाइप विरासतें और कुछ शामिल हैं जो आधुनिक प्रोटोकॉल में जीवित रहते हैं (NUL, TAB, LF, CR, ESC)। ASCII अभी भी UTF-8 के एक सख्त उपसमुच्चय के रूप में काम करता है, यही कारण है कि «शुद्ध ASCII टेक्स्ट» भी मान्य UTF-8 है और केवल-अंग्रेजी सिस्टम के लिए UTF-8 में स्थानांतरण दर्द रहित क्यों था।

Latin-1 / ISO-8859-1 (1987) एक एकल-बाइट 256-वर्ण विस्तार था जिसने पश्चिमी यूरोपीय उच्चारित अक्षर, मुद्रा प्रतीक और सामान्य विराम चिह्न जोड़े। यह 1995 से लगभग 2008 तक पश्चिमी वेब सामग्री के लिए वास्तविक एन्कोडिंग था जब तक कि UTF-8 ने इसे विस्थापित नहीं किया। Windows-1252 Latin-1 का Microsoft का सुपरसेट है, जो C1 नियंत्रण श्रेणी (0x80-0x9F) में «स्मार्ट उद्धरण», em-डैश और यूरो प्रतीक जोड़ता है; जब CSV फ़ाइलें Mac और Windows के बीच ईमेल की जाती हैं, यह क्लासिक é मोजीबेक का स्रोत है जब एक तरफ Windows-1252 बाइट को UTF-8 के रूप में पढ़ता है।

MySQL «utf8» जाल

MySQL में संस्करण 4.1 से एक कुख्यात वर्ण-सेट दोष है: utf8 वर्ण-सेट उपनाम वास्तव में UTF-8 नहीं है। यह एक अधिकतम 3-बाइट उपसमुच्चय है जो U+FFFF से ऊपर के वर्णों का प्रतिनिधित्व नहीं कर सकता, जिसका अर्थ है कि यह इमोजी या पूरक प्लेन वर्ण संग्रहीत नहीं कर सकता। utf8 कॉलम में «🎉» डालने से sql_mode के आधार पर «?» या एक त्रुटि उत्पन्न होती है। समाधान utf8mb4 है, जो MySQL 5.5.3 (मार्च 2010) में जोड़ा गया; MySQL 8.0 (अप्रैल 2018) ने utf8mb4 को नया डिफ़ॉल्ट बनाया। लेकिन 8.0 से पहले बनाए गए स्कीमा अक्सर अभी भी डिफ़ॉल्ट रूप से 3-बाइट संस्करण का उपयोग करते हैं। यदि आप उपयोगकर्ता इनपुट से इमोजी चुपचाप गायब होते देखते हैं, तो यह लगभग हमेशा कारण है। PostgreSQL में एक समान जाल नहीं है, यह वास्तविक UTF-8 को मूल रूप से स्वीकार करता है।

SMS, GSM-7 और 160-बाइट पेलोड

160-वर्ण SMS सीमा 1985 में Friedhelm Hillebrand की गणना तक जाती है, जो GSM कार्य पार्टी के एक इंजीनियर थे, जिन्होंने कथित तौर पर अपनी टाइपराइटर पर बैठकर, यादृच्छिक वाक्य टाइप किए, और गिना कि «अधिकांश संदेश 160 वर्णों या उससे कम में व्यक्त किए जा सकते हैं»। 160 को फिर 7-बिट वर्णमाला का उपयोग करके 140-बाइट पेलोड में फिट करने के लिए पीछे से व्युत्पन्न किया गया था (140 × 8 ÷ 7 = 160)। एन्कोडिंग विवरण 3GPP TS 23.038 (मूल रूप से GSM 03.38) में औपचारिक रूप से लिखे गए हैं, और वे आज भी SMS बिलिंग को नियंत्रित करते हैं।

बाइट में: एक एकल SMS तार पर 140 बाइट है। GSM-7 के साथ यह 160 वर्ण है; UCS-2 (एक 2-बाइट निश्चित-चौड़ाई एन्कोडिंग जो GSM-7 वर्णमाला के बाहर किसी भी चीज़ के लिए उपयोग की जाती है) के साथ यह 70 है। मल्टी-पार्ट संदेश पुनः-संयोजन के लिए उपयोग किए गए उपयोगकर्ता डेटा हेडर (User Data Header) में प्रति सेगमेंट 7 GSM-7 वर्ण या 3 UCS-2 वर्ण खो देते हैं, इसलिए लंबे संदेश 153 GSM-7 वर्ण प्रति सेगमेंट या 67 UCS-2 वर्ण प्रति सेगमेंट पर सीमित होते हैं। एक स्मार्ट उद्धरण, em-डैश, या इमोजी पूरे संदेश को UCS-2 में डाउनग्रेड करता है और प्रति-सेगमेंट सीमा को आधा कर देता है। Twilio का «Smart Encoding» मार्केटिंग अभियानों को सस्ते एन्कोडिंग में रखने के लिए घुमावदार उद्धरणों को सीधे के साथ स्वचालित रूप से बदल देता है।

बाइट सीमाएँ वास्तव में कहाँ काटती हैं

तीन श्रेणियाँ जहाँ बाइट (वर्ण नहीं) सीमाएँ आपको पकड़ लेंगी:

HTTP अनुरोध हेडर। कोई औपचारिक स्पेक अधिकतम नहीं, हर सर्वर एक लागू करता है। Apache का LimitRequestFieldSize डिफ़ॉल्ट प्रति हेडर 8 KB है; Nginx के large_client_header_buffers डिफ़ॉल्ट 4 × 8 KB हैं; IIS डिफ़ॉल्ट 16 KB है; AWS Application Load Balancer प्रति हेडर 16 KB और कुल 60 KB स्वीकार करता है; Cloudflare 32 KB की अनुमति देता है। फुलाए हुए दावा सेट वाले JWT नियमित रूप से Apache के 8 KB डिफ़ॉल्ट से अधिक होते हैं, जो टोकन-आधारित प्रमाणीकरण के लिए सबसे आम उत्पादन विफलता मोड है।

क्लाउड ऑब्जेक्ट स्टोरेज कुंजियाँ। S3 और GCS दोनों ऑब्जेक्ट कुंजियों को 1024 बाइट UTF-8 तक सीमित करते हैं। Azure Blob Storage ब्लॉब नामों को 1024 वर्णों (आंतरिक UTF-16) तक सीमित करता है। S3 के लिए, एक CJK-भारी फ़ाइल नाम (प्रति वर्ण 3 बाइट) ~341 वर्णों पर शीर्ष करता है; एक इमोजी-भारी (प्रति वर्ण 4 बाइट) ~256 पर, डेवलपर के अपेक्षा से बहुत पहले।

डेटाबेस पंक्ति और इंडेक्स सीमाएँ। MySQL InnoDB में DYNAMIC पंक्ति प्रारूप पर 65,535-बाइट पंक्ति आकार और 3072-बाइट इंडेक्स कुंजी-उपसर्ग सीमा है (पुराने COMPACT पर 767)। एक VARCHAR(255) utf8mb4 कॉलम को 1020 बाइट (255 × 4) इंडेक्स स्थान की आवश्यकता होती है, DYNAMIC पर ठीक, COMPACT पर टूटा हुआ। MongoDB BSON दस्तावेज़ 16 MB पर शीर्ष करते हैं। DynamoDB आइटम 400 KB (विशेषता नामों सहित) पर शीर्ष करते हैं। Redis मान 512 MB पर शीर्ष करते हैं।

सामान्य उपयोग के मामले

सामान्य गलतियाँ

  1. बाइट आकार के लिए JavaScript के .length पर भरोसा करना। .length UTF-16 कोड यूनिट देता है, बाइट नहीं और वर्ण नहीं। UTF-8 बाइट के लिए, new TextEncoder().encode(text).length का उपयोग करें; दृश्य वर्णों के लिए, Intl.Segmenter का उपयोग करें।
  2. यह मानना कि MySQL utf8 वास्तव में UTF-8 है। यह एक 3-बाइट उपसमुच्चय है जो चुपचाप इमोजी को छोड़ देता है। हमेशा उपयोगकर्ता-द्वारा-प्रस्तुत टेक्स्ट को स्पर्श करने वाले किसी भी कॉलम पर utf8mb4 (और कोलेशन के लिए utf8mb4_unicode_ci) का उपयोग करें।
  3. यह मानना कि एक इमोजी एक बाइट के बराबर है। एक एकल इमोजी UTF-8 में 4 बाइट, UTF-16 में 4 बाइट (सरोगेट जोड़ी) है। एक फ़ैमिली ZWJ अनुक्रम जो एक वर्ण जैसा दिखता है उसके लिए 30 बाइट से अधिक हो सकता है।
  4. सामग्री के रूप में UTF-8 BOM की गिनती। फ़ाइल की शुरुआत में तीन-बाइट UTF-8 BOM EF BB BF मेटाडेटा है, टेक्स्ट नहीं। अधिकांश CLI उपकरण (awk, head, sed) इसे पहले फ़ील्ड के भाग के रूप में व्यवहार करते हैं, जो कई «मेरे पहले कॉलम नाम में एक अजीब वर्ण क्यों है» बग का स्रोत है।
  5. गैर-ASCII टेक्स्ट के लिए «ASCII बाइट» गिनती रिपोर्ट करना। ASCII U+007F से ऊपर के वर्णों का प्रतिनिधित्व नहीं कर सकता। यह काउंटर तब चेतावनी देता है जब इनपुट में गैर-ASCII होता है ताकि आप जान सकें कि ASCII कॉलम सार्थक नहीं है।

अधिक अक्सर पूछे जाने वाले प्रश्न

जब टेक्स्ट वर्ण केवल 1 बाइट हैं तो एक इमोजी 4 बाइट क्यों है?

UTF-8 ASCII (U+0000 से U+007F) के लिए 1 बाइट, लैटिन-विस्तारित / ग्रीक / सिरिलिक / अरबी / हिब्रू (U+0080 से U+07FF) के लिए 2 बाइट, अधिकांश CJK और भारतीय लिपियों (U+0800 से U+FFFF) के लिए 3 बाइट, और इमोजी और पूरक प्लेन वर्णों (U+10000 से U+10FFFF) के लिए 4 बाइट का उपयोग करता है। 😀 (U+1F600) जैसा एक विशिष्ट इमोजी पूरक प्लेन में है और 4 बाइट खर्च करता है। संयुक्त इमोजी (जैसे फ़ैमिली 👨‍👩‍👧‍👦) कई बेस इमोजी को शून्य-चौड़ाई जोड़ने वालों के साथ एक साथ चिपकाकर बनाए गए हैं; प्रत्येक बेस इमोजी 4 बाइट है, प्रत्येक जोड़ने वाला 3 बाइट है, इसलिए 4 की फ़ैमिली 4×4 + 3×3 = 25 बाइट लेती है जो एक वर्ण जैसा दिखता है।

MySQL utf8 का वास्तव में क्या मतलब है?

MySQL में, वर्ण-सेट उपनाम utf8 वास्तविक UTF-8 का अधिकतम 3-बाइट उपसमुच्चय है। यह Unicode बेसिक मल्टीलिंगुअल प्लेन में हर वर्ण को एन्कोड कर सकता है लेकिन इमोजी या U+FFFF से ऊपर का कोई वर्ण संग्रहीत नहीं कर सकता। MySQL में वास्तविक 4-बाइट UTF-8 utf8mb4 है, MySQL 5.5.3 (मार्च 2010) से उपलब्ध, MySQL 8.0 (अप्रैल 2018) से डिफ़ॉल्ट। यदि आप स्कीमा बदल सकते हैं, तो हमेशा utf8mb4_0900_ai_ci कोलेशन (या पुराने सर्वर पर utf8mb4_unicode_ci) के साथ utf8mb4 का उपयोग करें।

क्या इस काउंटर में UTF-8 बाइट-क्रम चिह्न शामिल है?

नहीं। UTF-8 बाइट-क्रम चिह्न तीन बाइट EF BB BF है जो Windows पर Excel को UTF-8 का पता लगाने के लिए फ़ाइल की शुरुआत में चाहिए। काउंटर आपके द्वारा चिपकाए गए टेक्स्ट के बाइट को मापता है; यदि आपका टेक्स्ट BOM से शुरू होता है, तो उन तीन बाइट को सामग्री के रूप में गिना जाता है। यदि आप जानना चाहते हैं कि आपकी फ़ाइल के बाइट सीमा तक पहुँचेंगे या नहीं, फ़ाइल का केवल मुख्य भाग चिपकाएँ, BOM नहीं।

मेरा चीनी टेक्स्ट UTF-8 में प्रति वर्ण 3 बाइट क्यों दिखाता है?

लगभग सभी CJK विचारलिपियाँ Unicode श्रेणी U+4E00 से U+9FFF (CJK Unified Ideographs ब्लॉक) में बैठती हैं, जिसे UTF-8 प्रत्येक 3 बाइट के रूप में एन्कोड करता है। एक 100-वर्ण चीनी वाक्य इसलिए 300 UTF-8 बाइट है। UTF-16 में वही टेक्स्ट 200 बाइट है (प्रति वर्ण 2 बाइट), इसलिए मुख्य रूप से-CJK सामग्री के लिए UTF-16 अधिक कॉम्पैक्ट है। मिश्रित लैटिन-और-CJK सामग्री के लिए UTF-8 जीतता है क्योंकि लैटिन वर्णों की कीमत 2 के बजाय प्रत्येक 1 बाइट है।

क्या मेरा टेक्स्ट कहीं अपलोड किया जाता है?

नहीं। बाइट काउंटर पूरी तरह से आपके ब्राउज़र में चलता है। UTF-8 बाइट गिनती मानक TextEncoder API से आती है (प्रत्येक आधुनिक ब्राउज़र इसका समर्थन करता है), UTF-16 और Latin-1 गिनती सरल लूप से आती है। कोई नेटवर्क अनुरोध नहीं, कोई सर्वर कॉल नहीं, कोई लॉगिंग नहीं। एक बार पृष्ठ लोड हो जाने पर, उपकरण ऑफ़लाइन काम करता है। API टोकन, आंतरिक डेटा या किसी भी चीज़ का निरीक्षण करने के लिए सुरक्षित जिसे आप तृतीय-पक्ष टेक्स्ट काउंटर में चिपकाएँगे नहीं।

संबंधित टूल

वर्ण काउंटर मुफ़्त शब्द और वर्ण काउंटर ऑनलाइन पठन समय कैलकुलेटर स्ट्रिंग हैश विज़ुअलाइज़र