আরেকটি বাইক: আমরা ইউনিকোড স্ট্রিংগুলি 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 বিট দেয়) যথেষ্ট হবে, তবে পরিষেবা চিহ্নিতকারীরা খুব বেশি খায়।

এই খারাপ? আসলে তা না. একদিকে, যদি আমরা স্থান সম্পর্কে অনেক যত্ন করি, আমাদের কম্প্রেশন অ্যালগরিদম রয়েছে যা সহজেই সমস্ত অতিরিক্ত এনট্রপি এবং অপ্রয়োজনীয়তা দূর করতে পারে। অন্যদিকে, ইউনিকোডের লক্ষ্য ছিল সম্ভাব্য সর্বাধিক সর্বজনীন কোডিং প্রদান করা। উদাহরণস্বরূপ, আমরা UTF-8-এ এনকোড করা একটি লাইনকে কোডের জন্য অর্পণ করতে পারি যেটি আগে শুধুমাত্র ASCII-এর সাথে কাজ করেছিল এবং ভয় পাবেন না যে এটি ASCII পরিসরের একটি অক্ষর দেখতে পাবে যা আসলে সেখানে নেই (সর্বশেষে, UTF-8-এ সমস্ত শূন্য বিট থেকে শুরু করা বাইট - এটিই ASCII)। এবং যদি আমরা হঠাৎ করে শুরু থেকেই ডিকোড না করে একটি বড় স্ট্রিং থেকে একটি ছোট লেজ কেটে ফেলতে চাই (অথবা ক্ষতিগ্রস্থ অংশের পরে তথ্যের অংশ পুনরুদ্ধার করুন), আমাদের পক্ষে অফসেটটি খুঁজে পাওয়া সহজ যেখানে একটি অক্ষর শুরু হয় (এটি যথেষ্ট। একটি বিট উপসর্গ আছে যে বাইট এড়িয়ে যেতে 10).

তাহলে নতুন কিছু উদ্ভাবন কেন?

একই সময়ে, মাঝে মাঝে এমন পরিস্থিতি রয়েছে যখন ডিফ্লেটের মতো কম্প্রেশন অ্যালগরিদমগুলি খারাপভাবে প্রযোজ্য, কিন্তু আপনি স্ট্রিংগুলির কমপ্যাক্ট স্টোরেজ অর্জন করতে চান। ব্যক্তিগতভাবে, বিল্ডিং সম্পর্কে চিন্তা করার সময় আমি এই সমস্যার সম্মুখীন হয়েছি সংকুচিত উপসর্গ গাছ নির্বিচারে ভাষার শব্দ সহ একটি বড় অভিধানের জন্য। একদিকে, প্রতিটি শব্দ খুব ছোট, তাই এটি সংকুচিত করা অকার্যকর হবে। অন্যদিকে, আমি যে ট্রি বাস্তবায়ন বিবেচনা করেছি তা এমনভাবে ডিজাইন করা হয়েছে যাতে সঞ্চিত স্ট্রিংয়ের প্রতিটি বাইট একটি পৃথক ট্রি শীর্ষবিন্দু তৈরি করে, তাই তাদের সংখ্যা হ্রাস করা খুব দরকারী ছিল। আমার লাইব্রেরিতে Az.js (যেমন মধ্যে pymorphy2, যার উপর ভিত্তি করে) একটি অনুরূপ সমস্যা সহজভাবে সমাধান করা যেতে পারে - স্ট্রিংগুলি প্যাক করা 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% বেশি কমপ্যাক্ট.

আমি ফর্মে এনকোডিং এবং ডিকোডিং অ্যালগরিদম বাস্তবায়নের উদাহরণ উপস্থাপন করেছি জাভাস্ক্রিপ্ট এবং গো লাইব্রেরি, আপনি অবাধে আপনার কোড ব্যবহার করতে পারেন. তবে আমি এখনও জোর দেব যে এক অর্থে এই ফর্ম্যাটটি একটি "বাইসাইকেল" হিসাবে রয়ে গেছে এবং আমি এটি ব্যবহার করার পরামর্শ দিই না আপনার কেন প্রয়োজন তা বুঝতে না পেরে. এটি এখনও একটি গুরুতর "ইউটিএফ-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, এবং ইউনিকোড আগে শেষ হয়, এ 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 এর একটি তুলনামূলকভাবে সহজ বাস্তবায়ন স্থানান্তর করেছি - কোড ভলিউমের পরিপ্রেক্ষিতে এটি আমার UTF-C-এর সাথে তুলনীয় বলে প্রমাণিত হয়েছে, তবে কিছু ক্ষেত্রে ফলাফল দশ শতাংশ খারাপ ছিল (কখনও কখনও এটি অতিক্রম করতে পারে, কিন্তু খুব বেশি নয়)। উদাহরণস্বরূপ, হিব্রু এবং গ্রীক ভাষায় পাঠ্যগুলি UTF-C দ্বারা এনকোড করা হয়েছিল SCSU থেকে 60% ভালো (সম্ভবত তাদের কমপ্যাক্ট বর্ণমালার কারণে)।

আলাদাভাবে, আমি যোগ করব যে SCSU ছাড়াও ইউনিকোডকে কম্প্যাক্টলি প্রতিনিধিত্ব করার আরেকটি উপায় রয়েছে - BOCU-1, কিন্তু এটি MIME সামঞ্জস্যের জন্য লক্ষ্য করে (যা আমার প্রয়োজন ছিল না) এবং এনকোডিংয়ের জন্য একটু ভিন্ন পদ্ধতি গ্রহণ করে। আমি এর কার্যকারিতা মূল্যায়ন করিনি, তবে আমার কাছে মনে হচ্ছে এটি SCSU এর চেয়ে বেশি হওয়ার সম্ভাবনা কম।

সম্ভাব্য উন্নতি

আমি যে অ্যালগরিদমটি উপস্থাপন করেছি তা ডিজাইনের দ্বারা সর্বজনীন নয় (সম্ভবত এখানেই আমার লক্ষ্যগুলি ইউনিকোড কনসোর্টিয়ামের লক্ষ্যগুলি থেকে বিচ্ছিন্ন হয়)। আমি ইতিমধ্যে উল্লেখ করেছি যে এটি প্রাথমিকভাবে একটি কাজের জন্য তৈরি করা হয়েছিল (একটি উপসর্গ গাছে একটি বহুভাষিক অভিধান সংরক্ষণ করা), এবং এর কিছু বৈশিষ্ট্য অন্যান্য কাজের জন্য উপযুক্ত নাও হতে পারে। কিন্তু সত্য যে এটি একটি মান নয় একটি প্লাস হতে পারে - আপনি সহজেই আপনার প্রয়োজন অনুসারে এটি পরিবর্তন করতে পারেন.

উদাহরণস্বরূপ, সুস্পষ্ট উপায়ে আপনি রাষ্ট্রের উপস্থিতি থেকে মুক্তি পেতে পারেন, রাষ্ট্রহীন কোডিং করতে পারেন - শুধু ভেরিয়েবল আপডেট করবেন না offs, auxOffs и is21Bit এনকোডার এবং ডিকোডারে। এই ক্ষেত্রে, একই বর্ণমালার অক্ষরগুলির ক্রমগুলিকে কার্যকরভাবে প্যাক করা সম্ভব হবে না, তবে একটি গ্যারান্টি থাকবে যে একই অক্ষর সর্বদা একই বাইটের সাথে এনকোড করা হবে, প্রসঙ্গ নির্বিশেষে।

এছাড়াও, আপনি ডিফল্ট অবস্থা পরিবর্তন করে একটি নির্দিষ্ট ভাষায় এনকোডারকে টেইলার করতে পারেন - উদাহরণস্বরূপ, রাশিয়ান পাঠ্যগুলিতে ফোকাস করে, শুরুতে এনকোডার এবং ডিকোডার সেট করুন offs = 0x0400 и auxOffs = 0. এটি বিশেষ করে স্টেটলেস মোডের ক্ষেত্রে বোঝা যায়। সাধারণভাবে, এটি পুরানো আট-বিট এনকোডিং ব্যবহার করার মতোই হবে, তবে প্রয়োজন অনুসারে সমস্ত ইউনিকোড থেকে অক্ষর সন্নিবেশ করার ক্ষমতা সরিয়ে না দিয়ে।

আগে উল্লিখিত আরেকটি অপূর্ণতা হল যে UTF-C-তে এনকোড করা বড় টেক্সটে একটি স্বেচ্ছাচারী বাইটের কাছাকাছি অক্ষরের সীমানা খুঁজে বের করার কোন দ্রুত উপায় নেই। যদি আপনি শেষটি কেটে দেন, বলুন, এনকোড করা বাফার থেকে 100 বাইট, আপনি আবর্জনা পাওয়ার ঝুঁকিতে থাকবেন যা দিয়ে আপনি কিছুই করতে পারবেন না। এনকোডিং মাল্টি-গিগাবাইট লগ সংরক্ষণের জন্য ডিজাইন করা হয়নি, তবে সাধারণভাবে এটি সংশোধন করা যেতে পারে। বাইট 0xBF প্রথম বাইট হিসাবে কখনই প্রদর্শিত হবে না (তবে দ্বিতীয় বা তৃতীয় হতে পারে)। অতএব, এনকোডিং করার সময়, আপনি ক্রম সন্নিবেশ করতে পারেন 0xBF 0xBF 0xBF প্রতিটি, বলুন, 10 KB - তারপরে, যদি আপনার একটি সীমানা খুঁজে বের করতে হয়, তাহলে অনুরূপ মার্কার না পাওয়া পর্যন্ত নির্বাচিত অংশটি স্ক্যান করা যথেষ্ট হবে। শেষ অনুসরণ 0xBF একটি চরিত্রের সূচনা হবে নিশ্চিত করা হয়. (ডিকোড করার সময়, তিনটি বাইটের এই ক্রমটি অবশ্যই উপেক্ষা করা প্রয়োজন।)

সংক্ষিপ্ত বিবরণ

আপনি যদি এই পর্যন্ত পড়ে থাকেন, অভিনন্দন! আমি আশা করি আপনি, আমার মতো, ইউনিকোডের গঠন সম্পর্কে নতুন কিছু শিখেছেন (বা আপনার স্মৃতিকে সতেজ করেছেন)।

ডেমো পৃষ্ঠা। হিব্রু উদাহরণটি UTF-8 এবং SCSU উভয়ের উপর সুবিধাগুলি দেখায়।

উপরে বর্ণিত গবেষণাকে মানদণ্ডের উপর সীমাবদ্ধতা হিসাবে বিবেচনা করা উচিত নয়। যাইহোক, আমি সাধারণত আমার কাজের ফলাফল নিয়ে সন্তুষ্ট, তাই আমি তাদের সাথে খুশি ভাগ: উদাহরণস্বরূপ, একটি ছোট JS লাইব্রেরির ওজন মাত্র 1710 বাইট (এবং অবশ্যই কোন নির্ভরতা নেই)। আমি উপরে উল্লিখিত হিসাবে, তার কাজ পাওয়া যাবে ডেমো পৃষ্ঠা (এছাড়াও পাঠ্যের একটি সেট রয়েছে যার উপর এটি UTF-8 এবং SCSU এর সাথে তুলনা করা যেতে পারে)।

অবশেষে, আমি আবারও যে ক্ষেত্রে UTF-C ব্যবহার করা হয় সেগুলির প্রতি দৃষ্টি আকর্ষণ করব এটা মূল্য না:

• যদি আপনার লাইন যথেষ্ট দীর্ঘ হয় (100-200 অক্ষর থেকে)। এই ক্ষেত্রে, আপনি deflate মত কম্প্রেশন অ্যালগরিদম ব্যবহার সম্পর্কে চিন্তা করা উচিত.
• যদি তুমি চাও ASCII স্বচ্ছতা, অর্থাৎ, এটি আপনার জন্য গুরুত্বপূর্ণ যে এনকোড করা ক্রমগুলিতে ASCII কোডগুলি নেই যা মূল স্ট্রিং-এ ছিল না৷ এটির প্রয়োজনীয়তা এড়ানো যেতে পারে যদি, তৃতীয় পক্ষের API-এর সাথে ইন্টারঅ্যাক্ট করার সময় (উদাহরণস্বরূপ, একটি ডাটাবেসের সাথে কাজ করা), আপনি এনকোডিং ফলাফলকে বাইটের একটি বিমূর্ত সেট হিসাবে পাস করেন, স্ট্রিং হিসাবে নয়। অন্যথায়, আপনি অপ্রত্যাশিত দুর্বলতা পেতে ঝুঁকি.
• আপনি যদি একটি নির্বিচারে অফসেটে দ্রুত অক্ষরের সীমানা খুঁজে পেতে সক্ষম হতে চান (উদাহরণস্বরূপ, যখন একটি লাইনের অংশ ক্ষতিগ্রস্ত হয়)। এটি করা যেতে পারে, তবে শুধুমাত্র শুরু থেকে লাইনটি স্ক্যান করে (বা পূর্ববর্তী বিভাগে বর্ণিত পরিবর্তনটি প্রয়োগ করে)।
• আপনার যদি স্ট্রিংগুলির বিষয়বস্তুতে দ্রুত ক্রিয়াকলাপ সম্পাদন করতে হয় (এগুলি বাছাই করুন, তাদের মধ্যে সাবস্ট্রিংগুলি অনুসন্ধান করুন, সংযুক্ত করুন)। এর জন্য প্রথমে স্ট্রিংগুলিকে ডিকোড করতে হবে, তাই এই ক্ষেত্রে UTF-C UTF-8 এর চেয়ে ধীর হবে (কিন্তু কম্প্রেশন অ্যালগরিদমের চেয়ে দ্রুত)। যেহেতু একই স্ট্রিং সবসময় একইভাবে এনকোড করা হয়, তাই ডিকোডিংয়ের সঠিক তুলনার প্রয়োজন হয় না এবং বাইট-বাই-বাইটের ভিত্তিতে করা যেতে পারে।

আপডেট: ব্যবহারকারী টাইওমিচ নীচের মন্তব্যে UTF-C এর প্রযোজ্যতা সীমা হাইলাইট করে একটি গ্রাফ পোস্ট করেছে৷ এটি দেখায় যে UTF-C একটি সাধারণ-উদ্দেশ্য কম্প্রেশন অ্যালগরিদম (LZW এর একটি বৈচিত্র) থেকে বেশি দক্ষ যতক্ষণ পর্যন্ত প্যাক করা স্ট্রিংটি ছোট হয় ~140 অক্ষর (তবে, আমি লক্ষ্য করেছি যে তুলনাটি একটি পাঠ্যে করা হয়েছিল; অন্যান্য ভাষার জন্য ফলাফলটি আলাদা হতে পারে)।


উত্স: www.habr.com