മറ്റൊരു ബൈക്ക്: UTF-30 നേക്കാൾ 60-8% കൂടുതൽ ഒതുക്കമുള്ള യൂണികോഡ് സ്ട്രിംഗുകൾ ഞങ്ങൾ സംഭരിക്കുന്നു

നിങ്ങളൊരു ഡവലപ്പർ ആണെങ്കിൽ ഒരു എൻകോഡിംഗ് തിരഞ്ഞെടുക്കുന്നതിനുള്ള ചുമതല നിങ്ങൾ അഭിമുഖീകരിക്കുന്നുവെങ്കിൽ, യൂണികോഡ് മിക്കവാറും എല്ലായ്‌പ്പോഴും ശരിയായ പരിഹാരമായിരിക്കും. നിർദ്ദിഷ്ട പ്രാതിനിധ്യ രീതി സന്ദർഭത്തെ ആശ്രയിച്ചിരിക്കുന്നു, എന്നാൽ മിക്കപ്പോഴും ഇവിടെയും ഒരു സാർവത്രിക ഉത്തരമുണ്ട് - 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 ബിറ്റുകൾ നൽകുന്നു) മതിയെന്ന് തോന്നുന്നു, പക്ഷേ സേവന മാർക്കറുകൾ വളരെയധികം കഴിക്കുന്നു.

ഇത് മോശമാണോ? ശരിക്കുമല്ല. ഒരു വശത്ത്, ഞങ്ങൾ സ്ഥലത്തെക്കുറിച്ച് വളരെയധികം ശ്രദ്ധിക്കുന്നുണ്ടെങ്കിൽ, എല്ലാ അധിക എൻട്രോപ്പിയും ആവർത്തനവും എളുപ്പത്തിൽ ഇല്ലാതാക്കാൻ കഴിയുന്ന കംപ്രഷൻ അൽഗോരിതങ്ങൾ നമുക്കുണ്ട്. മറുവശത്ത്, സാധ്യമായ ഏറ്റവും സാർവത്രിക കോഡിംഗ് നൽകുക എന്നതായിരുന്നു യൂണികോഡിന്റെ ലക്ഷ്യം. ഉദാഹരണത്തിന്, മുമ്പ് ASCII-ൽ മാത്രം പ്രവർത്തിച്ചിരുന്ന കോഡിലേക്ക് UTF-8-ൽ എൻകോഡ് ചെയ്ത ഒരു ലൈൻ നമുക്ക് ഏൽപ്പിക്കാൻ കഴിയും, കൂടാതെ ASCII ശ്രേണിയിൽ നിന്ന് യഥാർത്ഥത്തിൽ ഇല്ലാത്ത ഒരു പ്രതീകം അത് കാണുമെന്ന് ഭയപ്പെടേണ്ടതില്ല (എല്ലാത്തിനുമുപരി, UTF-8-ൽ എല്ലാം സീറോ ബിറ്റിൽ നിന്ന് ആരംഭിക്കുന്ന ബൈറ്റുകൾ - ഇതാണ് ASCII എന്നത്). തുടക്കത്തിൽ തന്നെ ഡീകോഡ് ചെയ്യാതെ ഒരു വലിയ സ്ട്രിംഗിൽ നിന്ന് ഒരു ചെറിയ വാൽ പെട്ടെന്ന് മുറിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ (അല്ലെങ്കിൽ കേടായ വിഭാഗത്തിന് ശേഷം വിവരത്തിന്റെ ഒരു ഭാഗം പുനഃസ്ഥാപിക്കുക), ഒരു പ്രതീകം ആരംഭിക്കുന്ന ഓഫ്‌സെറ്റ് കണ്ടെത്തുന്നത് ഞങ്ങൾക്ക് എളുപ്പമാണ് (ഇത് മതി ഒരു ബിറ്റ് പ്രിഫിക്സുള്ള ബൈറ്റുകൾ ഒഴിവാക്കാൻ 10).

പിന്നെ എന്തിനാണ് പുതിയ എന്തെങ്കിലും കണ്ടുപിടിക്കുന്നത്?

അതേ സമയം, ഡീഫ്ലേറ്റ് പോലുള്ള കംപ്രഷൻ അൽഗോരിതങ്ങൾ മോശമായി ബാധകമാകുമ്പോൾ ഇടയ്ക്കിടെ സാഹചര്യങ്ങളുണ്ട്, എന്നാൽ സ്ട്രിംഗുകളുടെ ഒതുക്കമുള്ള സംഭരണം നേടാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നു. വ്യക്തിപരമായി, നിർമ്മാണത്തെക്കുറിച്ച് ചിന്തിക്കുമ്പോൾ ഞാൻ ഈ പ്രശ്നം നേരിട്ടു കംപ്രസ് ചെയ്ത പ്രിഫിക്സ് ട്രീ അനിയന്ത്രിതമായ ഭാഷകളിലെ വാക്കുകൾ ഉൾപ്പെടെ ഒരു വലിയ നിഘണ്ടുവിന്. ഒരു വശത്ത്, ഓരോ വാക്കും വളരെ ചെറുതാണ്, അതിനാൽ അത് കംപ്രസ് ചെയ്യുന്നത് ഫലപ്രദമല്ല. മറുവശത്ത്, ഞാൻ പരിഗണിച്ച ട്രീ ഇംപ്ലിമെന്റേഷൻ രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നതിനാൽ സംഭരിച്ചിരിക്കുന്ന സ്ട്രിംഗിന്റെ ഓരോ ബൈറ്റും ഒരു പ്രത്യേക ട്രീ വെർട്ടെക്സ് സൃഷ്ടിക്കുന്നു, അതിനാൽ അവയുടെ എണ്ണം കുറയ്ക്കുന്നത് വളരെ ഉപയോഗപ്രദമായിരുന്നു. എന്റെ ലൈബ്രറിയിൽ Az.js (എന്നപോലെ പൈമോർഫി2, അത് അടിസ്ഥാനമാക്കിയുള്ളതാണ്) സമാനമായ ഒരു പ്രശ്നം ലളിതമായി പരിഹരിക്കാൻ കഴിയും - സ്ട്രിംഗുകൾ പായ്ക്ക് ചെയ്തു DAWG-നിഘണ്ടു, അവിടെ സംഭരിച്ചിരിക്കുന്നു നല്ല പഴയ CP1251. പക്ഷേ, മനസ്സിലാക്കാൻ എളുപ്പമുള്ളതുപോലെ, പരിമിതമായ അക്ഷരമാലയിൽ മാത്രമേ ഇത് നന്നായി പ്രവർത്തിക്കൂ - അത്തരം ഒരു നിഘണ്ടുവിൽ ചൈനീസ് ഭാഷയിലുള്ള ഒരു വരി ചേർക്കാൻ കഴിയില്ല.

പ്രത്യേകമായി, അത്തരം ഒരു ഡാറ്റാ ഘടനയിൽ 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% കൂടുതൽ കോംപാക്ട്.

ഫോമിൽ എൻകോഡിംഗ്, ഡീകോഡിംഗ് അൽഗോരിതങ്ങൾ നടപ്പിലാക്കുന്നതിന്റെ ഉദാഹരണങ്ങൾ ഞാൻ അവതരിപ്പിച്ചു JavaScript, Go ലൈബ്രറികൾ, നിങ്ങൾക്ക് അവ നിങ്ങളുടെ കോഡിൽ സ്വതന്ത്രമായി ഉപയോഗിക്കാം. എന്നാൽ ഒരർത്ഥത്തിൽ ഈ ഫോർമാറ്റ് ഒരു "സൈക്കിൾ" ആയി തുടരുന്നുവെന്ന് ഞാൻ ഇപ്പോഴും ഊന്നിപ്പറയുന്നു, ഇത് ഉപയോഗിക്കാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നില്ല എന്തുകൊണ്ടാണ് നിങ്ങൾക്ക് ഇത് ആവശ്യമെന്ന് മനസിലാക്കാതെ. ഗുരുതരമായ "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-ലേക്ക് (പൊതുവായി മറ്റേതെങ്കിലും പ്രതീകങ്ങളിലേക്കും) മടങ്ങാനുള്ള അവസരം നഷ്‌ടപ്പെടും. അതിനാൽ ഞങ്ങൾ ഇത് ചെയ്യുന്നു:

1. രണ്ട് ബൈറ്റുകൾ 10yyyyyy yxxxxxxx ഒരു സംഖ്യയുള്ള ഒരു ചിഹ്നത്തെ സൂചിപ്പിക്കുക മാത്രമല്ല yyyyyy yxxxxxxx, മാത്രമല്ല മാറ്റം നിലവിലെ അക്ഷരമാല ഓൺ yyyyyy y0000000 (അതായത്, പ്രാധാന്യമില്ലാത്തവ ഒഴികെയുള്ള എല്ലാ ബിറ്റുകളും ഞങ്ങൾ ഓർക്കുന്നു 7 ബിറ്റ്);
2. ഒരു ബൈറ്റ് 0xxxxxxx ഇതാണ് നിലവിലെ അക്ഷരമാലയുടെ സ്വഭാവം. ഘട്ടം 1-ൽ ഞങ്ങൾ ഓർത്തിരിക്കുന്ന ഓഫ്‌സെറ്റിലേക്ക് ഇത് ചേർക്കേണ്ടതുണ്ട്. ഞങ്ങൾ അക്ഷരമാല മാറ്റിയിട്ടില്ലെങ്കിലും, ഓഫ്‌സെറ്റ് പൂജ്യമാണ്, അതിനാൽ ഞങ്ങൾ ASCII-യുമായി അനുയോജ്യത നിലനിർത്തി.

അതുപോലെ 3 ബൈറ്റുകൾ ആവശ്യമുള്ള കോഡുകൾക്ക്:

1. മൂന്ന് ബൈറ്റുകൾ 110yyyyy yxxxxxxx xxxxxxxx ഒരു സംഖ്യയുള്ള ഒരു ചിഹ്നം സൂചിപ്പിക്കുക yyyyyy yxxxxxxx xxxxxxxx, മാറ്റം നിലവിലെ അക്ഷരമാല ഓൺ yyyyyy y0000000 00000000 (ചെറുപ്പക്കാരൊഴികെ എല്ലാം ഓർത്തു 15 ബിറ്റ്), ഞങ്ങൾ ഇപ്പോൾ ഉള്ള ബോക്സ് ചെക്ക് ചെയ്യുക നീളമുള്ള മോഡ് (അക്ഷരമാല ഒരു ഇരട്ട-ബൈറ്റിലേക്ക് മാറ്റുമ്പോൾ, ഞങ്ങൾ ഈ ഫ്ലാഗ് പുനഃസജ്ജമാക്കും);
2. രണ്ട് ബൈറ്റുകൾ 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, കൂടാതെ യൂണികോഡ് നേരത്തെ അവസാനിക്കുന്നു, at 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 എൻകോഡർ എന്റെ അൽഗോരിതത്തേക്കാൾ സങ്കീർണ്ണവും കൂടുതൽ ബുദ്ധിമുട്ടുള്ളതുമായിരിക്കും.

താരതമ്യത്തിനായി, ഞാൻ എസ്‌സി‌എസ്‌യുവിന്റെ താരതമ്യേന ലളിതമായ നടപ്പാക്കൽ ജാവാസ്‌ക്രിപ്റ്റിലേക്ക് മാറ്റി - കോഡ് വോളിയത്തിന്റെ കാര്യത്തിൽ ഇത് എന്റെ യു‌ടി‌എഫ്-സിയുമായി താരതമ്യപ്പെടുത്താവുന്നതായി മാറി, പക്ഷേ ചില സന്ദർഭങ്ങളിൽ ഫലം പതിനായിരക്കണക്കിന് ശതമാനം മോശമായിരുന്നു (ചിലപ്പോൾ അത് കവിഞ്ഞേക്കാം, പക്ഷേ അധികം അല്ല). ഉദാഹരണത്തിന്, ഹീബ്രു, ഗ്രീക്ക് ഭാഷകളിലുള്ള പാഠങ്ങൾ യുടിഎഫ്-സി എൻകോഡ് ചെയ്തു എസ്‌സി‌എസ്‌യുവിനേക്കാൾ 60% മികച്ചത് (ഒരുപക്ഷേ അവയുടെ ഒതുക്കമുള്ള അക്ഷരമാലകൾ മൂലമാകാം).

യൂണികോഡിനെ ഒതുക്കമുള്ള രീതിയിൽ പ്രതിനിധീകരിക്കാൻ എസ്‌സി‌എസ്‌യു കൂടാതെ മറ്റൊരു മാർഗമുണ്ടെന്ന് ഞാൻ പ്രത്യേകം ചേർക്കും - BOCU-1, എന്നാൽ ഇത് MIME അനുയോജ്യത ലക്ഷ്യമിടുന്നു (എനിക്ക് ആവശ്യമില്ലാത്തത്) കൂടാതെ എൻകോഡിംഗിൽ അല്പം വ്യത്യസ്തമായ സമീപനം സ്വീകരിക്കുന്നു. അതിന്റെ ഫലപ്രാപ്തി ഞാൻ വിലയിരുത്തിയിട്ടില്ല, പക്ഷേ ഇത് SCSU-നേക്കാൾ ഉയർന്നതായിരിക്കാൻ സാധ്യതയില്ലെന്ന് എനിക്ക് തോന്നുന്നു.

സാധ്യമായ മെച്ചപ്പെടുത്തലുകൾ

ഞാൻ അവതരിപ്പിച്ച അൽഗോരിതം രൂപകൽപ്പന പ്രകാരം സാർവത്രികമല്ല (ഒരുപക്ഷേ എന്റെ ലക്ഷ്യങ്ങൾ യൂണികോഡ് കൺസോർഷ്യത്തിന്റെ ലക്ഷ്യങ്ങളിൽ നിന്ന് വ്യതിചലിക്കുന്നത് ഇവിടെയാണ്). ഇത് പ്രാഥമികമായി ഒരു ടാസ്‌ക്കിനായി വികസിപ്പിച്ചതാണെന്ന് ഞാൻ ഇതിനകം സൂചിപ്പിച്ചിട്ടുണ്ട് (ഒരു ബഹുഭാഷാ നിഘണ്ടു ഒരു പ്രിഫിക്‌സ് ട്രീയിൽ സൂക്ഷിക്കുന്നു), അതിന്റെ ചില സവിശേഷതകൾ മറ്റ് ജോലികൾക്ക് അനുയോജ്യമല്ലായിരിക്കാം. എന്നാൽ ഇത് ഒരു മാനദണ്ഡമല്ല എന്നത് ഒരു പ്ലസ് ആകാം - നിങ്ങളുടെ ആവശ്യങ്ങൾക്ക് അനുസൃതമായി നിങ്ങൾക്ക് ഇത് എളുപ്പത്തിൽ പരിഷ്കരിക്കാനാകും.

ഉദാഹരണത്തിന്, വ്യക്തമായ രീതിയിൽ നിങ്ങൾക്ക് സംസ്ഥാനത്തിന്റെ സാന്നിധ്യം ഒഴിവാക്കാം, സ്‌റ്റേറ്റ്‌ലെസ് കോഡിംഗ് നടത്താം - വേരിയബിളുകൾ അപ്‌ഡേറ്റ് ചെയ്യരുത് offs, auxOffs и is21Bit എൻകോഡറിലും ഡീകോഡറിലും. ഈ സാഹചര്യത്തിൽ, ഒരേ അക്ഷരമാലയിലെ പ്രതീകങ്ങളുടെ സീക്വൻസുകൾ ഫലപ്രദമായി പായ്ക്ക് ചെയ്യാൻ കഴിയില്ല, എന്നാൽ സന്ദർഭം പരിഗണിക്കാതെ തന്നെ ഒരേ പ്രതീകം എല്ലായ്പ്പോഴും ഒരേ ബൈറ്റുകൾ ഉപയോഗിച്ച് എൻകോഡ് ചെയ്തിട്ടുണ്ടെന്ന് ഒരു ഗ്യാരണ്ടി ഉണ്ടാകും.

കൂടാതെ, ഡിഫോൾട്ട് അവസ്ഥ മാറ്റിക്കൊണ്ട് നിങ്ങൾക്ക് ഒരു നിർദ്ദിഷ്ട ഭാഷയിലേക്ക് എൻകോഡറിനെ ക്രമീകരിക്കാൻ കഴിയും - ഉദാഹരണത്തിന്, റഷ്യൻ ടെക്സ്റ്റുകളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുക, തുടക്കത്തിൽ എൻകോഡറും ഡീകോഡറും സജ്ജമാക്കുക offs = 0x0400 и auxOffs = 0. സ്‌റ്റേറ്റ്‌ലെസ് മോഡിന്റെ കാര്യത്തിൽ ഇത് പ്രത്യേകിച്ചും അർത്ഥവത്താണ്. പൊതുവേ, ഇത് പഴയ എട്ട്-ബിറ്റ് എൻകോഡിംഗ് ഉപയോഗിക്കുന്നതിന് സമാനമായിരിക്കും, എന്നാൽ ആവശ്യാനുസരണം എല്ലാ യൂണിക്കോഡിൽ നിന്നും പ്രതീകങ്ങൾ ചേർക്കാനുള്ള കഴിവ് നീക്കം ചെയ്യാതെ തന്നെ.

നേരത്തെ സൂചിപ്പിച്ച മറ്റൊരു പോരായ്മ, UTF-C-യിൽ എൻകോഡ് ചെയ്‌തിരിക്കുന്ന വലിയ ടെക്‌സ്‌റ്റിൽ ഒരു അനിയന്ത്രിതമായ ബൈറ്റിന് ഏറ്റവും അടുത്തുള്ള പ്രതീക അതിർത്തി കണ്ടെത്താൻ വേഗത്തിലുള്ള മാർഗമില്ല എന്നതാണ്. എൻകോഡ് ചെയ്‌ത ബഫറിൽ നിന്ന് അവസാനത്തേത് 100 ബൈറ്റുകൾ മുറിച്ചുമാറ്റിയാൽ, നിങ്ങൾക്ക് ഒന്നും ചെയ്യാൻ കഴിയാത്ത മാലിന്യം ലഭിക്കാൻ സാധ്യതയുണ്ട്. മൾട്ടി-ജിഗാബൈറ്റ് ലോഗുകൾ സംഭരിക്കുന്നതിനായി എൻകോഡിംഗ് രൂപകൽപ്പന ചെയ്തിട്ടില്ല, എന്നാൽ പൊതുവേ ഇത് ശരിയാക്കാവുന്നതാണ്. ബൈറ്റ് 0xBF ആദ്യ ബൈറ്റായി ഒരിക്കലും ദൃശ്യമാകരുത് (എന്നാൽ രണ്ടാമത്തേതോ മൂന്നാമത്തേതോ ആകാം). അതിനാൽ, എൻകോഡ് ചെയ്യുമ്പോൾ, നിങ്ങൾക്ക് ക്രമം തിരുകാൻ കഴിയും 0xBF 0xBF 0xBF ഓരോന്നും പറയുക, 10 KB - അപ്പോൾ, നിങ്ങൾക്ക് ഒരു അതിർത്തി കണ്ടെത്തണമെങ്കിൽ, സമാനമായ ഒരു മാർക്കർ കണ്ടെത്തുന്നതുവരെ തിരഞ്ഞെടുത്ത ഭാഗം സ്കാൻ ചെയ്താൽ മതിയാകും. അവസാനത്തെ പിന്തുടരുന്നു 0xBF ഒരു കഥാപാത്രത്തിന്റെ തുടക്കമാകുമെന്ന് ഉറപ്പ്. (ഡീകോഡ് ചെയ്യുമ്പോൾ, മൂന്ന് ബൈറ്റുകളുടെ ഈ ക്രമം തീർച്ചയായും അവഗണിക്കേണ്ടതുണ്ട്.)

ചുരുക്കത്തിൽ

നിങ്ങൾ ഇത് വരെ വായിച്ചിട്ടുണ്ടെങ്കിൽ, അഭിനന്ദനങ്ങൾ! യൂണിക്കോഡിന്റെ ഘടനയെക്കുറിച്ച് എന്നെപ്പോലെ നിങ്ങളും പുതിയ എന്തെങ്കിലും (അല്ലെങ്കിൽ നിങ്ങളുടെ ഓർമ്മ പുതുക്കി) പഠിച്ചുവെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു.

ഡെമോ പേജ്. യുടിഎഫ്-8, എസ്‌സി‌എസ്‌യു എന്നിവയെക്കാളും ഗുണങ്ങൾ ഹീബ്രൂവിന്റെ ഉദാഹരണം കാണിക്കുന്നു.

മുകളിൽ വിവരിച്ച ഗവേഷണം മാനദണ്ഡങ്ങളുടെ മേലുള്ള കടന്നുകയറ്റമായി കണക്കാക്കരുത്. എന്നിരുന്നാലും, എന്റെ ജോലിയുടെ ഫലങ്ങളിൽ ഞാൻ പൊതുവെ സംതൃപ്തനാണ്, അതിനാൽ ഞാൻ അവരിൽ സന്തുഷ്ടനാണ് പങ്ക്: ഉദാഹരണത്തിന്, ഒരു മിനിഫൈഡ് JS ലൈബ്രറിയുടെ ഭാരം 1710 ബൈറ്റുകൾ മാത്രമാണ് (തീർച്ചയായും ഡിപൻഡൻസികളൊന്നുമില്ല). ഞാൻ മുകളിൽ സൂചിപ്പിച്ചതുപോലെ, അവളുടെ ജോലി ഇവിടെ കാണാം ഡെമോ പേജ് (UTF-8, SCSU എന്നിവയുമായി താരതമ്യപ്പെടുത്താവുന്ന ഒരു കൂട്ടം ടെക്‌സ്‌റ്റുകളും ഉണ്ട്).

അവസാനമായി, UTF-C ഉപയോഗിക്കുന്ന കേസുകളിലേക്ക് ഞാൻ ഒരിക്കൽ കൂടി ശ്രദ്ധ ആകർഷിക്കും അത് ശരിയല്ല:

• നിങ്ങളുടെ വരികൾ ദൈർഘ്യമേറിയതാണെങ്കിൽ (100-200 പ്രതീകങ്ങളിൽ നിന്ന്). ഈ സാഹചര്യത്തിൽ, ഡിഫ്ലേറ്റ് പോലുള്ള കംപ്രഷൻ അൽഗോരിതങ്ങൾ ഉപയോഗിക്കുന്നതിനെക്കുറിച്ച് നിങ്ങൾ ചിന്തിക്കണം.
• നിനക്ക് ആവശ്യമെങ്കിൽ ASCII സുതാര്യത, അതായത്, എൻകോഡ് ചെയ്ത സീക്വൻസുകളിൽ യഥാർത്ഥ സ്‌ട്രിംഗിൽ ഇല്ലാത്ത ASCII കോഡുകൾ അടങ്ങിയിട്ടില്ല എന്നത് നിങ്ങൾക്ക് പ്രധാനമാണ്. മൂന്നാം കക്ഷി API-കളുമായി സംവദിക്കുമ്പോൾ (ഉദാഹരണത്തിന്, ഒരു ഡാറ്റാബേസുമായി പ്രവർത്തിക്കുമ്പോൾ), നിങ്ങൾ എൻകോഡിംഗ് ഫലം ബൈറ്റുകളുടെ ഒരു അമൂർത്തമായ സെറ്റായി നൽകുകയും സ്ട്രിംഗുകളായിട്ടല്ലെങ്കിൽ, ഇതിന്റെ ആവശ്യകത ഒഴിവാക്കാനാകും. അല്ലെങ്കിൽ, നിങ്ങൾക്ക് അപ്രതീക്ഷിതമായ കേടുപാടുകൾ ലഭിക്കാൻ സാധ്യതയുണ്ട്.
• ഒരു അനിയന്ത്രിതമായ ഓഫ്‌സെറ്റിൽ (ഉദാഹരണത്തിന്, ഒരു വരിയുടെ ഒരു ഭാഗം കേടാകുമ്പോൾ) പ്രതീക അതിരുകൾ വേഗത്തിൽ കണ്ടെത്താൻ നിങ്ങൾക്ക് കഴിയണമെങ്കിൽ. ഇത് ചെയ്യാൻ കഴിയും, പക്ഷേ ആദ്യം മുതൽ ലൈൻ സ്കാൻ ചെയ്യുക (അല്ലെങ്കിൽ മുമ്പത്തെ വിഭാഗത്തിൽ വിവരിച്ച പരിഷ്ക്കരണം പ്രയോഗിക്കുക).
• നിങ്ങൾക്ക് സ്ട്രിംഗുകളുടെ ഉള്ളടക്കത്തിൽ വേഗത്തിൽ പ്രവർത്തനങ്ങൾ നടത്തണമെങ്കിൽ (അവ അടുക്കുക, അവയിലെ സബ്‌സ്ട്രിംഗുകൾക്കായി തിരയുക, സംയോജിപ്പിക്കുക). ഇതിന് ആദ്യം സ്ട്രിംഗുകൾ ഡീകോഡ് ചെയ്യേണ്ടത് ആവശ്യമാണ്, അതിനാൽ UTF-C ഈ സന്ദർഭങ്ങളിൽ UTF-8 നേക്കാൾ വേഗത കുറവായിരിക്കും (എന്നാൽ കംപ്രഷൻ അൽഗോരിതങ്ങളേക്കാൾ വേഗതയുള്ളതാണ്). ഒരേ സ്ട്രിംഗ് എല്ലായ്പ്പോഴും ഒരേ രീതിയിൽ എൻകോഡ് ചെയ്തിരിക്കുന്നതിനാൽ, ഡീകോഡിംഗിന്റെ കൃത്യമായ താരതമ്യം ആവശ്യമില്ല, കൂടാതെ ബൈറ്റ്-ബൈ-ബൈറ്റ് അടിസ്ഥാനത്തിൽ ചെയ്യാനും കഴിയും.

അപ്ഡേറ്റ്: ഉപയോക്താവ് ടിയോമിച്ച് ചുവടെയുള്ള അഭിപ്രായങ്ങളിൽ UTF-C-യുടെ പ്രയോഗ പരിധികൾ ഉയർത്തിക്കാട്ടുന്ന ഒരു ഗ്രാഫ് പോസ്റ്റ് ചെയ്തു. പാക്ക് ചെയ്ത സ്ട്രിംഗ് ചെറുതായിരിക്കുന്നിടത്തോളം UTF-C ഒരു പൊതു-ഉദ്ദേശ്യ കംപ്രഷൻ അൽഗോരിതത്തേക്കാൾ (LZW ന്റെ ഒരു വ്യതിയാനം) കൂടുതൽ കാര്യക്ഷമമാണെന്ന് ഇത് കാണിക്കുന്നു. ~140 പ്രതീകങ്ങൾ (എന്നിരുന്നാലും, താരതമ്യം ഒരു വാചകത്തിൽ നടത്തിയതാണെന്ന് ഞാൻ ശ്രദ്ധിക്കുന്നു; മറ്റ് ഭാഷകളിൽ ഫലം വ്യത്യസ്തമായിരിക്കും).


അവലംബം: www.habr.com