మీరు డెవలపర్ అయితే మరియు మీరు ఎన్‌కోడింగ్‌ను ఎంచుకునే పనిని ఎదుర్కొంటున్నట్లయితే, యూనికోడ్ దాదాపు ఎల్లప్పుడూ సరైన పరిష్కారంగా ఉంటుంది. నిర్దిష్ట ప్రాతినిధ్య పద్ధతి సందర్భంపై ఆధారపడి ఉంటుంది, కానీ చాలా తరచుగా ఇక్కడ కూడా సార్వత్రిక సమాధానం ఉంది - UTF-8. దాని గురించి మంచి విషయం ఏమిటంటే ఇది ఖర్చు లేకుండా అన్ని యూనికోడ్ అక్షరాలను ఉపయోగించడానికి మిమ్మల్ని అనుమతిస్తుంది చాలా ఎక్కువ చాలా సందర్భాలలో చాలా బైట్లు. నిజమే, లాటిన్ వర్ణమాల కంటే ఎక్కువగా ఉపయోగించే భాషల కోసం, "చాలా ఎక్కువ కాదు" కనీసం ఒక్కో అక్షరానికి రెండు బైట్లు. కేవలం 256 అందుబాటులో ఉన్న అక్షరాలకు పరిమితం చేసే చరిత్రపూర్వ ఎన్‌కోడింగ్‌లకు తిరిగి రాకుండా మనం మెరుగ్గా చేయగలమా?
ఈ ప్రశ్నకు సమాధానం ఇవ్వడానికి మరియు UTF-8లో ఉన్న రిడెండెన్సీని జోడించకుండా ప్రపంచంలోని చాలా భాషలలో లైన్‌లను నిల్వ చేయడానికి మిమ్మల్ని అనుమతించే సాపేక్షంగా సరళమైన అల్గారిథమ్‌ని అమలు చేయడానికి నా ప్రయత్నాన్ని మీకు పరిచయం చేయాలని నేను క్రింద ప్రతిపాదించాను.
నిరాకరణ. నేను వెంటనే కొన్ని ముఖ్యమైన రిజర్వేషన్లు చేస్తాను: వివరించిన పరిష్కారం UTF-8కి సార్వత్రిక ప్రత్యామ్నాయంగా అందించబడలేదు, ఇది కేసుల యొక్క ఇరుకైన జాబితాలో మాత్రమే అనుకూలంగా ఉంటుంది (క్రింద ఉన్న వాటిపై మరిన్ని), మరియు ఎట్టి పరిస్థితుల్లోనూ మూడవ పక్ష APIలతో (దీని గురించి తెలియని వారికి) పరస్పర చర్య చేయడానికి దీనిని ఉపయోగించకూడదు. చాలా తరచుగా, సాధారణ-ప్రయోజన కంప్రెషన్ అల్గారిథమ్‌లు (ఉదాహరణకు, డీఫ్లేట్) పెద్ద వాల్యూమ్‌ల టెక్స్ట్ డేటా యొక్క కాంపాక్ట్ స్టోరేజ్‌కు అనుకూలంగా ఉంటాయి. అదనంగా, ఇప్పటికే నా పరిష్కారాన్ని రూపొందించే ప్రక్రియలో, నేను యూనికోడ్‌లోనే ఇప్పటికే ఉన్న ప్రమాణాన్ని కనుగొన్నాను, ఇది అదే సమస్యను పరిష్కరిస్తుంది - ఇది కొంత క్లిష్టంగా ఉంటుంది (మరియు తరచుగా అధ్వాన్నంగా ఉంటుంది), కానీ ఇప్పటికీ ఇది ఆమోదించబడిన ప్రమాణం మరియు కేవలం ఉంచబడలేదు మోకాలిపై కలిసి. అతని గురించి కూడా చెబుతాను.
యూనికోడ్ మరియు UTF-8 గురించి
ప్రారంభించడానికి, అది ఏమిటో గురించి కొన్ని మాటలు యూనికోడ్ и UTF-8.
మీకు తెలిసినట్లుగా, 8-బిట్ ఎన్‌కోడింగ్‌లు జనాదరణ పొందాయి. వారితో, ప్రతిదీ చాలా సులభం: 256 అక్షరాలను 0 నుండి 255 వరకు సంఖ్యలతో లెక్కించవచ్చు మరియు 0 నుండి 255 వరకు ఉన్న సంఖ్యలను స్పష్టంగా ఒక బైట్‌గా సూచించవచ్చు. మేము ప్రారంభానికి తిరిగి వెళితే, ASCII ఎన్కోడింగ్ పూర్తిగా 7 బిట్‌లకు పరిమితం చేయబడింది, కాబట్టి దాని బైట్ ప్రాతినిధ్యంలో అత్యంత ముఖ్యమైన బిట్ సున్నా, మరియు చాలా 8-బిట్ ఎన్‌కోడింగ్‌లు దానికి అనుకూలంగా ఉంటాయి (అవి “ఎగువ”లో మాత్రమే విభిన్నంగా ఉంటాయి. భాగం, ఇక్కడ అత్యంత ముఖ్యమైన బిట్ ఒకటి ).
ఆ ఎన్‌కోడింగ్‌ల నుండి యూనికోడ్ ఎలా భిన్నంగా ఉంటుంది మరియు దానితో చాలా నిర్దిష్ట ప్రాతినిధ్యాలు ఎందుకు అనుబంధించబడ్డాయి - UTF-8, UTF-16 (BE మరియు LE), UTF-32? దానిని క్రమంలో క్రమబద్ధీకరించుదాం.
ప్రాథమిక యూనికోడ్ ప్రమాణం అక్షరాలు (మరియు కొన్ని సందర్భాల్లో, అక్షరాల యొక్క వ్యక్తిగత భాగాలు) మరియు వాటి సంఖ్యల మధ్య అనురూప్యాన్ని మాత్రమే వివరిస్తుంది. మరియు ఈ ప్రమాణంలో చాలా సాధ్యమైన సంఖ్యలు ఉన్నాయి - నుండి 0x00 కు 0x10FFFF (1 ముక్కలు). మనం అటువంటి పరిధిలో ఉన్న సంఖ్యను వేరియబుల్‌లో ఉంచాలనుకుంటే, మనకు 114 లేదా 112 బైట్లు సరిపోవు. మరియు మా ప్రాసెసర్‌లు త్రీ-బైట్ నంబర్‌లతో పనిచేయడానికి పెద్దగా రూపొందించబడలేదు కాబట్టి, మేము ఒక్కో అక్షరానికి 1 బైట్‌లను ఉపయోగించాల్సి వస్తుంది! ఇది UTF-2, కానీ ఖచ్చితంగా ఈ "వ్యర్థత" కారణంగా ఈ ఫార్మాట్ ప్రజాదరణ పొందలేదు.
అదృష్టవశాత్తూ, యూనికోడ్‌లోని అక్షరాల క్రమం యాదృచ్ఛికంగా లేదు. వారి మొత్తం సెట్ 17 "గా విభజించబడిందివిమానాలు", వీటిలో ప్రతి ఒక్కటి 65536 (0x10000) "కోడ్ పాయింట్లు" ఇక్కడ "కోడ్ పాయింట్" భావన కేవలం ఉంది అక్షర సంఖ్య, దీనికి యూనికోడ్ ద్వారా కేటాయించబడింది. కానీ, పైన చెప్పినట్లుగా, యూనికోడ్‌లో వ్యక్తిగత అక్షరాలు మాత్రమే కాకుండా, వాటి భాగాలు మరియు సేవా గుర్తులు కూడా లెక్కించబడతాయి (మరియు కొన్నిసార్లు ఏమీ సంఖ్యకు అనుగుణంగా ఉండదు - బహుశా ప్రస్తుతానికి, కానీ మాకు ఇది అంత ముఖ్యమైనది కాదు), కాబట్టి ఇది మరింత సరైనది ఎల్లప్పుడూ సంఖ్యల సంఖ్య గురించి ప్రత్యేకంగా మాట్లాడుతుంది మరియు చిహ్నాల గురించి కాదు. అయితే, కింది వాటిలో, సంక్షిప్తత కోసం, నేను తరచుగా "కోడ్ పాయింట్" అనే పదాన్ని సూచిస్తూ "చిహ్నం" అనే పదాన్ని ఉపయోగిస్తాను.
యూనికోడ్ విమానాలు. మీరు చూడగలిగినట్లుగా, చాలా వరకు (4 నుండి 13 విమానాలు) ఇప్పటికీ ఉపయోగించబడలేదు.
చాలా విశేషమైన విషయం ఏమిటంటే, అన్ని ప్రధాన "గుజ్జు" సున్నా సమతలంలో ఉంటుంది, దీనిని ""ప్రాథమిక బహుభాషా విమానం". ఒక లైన్ ఆధునిక భాషలలో (చైనీస్‌తో సహా) వచనాన్ని కలిగి ఉంటే, మీరు ఈ విమానం దాటి వెళ్లలేరు. కానీ మీరు మిగిలిన యూనికోడ్‌ను కూడా కత్తిరించలేరు - ఉదాహరణకు, ఎమోజీలు ప్రధానంగా చివరిలో ఉంటాయి తదుపరి విమానం,"అనుబంధ బహుభాషా విమానం"(ఇది నుండి విస్తరించింది 0x10000 కు 0x1FFFF) కాబట్టి UTF-16 ఇలా చేస్తుంది: అన్ని అక్షరాలు లోపల వస్తాయి ప్రాథమిక బహుభాషా విమానం, సంబంధిత రెండు-బైట్ సంఖ్యతో "ఉన్నట్లుగా" ఎన్కోడ్ చేయబడతాయి. అయితే, ఈ శ్రేణిలోని కొన్ని సంఖ్యలు నిర్దిష్ట అక్షరాలను సూచించవు, కానీ ఈ జత బైట్‌ల తర్వాత మనం మరొకదాన్ని పరిగణించాల్సిన అవసరం ఉందని సూచిస్తుంది - ఈ నాలుగు బైట్‌ల విలువలను కలపడం ద్వారా, మేము కవర్ చేసే సంఖ్యను పొందుతాము మొత్తం చెల్లుబాటు అయ్యే యూనికోడ్ పరిధి. ఈ ఆలోచనను "సర్రోగేట్ జంటలు" అని పిలుస్తారు-మీరు వారి గురించి విని ఉండవచ్చు.
కాబట్టి UTF-16కి "కోడ్ పాయింట్"కి రెండు లేదా (చాలా అరుదైన సందర్భాలలో) నాలుగు బైట్లు అవసరం. ఎల్లవేళలా నాలుగు బైట్‌లను ఉపయోగించడం కంటే ఇది ఉత్తమం, అయితే లాటిన్ (మరియు ఇతర ASCII అక్షరాలు) ఈ విధంగా ఎన్కోడ్ చేసినప్పుడు సున్నాలపై సగం స్థలాన్ని వృధా చేస్తుంది. UTF-8 దీన్ని సరిచేయడానికి రూపొందించబడింది: దీనిలోని ASCII మునుపటిలాగా ఒక బైట్‌ను మాత్రమే ఆక్రమిస్తుంది; నుండి కోడ్‌లు 0x80 కు 0x7FF - రెండు బైట్లు; నుండి 0x800 కు 0xFFFF - మూడు, మరియు నుండి 0x10000 కు 0x10FFFF - నాలుగు. ఒక వైపు, లాటిన్ వర్ణమాల మంచిగా మారింది: ASCIIతో అనుకూలత తిరిగి వచ్చింది మరియు పంపిణీ 1 నుండి 4 బైట్‌ల వరకు "విస్తరిస్తుంది". కానీ లాటిన్ కాకుండా ఇతర వర్ణమాలలు, అయ్యో, UTF-16తో పోలిస్తే ఏ విధంగానూ ప్రయోజనం పొందవు మరియు చాలా మందికి ఇప్పుడు రెండు బైట్‌లకు బదులుగా మూడు బైట్లు అవసరం - రెండు-బైట్ రికార్డ్‌తో కవర్ చేయబడిన పరిధి 32 రెట్లు తగ్గిపోయింది. 0xFFFF కు 0x7FF, మరియు చైనీస్ లేదా, ఉదాహరణకు, జార్జియన్ ఇందులో చేర్చబడలేదు. సిరిలిక్ మరియు ఐదు ఇతర వర్ణమాలలు - హుర్రే - లక్కీ, ఒక్కో అక్షరానికి 2 బైట్లు.
ఇది ఎందుకు జరుగుతుంది? UTF-8 అక్షర కోడ్‌లను ఎలా సూచిస్తుందో చూద్దాం:
నేరుగా సంఖ్యలను సూచించడానికి, గుర్తుతో గుర్తించబడిన బిట్‌లు ఇక్కడ ఉపయోగించబడతాయి x. రెండు-బైట్ రికార్డులో కేవలం 11 బిట్‌లు మాత్రమే ఉన్నాయని చూడవచ్చు (16 లో). ఇక్కడ ప్రముఖ బిట్‌లు సహాయక ఫంక్షన్‌ను మాత్రమే కలిగి ఉంటాయి. నాలుగు-బైట్ రికార్డ్ విషయంలో, 21 బిట్‌లలో 32 కోడ్ పాయింట్ నంబర్ కోసం కేటాయించబడ్డాయి - మూడు బైట్లు (మొత్తం 24 బిట్‌లను ఇస్తాయి) సరిపోతాయని అనిపిస్తుంది, అయితే సర్వీస్ మార్కర్‌లు ఎక్కువగా తింటాయి.
ఇది చెడ్డదా? నిజంగా కాదు. ఒకవైపు, మేము స్థలం గురించి చాలా శ్రద్ధ వహిస్తే, మేము అన్ని అదనపు ఎంట్రోపీ మరియు రిడెండెన్సీని సులభంగా తొలగించగల కంప్రెషన్ అల్గారిథమ్‌లను కలిగి ఉన్నాము. మరోవైపు, యూనికోడ్ యొక్క లక్ష్యం అత్యంత సార్వత్రిక కోడింగ్‌ను అందించడం. ఉదాహరణకు, మేము UTF-8లో ఎన్కోడ్ చేసిన పంక్తిని మునుపు ASCIIతో మాత్రమే పనిచేసిన కోడ్‌కి అప్పగించగలము మరియు అది ASCII పరిధిలోని అక్షరాన్ని చూస్తుందని భయపడవద్దు (అన్నింటికంటే, UTF-8లో అన్నీ సున్నా బిట్ నుండి ప్రారంభమయ్యే బైట్లు - ASCII అంటే ఇదే). మరియు మేము అకస్మాత్తుగా ఒక పెద్ద స్ట్రింగ్ నుండి చిన్న తోకను మొదటి నుండి డీకోడ్ చేయకుండా (లేదా దెబ్బతిన్న విభాగం తర్వాత సమాచారాన్ని కొంత భాగాన్ని పునరుద్ధరించాలనుకుంటే), అక్షరం ప్రారంభమయ్యే ఆఫ్‌సెట్‌ను కనుగొనడం మాకు సులభం (ఇది సరిపోతుంది బిట్ ఉపసర్గ ఉన్న బైట్‌లను దాటవేయడానికి 10).
అలాంటప్పుడు కొత్తగా కనిపెట్టడం ఎందుకు?
అదే సమయంలో, డిఫ్లేట్ వంటి కుదింపు అల్గారిథమ్‌లు సరిగా వర్తించని సందర్భాలు అప్పుడప్పుడు ఉన్నాయి, కానీ మీరు స్ట్రింగ్‌ల కాంపాక్ట్ స్టోరేజ్‌ను సాధించాలనుకుంటున్నారు. వ్యక్తిగతంగా, భవనం గురించి ఆలోచిస్తున్నప్పుడు నేను ఈ సమస్యను ఎదుర్కొన్నాను ఏకపక్ష భాషల్లోని పదాలతో సహా పెద్ద నిఘంటువు కోసం. ఒక వైపు, ప్రతి పదం చాలా చిన్నది, కాబట్టి దానిని కుదించడం అసమర్థంగా ఉంటుంది. మరోవైపు, నేను పరిగణించిన ట్రీ ఇంప్లిమెంటేషన్ రూపొందించబడింది, తద్వారా నిల్వ చేయబడిన స్ట్రింగ్‌లోని ప్రతి బైట్ ప్రత్యేక చెట్టు శీర్షాన్ని ఉత్పత్తి చేస్తుంది, కాబట్టి వాటి సంఖ్యను తగ్గించడం చాలా ఉపయోగకరంగా ఉంది. నా లైబ్రరీలో (లో వలె , ఇది ఆధారంగా) ఇదే సమస్య కేవలం పరిష్కరించబడుతుంది - తీగలను ప్యాక్ చేయబడింది - నిఘంటువు, అక్కడ నిల్వ చేయబడింది . కానీ, అర్థం చేసుకోవడం సులభం, ఇది పరిమిత వర్ణమాలకి మాత్రమే బాగా పని చేస్తుంది - చైనీస్‌లో ఒక లైన్ అటువంటి నిఘంటువుకి జోడించబడదు.
విడిగా, అటువంటి డేటా నిర్మాణంలో UTF-8ని ఉపయోగిస్తున్నప్పుడు తలెత్తే మరొక అసహ్యకరమైన స్వల్పభేదాన్ని నేను గమనించాలనుకుంటున్నాను. పై చిత్రంలో ఒక అక్షరాన్ని రెండు బైట్‌లుగా వ్రాసినప్పుడు, దాని సంఖ్యకు సంబంధించిన బిట్‌లు వరుసలో రావు, కానీ ఒక జత బిట్‌లతో వేరు చేయబడతాయి 10 మధ్యలో: 110xxxxx 10xxxxxx. దీని కారణంగా, క్యారెక్టర్ కోడ్‌లో రెండవ బైట్ యొక్క దిగువ 6 బిట్‌లు ఓవర్‌ఫ్లో అయినప్పుడు (అనగా, పరివర్తన ఏర్పడుతుంది 10111111 → 10000000), తర్వాత మొదటి బైట్ కూడా మారుతుంది. "p" అనే అక్షరం బైట్‌ల ద్వారా సూచించబడిందని తేలింది 0xD0 0xBF, మరియు తదుపరి “r” ఇప్పటికే ఉంది 0xD1 0x80. ఉపసర్గ చెట్టులో, ఇది పేరెంట్ నోడ్‌ను రెండుగా విభజించడానికి దారితీస్తుంది - ఉపసర్గ కోసం ఒకటి 0xD0, మరియు మరొకటి కోసం 0xD1 (అయితే మొత్తం సిరిలిక్ వర్ణమాల రెండవ బైట్ ద్వారా మాత్రమే ఎన్కోడ్ చేయబడుతుంది).
నేను ఏమి పొందాను
ఈ సమస్యను ఎదుర్కొన్నప్పుడు, నేను బిట్‌లతో గేమ్‌లు ఆడడాన్ని ప్రాక్టీస్ చేయాలని నిర్ణయించుకున్నాను మరియు అదే సమయంలో మొత్తం యూనికోడ్ నిర్మాణంతో కొంచెం మెరుగ్గా పరిచయం పొందాను. ఫలితంగా UTF-C ఎన్కోడింగ్ ఫార్మాట్ ("C" కోసం కాంపాక్ట్), ఇది కోడ్ పాయింట్‌కు 3 బైట్‌ల కంటే ఎక్కువ ఖర్చు చేయదు మరియు చాలా తరచుగా మీరు ఖర్చు చేయడానికి మాత్రమే అనుమతిస్తుంది మొత్తం ఎన్కోడ్ చేసిన లైన్ కోసం ఒక అదనపు బైట్. ఇది అనేక ASCII యేతర వర్ణమాలలలో ఇటువంటి ఎన్‌కోడింగ్‌గా మారుతుంది. UTF-30 కంటే 60-8% ఎక్కువ కాంపాక్ట్.
నేను రూపంలో ఎన్కోడింగ్ మరియు డీకోడింగ్ అల్గారిథమ్‌ల అమలుకు ఉదాహరణలను అందించాను , మీరు వాటిని మీ కోడ్‌లో ఉచితంగా ఉపయోగించవచ్చు. కానీ ఒక కోణంలో ఈ ఫార్మాట్ “సైకిల్”గా మిగిలిపోయిందని నేను ఇప్పటికీ నొక్కి చెబుతాను మరియు దీన్ని ఉపయోగించమని నేను సిఫార్సు చేయను మీకు ఇది ఎందుకు అవసరమో తెలుసుకోకుండా. ఇది ఇప్పటికీ తీవ్రమైన "UTF-8 మెరుగుదల" కంటే ఎక్కువ ప్రయోగం. అయినప్పటికీ, అక్కడ కోడ్ పెద్ద సంఖ్యలో వ్యాఖ్యలు మరియు పరీక్ష కవరేజీతో చక్కగా, సంక్షిప్తంగా వ్రాయబడింది.
పరీక్ష ఫలితాలు మరియు UTF-8తో పోలిక
నేను కూడా చేసాను , ఇక్కడ మీరు అల్గోరిథం యొక్క పనితీరును అంచనా వేయవచ్చు, ఆపై దాని సూత్రాలు మరియు అభివృద్ధి ప్రక్రియ గురించి నేను మీకు మరింత తెలియజేస్తాను.
అనవసరమైన బిట్‌లను తొలగిస్తోంది
నేను UTF-8ని ప్రాతిపదికగా తీసుకున్నాను. ప్రతి బైట్‌లోని సర్వీస్ బిట్‌ల సంఖ్యను తగ్గించడం దానిలో మార్చగల మొదటి మరియు అత్యంత స్పష్టమైన విషయం. ఉదాహరణకు, UTF-8లో మొదటి బైట్ ఎల్లప్పుడూ దేనితోనైనా ప్రారంభమవుతుంది 0, లేదా తో 11 - ఒక ఉపసర్గ 10 కింది బైట్లు మాత్రమే దానిని కలిగి ఉన్నాయి. ఉపసర్గను భర్తీ చేద్దాం 11 న 1, మరియు తదుపరి బైట్‌ల కోసం మేము ఉపసర్గలను పూర్తిగా తొలగిస్తాము. ఏమి జరుగుతుంది?
0xxxxxxx - 1 బైట్
10xxxxxx xxxxxxxx - 2 బైట్లు
110xxxxx xxxxxxxx xxxxxxxx - 3 బైట్లు
వేచి ఉండండి, నాలుగు-బైట్ రికార్డు ఎక్కడ ఉంది? కానీ ఇది ఇకపై అవసరం లేదు - మూడు బైట్‌లలో వ్రాసేటప్పుడు, మనకు ఇప్పుడు 21 బిట్‌లు అందుబాటులో ఉన్నాయి మరియు ఇది అన్ని సంఖ్యలకు సరిపోతుంది 0x10FFFF.
ఇక్కడ మనం ఏమి త్యాగం చేసాము? బఫర్‌లోని ఏకపక్ష స్థానం నుండి అక్షర సరిహద్దులను గుర్తించడం చాలా ముఖ్యమైన విషయం. మేము ఏకపక్ష బైట్‌ని సూచించలేము మరియు దాని నుండి తదుపరి అక్షరం యొక్క ప్రారంభాన్ని కనుగొనలేము. ఇది మా ఫార్మాట్ యొక్క పరిమితి, కానీ ఆచరణలో ఇది చాలా అరుదుగా అవసరం. మేము సాధారణంగా మొదటి నుండి బఫర్ ద్వారా అమలు చేయగలము (ముఖ్యంగా చిన్న పంక్తుల విషయానికి వస్తే).
2 బైట్‌లతో భాషలను కవర్ చేసే పరిస్థితి కూడా మెరుగుపడింది: ఇప్పుడు రెండు-బైట్ ఫార్మాట్ 14 బిట్‌ల పరిధిని ఇస్తుంది మరియు ఇవి వరకు కోడ్‌లు 0x3FFF. చైనీయులు దురదృష్టవంతులు (వారి అక్షరాలు ఎక్కువగా ఉంటాయి 0x4E00 కు 0x9FFF), కానీ జార్జియన్లు మరియు అనేక ఇతర ప్రజలు మరింత సరదాగా ఉంటారు - వారి భాషలు కూడా ఒక్కో అక్షరానికి 2 బైట్‌లకు సరిపోతాయి.
ఎన్‌కోడర్ స్థితిని నమోదు చేయండి
పంక్తుల లక్షణాల గురించి ఇప్పుడు ఆలోచిద్దాం. నిఘంటువు చాలా తరచుగా ఒకే వర్ణమాల యొక్క అక్షరాలతో వ్రాసిన పదాలను కలిగి ఉంటుంది మరియు ఇది అనేక ఇతర గ్రంథాలకు కూడా వర్తిస్తుంది. ఈ వర్ణమాలను ఒకసారి సూచించి, అందులోని అక్షరం సంఖ్యను మాత్రమే సూచిస్తే బాగుంటుంది. యూనికోడ్ పట్టికలోని అక్షరాల అమరిక మనకు సహాయపడుతుందో లేదో చూద్దాం.
పైన చెప్పినట్లుగా, యూనికోడ్ విభజించబడింది విమానం ఒక్కొక్కటి 65536 కోడ్‌లు. కానీ ఇది చాలా ఉపయోగకరమైన విభజన కాదు (ఇప్పటికే చెప్పినట్లుగా, చాలా తరచుగా మేము సున్నా విమానంలో ఉన్నాము). ద్వారా విభజన మరింత ఆసక్తికరంగా ఉంటుంది బ్లాక్స్. ఈ పరిధులు ఇకపై స్థిర పొడవును కలిగి ఉండవు మరియు మరింత అర్థవంతంగా ఉంటాయి - నియమం ప్రకారం, ప్రతి ఒక్కటి ఒకే వర్ణమాల నుండి అక్షరాలను మిళితం చేస్తుంది.
బెంగాలీ వర్ణమాల యొక్క అక్షరాలను కలిగి ఉన్న బ్లాక్. దురదృష్టవశాత్తు, చారిత్రక కారణాల వల్ల, ఇది చాలా దట్టమైన ప్యాకేజింగ్‌కు ఉదాహరణ - 96 అక్షరాలు 128 బ్లాక్ కోడ్ పాయింట్‌లలో అస్తవ్యస్తంగా చెల్లాచెదురుగా ఉన్నాయి.
బ్లాక్‌ల ప్రారంభాలు మరియు వాటి పరిమాణాలు ఎల్లప్పుడూ 16 యొక్క గుణిజాలుగా ఉంటాయి - ఇది సౌలభ్యం కోసం మాత్రమే చేయబడుతుంది. అదనంగా, అనేక బ్లాక్‌లు 128 లేదా 256 గుణిజాలుగా ఉండే విలువలతో ప్రారంభమవుతాయి మరియు ముగుస్తాయి - ఉదాహరణకు, ప్రాథమిక సిరిలిక్ వర్ణమాల నుండి 256 బైట్‌లను తీసుకుంటుంది 0x0400 కు 0x04FF. ఇది చాలా సౌకర్యవంతంగా ఉంటుంది: మేము ఉపసర్గను ఒకసారి సేవ్ చేస్తే 0x04, అప్పుడు ఏదైనా సిరిలిక్ అక్షరాన్ని ఒక బైట్‌లో వ్రాయవచ్చు. నిజమే, ఈ విధంగా మేము ASCIIకి (మరియు సాధారణంగా ఏదైనా ఇతర పాత్రలకు) తిరిగి వచ్చే అవకాశాన్ని కోల్పోతాము. కాబట్టి మేము దీన్ని చేస్తాము:
- రెండు బైట్లు
10yyyyyy yxxxxxxxసంఖ్యతో కూడిన చిహ్నాన్ని సూచించడమే కాదుyyyyyy yxxxxxxx, కానీ కూడా మార్చండి ప్రస్తుత వర్ణమాల నyyyyyy y0000000(అనగా మేము అతి తక్కువ ముఖ్యమైన వాటిని మినహాయించి అన్ని బిట్‌లను గుర్తుంచుకుంటాము 7 బిట్); - ఒక బైట్
0xxxxxxxఇది ప్రస్తుత వర్ణమాల యొక్క లక్షణం. ఇది కేవలం 1వ దశలో మనం గుర్తుపెట్టుకున్న ఆఫ్‌సెట్‌కు జోడించాల్సిన అవసరం ఉంది. మేము వర్ణమాలని మార్చనప్పటికీ, ఆఫ్‌సెట్ సున్నా, కాబట్టి మేము ASCIIతో అనుకూలతను కొనసాగించాము.
అదేవిధంగా 3 బైట్లు అవసరమయ్యే కోడ్‌ల కోసం:
- మూడు బైట్లు
110yyyyy yxxxxxxx xxxxxxxxసంఖ్యతో చిహ్నాన్ని సూచించండిyyyyyy yxxxxxxx xxxxxxxx, మార్పు ప్రస్తుత వర్ణమాల నyyyyyy y0000000 00000000(చిన్నవాళ్ళు తప్ప మిగతావన్నీ గుర్తుకొచ్చాయి 15 బిట్), మరియు మనం ఇప్పుడు ఉన్న పెట్టెను చెక్ చేయండి పొడవు మోడ్ (అల్ఫాబెట్‌ను తిరిగి డబుల్-బైట్‌కి మార్చినప్పుడు, మేము ఈ ఫ్లాగ్‌ని రీసెట్ చేస్తాము); - రెండు బైట్లు
0xxxxxxx xxxxxxxxలాంగ్ మోడ్‌లో ఇది ప్రస్తుత వర్ణమాల యొక్క పాత్ర. అదేవిధంగా, మేము దీన్ని 1వ దశ నుండి ఆఫ్‌సెట్‌తో జోడిస్తాము. ఒకే తేడా ఏమిటంటే ఇప్పుడు మనం రెండు బైట్‌లను చదివాము (ఎందుకంటే మేము ఈ మోడ్‌కి మారాము).
బాగానే ఉంది: ఇప్పుడు మనం అదే 7-బిట్ యూనికోడ్ శ్రేణి నుండి అక్షరాలను ఎన్కోడ్ చేయవలసి ఉండగా, ప్రారంభంలో 1 అదనపు బైట్ మరియు ఒక్కో అక్షరానికి మొత్తం ఒక బైట్ ఖర్చు చేస్తాము.
మునుపటి సంస్కరణల్లో ఒకదాని నుండి పని చేస్తోంది. ఇది ఇప్పటికే తరచుగా UTF-8ని కొడుతుంది, కానీ ఇంకా మెరుగుదల కోసం స్థలం ఉంది.
ఇంతకంటే దారుణం ఏమిటి? మొదట, మనకు ఒక షరతు ఉంది, అవి ప్రస్తుత వర్ణమాల ఆఫ్‌సెట్ మరియు చెక్‌బాక్స్ దీర్ఘ మోడ్. ఇది మమ్మల్ని మరింత పరిమితం చేస్తుంది: ఇప్పుడు ఒకే అక్షరాలను వేర్వేరు సందర్భాలలో వేర్వేరుగా ఎన్కోడ్ చేయవచ్చు. సబ్‌స్ట్రింగ్‌ల కోసం శోధించడం, ఉదాహరణకు, బైట్‌లను పోల్చడం ద్వారా మాత్రమే కాకుండా, దీన్ని పరిగణనలోకి తీసుకొని చేయాలి. రెండవది, మేము వర్ణమాలను మార్చిన వెంటనే, ASCII అక్షరాల ఎన్‌కోడింగ్‌తో ఇది చెడ్డది (మరియు ఇది లాటిన్ వర్ణమాల మాత్రమే కాదు, ఖాళీలతో సహా ప్రాథమిక విరామ చిహ్నాలు కూడా) - వారు వర్ణమాలని మళ్లీ 0కి మార్చాలి, అనగా, మళ్ళీ ఒక అదనపు బైట్ (ఆ తర్వాత మా ప్రధాన పాయింట్‌కి తిరిగి రావడానికి మరొకటి).
ఒక అక్షరం మంచిది, రెండు ఉత్తమం
పైన వివరించిన మూడింటికి మరొకదానిని పిండడం ద్వారా మన బిట్ ప్రిఫిక్స్‌లను కొద్దిగా మార్చడానికి ప్రయత్నిద్దాం:
0xxxxxxx - సాధారణ మోడ్‌లో 1 బైట్, లాంగ్ మోడ్‌లో 2
11xxxxxx - 1 బైట్
100xxxxx xxxxxxxx - 2 బైట్లు
101xxxxx xxxxxxxx xxxxxxxx - 3 బైట్లు
ఇప్పుడు రెండు-బైట్ రికార్డులో తక్కువ అందుబాటులో ఉన్న బిట్ ఒకటి ఉంది - కోడ్ పాయింట్లు వరకు 0x1FFFకానీ కాదు 0x3FFF. అయినప్పటికీ, ఇది ఇప్పటికీ డబుల్-బైట్ UTF-8 కోడ్‌ల కంటే పెద్దదిగా ఉంది, చాలా సాధారణ భాషలు ఇప్పటికీ సరిపోతాయి, అత్యంత గుర్తించదగిన నష్టం పడిపోయింది и , జపనీయులు విచారంగా ఉన్నారు.
ఈ కొత్త కోడ్ ఏమిటి? 11xxxxxx? ఇది 64 అక్షరాల పరిమాణంలో ఉన్న చిన్న “స్టాష్”, ఇది మా ప్రధాన వర్ణమాలను పూర్తి చేస్తుంది, కాబట్టి నేను దీనిని సహాయక (అక్సిలరీ) అని పిలిచాను (సహాయక) వర్ణమాల. మేము ప్రస్తుత వర్ణమాలను మార్చినప్పుడు, పాత వర్ణమాలలోని ఒక భాగం సహాయకంగా మారుతుంది. ఉదాహరణకు, మేము ASCII నుండి సిరిలిక్‌కి మారాము - ఇప్పుడు స్టాష్‌లో 64 అక్షరాలు ఉన్నాయి లాటిన్ వర్ణమాల, సంఖ్యలు, స్థలం మరియు కామా (ASCII కాని గ్రంథాలలో చాలా తరచుగా చొప్పించడం). ASCIIకి తిరిగి మారండి - మరియు సిరిలిక్ వర్ణమాల యొక్క ప్రధాన భాగం సహాయక వర్ణమాలగా మారుతుంది.
రెండు వర్ణమాలలను యాక్సెస్ చేసినందుకు ధన్యవాదాలు, మేము వర్ణమాలలను మార్చడానికి తక్కువ ఖర్చుతో పెద్ద సంఖ్యలో టెక్స్ట్‌లను నిర్వహించగలము (విరామ చిహ్నాలు చాలా తరచుగా ASCIIకి తిరిగి రావడానికి దారి తీస్తుంది, కానీ ఆ తర్వాత మేము అదనపు వర్ణమాల నుండి అనేక ASCII కాని అక్షరాలను పొందుతాము. మళ్లీ మారుతోంది ).
బోనస్: ఉప-వర్ణమాల ఉపసర్గ 11xxxxxx మరియు దాని ప్రారంభ ఆఫ్‌సెట్‌ని ఎంచుకోవడం 0xC0, మేము CP1252తో పాక్షిక అనుకూలతను పొందుతాము. మరో మాటలో చెప్పాలంటే, CP1252లో ఎన్కోడ్ చేయబడిన అనేక (కానీ అన్నీ కాదు) వెస్ట్రన్ యూరోపియన్ టెక్స్ట్‌లు UTF-Cలో ఒకే విధంగా కనిపిస్తాయి.
ఇక్కడ, అయితే, ఒక కష్టం తలెత్తుతుంది: ప్రధాన వర్ణమాల నుండి సహాయక ఒకదాన్ని ఎలా పొందాలి? మీరు అదే ఆఫ్‌సెట్‌ను వదిలివేయవచ్చు, కానీ - అయ్యో - ఇక్కడ యూనికోడ్ నిర్మాణం ఇప్పటికే మాకు వ్యతిరేకంగా ప్లే అవుతోంది. చాలా తరచుగా వర్ణమాల యొక్క ప్రధాన భాగం బ్లాక్ ప్రారంభంలో ఉండదు (ఉదాహరణకు, రష్యన్ రాజధాని "A" కోడ్‌ను కలిగి ఉంటుంది 0x0410, అయినప్పటికీ సిరిలిక్ బ్లాక్ మొదలవుతుంది 0x0400) ఈ విధంగా, మొదటి 64 అక్షరాలను స్టాష్‌లోకి తీసుకున్న తర్వాత, మేము వర్ణమాల యొక్క తోక భాగానికి యాక్సెస్‌ను కోల్పోవచ్చు.
ఈ సమస్యను పరిష్కరించడానికి, నేను వివిధ భాషలకు సంబంధించిన కొన్ని బ్లాక్‌లను మాన్యువల్‌గా పరిశీలించాను మరియు వాటి కోసం ప్రధానమైన వాటిలో సహాయక వర్ణమాల యొక్క ఆఫ్‌సెట్‌ను పేర్కొన్నాను. లాటిన్ వర్ణమాల, మినహాయింపుగా, సాధారణంగా బేస్ 64 లాగా క్రమం చేయబడింది.
తుది మెరుగులు దిద్దారు
చివరగా మనం ఎక్కడ ఏదైనా మెరుగుపరుచుకోవచ్చో ఆలోచిద్దాం.
ఫార్మాట్ అని గమనించండి 101xxxxx xxxxxxxx xxxxxxxx వరకు సంఖ్యలను ఎన్కోడ్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది 0x1FFFFF, మరియు యూనికోడ్ ముందుగా ముగుస్తుంది, వద్ద 0x10FFFF. మరో మాటలో చెప్పాలంటే, చివరి కోడ్ పాయింట్ ఇలా సూచించబడుతుంది 10110000 11111111 11111111. కాబట్టి, మొదటి బైట్ రూపంలో ఉంటే మనం చెప్పగలం 1011xxxx (ఎక్కడ xxxx 0 కంటే ఎక్కువ), అప్పుడు దాని అర్థం వేరేది. ఉదాహరణకు, మీరు ఒక బైట్‌లో ఎన్కోడింగ్ చేయడానికి నిరంతరం అందుబాటులో ఉండే మరో 15 అక్షరాలను జోడించవచ్చు, కానీ నేను దానిని భిన్నంగా చేయాలని నిర్ణయించుకున్నాను.
ఇప్పుడు మూడు బైట్లు అవసరమయ్యే యూనికోడ్ బ్లాక్‌లను చూద్దాం. సాధారణంగా, ఇప్పటికే చెప్పినట్లుగా, ఇవి చైనీస్ అక్షరాలు - కానీ వాటితో ఏదైనా చేయడం కష్టం, వాటిలో 21 వేలు ఉన్నాయి. కానీ హిరాగానా మరియు కటకానా కూడా అక్కడికి వెళ్లాయి - మరియు వాటిలో చాలా ఎక్కువ లేవు, రెండు వందల కంటే తక్కువ. మరియు, మేము జపనీయులను గుర్తుంచుకున్నందున, ఎమోజీలు కూడా ఉన్నాయి (వాస్తవానికి, అవి యూనికోడ్‌లో చాలా ప్రదేశాలలో చెల్లాచెదురుగా ఉన్నాయి, కానీ ప్రధాన బ్లాక్‌లు పరిధిలో ఉన్నాయి 0x1F300 - 0x1FBFF) మీరు ఇప్పుడు అనేక కోడ్ పాయింట్ల నుండి ఒకేసారి అసెంబుల్ చేయబడిన ఎమోజీలు (ఉదాహరణకు, ఎమోజి) ఉన్నాయనే విషయం గురించి ఆలోచిస్తే అనేక 7 కోడ్‌లను కలిగి ఉంటుంది!), ఆపై ఒక్కోదానిపై మూడు బైట్‌లను ఖర్చు చేయడం పూర్తిగా అవమానకరం (ఒక చిహ్నం, పీడకల కోసం 7×3 = 21 బైట్లు).
కాబట్టి, మేము ఎమోజి, హిరాగానా మరియు కటకానాకు సంబంధించిన కొన్ని ఎంచుకున్న పరిధులను ఎంచుకుంటాము, వాటిని ఒక నిరంతర జాబితాలోకి మళ్లీ నంబర్ చేస్తాము మరియు వాటిని మూడు కాకుండా రెండు బైట్‌లుగా ఎన్కోడ్ చేస్తాము:
1011xxxx xxxxxxxx
గొప్పది: పైన పేర్కొన్న ఎమోజి, 7 కోడ్ పాయింట్‌లను కలిగి ఉంటుంది, UTF-8లో 25 బైట్‌లను తీసుకుంటాము మరియు మేము దానిని సరిపోతాము 14 (ప్రతి కోడ్ పాయింట్‌కి సరిగ్గా రెండు బైట్లు). మార్గం ద్వారా, హబ్ర్ దానిని జీర్ణించుకోవడానికి నిరాకరించాడు (పాత మరియు కొత్త ఎడిటర్‌లో), కాబట్టి నేను దానిని చిత్రంతో చొప్పించవలసి వచ్చింది.
మరొక సమస్యను పరిష్కరించడానికి ప్రయత్నిద్దాం. మనకు గుర్తున్నట్లుగా, ప్రాథమిక వర్ణమాల తప్పనిసరిగా ఉంటుంది అధిక 6 బిట్స్, మేము గుర్తుంచుకోండి మరియు ప్రతి తదుపరి డీకోడ్ చేసిన చిహ్నం యొక్క కోడ్‌కు జిగురు చేస్తాము. బ్లాక్‌లో ఉన్న చైనీస్ అక్షరాల విషయంలో 0x4E00 - 0x9FFF, ఇది బిట్ 0 లేదా 1. ఇది చాలా అనుకూలమైనది కాదు: ఈ రెండు విలువల మధ్య (అనగా మూడు బైట్‌లను ఖర్చు చేయడం) మనం నిరంతరం వర్ణమాలని మార్చవలసి ఉంటుంది. కానీ లాంగ్ మోడ్‌లో, సంక్షిప్త మోడ్‌ను ఉపయోగించి మనం ఎన్కోడ్ చేసే అక్షరాల సంఖ్యను తీసివేయవచ్చు (పైన వివరించిన అన్ని ట్రిక్‌ల తర్వాత, ఇది 10240) - అప్పుడు హైరోగ్లిఫ్‌ల పరిధి మారుతుందని గమనించండి. 0x2600 - 0x77FF, మరియు ఈ సందర్భంలో, ఈ మొత్తం శ్రేణిలో, అత్యంత ముఖ్యమైన 6 బిట్‌లు (21లో) 0కి సమానంగా ఉంటాయి. కాబట్టి, హైరోగ్లిఫ్‌ల సీక్వెన్స్‌లు ప్రతి చిత్రలిపికి రెండు బైట్‌లను ఉపయోగిస్తాయి (అంత పెద్ద పరిధికి ఇది సరైనది), వర్ణమాల స్విచ్‌లను కలిగిస్తుంది.
ప్రత్యామ్నాయ పరిష్కారాలు: SCSU, BOCU-1
యూనికోడ్ నిపుణులు, ఇప్పుడే కథనం యొక్క శీర్షికను చదివిన తర్వాత, యూనికోడ్ ప్రమాణాలలో నేరుగా ఉన్న విషయాన్ని మీకు గుర్తు చేయడానికి చాలా మటుకు తొందరపడతారు. (SCSU), ఇది వ్యాసంలో వివరించిన దానికి సమానమైన ఎన్కోడింగ్ పద్ధతిని వివరిస్తుంది.
నేను నిజాయితీగా అంగీకరిస్తున్నాను: నేను నా నిర్ణయాన్ని వ్రాయడంలో లోతుగా మునిగిపోయిన తర్వాత మాత్రమే దాని ఉనికి గురించి తెలుసుకున్నాను. నేను దాని గురించి మొదటి నుండి తెలిసి ఉంటే, నేను బహుశా నా స్వంత విధానంతో ముందుకు రావడానికి బదులుగా అమలును వ్రాయడానికి ప్రయత్నించాను.
ఆసక్తికరమైన విషయమేమిటంటే, SCSU నేను నా స్వంతంగా రూపొందించిన ఆలోచనలకు సమానమైన ఆలోచనలను ఉపయోగిస్తుంది (“వర్ణమాలలు” అనే భావనకు బదులుగా వారు “విండోస్”ని ఉపయోగిస్తున్నారు మరియు వాటిలో నా కంటే ఎక్కువ అందుబాటులో ఉన్నాయి). అదే సమయంలో, ఈ ఆకృతికి ప్రతికూలతలు కూడా ఉన్నాయి: ఇది ఎన్కోడింగ్ కంటే కంప్రెషన్ అల్గోరిథంలకు కొద్దిగా దగ్గరగా ఉంటుంది. ప్రత్యేకించి, ప్రమాణం అనేక ప్రాతినిధ్య పద్ధతులను ఇస్తుంది, కానీ సరైనదాన్ని ఎలా ఎంచుకోవాలో చెప్పలేదు - దీని కోసం, ఎన్‌కోడర్ తప్పనిసరిగా కొన్ని రకాల హ్యూరిస్టిక్‌లను ఉపయోగించాలి. అందువల్ల, మంచి ప్యాకేజింగ్‌ను ఉత్పత్తి చేసే SCSU ఎన్‌కోడర్ నా అల్గారిథమ్ కంటే చాలా క్లిష్టంగా మరియు మరింత గజిబిజిగా ఉంటుంది.
పోలిక కోసం, నేను SCSU యొక్క సాపేక్షంగా సరళమైన అమలును JavaScriptకి బదిలీ చేసాను - కోడ్ వాల్యూమ్ పరంగా ఇది నా UTF-Cతో పోల్చదగినదిగా మారింది, కానీ కొన్ని సందర్భాల్లో ఫలితం పదుల శాతం అధ్వాన్నంగా ఉంది (కొన్నిసార్లు అది మించి ఉండవచ్చు, కానీ ఎక్కువ కాదు). ఉదాహరణకు, హిబ్రూ మరియు గ్రీకు భాషలలోని పాఠాలు UTF-C ద్వారా ఎన్కోడ్ చేయబడ్డాయి SCSU కంటే 60% మెరుగ్గా ఉంది (బహుశా వాటి కాంపాక్ట్ వర్ణమాల వల్ల కావచ్చు).
విడిగా, నేను SCSU కాకుండా యూనికోడ్‌ని కాంపాక్ట్‌గా సూచించడానికి మరొక మార్గం కూడా ఉందని జోడిస్తాను - , కానీ ఇది MIME అనుకూలతను లక్ష్యంగా చేసుకుంది (ఇది నాకు అవసరం లేదు) మరియు ఎన్‌కోడింగ్‌కు కొద్దిగా భిన్నమైన విధానాన్ని తీసుకుంటుంది. నేను దాని ప్రభావాన్ని అంచనా వేయలేదు, కానీ అది SCSU కంటే ఎక్కువగా ఉండే అవకాశం లేదని నాకు అనిపిస్తోంది.
సాధ్యమైన మెరుగుదలలు
నేను అందించిన అల్గోరిథం డిజైన్ ద్వారా సార్వత్రికమైనది కాదు (బహుశా ఇక్కడే నా లక్ష్యాలు యూనికోడ్ కన్సార్టియం యొక్క లక్ష్యాలకు భిన్నంగా ఉండవచ్చు). ఇది ప్రాథమికంగా ఒక పని (ఉపసర్గ చెట్టులో బహుభాషా నిఘంటువును నిల్వ చేయడం) కోసం అభివృద్ధి చేయబడిందని నేను ఇప్పటికే పేర్కొన్నాను మరియు దానిలోని కొన్ని లక్షణాలు ఇతర పనులకు సరిగ్గా సరిపోకపోవచ్చు. కానీ అది ప్రమాణం కాదనే వాస్తవం ప్లస్ కావచ్చు - మీరు మీ అవసరాలకు అనుగుణంగా సులభంగా సవరించవచ్చు.
ఉదాహరణకు, స్పష్టమైన మార్గంలో మీరు స్థితి ఉనికిని వదిలించుకోవచ్చు, స్థితిలేని కోడింగ్ చేయవచ్చు - కేవలం వేరియబుల్స్‌ను అప్‌డేట్ చేయవద్దు offs, auxOffs и is21Bit ఎన్‌కోడర్ మరియు డీకోడర్‌లో. ఈ సందర్భంలో, ఒకే వర్ణమాల యొక్క అక్షరాల క్రమాలను సమర్థవంతంగా ప్యాక్ చేయడం సాధ్యం కాదు, అయితే సందర్భంతో సంబంధం లేకుండా అదే అక్షరం ఎల్లప్పుడూ ఒకే బైట్‌లతో ఎన్కోడ్ చేయబడుతుందని హామీ ఉంటుంది.
అదనంగా, మీరు డిఫాల్ట్ స్థితిని మార్చడం ద్వారా ఎన్‌కోడర్‌ను నిర్దిష్ట భాషకు అనుగుణంగా మార్చవచ్చు - ఉదాహరణకు, రష్యన్ టెక్స్ట్‌లపై దృష్టి సారించడం, ప్రారంభంలో ఎన్‌కోడర్ మరియు డీకోడర్‌ను సెట్ చేయండి offs = 0x0400 и auxOffs = 0. స్టేట్‌లెస్ మోడ్ విషయంలో ఇది ప్రత్యేకంగా అర్ధమే. సాధారణంగా, ఇది పాత ఎనిమిది-బిట్ ఎన్‌కోడింగ్‌ను ఉపయోగించడం వలె ఉంటుంది, అయితే అవసరమైన విధంగా అన్ని యూనికోడ్ నుండి అక్షరాలను చొప్పించే సామర్థ్యాన్ని తీసివేయకుండా ఉంటుంది.
ముందుగా పేర్కొన్న మరో లోపం ఏమిటంటే, UTF-Cలో ఎన్కోడ్ చేయబడిన పెద్ద టెక్స్ట్‌లో ఏకపక్ష బైట్‌కు దగ్గరగా ఉన్న అక్షర సరిహద్దును కనుగొనడానికి శీఘ్ర మార్గం లేదు. మీరు ఎన్కోడ్ చేయబడిన బఫర్ నుండి 100 బైట్‌లను కత్తిరించినట్లయితే, మీరు ఏమీ చేయలేని చెత్తను పొందే ప్రమాదం ఉంది. ఎన్కోడింగ్ బహుళ-గిగాబైట్ లాగ్‌లను నిల్వ చేయడానికి రూపొందించబడలేదు, అయితే సాధారణంగా దీనిని సరిదిద్దవచ్చు. బైట్ 0xBF మొదటి బైట్‌గా ఎప్పుడూ కనిపించకూడదు (కానీ రెండవ లేదా మూడవది కావచ్చు). అందువల్ల, ఎన్కోడింగ్ చేసేటప్పుడు, మీరు క్రమాన్ని చొప్పించవచ్చు 0xBF 0xBF 0xBF ప్రతి, చెప్పండి, 10 KB - అప్పుడు, మీరు సరిహద్దును కనుగొనవలసి వస్తే, ఇదే మార్కర్ కనుగొనబడే వరకు ఎంచుకున్న భాగాన్ని స్కాన్ చేయడానికి సరిపోతుంది. చివరిదాన్ని అనుసరిస్తోంది 0xBF క్యారెక్టర్‌కి నాంది అని హామీ ఇచ్చారు. (డీకోడింగ్ చేసేటప్పుడు, మూడు బైట్‌ల ఈ క్రమాన్ని విస్మరించాల్సిన అవసరం ఉంది.)
సంగ్రహించేందుకు
మీరు ఇంతవరకు చదివి ఉంటే, అభినందనలు! యూనికోడ్ నిర్మాణం గురించి మీరు కూడా నాలాగే కొత్తగా (లేదా మీ మెమరీని రిఫ్రెష్ చేసారు) నేర్చుకున్నారని నేను ఆశిస్తున్నాను.
డెమో పేజీ. హిబ్రూ ఉదాహరణ UTF-8 మరియు SCSU రెండింటి కంటే ప్రయోజనాలను చూపుతుంది.
పైన వివరించిన పరిశోధన ప్రమాణాల ఆక్రమణగా పరిగణించరాదు. అయితే, నేను సాధారణంగా నా పని ఫలితాలతో సంతృప్తి చెందాను, కాబట్టి నేను వారితో సంతోషంగా ఉన్నాను : ఉదాహరణకు, minified JS లైబ్రరీ బరువు 1710 బైట్లు మాత్రమే (మరియు డిపెండెన్సీలు లేవు, అయితే). నేను పైన చెప్పినట్లుగా, ఆమె పనిని ఇక్కడ చూడవచ్చు (యుటిఎఫ్-8 మరియు ఎస్‌సిఎస్‌యుతో పోల్చగలిగే పాఠాల సమితి కూడా ఉంది).
చివరగా, UTF-C ఉపయోగించబడే సందర్భాల గురించి నేను మరోసారి దృష్టిని ఆకర్షిస్తాను అది విలువ కాదు:
- మీ పంక్తులు తగినంత పొడవుగా ఉంటే (100-200 అక్షరాల నుండి). ఈ సందర్భంలో, మీరు డిఫ్లేట్ వంటి కంప్రెషన్ అల్గారిథమ్‌లను ఉపయోగించడం గురించి ఆలోచించాలి.
- ఒక వేళ నీకు అవసరం అయితే ASCII పారదర్శకత, అంటే, ఎన్కోడ్ చేసిన సీక్వెన్స్‌లు అసలు స్ట్రింగ్‌లో లేని ASCII కోడ్‌లను కలిగి ఉండకపోవడం మీకు ముఖ్యం. థర్డ్-పార్టీ APIలతో ఇంటరాక్ట్ అవుతున్నప్పుడు (ఉదాహరణకు, డేటాబేస్‌తో పని చేయడం) మీరు ఎన్కోడింగ్ ఫలితాన్ని బైట్‌ల నైరూప్య సెట్‌గా పాస్ చేస్తే, స్ట్రింగ్‌లుగా కాకుండా దీని అవసరం నివారించబడుతుంది. లేకపోతే, మీరు ఊహించని హానిని పొందే ప్రమాదం ఉంది.
- మీరు ఏకపక్ష ఆఫ్‌సెట్‌లో అక్షర సరిహద్దులను త్వరగా కనుగొనగలిగితే (ఉదాహరణకు, పంక్తిలో కొంత భాగం దెబ్బతిన్నప్పుడు). ఇది చేయవచ్చు, కానీ మొదటి నుండి లైన్‌ను స్కాన్ చేయడం ద్వారా మాత్రమే (లేదా మునుపటి విభాగంలో వివరించిన సవరణను వర్తింపజేయడం ద్వారా).
- మీరు తీగలలోని విషయాలపై త్వరగా కార్యకలాపాలను నిర్వహించాల్సిన అవసరం ఉంటే (వాటిని క్రమబద్ధీకరించండి, వాటిలో సబ్‌స్ట్రింగ్‌ల కోసం శోధించండి, కలపండి). దీనికి ముందుగా స్ట్రింగ్‌లను డీకోడ్ చేయడం అవసరం, కాబట్టి UTF-C ఈ సందర్భాలలో UTF-8 కంటే నెమ్మదిగా ఉంటుంది (కానీ కుదింపు అల్గారిథమ్‌ల కంటే వేగంగా ఉంటుంది). ఒకే స్ట్రింగ్ ఎల్లప్పుడూ ఒకే విధంగా ఎన్కోడ్ చేయబడి ఉంటుంది కాబట్టి, డీకోడింగ్ యొక్క ఖచ్చితమైన పోలిక అవసరం లేదు మరియు బైట్-బై-బైట్ ఆధారంగా చేయవచ్చు.
నవీకరణ: యూజర్ UTF-C యొక్క వర్తించే పరిమితులను హైలైట్ చేసే గ్రాఫ్‌ను పోస్ట్ చేసారు. ప్యాక్ చేయబడిన స్ట్రింగ్ తక్కువగా ఉన్నంత వరకు సాధారణ-ప్రయోజన కంప్రెషన్ అల్గారిథమ్ (LZW యొక్క వైవిధ్యం) కంటే UTF-C మరింత సమర్థవంతంగా పనిచేస్తుందని ఇది చూపిస్తుంది. ~140 అక్షరాలు (అయితే, పోలిక ఒక వచనంపై నిర్వహించబడిందని నేను గమనించాను; ఇతర భాషలకు ఫలితం భిన్నంగా ఉండవచ్చు).
మూలం: www.habr.com