ইউটিএফ -16 কে ক্ষতিকারক হিসাবে বিবেচনা করা উচিত?

432

আমি সম্ভবত এটি বেশ বিতর্কিত প্রশ্নটি জিজ্ঞাসা করতে যাচ্ছি: "সর্বাধিক জনপ্রিয় এনকোডিংগুলি ইউটিএফ -16 কে ক্ষতিকারক হিসাবে বিবেচনা করা উচিত?"

কেন আমি এই প্রশ্ন জিজ্ঞাসা?

ইউটিএফ -16 আসলে একটি পরিবর্তনশীল দৈর্ঘ্যের এনকোডিং হয় তা সম্পর্কে কতজন প্রোগ্রামার সচেতন? এর মাধ্যমে আমার অর্থ এই যে এখানে কোড পয়েন্ট রয়েছে যা সারোগেট জোড় হিসাবে উপস্থাপিত হয়, একাধিক উপাদান নেয়।

আমি জানি; প্রচুর অ্যাপ্লিকেশন, ফ্রেমওয়ার্ক এবং এপিআইগুলি ইউটিএফ -16 ব্যবহার করে, যেমন জাভার স্ট্রিং, সি # এর স্ট্রিং, উইন 32 এপিআই, কিউটি জিউআই লাইব্রেরি, আইসিইউ ইউনিকোড লাইব্রেরি ইত্যাদি। তবে, এই সবের সাথে প্রসেসিংয়ে প্রচুর বেসিক বাগ রয়েছে বিএমপি-এর বাইরে থাকা অক্ষরের (যে অক্ষরগুলি দুটি ইউটিএফ -16 উপাদান ব্যবহার করে এনকোড করা উচিত)।

উদাহরণস্বরূপ, এই অক্ষরগুলির মধ্যে একটি সম্পাদনা করার চেষ্টা করুন:

আপনি কোন ফন্টগুলি ইনস্টল করেছেন তার উপর নির্ভর করে আপনি কিছু মিস করতে পারেন। এই অক্ষরগুলি সমস্ত বিএমপির বাইরে (বেসিক বহুভাষিক প্লেন)। আপনি যদি এই অক্ষরগুলি দেখতে না পান তবে আপনি তাদের ইউনিকোড অক্ষর রেফারেন্সে দেখার চেষ্টা করতে পারেন ।

উদাহরণস্বরূপ, উইন্ডোগুলিতে এই অক্ষরগুলির অন্তর্ভুক্ত ফাইলের নাম তৈরি করার চেষ্টা করুন; ইউটিএফ -16 ব্যবহার করে এমন বিভিন্ন অ্যাপ্লিকেশনগুলিতে তারা কীভাবে আচরণ করে তা দেখতে "ব্যাকস্পেস" দিয়ে এই অক্ষরগুলি মুছার চেষ্টা করুন। আমি কিছু পরীক্ষা করেছি এবং ফলাফলগুলি বেশ খারাপ:

  • অপেরা তাদের সম্পাদনা করতে সমস্যা (ব্যাকস্পেসে প্রয়োজনীয় 2 টি প্রেস মুছুন)
  • নোটপ্যাড তাদের সাথে সঠিকভাবে ডিল করতে পারে না (ব্যাকস্পেসে প্রয়োজনীয় 2 টি প্রেস মুছুন)
  • উইন্ডো সংলাপগুলিতে ভাঙা ফাইলগুলির নাম সম্পাদনা (ব্যাকস্পেসে প্রয়োজনীয় 2 টি প্রেস মুছুন)
  • সমস্ত কিউটি 3 অ্যাপ্লিকেশনগুলি সেগুলি মোকাবেলা করতে পারে না - একটি চিহ্নের পরিবর্তে দুটি খালি স্কোয়ার দেখান ।
  • বিএমপির u'X'!=unicode('X','utf-16')বাইরের অক্ষরে এক্স থাকলে কিছু প্ল্যাটফর্মে সরাসরি ব্যবহৃত হলে পাইথন এ জাতীয় অক্ষরগুলিকে ভুলভাবে এনকোড করে ।
  • পাইথন 2.5 ইউনিকোডেটা এই অক্ষরগুলির বৈশিষ্ট্য পেতে ব্যর্থ হয় যখন পাইথনটি ইউটিএফ -16 ইউনিকোড স্ট্রিং দিয়ে সংকলিত হয়।
  • স্ট্যাকওভারফ্লো এই ইউনিকোড অক্ষর হিসাবে সরাসরি সম্পাদনা করা থাকলে এই অক্ষরগুলি পাঠ্য থেকে সরিয়ে ফেলবে বলে মনে হয় (এই অক্ষরগুলি এইচটিএমএল ইউনিকোড পলায়ন ব্যবহার করে দেখানো হয়)।
  • উইনফোর্ডস টেক্সটবক্স ম্যাক্সলেংথের সাথে সীমাবদ্ধ থাকলে অবৈধ স্ট্রিং তৈরি করতে পারে ।

দেখে মনে হচ্ছে যে ইউটিএফ -16 ব্যবহার করে এমন অ্যাপ্লিকেশনগুলিতে এই জাতীয় বাগগুলি খুঁজে পাওয়া চূড়ান্ত সহজ।

সুতরাং ... আপনি কি মনে করেন যে ইউটিএফ -16 কে ক্ষতিকারক হিসাবে বিবেচনা করা উচিত?

unicode 
— আর্টিয়াম om
সূত্র
64
সত্যিই সঠিক নয়। আমি ব্যাখ্যা করছি, আপনি যদি "שָׁ", "ָ" এবং "ׁ", স্বরবর্ণ সমন্বিত যৌগিক চরিত্রটি "שָׁ" লিখেন, তবে তাদের প্রত্যেকটির অপসারণ যৌক্তিক হয়, আপনি যখন চাপবেন তখন একটি কোড-পয়েন্ট মুছে ফেলবেন " ব্যাকস্পেস "এবং" ডেল "চাপলে স্বরযুক্ত সমস্ত অক্ষর মুছে ফেলুন। তবে, আপনি কখনই অবৈধ পাঠের স্থিতি তৈরি করবেন না - অবৈধ কোড পয়েন্ট। সুতরাং, আপনি যখন ব্যাকস্পেস টিপুন এবং অবৈধ পাঠ্য পেয়েছেন তখন পরিস্থিতিটি ভুল।
41
সিসকোআইফোন: যদি কোনও বাগটি "বিভিন্ন ব্যক্তি দ্বারা বহুবার বিভিন্ন সময়ে রিপোর্ট করা হয়" এবং তার কয়েক বছর পরে একজন ডেভেলপার একটি ডেভ ব্লগে লিখেছেন যে "বিশ্বাস করুন বা না করুন, আচরণটি বেশিরভাগ উদ্দেশ্যমূলক!", তারপর (বলতে গেলে) এটি হালকাভাবে) আমি মনে করি যে এটি সম্ভবত সেরা ডিজাইনের সিদ্ধান্ত হয়নি। :-) কেবল ইচ্ছাকৃতর অর্থ হ'ল এটি কোনও বাগ নয়।
145
দুর্দান্ত পোস্ট। ইউটিএফ -16 প্রকৃতপক্ষে "উভয় পৃথিবীর মধ্যে সবচেয়ে খারাপ": ইউটিএফ 8 এর পরিবর্তনশীল দৈর্ঘ্য, সমস্ত ইউনিকোডকে কভার করে, কাঁচা কোডপয়েন্টগুলিতে এবং থেকে ট্রান্সফর্মেশন অ্যালগরিদম প্রয়োজন হয়, এটি এএসসিআইআই-তে সীমাবদ্ধ থাকে এবং এর কোনও শেষ নেই। ইউটিএফ 32 নির্দিষ্ট দৈর্ঘ্যের, কোনও রূপান্তর প্রয়োজন না, তবে আরও স্থান নেয় এবং এন্ডিয়নেস সমস্যা রয়েছে has এতদূর ভাল, আপনি সিরিয়ালাইজেশনের জন্য ইউটিএফ 32 এবং অভ্যন্তরীণভাবে ইউটিএফ 8 ব্যবহার করতে পারেন। তবে ইউটিএফ 16 এর কোনও সুবিধা নেই: এটি এন্ডিয়ান-নির্ভর, এটি পরিবর্তনশীল দৈর্ঘ্যের, এটি প্রচুর জায়গা নেয়, এটি ASCII- সামঞ্জস্যপূর্ণ নয়। ইউটিএফ 16কে সঠিকভাবে মোকাবেলার জন্য প্রয়োজনীয় প্রচেষ্টাটি ইউটিএফ 8-তে আরও ভাল ব্যয় করা যেতে পারে।
— কেরেক এসবি
26
@Ian: হল UTF-8 করেনা হল UTF-8 হিসাবে একই আদেশ সহকারে আছে। আপনি ইউটিএফ -8 এ সারোগেটস রাখতে পারবেন না। ইউটিএফ -8 এমন কিছু হিসাবে মুখোশ দেয় না যা ইউটিএফ -16 ব্যবহার করে বেশিরভাগ প্রোগ্রামাররা এটি ভুল ব্যবহার করছে। আমি জানি. আমি এগুলি বারবার এবং বারবার দেখেছি।
— tchrist
18
এছাড়াও, ইউটিএফ -8 এর সমস্যা নেই কারণ প্রত্যেকে এটিকে ভেরিয়েবল প্রস্থের এনকোডিং হিসাবে বিবেচনা করে। ইউটিএফ -16 এর সমস্যা হওয়ার কারণ হ'ল প্রত্যেকে এটির সাথে একটি নির্দিষ্ট প্রস্থের এনকোডিংয়ের মতো আচরণ করে।
— ক্রিস্টোফার হামারস্ট্রিম

উত্তর:

340

এটি একটি পুরানো উত্তর। সর্বশেষ আপডেটের জন্য ইউটিএফ -8 সর্বত্র
দেখুন ।

মতামত: হ্যাঁ, ইউটিএফ -16 ক্ষতিকারক হিসাবে বিবেচনা করা উচিত । এর বিদ্যমান কারণটি হ'ল কারণ কিছু সময় আগে একটি বিভ্রান্ত বিশ্বাস ছিল যে বিদ্যাচার এখন ইউসিএস -4 যা হতে চলেছে।

ইউটিএফ -8 এর "অ্যাংলো-কেন্দ্রিকতা" সত্ত্বেও, এটি পাঠ্যের একমাত্র দরকারী এনকোডিং হিসাবে বিবেচনা করা উচিত। কেউ যুক্তি দিতে পারে যে প্রোগ্রামগুলির সোর্স কোড, ওয়েব পেজ এবং এক্সএমএল ফাইল, ওএস ফাইলের নাম এবং অন্যান্য কম্পিউটার থেকে কম্পিউটারের পাঠ্য ইন্টারফেসের অস্তিত্ব থাকা উচিত নয়। কিন্তু যখন তারা করেন, পাঠ্যটি কেবল মানব পাঠকদের জন্য নয়।

অন্যদিকে, ইউটিএফ -8 ওভারহেড অর্থ প্রদানের জন্য একটি ছোট দাম, যখন এর উল্লেখযোগ্য সুবিধা রয়েছে। অজানা কোডের সাথে সামঞ্জস্যের মতো সুবিধা যা স্রেফ স্ট্রিংগুলি দিয়ে যায় char*। এটি একটি দুর্দান্ত জিনিস। ইউটিএফ -8 এর তুলনায় ইউটিএফ -16 এ সংক্ষিপ্ত কিছু দরকারী চরিত্র রয়েছে।

আমি বিশ্বাস করি যে অন্য সমস্ত এনকোডিংগুলি শেষ পর্যন্ত মারা যাবে। এর সাথে জড়িত যে এমএস-উইন্ডোজ, জাভা, আইসিইউ, অজগর এটিকে তাদের প্রিয় হিসাবে ব্যবহার বন্ধ করে দেয়। দীর্ঘ গবেষণা এবং আলোচনার পরে, আমার সংস্থার উন্নয়ন সম্মেলনগুলি ওএস এপিআই কল বাদে অন্য কোথাও ইউটিএফ -16 ব্যবহার নিষিদ্ধ করে, এবং এটি আমাদের অ্যাপ্লিকেশনগুলিতে পারফরম্যান্সের গুরুত্ব এবং আমরা উইন্ডোজ ব্যবহার করি এই সত্য সত্ত্বেও। রূপান্তর ফাংশনগুলি সর্বদা-ধরে নেওয়া-ইউটিএফ 8 std::stringগুলি স্থানীয় ইউটিএফ -16 এ রূপান্তর করতে বিকশিত হয়েছিল , যা উইন্ডোজ নিজেই যথাযথভাবে সমর্থন করে না ।

যে লোকেরা " যেখানে প্রয়োজন সেখানে যা প্রয়োজন সেখানে ব্যবহার করুন " বলে আমি বলি: সর্বত্র একই এনকোডিংটি ব্যবহার করার একটি বিশাল সুবিধা রয়েছে এবং আমি অন্যথায় করার যথেষ্ট কারণ দেখতে পাচ্ছি না। বিশেষত, আমি মনে করি wchar_tসি ++ যুক্ত করা একটি ভুল ছিল এবং সি ++ 0 এক্স-তে ইউনিকোড সংযোজনগুলিও রয়েছে। এসটিএল বাস্তবায়ন থেকে যা দাবি করা আবশ্যক তা হ'ল প্রতিটি std::stringবা char*পরামিতি ইউনিকোড-সামঞ্জস্যপূর্ণ বলে বিবেচিত হবে।

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

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

  • ব্যবহার করবেন না wchar_tবা std::wstringকোন হল UTF-16 গ্রহণ API গুলি সংলগ্ন বিন্দু ছাড়া অন্য জায়গায়।
  • ব্যবহার করবেন না _T("")বা L""হল UTF-16 লিটারেল (এই আইএমও মান আউট হল UTF-16 থামিয়ে দেওয়া একটি অংশ হিসাবে গ্রহণ করা উচিত)।
  • ধরনের, ফাংশন বা তাদের ডেরাইভেটিভস যে সংবেদনশীল ব্যবহার করবেন না _UNICODE, যেমন ধ্রুব LPTSTRবা CreateWindow()।
  • তবুও, _UNICODEসর্বদা সংজ্ঞায়িত, char*উইনএপিআইতে নীরবে সংকলিত হওয়া স্ট্রিংগুলি এড়ানোর জন্য
  • std::stringsএবং char*প্রোগ্রামের যে কোনও জায়গায় ইউটিএফ -8 হিসাবে বিবেচিত হয় (অন্যথায় বলা না হলে)
  • আমার সমস্ত স্ট্রিংগুলি std::stringযদিও আপনি চর * বা স্ট্রিংটিতে আক্ষরিক সাথে পার করতে পারেন convert(const std::string &)।

  • কেবল উইন 32 ফাংশনগুলি ব্যবহার করুন যা উইডারদের গ্রহণ করে ( LPWSTR)। যাঁরা গ্রহণ করেন LPTSTRবা করেন না LPSTR। এইভাবে প্যারামিটারগুলি পাস করুন:

    ::SetWindowTextW(Utils::convert(someStdString or "string litteral").c_str())

    (নীতিটি নীচে রূপান্তর ফাংশন ব্যবহার করে))

  • এমএফসি স্ট্রিং সহ:

    CString someoneElse; // something that arrived from MFC. Converted as soon as possible, before passing any further away from the API call:

std::string s = str(boost::format("Hello %s\n") % Convert(someoneElse));
AfxMessageBox(MfcUtils::Convert(s), _T("Error"), MB_OK);

  • উইন্ডোজে ফাইল, ফাইলের নাম এবং এফ স্ট্রিমের সাথে কাজ করা:

    • পাস কখনও std::stringবা const char*করার ফাইলের নাম আর্গুমেন্ট fstreamপরিবার। এমএসভিসি এসটিএল ইউটিএফ -8 টি যুক্তি সমর্থন করে না, তবে একটি মানহীন এক্সটেনশন রয়েছে যা নিম্নলিখিত হিসাবে ব্যবহার করা উচিত:

    • রূপান্তর করুন std::stringআর্গুমেন্ট std::wstringসঙ্গে Utils::Convert:

      std::ifstream ifs(Utils::Convert("hello"),
                  std::ios_base::in |
                  std::ios_base::binary);

      যখন এমএসভিসির দৃষ্টিভঙ্গি fstreamপরিবর্তিত হয় তখন আমাদের ম্যানুয়ালি রূপান্তর করতে হবে ।

    • এই কোডটি মাল্টি-প্ল্যাটফর্ম নয় এবং ভবিষ্যতে ম্যানুয়ালি পরিবর্তিত হতে পারে
    • দেখুন fstreamআরও তথ্যের জন্য ইউনিকোড গবেষণা / আলোচনা ক্ষেত্রে 4215।
    • কখনও ইউটিএফ 8 সামগ্রী সহ পাঠ্য আউটপুট ফাইলগুলি তৈরি করবেন না
    • fopen()RAII / OOD কারণে ব্যবহার করা থেকে বিরত থাকুন। প্রয়োজনে _wfopen()উপরের WinAPI কনভেনশনগুলি ব্যবহার করুন ।
// For interface to win32 API functions
std::string convert(const std::wstring& str, unsigned int codePage /*= CP_UTF8*/)
{
    // Ask me for implementation..
    ...
}

std::wstring convert(const std::string& str, unsigned int codePage /*= CP_UTF8*/)
{
    // Ask me for implementation..
    ...
}

// Interface to MFC
std::string convert(const CString &mfcString)
{
#ifdef UNICODE
    return Utils::convert(std::wstring(mfcString.GetString()));
#else
    return mfcString.GetString();   // This branch is deprecated.
#endif
}

CString convert(const std::string &s)
{
#ifdef UNICODE
    return CString(Utils::convert(s).c_str());
#else
    Exceptions::Assert(false, "Unicode policy violation. See W569"); // This branch is deprecated as it does not support unicode
    return s.c_str();   
#endif
}
— পাভেল রাদজিভিলভস্কি
সূত্র
39
আমি একমত হতে পারি না অনেক এশিয়ান ভাষার জন্য utf8 ওভার utf16 এর সুবিধাগুলি আপনার করা পয়েন্টগুলিকে পুরোপুরি আধিপত্য করে। জাপানি, থাই, চাইনিজ ইত্যাদি এই এনকোডিংটি ছেড়ে দিতে চলেছে এমন আশা করা নির্দোষ। চরসেটগুলির মধ্যে সমস্যাযুক্ত সংঘাতগুলি তখন হয় যখন চরসেটগুলি বেশিরভাগ ক্ষেত্রে ভিন্নতা ব্যতীত একই রকম মনে হয়। আমি মানিক করার পরামর্শ দিই: স্থির 7 বিট: আইসো-আইআরভি -1 170; 8 বিট ভেরিয়েবল: utf8; 16 বিট ভেরিয়েবল: utf16; 32 বিট স্থির: ucs4।
82
@ চার্লস: আপনার ইনপুট জন্য ধন্যবাদ। সত্য, কিছু বিএমপি অক্ষর UTF-8 -র তুলনায় UTF-16 এর চেয়ে বেশি। তবে, আসুন এটির মুখোমুখি হোন: সমস্যাটি বিএমপি চাইনিজ চরিত্রগুলির বাইটগুলির মধ্যে নেই, তবে উত্পন্ন সফ্টওয়্যার ডিজাইনের জটিলতা। যদি কোনও চীনা প্রোগ্রামারকে যেভাবেই চলক-দৈর্ঘ্যের চরিত্রগুলির জন্য নকশা তৈরি করতে হয়, মনে হয় ইউটিএফ -8 এখনও সিস্টেমের অন্যান্য ভেরিয়েবলের তুলনায় মূল্য দিতে একটি ছোট দাম। তিনি ইউটিএফ -16 কে সংক্ষেপণের অ্যালগরিদম হিসাবে ব্যবহার করতে পারেন যদি জায়গাটি এত গুরুত্বপূর্ণ হয় তবে তবুও এটি এলজেডের সাথে কোনও মিল হবে না, এবং এলজেড বা অন্যান্য জেনেরিক সংক্ষেপণের পরে উভয়ই একই আকার এবং এনট্রপি গ্রহণ করে।
32
আমি মূলত যা বলি তা হ'ল ওয়ান এনকোডিংয়ের মাধ্যমে সরলকরণ দেওয়া যা বিদ্যমান চর * প্রোগ্রামগুলির সাথেও সামঞ্জস্যপূর্ণ এবং আজকের সময়ের জন্য এটিও সবচেয়ে জনপ্রিয় যা অকল্পনীয়। এটি প্রায় ভাল পুরানো "প্লেইন টেক্সট" দিনের মতো। একটি নাম দিয়ে একটি ফাইল খুলতে চান? আপনি কী ধরণের ইউনিকোড করছেন ইত্যাদি যত্ন নেওয়ার দরকার নেই। আমি পরামর্শ দিচ্ছি যে আমরা, বিকাশকারীরা, ইউটিএফ -১ 16 কে গুরুতর অপ্টিমাইজেশনের খুব বিশেষ ক্ষেত্রে সীমাবদ্ধ রাখি যেখানে একটি ক্ষুদ্রতম পারফরম্যান্স মানব-মাসের কাজের জন্য উপযুক্ত।
17
অভ্যন্তরীণভাবে ইউটিএফ -8 ব্যবহার করার সময় লিনাক্সের একটি নির্দিষ্ট প্রয়োজনীয়তা ছিল: ইউনিক্সের সাথে সামঞ্জস্য। উইন্ডোজের এটির প্রয়োজন ছিল না, এবং এইভাবে যখন বিকাশকারীরা ইউনিকোড প্রয়োগ করেন, তারা প্রায় সমস্ত ফাংশনের ইউসিএস -২ সংস্করণ যুক্ত করে পাঠ্য পরিচালনা করে এবং মাল্টবাইটগুলি কেবল ইউসিএস -২ এ রূপান্তরিত করে এবং অন্যান্যগুলিকে কল করেন। পরে তিনি ইউসিএফ -১ rep এর সাথে ইউটিএফ -১ with স্থাপন করে। অন্যদিকে লিনাক্স 8-বিট এনকোডিংগুলিতে রেখেছিল এবং ইউটিএফ -8 ব্যবহার করে, কারণ এটি ক্ষেত্রে উপযুক্ত পছন্দ।
— মিরসিয়া চিরিয়া
34
@ পাভেল রদজিভিলভস্কি: বিটিডাব্লু, " আপনার বিশ্বাস যে অন্য সমস্ত এনকোডিং শেষ পর্যন্ত মারা যাবে। এর মধ্যে এমএস-উইন্ডোজ, জাভা, আইসিইউ, পাইথন এটি তাদের প্রিয় হিসাবে ব্যবহার বন্ধ করে দিয়েছে।" এবং "বিশেষত, আমি মনে করি যে সি ++ তে wchar_t যুক্ত করা একটি ভুল ছিল এবং সি ++ অক্সের ইউনিকোড সংযোজনগুলিও তাই।" হয় হয় বেশ নির্বোধ বা খুব অহঙ্কারী। এবং এটি এমন কোনও ব্যক্তির কাছ থেকে আসছে যা বাড়িতে লিনাক্সের সাথে কোডিং করছে এবং ইউটিএফ -8 অক্ষর নিয়ে কে খুশি। স্পষ্টভাবে এটা করা: এটা ঘটবে না ।
— পারাসেবল
157

ইউনিকোড কোডপয়েন্টগুলি চরিত্র নয়! কখনও কখনও তারা এমনকি গ্লাইফ (ভিজ্যুয়াল ফর্ম) হয় না।

কিছু উদাহরণ:

  • "Ⅲ" এর মতো রোমান সংখ্যার কোডপয়েন্ট। ("Iii" এর মতো দেখতে একটি একক অক্ষর))
  • "Á" এর মতো উত্সাহিত অক্ষর, যা একক সম্মিলিত অক্ষর "\ u00e1" বা একটি চরিত্র এবং পৃথক পৃথক "ac u0061 \ u0301" হিসাবে উপস্থাপন করা যেতে পারে।
  • গ্রীক লোয়ারকেস সিগমার মতো অক্ষর, যার শব্দের অবস্থানগুলির মধ্য ("σ") এবং শেষ ("ς") এর বিভিন্ন রূপ রয়েছে তবে যা অনুসন্ধানের প্রতিশব্দ হিসাবে বিবেচনা করা উচিত।
  • ইউনিকোডের বিচক্ষণ হাইফেন ইউ +00 এডি, যা প্রেক্ষাপটের উপর নির্ভর করে দৃশ্যত প্রদর্শিত হতে পারে বা নাও হতে পারে এবং যা শব্দার্থক অনুসন্ধানের জন্য উপেক্ষা করা হয়।

ইউনিকোড সম্পাদনা ডান পাওয়ার একমাত্র উপায় হ'ল কোনও বিশেষজ্ঞের দ্বারা লিখিত একটি গ্রন্থাগার ব্যবহার করা , বা বিশেষজ্ঞ হওয়া এবং নিজেই একটি লেখা। যদি আপনি কেবল কোডপয়েন্টগুলি গণনা করছেন তবে আপনি পাপের অবস্থায় বাস করছেন।

— ড্যানিয়েল নিউবি
সূত্র
19
এই. এই অনেক। ইউটিএফ -16 সমস্যা সৃষ্টি করতে পারে তবে ইউটিএফ -32 ব্যবহার করে এমনকি (এবং ইচ্ছা) এখনও আপনাকে সমস্যাগুলি দিতে পারে।
— বি কেট
11
একটি চরিত্র কি? আপনি একটি চরিত্র হিসাবে একটি কোড পয়েন্ট সংজ্ঞায়িত করতে পারেন এবং বেশ কিছুটা জরিমানা পেতে পারেন। আপনি যদি কোনও ব্যবহারকারীর দ্বারা দৃশ্যমান গ্লাইফ বোঝায় তবে এটি অন্যরকম।
— tchrist
7
@ ক্রিসট স্পষ্ট বরাদ্দ দেওয়ার জন্য নিশ্চিত যে সংজ্ঞাটি ঠিক আছে, তবে অন্য কিছুর জন্য? খুব বেশি না. যদি আপনি একত্রিত চরিত্রটিকে একমাত্র চরিত্র হিসাবে পরিচালনা করেন (যেমন একটি মুছতে বা "প্রথম এন অক্ষরগুলি গ্রহণ করুন" অপারেশন) আপনি অদ্ভুত এবং ভুল আচরণ পাবেন wrong যদি কোনও কোড পয়েন্টের অন্তত অন্যটির সাথে মিলিত হওয়ার অর্থ থাকে তবে আপনি এটিকে নিজের মতো করে কোনও বুদ্ধিমান পদ্ধতিতে পরিচালনা করতে পারবেন না।
— ভু
6
@ পেসারিয়ার, এটি পার্টিতে দেরী হয়েছে, তবে আমাকে এ সম্পর্কে মন্তব্য করতে হবে। কিছু ভাষায় ডায়াক্রিটিক্স (সিএফ ভিয়েতনামী, অর্থাৎ ম্যাট ệ) এর সম্ভাব্য সংমিশ্রণের খুব বড় সেট রয়েছে। ডায়াক্রিটিকের পরিবর্তে একটি চরিত্রের চেয়ে কম্বিনেশন থাকা খুব সহায়ক।
— অ্যাথাস্টার
21
পরিভাষায় একটি ছোট নোট: কোডপয়েন্টগুলি ইউনিকোড অক্ষরের সাথে মিল রাখে ; ড্যানিয়েল এখানে যা বলছেন তা ব্যবহারকারী-অনুভূতিযুক্ত অক্ষর , যা ইউনিকোড গ্রাফিয়াম ক্লাস্টারের সাথে মিলে যায়
— ক্রিস্টোফ
54

ইউনিকোড ট্রান্সফর্মেশন ফর্ম (ইউটিএফ) কী ব্যবহার করতে হবে তার উপর একটি সরল নিয়ম রয়েছে: - স্টোরেজ এবং যোগাযোগের জন্য utf-8 - ডেটা প্রসেসিংয়ের জন্য utf-16 - আপনি ব্যবহার করতে পারেন প্ল্যাটফর্মের বেশিরভাগ এপিআই যদি আপনি utf-32 দিয়ে যেতে পারেন utf-32 (UNIX বিশ্বে প্রচলিত)।

বেশিরভাগ সিস্টেমে utf-16 ব্যবহার করে (উইন্ডোজ, ম্যাক ওএস, জাভা,। নেট, আইসিইউ, কিউটি)। এই নথিটিও দেখুন: http://unicode.org/notes/tn12/

"UTF-16 ক্ষতিকারক হিসাবে" ফিরে যান, আমি বলব: অবশ্যই না definitely

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

এখানে কেবল এই সিরিজটি পড়ুন http://www.siao2.com/2009/06/29/9800913.aspx এবং দেখুন কীভাবে ইউটিএফ -16 একটি সহজ সমস্যা হয়ে যায়।

— মিহাই নীতা
সূত্র
26
ইউএনএফএস -32 ইউনিক্স বিশ্বে সাধারণ যেখানে কিছু উদাহরণ যুক্ত করুন!
— maxschlepzig
48
না, আপনি ডেটা প্রসেসিংয়ের জন্য ইউটিএফ -16 ব্যবহার করতে চান না। পাছায় ব্যথা হচ্ছে এটির ইউটিএফ -8 এর সমস্ত অসুবিধাগুলি রয়েছে তবে এর কোনও সুবিধা নেই। ইউটিএফ -8 এবং ইউটিএফ -32 উভয়ই জঘন্য হ্যাকের চেয়ে পূর্বে সুস্পষ্টভাবে মিসেস ইউটিএফ -16 নামে পরিচিত, যার প্রথম নাম ইউসিএস -2 ছিল।
— tchrist
34
আমি গতকাল জাভা কোর স্ট্রিং ক্লাসের equalsIgnoreCaseপদ্ধতিতে (একটি স্ট্রিং ক্লাসের অন্যরাও) একটি বাগ খুঁজে পেয়েছি যা জাভা ইউটিএফ -8 বা ইউটিএফ -32 ব্যবহার করে না এমনটি কখনও ঘটত না। যে কোনও কোডে ইউটিএফ -16 ব্যবহার করে এমন লক্ষ লক্ষ এই ঘুমন্ত বোমা শেল রয়েছে এবং আমি সেগুলি থেকে অসুস্থ এবং ক্লান্ত। ইউটিএফ -16 হ'ল একটি দুষ্টু পোক্স যা আমাদের সফ্টওয়্যারটিকে চিরকালের জন্য এবং চতুর বাগের বাগের সাথে জর্জরিত করে। এটি স্পষ্টত ক্ষতিকারক এবং এটিকে অবমূল্যায়ন ও নিষিদ্ধ করা উচিত।
— tchrist
7
@ ট্রিচ্রিস্ট বাহ সুতরাং একটি অ-সারোগেট সচেতন ফাংশন (কারণ এটি যখন লেখা ছিল তখন কিছুই ছিল না এবং দুঃখের সাথে এমনভাবে নথিভুক্ত করা হয়েছে যা সম্ভবত এটি খাপ খাইয়ে নেওয়া অসম্ভব করে তোলে - এটি নির্দিষ্ট করে। টুঅপারকেস (চর)) এর ফলে ভুল আচরণ হবে? আপনি জানেন যে একটি ইউটিএফ -32 ফাংশন পুরানো কোড পয়েন্ট মানচিত্র সহ এটি আরও ভাল পরিচালনা করতে পারে না? এছাড়াও পুরো জাভা এপিআই হ্যান্ডলগুলি বিশেষত ভাল নয় এবং ইউনিকোড সম্পর্কে আরও জটিল পয়েন্টগুলি হ্যান্ডল করে না - এবং পরবর্তীকালে ব্যবহৃত এনকোডিং মোটেও গুরুত্বপূর্ণ হবে না।
— ভু
8
-১:। .Substring(1)নেট একটি শর্তহীন , এমন কোনও একটি ক্ষুদ্র উদাহরণ যা নন-বিএমপি ইউনিকোডের সকলের জন্য সমর্থনকে ভেঙে দেয়। সবকিছু হল UTF-16 ব্যবহার করে এই সমস্যা আছে; এটি একটি নির্দিষ্ট-প্রস্থের এনকোডিং হিসাবে বিবেচনা করা খুব সহজ এবং আপনি সমস্যা খুব কমই দেখতে পান। আপনি ইউনিকোড সমর্থন করতে চাইলে এটি একটি সক্রিয়ভাবে ক্ষতিকারক এনকোডিং করে makes
— রোমান স্টারকভ
43

হ্যাঁ একেবারে.

কেন? এটি ব্যায়াম কোড সঙ্গে করতে হবে ।

আপনি যদি টম ক্রিশ্চেনসেনের বিশাল কর্পাসে এই কোডপয়েন্ট ব্যবহারের পরিসংখ্যানগুলি দেখেন তবে আপনি দেখতে পাবেন যে ট্রান্স -8 বিট বিএমপি কোডপয়েন্টগুলি বিএমপি নন কোডপয়েন্টগুলির চেয়ে আরও বেশি মাত্রায় বাড়িয়ে দিলে বিভিন্ন অর্ডার ব্যবহার করা হয়:

 2663710 U+002013 ‹–›  GC=Pd    EN DASH
 1065594 U+0000A0 ‹ ›  GC=Zs    NO-BREAK SPACE
 1009762 U+0000B1 ‹±›  GC=Sm    PLUS-MINUS SIGN
  784139 U+002212 ‹−›  GC=Sm    MINUS SIGN
  602377 U+002003 ‹ ›  GC=Zs    EM SPACE

 544 U+01D49E ‹𝒞›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL C
 450 U+01D4AF ‹𝒯›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL T
 385 U+01D4AE ‹𝒮›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL S
 292 U+01D49F ‹𝒟›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL D
 285 U+01D4B3 ‹𝒳›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL X

টিডিডি ডিকামটি ধরুন: "আনস্টেস্টেড কোডটি ভাঙা কোড" এবং এটিকে "অব্যক্ত কোডটি ভাঙা কোড" হিসাবে পুনরায় লিখুন এবং ভাবুন যে প্রোগ্রামাররা কতবার বি-বিএমপি কোডপয়েন্টগুলিতে ডিল করতে হয়।

ভেরিয়েবল-প্রস্থের এনকোডিং হিসাবে ইউটিএফ -16 এর সাথে ডিল না করার সাথে সম্পর্কিত বাগগুলি ইউটিএফ -8 এর সমতুল বাগগুলির চেয়ে অজানা হওয়ার সম্ভাবনা অনেক বেশি । কিছু প্রোগ্রামিং ল্যাঙ্গুয়েজগুলি এখনও আপনাকে ইউসিএস -2 এর পরিবর্তে ইউটিএফ -16 দেওয়ার গ্যারান্টি দেয় না এবং কিছু তথাকথিত উচ্চ-স্তরের প্রোগ্রামিং ল্যাঙ্গুয়েজ কোড-পয়েন্টগুলির পরিবর্তে কোড ইউনিটগুলিতে অ্যাক্সেস সরবরাহ করে (এমনকি সি আপনাকেও অ্যাক্সেস দেয় বলে মনে করা হচ্ছে) কোডপয়েন্টগুলি যদি আপনি ব্যবহার করেন তবে wchar_tকিছু প্ল্যাটফর্মগুলি যা করুক না কেন)।

— নিনজালজ
সূত্র
16
"ভেরিয়েবল-প্রস্থের এনকোডিং হিসাবে ইউটিএফ -16 এর সাথে ডিল না করার বিষয়ে সম্পর্কিত বাগগুলি ইউটিএফ -8 এর সমতুল্য বাগগুলির চেয়ে অজানা হওয়ার সম্ভাবনা অনেক বেশি।" এটি ইস্যুটির মূল এবং তাই সঠিক উত্তর।
— শান ম্যাকমিলান
3
অবিকল। যদি আপনার ইউটিএফ -8 হ্যান্ডলিং বিরক্ত হয় তবে তা অবিলম্বে সুস্পষ্ট হয়ে উঠবে। যদি আপনার ইউটিএফ -8 হ্যান্ডলিংটি বিরক্ত হয় তবে আপনি কেবলমাত্র যদি অস্বাভাবিক হান চরিত্র বা গণিতের প্রতীক স্থাপন করেন তবে তা লক্ষ্য করবেন।
— যান্ত্রিক শামুক 7
1
খুব সত্য, তবে অন্যদিকে, ঘন ঘন ঘন মামলার ক্ষেত্রে বাগগুলি খুঁজে পাওয়ার জন্য আপনার ভাগ্যের উপর নির্ভর করা উচিত তবে ইউনিট পরীক্ষাগুলি কী?
— মুশিফিল
@ মুসিফিল: সুতরাং, বিএমপিবিহীন চরিত্রগুলির জন্য আপনি কখন সর্বশেষ ইউনিট পরীক্ষা তৈরি করেছিলেন?
— নিনজালজ
1
আমার আগের বক্তব্যটি বিশদভাবে জানাতে: এমনকি ইউটিএফ -8 এর সাথেও, আপনি আশ্বস্ত হতে পারবেন না যে আপনি কেবলমাত্র কিছু কার্যনির্বাহী উদাহরণ দেখার পরে সমস্ত ঘটনা কভার করেছেন। ইউটিএফ -১ with এর সাথে একই: আপনার কোডটি নন-সার্গেট এবং সরোগেটের সাথে উভয়ই কাজ করে কিনা তা পরীক্ষা করে দেখতে হবে। (কেউ কেউ
— যুক্তিও
40

আমি পরামর্শ দেব যে ইউটিএফ -16 ভাবা ক্ষতিকারক হিসাবে বিবেচিত হতে পারে বলে যে আপনাকে ইউনিকোডের আরও বৃহত্তর বোঝার প্রয়োজন ।

যেহেতু একটি বিষয়গত প্রশ্নে আমার মতামত উপস্থাপনের জন্য আমি অবহেলিত ছিলাম, তাই আমাকে আরও বিশদভাবে বলুন। এটি আপনাকে ইউটিএফ -16 সম্পর্কে ঠিক বিরক্ত করে? আপনি কি ইউটিএফ -8 এ সমস্ত এনকোড করা পছন্দ করবেন? হল UTF-7? বা ইউসিএস -4 কেমন? অবশ্যই কিছু অ্যাপ্লিকেশনগুলি এরিসিংল চরিত্রের কোডটি হ্যান্ডেল করার জন্য তৈরি করা হয়নি - তবে আন্তর্জাতিক সীমানাগুলির মধ্যে যোগাযোগের জন্য সেগুলি বিশেষত আজকের বিশ্বব্যাপী তথ্য ডোমেনে প্রয়োজনীয়।

তবে সত্যই, আপনি যদি ইউটিএফ -১ feel কে ক্ষতিকারক হিসাবে বিবেচনা করা উচিত কারণ এটি বিভ্রান্তিকর হয় বা ভুলভাবে প্রয়োগ করা যেতে পারে (ইউনিকোড অবশ্যই হতে পারে), তবে চরিত্রের এনকোডিংয়ের কোন পদ্ধতিটি ক্ষতিকারক হিসাবে বিবেচিত হবে?

সম্পাদনা: স্পষ্ট করার জন্য: কেন একটি স্ট্যান্ডার্ডের অনুপযুক্ত বাস্তবায়নকে মানের গুনের প্রতিফলন বিবেচনা করবেন? অন্যরা যেমন পরবর্তীকালে উল্লেখ করেছে যে কেবল কোনও অ্যাপ্লিকেশনটি কোনও সরঞ্জাম অনুপযুক্তভাবে ব্যবহার করে, তার অর্থ এই নয় যে সরঞ্জামটি নিজেই ত্রুটিযুক্ত। যদি এমনটি হয় তবে আমরা সম্ভবত "var কীওয়ার্ডকে ক্ষতিকারক বলে মনে করি", বা "থ্রেডিংকে ক্ষতিকারক বলে মনে করি" এর মতো জিনিস বলতে পারি। আমি মনে করি যে প্রশ্নটি অনেকগুলি প্রোগ্রামার সঠিকভাবে এটি প্রয়োগ ও প্রয়োগ করতে সমস্যাগুলির সাথে মানটির গুণমান এবং প্রকৃতিটিকে বিভ্রান্ত করে, যা ইউনিকোডের চেয়ে বরং ইউনিকোড কীভাবে কাজ করে তাদের বোঝার অভাব থেকে আমি আরও বেশি কান্ড অনুভব করি।

— patjbs
সূত্র
33
-১: আর্টিয়ামের কিছু আপত্তি সম্বোধন না করে কেবল তার পৃষ্ঠপোষকতা করার বিষয়ে কীভাবে?
8
বিটিডাব্লু: আমি যখন এই নিবন্ধটি লিখতে শুরু করি তখন আমি প্রায় লিখতে চেয়েছিলাম "ইউনিকোডের সফ্টিয়ের নিবন্ধে জোল কি ক্ষতিকারক হিসাবে বিবেচিত হওয়া উচিত" কারণ সেখানে অনেক ভুল রয়েছে। উদাহরণস্বরূপ: utf-8 এনকোডিংটি 4 টি অক্ষর পর্যন্ত লাগে 6 না Also এছাড়াও এছাড়াও এটি ইউসিএস -2 এবং ইউটিএফ -16 এর মধ্যে পার্থক্য করে না যা সত্যই আলাদা - এবং আমি যে সমস্যার কথা বলি তা আসলেই ঘটায়।
32
এছাড়াও, এটি লক্ষ করা উচিত যে জোল যখন সেই নিবন্ধটি লিখেছিলেন, তখন ইউটিএফ -8 স্ট্যান্ডার্ড ডাব্লুএস 6 বাইট নয়, 4 নয়। আরএফসি 3629 এই নিবন্ধটি লেখার পরে বেশ কয়েক মাস ধরে স্ট্যান্ডার্ডটি 4 বাইটে বদলেছিল। ইন্টারনেটের যে কোনও কিছুর মতো, এটি একাধিক উত্স থেকে পড়া এবং আপনার উত্সগুলির বয়স সম্পর্কে সচেতন হওয়ার জন্য অর্থ প্রদান করে। লিঙ্কটির উদ্দেশ্য "শেষ অবধি সমস্ত হতে" হবে না, বরং এটি একটি সূচনা বিন্দু।
7
আমি তুলে ধরব: utf-8 বা utf-32 যা: প্রায় সব ক্ষেত্রেই চলক দৈর্ঘ্যের এনকোডিং (বিএমপি সহ) বা সর্বদা স্থির দৈর্ঘ্যের এনকোডিং।
18
@ আইকনিকে: মূর্খ হবেন না। হল UTF-16 একেবারে নয় কার্যত প্রক্রিয়াকরণ পাঠ্যের জন্য মান। আমাকে পাঠ্য প্রক্রিয়াকরণের জন্য আরও উপযুক্ত একটি প্রোগ্রামিং ল্যাঙ্গোয়েজ দেখান যা পার্ল, যা সর্বদা (ভাল, এক দশকেরও বেশি সময় ধরে) অভ্যন্তরীণভাবে অন্তর্নিহিত ইউটিএফ -8 উপস্থাপনা সহ বিমূর্ত অক্ষর ব্যবহার করে। এই কারণে, প্রতিটি পার্ল প্রোগ্রাম ব্যবহারকারীকে নিয়মিত বোকা সারোগেটের চারপাশে বাঁদর না করে সমস্ত ইউনিকোড স্বয়ংক্রিয়ভাবে পরিচালনা করে। স্ট্রিংয়ের দৈর্ঘ্য কোড পয়েন্টগুলিতে এর গণনা, কোড ইউনিট নয়। অন্য কিছু হ'ল পিছনে সামঞ্জস্যের পিছনে পিছনে রাখার নিছক বোকামি।
— tchrist
37

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

তবে নোট করুন যে এমনকি utf-32 ব্যবহারের অর্থ এই নয় যে প্রতিটি 32-বিট কোড পয়েন্ট সর্বদা একটি চরিত্রের প্রতিনিধিত্ব করবে। অক্ষরগুলিকে একত্রিত করার কারণে, একটি আসল অক্ষরটিতে বেশ কয়েকটি কোড পয়েন্ট থাকতে পারে। ইউনিকোড কখনই তুচ্ছ নয়।

BTW। প্ল্যাটফর্ম এবং অ্যাপ্লিকেশন সহ সম্ভবত একই শ্রেণীর ত্রুটি রয়েছে যা অক্ষরগুলি 8-বিট হওয়ার প্রত্যাশা করে, যা উত্স -8 খাওয়ানো হয়।

— JacquesB
সূত্র
12
জাভার ক্ষেত্রে যদি আপনি তাদের সময়রেখার দিকে নজর রাখেন ( java.com/en/javahistory/timeline.jsp ), আপনি দেখতে পাচ্ছেন যে স্ট্রিংয়ের প্রাথমিকভাবে বিকাশ ঘটেছিল ইউনিকোডের 16 বিটের সময় (এটি 1996 সালে পরিবর্তিত হয়েছিল)। বিএমপি কোডবিহীন কোড পয়েন্টগুলি হ্যান্ডেল করার ক্ষমতা নিয়ে তাদের বল্টু করতে হয়েছিল, ফলে বিভ্রান্তি।
— ক্যাথি ভ্যান স্টোন
10
@ ক্যাথি: যদিও আসলে সি # এর অজুহাত নয়। সাধারণত, আমি সম্মত হই যে, এখানে একটি CodePointপ্রকার থাকা উচিত , একটি একক কোড পয়েন্ট (২১ বিট) CodeUnitধারণ করা উচিত , একটি প্রকারের মধ্যে একটি একক কোড ইউনিট (ইউটিএফ -১ for এর জন্য ১ and বিট) Characterথাকত এবং কোনও ধরণের আদর্শভাবে একটি সম্পূর্ণ গ্রাফিয়াম সমর্থন করতে হবে। তবে এটি এটিকে কার্যকরীভাবে একটি String...
— জো
1
এই উত্তরটি প্রায় দুই বছর পুরানো, তবে আমি সাহায্য করতে পারছি না তবে এটিতে মন্তব্য করতে। "'চর' নামে একটি ধরণের নাম রাখা যা সবসময় কোনও চরিত্রের প্রতিনিধিত্ব করে না তা বেশ বিভ্রান্তিকর" " এবং তবুও লোকেরা সিটিতে সর্বদা এটি ব্যবহার করে এবং একক বাইটে সংরক্ষণ করা যেতে পারে এমন পূর্ণসংখ্যার ডেটা উপস্থাপন করতে পছন্দ করে।
— জ্যাব
এবং আমি প্রচুর সি কোড দেখেছি যা অক্ষর এনকোডিং সঠিকভাবে পরিচালনা করে না।
— dan04
1
সি # এর একটি ভিন্ন অজুহাত রয়েছে: এটি উইন্ডোজের জন্য ডিজাইন করা হয়েছিল, এবং উইন্ডোজটি ইউসিএস -২ এ নির্মিত হয়েছিল (এটি খুব বিরক্তিকর যে আজও উইন্ডোজ এপিআইগুলি ইউটিএফ -8 সমর্থন করতে পারে না)। এছাড়াও, আমি মনে করি মাইক্রোসফ্ট জাভা সামঞ্জস্য চেয়েছিল (.NET 1.0 এর একটি জাভা সামঞ্জস্য লাইব্রেরি ছিল, তবে তারা জাভা সমর্থনটি খুব দ্রুত ফেলে দিয়েছে - আমি অনুমান করছি এটি
— এমএসের
20

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

— rmeador
সূত্র
3
ইউএমএফ -16 বিএমপির অভ্যন্তরের যে কোনও কিছুর জন্য সহজ, এজন্য এটি এত ব্যাপকভাবে ব্যবহৃত হয়। তবে আমিও ইউটিএফ -8 এর একজন অনুরাগী, এটির বাইট অর্ডার নিয়েও কোনও সমস্যা নেই, এটি তার উপকারে কাজ করে।
— ম্যালকম
2
তাত্ত্বিকভাবে, হ্যাঁ অনুশীলনে এমন কিছু রয়েছে যেমন, বলুন, ইউটিএফ -16 বিই, যার অর্থ বিওএম ছাড়াই বড় এন্ডিয়ানে ইউটিএফ -16 রয়েছে। এটি আমি তৈরি কিছু জিনিস নয়, এটি আইডি 3v2.4 ট্যাগগুলিতে অনুমোদিত আইকন এনডোডিং (আইডি 3 ভি 2 ট্যাগ চুষে ফেলেছে, তবে দুর্ভাগ্যক্রমে, ব্যাপকভাবে ব্যবহৃত হয়)। এবং এই জাতীয় ক্ষেত্রে আপনাকে অন্তর্নিহিততা বাহ্যিকভাবে সংজ্ঞায়িত করতে হবে, কারণ পাঠ্যে নিজেই বিওএম নেই। ইউটিএফ -8 সর্বদা একভাবে লেখা থাকে এবং এতে এরকম সমস্যা হয় না।
— ম্যালকম 15
23
না, ইউটিএফ -16 সহজ নয়। এটা শক্ত। এটি বিভ্রান্ত করে এবং প্রস্থের নির্দিষ্ট স্থির করে ভেবে আপনাকে ধোঁকা দেয়। এ জাতীয় সমস্ত কোডটি নষ্ট হয়ে গেছে এবং আরও অনেক কারণ আপনি খুব বেশি দেরি না করা অবধি লক্ষ্য করবেন না। কেস ইন পয়েন্ট: আমি গতকাল জাভা কোর লাইব্রেরিগুলিতে আরও একটি বোকা UTF-16 বাগটি পেয়েছি, এবার স্ট্রিং.ইকিয়ালস আইগনোরকেসে, যা ইউসিএস -২ ব্রিনেদাথ বগেরিতে বাকি ছিল, এবং তাই 16/17 বৈধ ইউনিকোড কোড পয়েন্টে ব্যর্থ। সেই কোডটি কত দিন ধরে রয়েছে? এটি বগি হওয়ার কোনও অজুহাত নেই। ইউটিএফ -16 নিখুঁত বোকামি এবং দুর্ঘটনার জন্য অপেক্ষা করছে। ইউটিএফ -16 থেকে চিৎকার চালাও।
— tchrist
3
ইউটিএফ -16 নির্ধারিত দৈর্ঘ্য নয় তা না জানার জন্য @ ট্রিচ্রিস্টকে অবশ্যই একজন খুব অজ্ঞ বিকাশকারী হতে হবে। আপনি যদি উইকিপিডিয়া দিয়ে শুরু করেন, আপনি নীচের অংশে খুব উপরে পড়বেন: "এটি কোড পয়েন্টের জন্য এক বা দুটি 16-বিট কোড ইউনিটের একটির ভেরিয়েবল-দৈর্ঘ্যের ফলাফল তৈরি করে"। ইউনিকোড এফএকিউ একই কথা বলে: unicode.org/faq//utf_bom.html#utf16-1 । আমি জানি না, ইউটিএফ -16 কীভাবে যে কাউকে প্রতারণা করতে পারে যদি এটি সর্বত্র লিখিত হয় যে এটি পরিবর্তনশীল দৈর্ঘ্য। পদ্ধতি হিসাবে, এটি কখনও ইউটিএফ -16 এর জন্য ডিজাইন করা হয়নি এবং এটি ইউনিকোড হিসাবে বিবেচিত হওয়া উচিত নয় as
— ম্যালকম
2
@ টচ্রিস্ট আপনার কাছে কি আপনার পরিসংখ্যানের উত্স আছে? যদিও ভাল প্রোগ্রামারদের দুষ্প্রাপ্যতা থাকলেও আমি মনে করি এটি ভাল, কারণ আমরা আরও মূল্যবান হয়ে উঠি। :) জাভা এপিআই-র জন্য, চর-ভিত্তিক অংশগুলি অবশেষে হ্রাস পেতে পারে, তবে এটি কোনও গ্যারান্টি নয় যে সেগুলি ব্যবহৃত হবে না। এবং সক্ষমতার কারণে সেগুলি অবশ্যই মুছে ফেলা হবে না।
— ম্যালকম
18

ঠিক আছে, এখানে একটি এনকোডিং রয়েছে যা স্থির আকারের প্রতীক ব্যবহার করে। আমি অবশ্যই ইউটিএফ -32 বলতে চাইছি। তবে প্রতিটি চিহ্নের জন্য 4 বাইট হ'ল নষ্ট স্থান খুব বেশি, কেন আমরা এটি প্রতিদিনের পরিস্থিতিতে ব্যবহার করব?

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

তবে আমি মনে করি যে কেবল বিএমপি সমর্থনযুক্ত উত্তরাধিকারী সফ্টওয়্যারগুলির সমস্যাগুলি কিছুটা অতিরঞ্জিত। বিএমপির বাইরের অক্ষরগুলি কেবল খুব নির্দিষ্ট ক্ষেত্রে এবং ক্ষেত্রগুলিতেই সম্মুখীন হয়। ইউনিকোডের অফিসিয়াল এফএকিউ অনুসারে , "এমনকি পূর্ব এশীয় পাঠ্যগুলিতে, সারোগেট জোড়গুলির ঘটনাগুলি সর্বনিম্ন পাঠ্য সংগ্রহের 1% এরও কম হওয়া উচিত"। অবশ্যই, বিএমপির বাইরের চরিত্রগুলিকে অবহেলা করা উচিত নয় কারণ কোনও প্রোগ্রাম অন্যভাবে ইউনিকোড-কনফরম্যান্ট নয়, তবে বেশিরভাগ প্রোগ্রামগুলিতে এই জাতীয় অক্ষরযুক্ত পাঠ্যগুলি নিয়ে কাজ করার উদ্দেশ্যে নয়। এ কারণেই যদি তারা এটি সমর্থন না করে তবে এটি অপ্রীতিকর, তবে বিপর্যয় নয়।

এখন বিকল্প বিবেচনা করা যাক। যদি ইউটিএফ -16 উপস্থিত না থাকে, তবে আমাদের কাছে এমন একটি এনকোডিং নেই যা নন-এএসসিআইআই পাঠ্যের জন্য ভাল উপযুক্ত এবং ইউসিএস -২ এর জন্য তৈরি সমস্ত সফ্টওয়্যার ইউনিকোড-অনুবর্তী থাকার জন্য সম্পূর্ণ নতুনভাবে ডিজাইন করতে হবে। সম্ভবত সম্ভবত ইউনিকোড গ্রহণকে ধীর করবে। এছাড়াও আমরা ইউসিএফ -8 এএসসিআইআইয়ের মতো ইউটিএফ -8 এর মতো পাঠ্যের সাথে সামঞ্জস্যতা বজায় রাখতে পারতাম না।

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

সুতরাং আমি মনে করি না যে এনকোডিংটি নিজেই ক্ষতিকারক হিসাবে বিবেচিত হওয়া উচিত। ইউটিএফ -16 সরলতা এবং সংক্ষিপ্ততার মধ্যে একটি আপস এবং এটি যেখানে প্রয়োজন সেখানে যা প্রয়োজন তা ব্যবহার করার কোনও ক্ষতি নেই । কিছু ক্ষেত্রে আপনাকে ASCII এর সাথে সামঞ্জস্য বজায় রাখতে হবে এবং আপনার ইউটিএফ -8 প্রয়োজন, কিছু ক্ষেত্রে আপনি হ্যান ভাবচিত্রগুলির সাথে কাজ করতে এবং ইউটিএফ -16 ব্যবহার করে স্থান সংরক্ষণ করতে চান, কিছু ক্ষেত্রে আপনার অক্ষরের সার্বজনীন উপস্থাপনা প্রয়োজন একটি স্থির- দৈর্ঘ্য এনকোডিং। আরও উপযুক্ত কি ব্যবহার করুন, এটি সঠিকভাবে করুন।

— ম্যালকম
সূত্র
21
এটি একটি বরং ঝলকানো, অ্যাংলো-কেন্দ্রিক দৃষ্টিভঙ্গি, ম্যালকম m "এএসসিআইআই মার্কিন যুক্তরাষ্ট্রের পক্ষে যথেষ্ট ভাল - সমুদ্রের বাকি অংশগুলি আমাদের সাথে ফিট করে" with
— জোনাথন লেফলার
28
প্রকৃতপক্ষে আমি রাশিয়া থেকে এসেছি এবং সব সময় সিরিলিকের মুখোমুখি (আমার নিজস্ব প্রোগ্রামগুলি সহ), তাই আমার মনে হয় না যে আমার অ্যাংলো কেন্দ্রিক দৃষ্টিভঙ্গি রয়েছে। :) এএসসিআইআই উল্লেখ করা মোটামুটি প্রশংসনীয় নয়, কারণ এটি ইউনিকোড নয় এবং নির্দিষ্ট অক্ষরগুলি সমর্থন করে না। ইউটিএফ -8, ইউটিএফ -16, ইউটিএফ -32 খুব একই আন্তর্জাতিক চরিত্র সেটগুলিকে সমর্থন করে, তারা কেবল তাদের নির্দিষ্ট ক্ষেত্রগুলিতে ব্যবহারের উদ্দেশ্যে are এবং এটি হ'ল আমার বক্তব্য: আপনি যদি বেশিরভাগ ইংরেজি ব্যবহার করেন তবে ইউটিএফ -8 ব্যবহার করুন, আপনি বেশিরভাগ সিরিলিক ব্যবহার করেন, ইউটিএফ -16 ব্যবহার করুন, আপনি যদি প্রাচীন ভাষা ব্যবহার করেন তবে ইউটিএফ -32 ব্যবহার করুন। খুবই সাধারণ.
— ম্যালকম
16
"সত্য নয়, জাপানীজ, চাইনিজ বা আরবি জাতীয় এশিয়ান স্ক্রিপ্টগুলিও বিএমপির অন্তর্গত B বিএমপিতে 0xFFFF অক্ষর রয়েছে (65536)। একা চাইনিজ এর চেয়ে বেশি আছে। চীনা মান (জিবি 18030) এর চেয়ে বেশি। ইউনিকোড 5.1 ইতিমধ্যে 100,000 টিরও বেশি অক্ষর বরাদ্দ করেছে।
12
@ মারকোলম: "বিএমপি নিজেই খুব বড় এবং অবশ্যই আজকাল ব্যবহৃত সমস্ত স্ক্রিপ্টগুলি অন্তর্ভুক্ত করতে যথেষ্ট বড়" সত্য নয়। এই মুহুর্তে ইউনিকোড ইতিমধ্যে প্রায় 100 কে অক্ষর বরাদ্দ করেছে, বিএমপির চেয়ে আরও বেশি কিছু সংস্থান করতে পারে। বিএমপির বাইরে চীনা অক্ষরের বড় অংশ রয়েছে। এবং এর মধ্যে কিছুগুলির জন্য জিবি -13030 (বাধ্যতামূলক চীনা মান) প্রয়োজন। অন্যান্য (বাধ্যতামূলক) জাপানি এবং কোরিয়ান স্ট্যান্ডার্ড দ্বারা প্রয়োজনীয়। সুতরাং আপনি যদি এই বাজারগুলিতে কিছু বিক্রয় করার চেষ্টা করেন, আপনার বিএমপি সমর্থন ছাড়াই প্রয়োজন।
8
ইউটিএফ -16 ব্যবহার করে এমন কিছু যা কেবল সংকীর্ণ বিএমপি অক্ষরগুলি পরিচালনা করতে পারে তা আসলে ইউটিএফ -16 ব্যবহার করছে না। এটি বাগি এবং ভাঙা। ওপিটির ভিত্তিটি দুর্দান্ত: ইউটিএফ -16 ক্ষতিকারক, কারণ এটি ভগ্ন লোকদের ভাঙা কোড লেখার দিকে পরিচালিত করে। হয় আপনি ইউনিকোড পাঠ্য পরিচালনা করতে পারেন, বা আপনি পারবেন না। যদি আপনি না করতে পারেন তবে আপনি একটি উপসেটটি বেছে নিচ্ছেন, এটি কেবলমাত্র ASCII- র কেবল পাঠ্য প্রক্রিয়াজাতকরণের মতো বোকা।
— tchrist
16

উইন্ডোজ আন্তর্জাতিকীকরণের বছরগুলি বিশেষত পূর্ব এশীয় ভাষাগুলিতে আমার কলুষিত হতে পারে তবে আমি ইউটিএফ -16 এর দিকে ঝুঁকছি অভ্যন্তরীণ-থেকে-প্রোগ্রামের স্ট্রিংয়ের উপস্থাপনার জন্য, এবং ইউটিএফ -8 নেটওয়ার্ক বা প্লেইন টেক্সটের মতো নথির ফাইল স্টোরেজের জন্য। ইউটিএফ -16 সাধারণত উইন্ডোজে দ্রুত প্রক্রিয়া করা যায়, সুতরাং উইন্ডোজে ইউটিএফ -16 ব্যবহারের এটি প্রাথমিক উপকার।

ইউটিএফ -১ to এ ঝাঁপিয়ে পড়া নাটকীয়ভাবে আন্তর্জাতিক পাঠ্য পরিচালনা করে এমন গড় পণ্যগুলির পর্যাপ্ততা উন্নত করে। কেবলমাত্র কয়েকটি সংকীর্ণ কেস রয়েছে যখন সরোগেট জোড়গুলি বিবেচনা করা প্রয়োজন (মুছে ফেলা, সন্নিবেশ এবং লাইন ব্রেকিং, মূলত) এবং গড়-কেস বেশিরভাগ ক্ষেত্রেই সরলভাবে পাস হয়। এবং জেআইএস ভেরিয়েন্টের মতো আগের এনকোডিংগুলির বিপরীতে, ইউটিএফ -১ সরোগেট জোড়াগুলিকে খুব সরু সীমার মধ্যে সীমাবদ্ধ করে, তাই চেকটি সত্যই দ্রুত এবং সামনের দিকে এবং পিছনে কাজ করে works

মঞ্জুর, এটি সঠিকভাবে এনকোডেড ইউটিএফ -8-তেও প্রায় তত দ্রুত। তবে অনেকগুলি ভাঙ্গা ইউটিএফ -8 অ্যাপ্লিকেশন রয়েছে যা দুটি ইউটিএফ -8 ক্রম হিসাবে ভুলভাবে সার্গেট জোড়গুলি এনকোড করে। সুতরাং ইউটিএফ -8 মুক্তির গ্যারান্টি দেয় না।

আইই 2000 বা ততকালীন থেকে সার্গেট জুটিগুলি বেশ ভালভাবে পরিচালনা করে, যদিও এটি সাধারণত তাদের ইউটিএফ -8 পৃষ্ঠা থেকে অভ্যন্তরীণ ইউটিএফ -16 উপস্থাপনায় রূপান্তরিত করে; আমি মোটামুটি নিশ্চিত যে ফায়ারফক্স ঠিক এটি পেয়েছে, তাই অপেরা কী করে তা আমি সত্যিই চিন্তা করি না।

ইউটিএফ -32 (ওরফে ইউসিএস 4) বেশিরভাগ অ্যাপ্লিকেশনের পক্ষে অর্থহীন, যেহেতু এটি এতটাই স্থান-চাহিদা, তাই এটি বেশ নন স্টার্টার।

— JasonTrue
সূত্র
6
আমি ইউটিএফ -8 এবং সারোগেট জোড়গুলিতে আপনার মন্তব্যটি যথেষ্টভাবে পাইনি। সারোগেট জোড়গুলি কেবল একটি ধারণা যা ইউটিএফ -16 এনকোডিংয়ে অর্থবহ, তাই না? সম্ভবত যে কোডটি ইউটিএফ -16 এনকোডিং থেকে সরাসরি ইউটিএফ -8 এনকোডিংয়ে রূপান্তরিত হয় এটি ভুল হতে পারে এবং সেই ক্ষেত্রে সমস্যাটি ভুলভাবে ইউটিএফ -16 পড়ছে, ইউটিএফ -8 না লিখে। এটা কি সঠিক?
— ক্রেগ ম্যাককুইন
11
জেসন যে কথা বলছে তা হ'ল এমন সফ্টওয়্যার যা ইচ্ছাকৃতভাবে ইউটিএফ -8 প্রয়োগ করে: একটি সারোগেট জুড়ি তৈরি করুন, তারপরে ইউটিএফ -8 প্রতিটি অর্ধে আলাদাভাবে এনকোড করুন। সেই এনকোডিংয়ের সঠিক নামটি সিইএসইউ -8, তবে ওরাকল (উদাঃ) এটিকে ইউটিএফ -8 হিসাবে ভুল উপস্থাপন করে। জাভা অবজেক্ট সিরিয়ালাইজেশনের জন্য অনুরূপ স্কিম নিয়োগ করে তবে এটি "পরিবর্তিত ইউটিএফ -8" হিসাবে এবং কেবলমাত্র অভ্যন্তরীণ ব্যবহারের জন্য ডকুমেন্টেড। (এখন, আমরা যদি লোকেরা কেবল সেই ডকুমেন্টেশনটি পড়তে পারি এবং ডেটা ইনপুটস্ট্রিম # রিডআউটএফ () এবং ডেটাআউটপুটস্ট্রিম # রাইটআউটএফ () অনুপযুক্তভাবে ব্যবহার করতে পারি ...)
আফাইক, ইউটিএফ -32 এখনও পরিবর্তনশীল দৈর্ঘ্যের এনকোডিং এবং ইউসিএস 4 এর সমান নয় যা কোড পয়েন্টের নির্দিষ্ট পরিসীমা।
— ইওনিল
ইউনিল, ইউটিএফ -32 কেবল তখনই ইউসিএস 4 থেকে আলাদা হবে যখন আমাদের কাছে ইউনিকোড স্ট্যান্ডার্ড থাকে যাতে ইউসিএস 5 বা এর চেয়ে বড় কিছু থাকে।
— জেসনট্রু
@ জেসনট্রু এখনও তবুও, কেবল ফলাফলগুলি সমানভাবে সমান, নকশার দ্বারা গ্যারান্টিযুক্ত নয়। একই জিনিসটি 32-বিট মেমরি ঠিকানা, ওয়াই 2 কে, ইউটিএফ 16 / ইউসিএস 2 এ ঘটেছিল। নাকি আমাদের সেই সাম্যের কোনও গ্যারান্টি আছে? আমাদের যদি থাকে তবে আমি আনন্দের সাথে এটি ব্যবহার করব। তবে আমি কোনও সম্ভাব্য ব্রেকিং কোড লিখতে চাই না । আমি একটি চরিত্রের স্তরের কোড লিখছি, এবং ইউটিএফের মধ্যে ট্রান্সকোড করার কোনও গ্যারান্টিযুক্ত উপায়ের অভাব <-> কোড পয়েন্ট আমাকে অনেকটা বাড়িয়ে তুলছে।
— Eonil
16

ইউটিএফ -8 অবশ্যই যাওয়ার উপায়, সম্ভবত উচ্চতর পারফরম্যান্স এলোমেলো অ্যাক্সেসের প্রয়োজন হয় এমন আলগোরিদিমগুলিতে অভ্যন্তরীণ ব্যবহারের জন্য ইউটিএফ -32 সহ (তবে এটি অক্ষরের সমন্বয়কে উপেক্ষা করে)।

ইউটিএফ -16 এবং ইউটিএফ -32 উভয়ই (পাশাপাশি তাদের এলই / বিই রূপগুলি) চূড়ান্ততার সমস্যায় ভুগছে, তাই এগুলি কখনই বাহ্যিকভাবে ব্যবহার করা উচিত নয়।

— Tronic
সূত্র
9
ইউটিএফ -8 দিয়েও অবিচ্ছিন্ন সময় এলোমেলো অ্যাক্সেস সম্ভব, কেবল কোড পয়েন্টের পরিবর্তে কোড ইউনিট ব্যবহার করুন। হতে পারে আপনার সত্যিকারের এলোমেলো কোড পয়েন্ট অ্যাক্সেসের দরকার আছে তবে আমি কখনও ব্যবহারের কেস দেখিনি, এবং এর পরিবর্তে আপনি এলোমেলো গ্রাফিম ক্লাস্টার অ্যাক্সেসটি পেতে চান।
15

হল UTF-16? অবশ্যই ক্ষতিকারক এখানে আমার লবণের শস্য, তবে একটি প্রোগ্রামে পাঠ্যের জন্য ঠিক তিনটি গ্রহণযোগ্য এনকোডিং রয়েছে:

  • এএসসিআইআই: নিম্ন স্তরের জিনিসগুলির সাথে কাজ করার সময় (যেমন: মাইক্রোকন্ট্রোলার) যা আরও ভাল কিছু দিতে পারে না
  • ইউটিএফ 8: ফিক্সগুলির মতো স্থির-প্রস্থ মিডিয়ায় স্টোরেজ

  • পূর্ণসংখ্যা কোডপয়েন্টস ("সিপি"?): আপনার প্রোগ্রামিং ভাষা এবং প্ল্যাটফর্মের জন্য সুবিধাজনক বৃহত্তম সংখ্যার একটি অ্যারে (কম রিসোর্সের সীমাতে ASCII- এর সিদ্ধান্ত) পুরানো কম্পিউটারগুলিতে ইন্টি 32 এবং 64-বিট অ্যাড্রেসিং সহ যেকোনো কিছুতে 64 হওয়া উচিত।

  • স্পষ্টতই লিগ্যাসি কোডের ইন্টারফেসগুলি পুরানো কোডটিকে সঠিক করে তোলার জন্য কী এনকোডিংয়ের প্রয়োজন তা ব্যবহার করে।

— ডেভিড এক্স
সূত্র
4
@ সিমন বুচান, U+10ffffসর্বাধিক উইন্ডোটির বাইরে চলে যাবে যখন (কোড না থাকলে) কোডপয়েন্টগুলি শেষ হয়ে যাবে। এটি বলেছিল, গতির জন্য পি 64৪ সিস্টেমে ইন্ট 32 ব্যবহার করা সম্ভবত নিরাপদ, যেহেতু আমার সন্দেহ হয় যে U+ffffffffআপনি 2050 এর আশেপাশে 128 বিট সিস্টেমে আপনার কোডটি পুনরায় লিখতে বাধ্য করার আগে তারা ছাড়িয়ে যাবে ( "বৃহত্তম উপলব্ধ" এর বিপরীতে সুবিধাজনক "(এটি সম্ভবত int256 বা bignums বা কিছু হতে পারে)"
— ডেভিড এক্স
1
@ ডেভিড: ইউনিকোড 5.2 কোডগুলি 107,361 কোডপয়েন্ট enc 867,169 অব্যবহৃত কোডপয়েন্ট রয়েছে। "কখন" কেবল নির্বোধ। একটি ইউনিকোড কোডপয়েন্টটি 0 থেকে 0x10FFFF পর্যন্ত সংখ্যার হিসাবে সংজ্ঞায়িত করা হয়, এমন একটি সম্পত্তি যা ইউটিএফ -16 নির্ভর করে। (এছাড়াও 2050 128 বিট সিস্টেমের জন্য একটি অনুমান কমিয়ে দেবে বলে মনে হচ্ছে যখন কোনও 64-বিট সিস্টেম ইন্টারনেটের সম্পূর্ণতা তার ঠিকানার
3
@ ডেভিড: আপনার "কখন" ইউনিকোড কোডপয়েন্টগুলি শেষ হওয়ার কথা উল্লেখ করছে, 128-বিট সুইচ নয় যা হ্যাঁ, পরবর্তী কয়েক শতাব্দীতে হবে। স্মৃতি থেকে ভিন্ন, চরিত্রগুলির কোনও তাত্পর্যপূর্ণ বৃদ্ধি নেই, তাই ইউনিকোড কনসোর্টিয়ামটি নির্দিষ্টভাবে গ্যারান্টি দিয়েছে যে তারা কখনও কোনও উপরে কোডপয়েন্ট বরাদ্দ করবে নাU+10FFFF । এটি সত্যই এই পরিস্থিতিতেগুলির মধ্যে একটি যখন 21 বিট কারও পক্ষে যথেষ্ট।
10
@ সিমন বুচান: কমপক্ষে প্রথম যোগাযোগ হওয়া পর্যন্ত। :)
3
ইউনিকোড গ্যারান্টি দিয়েছিল যে ইউ + এফএফএফএফ এর উপরেও কোনও কোড পয়েন্ট থাকবে না।
— শ্যানন সিভেরেন্স
13

ইউনিকোড 0x10FFFF (1,114,112 কোড) পর্যন্ত কোড পয়েন্টগুলি সংজ্ঞায়িত করে, বহুভাষিক পরিবেশে স্ট্রিং / ফাইলের নাম ইত্যাদির সাথে চলমান সমস্ত অ্যাপ্লিকেশন এটিকে সঠিকভাবে পরিচালনা করতে হবে।

ইউটিফ -16 : কেবল 1,112,064 কোডগুলিকে আচ্ছাদন করে। যদিও ইউনিকোডের শেষে রয়েছে তারা 15-16 প্লেন (ব্যক্তিগত ব্যবহারের অঞ্চল) থেকে রয়েছে। এটি ইউটিএফ -16 ধারণাটি ভঙ্গ করা ছাড়া ভবিষ্যতে আর বাড়তে পারে না ।

উত -8 : তাত্ত্বিকভাবে 2,216,757,376 কোডগুলি coversেকে দেয়। ইউনিকোড কোডের বর্তমান পরিসরটি সর্বোচ্চ 4 বাইট ক্রম দ্বারা উপস্থাপিত হতে পারে। এটি বাইট অর্ডার সমস্যার সাথে ভোগেনা, এটি এসকিআইয়ের সাথে "সামঞ্জস্যপূর্ণ"।

উত্স -32 : তাত্ত্বিকভাবে 2 ^ 32 = 4,294,967,296 কোডগুলি অন্তর্ভুক্ত করে। বর্তমানে এটি পরিবর্তনশীল দৈর্ঘ্যের এনকোড নয় এবং সম্ভবত ভবিষ্যতে হবে না not

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

মূল সমস্যাটি হ'ল অনেক প্রোগ্রামার উইন্ডোজ ইউনিকোড = ইউটিএফ -16 এর সাথে লেনদেন করে এমনকি এটি পরিবর্তনশীল দৈর্ঘ্যের এনকোডড হওয়াটিও জানেন না বা উপেক্ষা করেন না।

এটি * নিক্স প্ল্যাটফর্মে সাধারণত যেভাবে হয় তা বেশ ভাল, সি স্ট্রিংগুলি (চর *) ইউটিফ -8 এনকোডেড, প্রশস্ত সি স্ট্রিং (ডাব্লুচিকার_আট *) ইউটিফ -32 হিসাবে ব্যাখ্যা করা হয় ।

— পাভেল মাচ্যানিয়াক
সূত্র
7
দ্রষ্টব্য: ইউটিএফ -১ ইউনিকোড কনসোর্টিয়াম হিসাবে সমস্ত ইউনিকোডকে অন্তর্ভুক্ত করে যে সিদ্ধান্ত নিয়েছে যে 10 এফএফএফএফ ইউনিকোডের শীর্ষ রেঞ্জ এবং সংজ্ঞায়িত ইউটিএফ -8 সর্বাধিক 4 বাইট দৈর্ঘ্য এবং স্পষ্টভাবে বহির্ভূত পরিসীমা 0xD800-0xDFFF বৈধ কোড পয়েন্ট পরিসীমা থেকে এবং এই পরিসীমাটি ব্যবহারের জন্য ব্যবহৃত হয় সারোগেট জোড়া। সুতরাং যে কোনও বৈধ ইউনিকোড পাঠ্য এই এনকোডিংগুলির প্রত্যেকটির সাথে উপস্থাপন করা যেতে পারে। ভবিষ্যতে বাড়ার বিষয়েও। দেখে মনে হয় না যে 1 মিলিয়ন কোড পয়েন্ট কোনও দূর ভবিষ্যতে যথেষ্ট হবে না।
7
@ কেরেক: ভুল: ইউসিএস -২ একটি বৈধ ইউনিকোড এনকোডিং নয়। সংজ্ঞা অনুসারে সমস্ত ইউটিএফ- * এনকোডিংগুলি কোনও ইউনিকোড কোড পয়েন্ট উপস্থাপন করতে পারে যা ইন্টারচেঞ্জের জন্য আইনী। ইউসিএস -২ এর তুলনায় অনেক কম প্রতিনিধিত্ব করতে পারে, আরও কয়েকটিও। পুনরাবৃত্তি: ইউসিএস -২ কোনও বৈধ ইউনিকোড এনকোডিং নয়, এএসসিআইআইয়ের চেয়ে অন্য কোনও বিষয়।
— tchrist
1
"আমি উত -8 এর সাধারণ ব্যবহারের পক্ষে সমর্থন জানিনা do এটি পরিবর্তনশীল দৈর্ঘ্যের এনকোডেড (সূচী দ্বারা অ্যাক্সেস করা যাবে না)"
— ইয়ান বয়ড
9
@ ইয়ান বয়ড, একটি এলোমেলো অ্যাক্সেস প্যাটার্নে স্ট্রিংয়ের স্বতন্ত্র চরিত্রটি অ্যাক্সেস করার প্রয়োজনটি অবিশ্বাস্যভাবে অত্যুক্তি করা হয়েছে। এটি চরিত্রের ম্যাট্রিক্সের তির্যকটি গণনা করার মত সাধারণ, যা খুব বিরল। স্ট্রিংগুলি কার্যত সর্বদা ক্রমানুসারে প্রক্রিয়াভুক্ত হয় এবং যেহেতু আপনি ইউটিএফ -8 চর এন এ আছেন (ইউটিএফ -8 চর এন + 1 অ্যাক্সেস করেছেন তাই) কোনও সমস্যা নেই। স্ট্রিংগুলিতে এলোমেলো অ্যাক্সেস করার খুব বেশি প্রয়োজন নেই। আপনি যদি মনে করেন যে ইউটিএফ -8 এর পরিবর্তে ইউটিএফ -32 এ যাওয়ার সঞ্চয় স্থানটি আপনার নিজের মতামত, তবে আমার কাছে এটি পুরোপুরি একটি অ-ইস্যু।
— tchrist
2
@ ক্রিশ্চ, আমি আপনাকে স্ট্রিংগুলি কার্যত সর্বদা প্রক্রিয়াকরণে মঞ্জুর করব যদি আপনি "সিক্যুয়াল" হিসাবে বিপরীত পুনরাবৃত্তি অন্তর্ভুক্ত করেন এবং প্রসারিত করুন যে একটি স্ট্রিংয়ের পিছনের শেষের সাথে একটি পরিচিত স্ট্রিংয়ের সাথে আরও কিছুটা তুলনা করা যায়। দুটি খুব সাধারণ পরিস্থিতি হ'ল স্ট্রিংয়ের শেষে থেকে সাদা স্থান ছাঁটাই করা এবং কোনও পথের শেষে ফাইল এক্সটেনশন পরীক্ষা করা।
— অ্যান্ডি ডেন্ট
11

এটি তালিকায় যুক্ত করুন:

উপস্থাপিত পরিস্থিতিটি সহজ (এটির তুলনায় আরও সহজ যেহেতু আমি এখানে এটি উপস্থাপিতের তুলনায় আরও উপস্থাপন করব!): 1.এ উইনফর্মস টেক্সটবক্স একটি ফর্মের সাথে খালি খালি বসে। এটির ম্যাক্সেলেন্থ সেট 20 হয়েছে ।

2. ব্যবহারকারী পাঠ্যবক্সে টাইপ করে বা এটিতে পাঠ্য আটকায়।

৩. আপনি টেক্সটবক্সে যা টাইপ করুন বা পেস্ট করবেন তা বিবেচনাধীন নয়, আপনি ২০ বছরের মধ্যে সীমাবদ্ধ, যদিও এটি সহানুভূতিতে ২০ এর বাইরে পাঠ্যকে বীপ করবে (এখানে ওয়াইএমএমভি; আমি আমার সাউন্ড স্কিমটি আমাকে সে প্রভাব দেবার জন্য পরিবর্তন করেছি!)।

৪.এখন ছোট প্যাকেটের পাঠ্য আকর্ষণীয় দু: সাহসিক কাজ শুরু করতে অন্য কোথাও প্রেরণ করা হয়।

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

একঘেয়েমি প্রশমিত করতে আমি এমনকি ফর্মটির নাম দিয়েছি ম্যাজিক কার্পেট রাইড ।

এটি কার্যকর নয়, এটির জন্য মূল্যবান।

সুতরাং পরিবর্তে, আমি আমার ম্যাজিক কার্পেট রাইড ফর্মটিতে নিম্নলিখিত 20 টি অক্ষর প্রবেশ করিয়েছি :

0123401234012340123 𠀀

আহ ওহ.

এই শেষ চরিত্রটি ইউ + 20000, ইউনিকোডের প্রথম এক্সটেনশন বি আইডোগ্রাফ (ওরফে ইউ + ডি 840 ইউ + ডিসি 100, এর নিকটতম বন্ধু যারা তাকে সম্মোহিত হতে লজ্জা পাচ্ছে না, যেমনটি সামনে ছিল) ....

এখানে চিত্র বর্ণনা লিখুন

এবং এখন আমাদের একটি বল খেলা আছে।

কারণ যখন টেক্সটবক্স.ম্যাক্সলেংথ সম্পর্কে কথা হয়

পাঠ্য বাক্সে ম্যানুয়ালি প্রবেশ করা যায় এমন সর্বাধিক সংখ্যক অক্ষর পান বা সেট করে।

আসলে এর অর্থ কী

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

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

  • System.Text.EncoderFallbackException: নির্দিষ্ট কোড পৃষ্ঠায় সূচক 0 তে ইউনিকোড অক্ষর \ uD850 অনুবাদ করতে অক্ষম *

আপনি নেট স্ট্রোকওয়ার্কের অন্য কোথাও এই স্ট্রিংটি পাস করলে ব্যতিক্রম (যেমনটি আমার সহকর্মী ড্যান থম্পসন করছিলেন)।

এখন ঠিক আছে, সম্ভবত পুরো ইউসিএস -২ থেকে ইউটিএফ -16 সিরিজটি অনেকের নাগালের বাইরে।
তবে এটি আশা করা যুক্তিসঙ্গত নয় যে টেক্সটবক্স T পাঠ্য কোনও সিস্টেম.স্ট্রিং তৈরি করবে না এটি। নেট ফ্রেমওয়ার্কের অন্য টুকরোটি ফেলে দেবে না? আমি বোঝাতে চাইছি, নিয়ন্ত্রণের কিছু ইভেন্ট আকারে এমন একটি সুযোগ নেই যা আসন্ন কাটাকাটি সম্পর্কে আপনাকে জানায় যেখানে আপনি সহজেই স্মার্ট বৈধতা যুক্ত করতে পারেন - বৈধতা যা নিয়ন্ত্রণ নিজেই করতে আপত্তি করে না। আমি এতদূর যেতে পারি যে এই পাঙ্ক নিয়ন্ত্রণ একটি সুরক্ষা চুক্তি ভঙ্গ করছে যা এমনকি যদি সুরক্ষা সমস্যা তৈরি করতে পারে তবে আপনি যদি অপ্রত্যাশিত ব্যতিক্রমগুলির কারণে কোনও অ্যাপ্লিকেশনকে পরিষেবার অস্বীকার হিসাবে অকার্যকরভাবে বাতিল করতে পারেন। কেন কোনও উইনফোর্স প্রক্রিয়া বা পদ্ধতি বা অ্যালগরিদম বা কৌশল অবৈধ ফলাফল আনতে হবে?

সূত্র: মাইকেল এস কাপলান এমএসডিএন ব্লগ

— ম্যাথিউ
সূত্র
ধন্যবাদ, খুব ভাল লিঙ্ক! আমি এটি প্রশ্নের তালিকায় যুক্ত করেছি।
9

আমি অগত্যা বলব না যে ইউটিএফ -16 ক্ষতিকারক। এটি মার্জিত নয়, তবে এটি ইউসিএস -২ এর সাথে সামনের দিকে সামঞ্জস্যের উদ্দেশ্যে কাজ করে ঠিক যেমন জিবি ১80০৩০ জিবি 2312 এর সাথে, এবং ইউটিএফ -8 ASCII এর সাথে করে।

মাইক্রোসফ্ট এবং সান প্রায় 16-বিট চরিত্রের চারপাশে বিশাল এপিআই তৈরি করার পরে, মিড্রিমে ইউনিকোডের কাঠামোয় মৌলিক পরিবর্তন করা ক্ষতিকারক। পরিবর্তনের সচেতনতা ছড়িয়ে দিতে ব্যর্থতা আরও ক্ষতিকারক ছিল ।

— dan04
সূত্র
8
ইউটিএফ -8 হ'ল এএসসিআইআই-র একটি সুপারস্টার, তবে ইউটিএফ -16 ইউসিএস -2-এর সুপারসেট নয়। যদিও প্রায় একজন সুপারসেট, ইউটিএফ -8 এ ইউসিএস -2 এর সঠিক এনকোডিংয়ের ফলে সিইএসইউ -8 নামে পরিচিত ঘৃণার ফলস্বরূপ; ইউসিএস -২ এর সরোগেট নেই, কেবলমাত্র সাধারণ কোড পয়েন্ট, তাই তাদের অবশ্যই এটি অনুবাদ করা উচিত। ইউটিএফ -16 এর আসল সুবিধা হ'ল ইউটিএফ -8 এর জন্য একটি সম্পূর্ণ পুনর্লিখনের চেয়ে কোনও ইউসিএস -2 কোডবেস আপগ্রেড করা সহজ। মজার, হাহ?
1
অবশ্যই, প্রযুক্তিগতভাবে ইউটিএফ -16 ইউসিএস -2 এর সুপারস্টার নয়, তবে ইউ + ডি 800 থেকে ইউ + ডিএফএফএফ কখন ইউটিএফ -16 সারোগেট ব্যতীত অন্য কোনও কিছুর জন্য ব্যবহৃত হয় ?
— dan04
2
কিছু যায় আসে না। বাইস্ট্রিমে অন্ধভাবে চলে যাওয়া ছাড়া অন্য যে কোনও প্রক্রিয়াজাতকরণের জন্য আপনাকে সরোগেট জোড়গুলি ডিকোড করতে হবে, আপনি যদি এটি ইউসিএস -২ হিসাবে চিকিত্সা করেন তবে আপনি এটি করতে পারবেন না।
6

ইউটিএফ -16 হ্যান্ডলিং এবং স্পেসের মধ্যে সেরা সমঝোতা এবং এজন্য বেশিরভাগ বড় প্ল্যাটফর্মগুলি (উইন 32, জাভা,। নেট) স্ট্রিংগুলির অভ্যন্তরীণ উপস্থাপনের জন্য এটি ব্যবহার করে।

— নেমানজা ত্রিফুনোভিচ
সূত্র
31
-1 কারণ ইউটিএফ -8 সম্ভবত ছোট হতে পারে বা উল্লেখযোগ্যভাবে পৃথক নয়। নির্দিষ্ট এশিয়ান স্ক্রিপ্টগুলির জন্য ইউটিএফ -8 গ্লিফ প্রতি তিন বাইট হয় যখন ইউটিএফ -16 কেবল দুটি হয় তবে এটি ইউটিএফ -8 এএসসিআইআইয়ের একমাত্র বাইট হিসাবে ভারসাম্যপূর্ণ (যা প্রায়শই পণ্যের নাম, কমান্ড এবং এ জাতীয় এশিয়ান ভাষার মধ্যে প্রদর্শিত হয় না) কিছু)। তদ্ব্যতীত, বর্ণিত ভাষাগুলিতে, একটি গ্লাইফ লাতিন অক্ষরের চেয়ে বেশি তথ্য সরবরাহ করে তাই এটি আরও বেশি স্থান গ্রহণের পক্ষে যুক্তিযুক্ত।
32
উভয় বিকল্পের সবচেয়ে খারাপ দিকগুলির সংমিশ্রণটিকে আমি ভাল সমঝোতা বলব না।
18
এটি ইউটিএফ -8 এর চেয়ে সহজ নয়। এটিও পরিবর্তনশীল দৈর্ঘ্যের।
— লুস্কুবাল
36
ইউটিএফ -16 এর সুবিধাগুলি সম্পর্কে বিতর্ক একদিকে রেখে: উইন্ডোজ, জাভা বা। নেট ইউটিএফ -16 ব্যবহারের কারণ নয় is উইন্ডোজ এবং জাভা তারিখটি এমন এক সময়ের, যেখানে ইউনিকোড ছিল একটি 16-বিট এনকোডিং। ইউসিএস -২ তখন যুক্তিসঙ্গত পছন্দ ছিল। ইউনিকোড যখন ইউটিএফ -16 এ স্থানান্তরিত হয়ে একটি 21-বিট এনকোডিং হয়ে যায় তখন বিদ্যমান প্ল্যাটফর্মগুলির মধ্যে সেরা পছন্দ ছিল। পরিচালনা বা স্থান সমঝোতার সাথে স্বাচ্ছন্দ্যের সাথে এর কোনও সম্পর্ক ছিল না। এটি কেবল উত্তরাধিকারের বিষয়।
— জোয়
10
.NET এখানে উইন্ডোজ উত্তরাধিকার সূত্রে প্রাপ্ত।
— জোয়
6

আমি কখনও ইউটিএফ -16 এর বিষয়টি বুঝতে পারি নি। আপনি যদি সর্বাধিক স্থান-দক্ষ প্রতিনিধিত্ব চান তবে ইউটিএফ -8 ব্যবহার করুন। আপনি যদি পাঠ্যটিকে স্থির দৈর্ঘ্যের হিসাবে বিবেচনা করতে সক্ষম হতে চান তবে ইউটিএফ -32 ব্যবহার করুন। আপনি যদি না চান তবে ইউটিএফ -16 ব্যবহার করুন। সবচেয়ে খারাপ বিষয়, যেহেতু ইউটিএফ -16 এর সমস্ত সাধারণ (বেসিক বহুভাষিক বিমান) অক্ষর একক কোড পয়েন্টে ফিট করে, ইউটিএফ -16 স্থির-দৈর্ঘ্য বলে ধরে নেওয়া বাগগুলি সূক্ষ্ম এবং খুঁজে পাওয়া শক্ত হবে, আপনি যদি চেষ্টা করার চেষ্টা করেন তবে এটি ইউটিএফ -8 দিয়ে, আপনি আন্তর্জাতিককরণের চেষ্টা করার সাথে সাথে আপনার কোডটি দ্রুত এবং উচ্চস্বরে ব্যর্থ হবে।

— dsimcha
সূত্র
6

যেহেতু আমি এখনও মন্তব্য করতে পারি না, তাই আমি এটি একটি উত্তর হিসাবে পোস্ট করি, যেহেতু মনে হয় আমি অন্যথায় লেখকের সাথে যোগাযোগ করতে পারি না utf8everywhere.org। অন্যান্য স্ট্যাকেক্সচেঞ্জে আমার যথেষ্ট খ্যাতি রয়েছে বলে আমি স্বয়ংক্রিয়ভাবে মন্তব্যটির সুবিধাটি পাই না এটি লজ্জার বিষয়।

এটি মতামতের একটি মন্তব্য হিসাবে বোঝানো হয়েছে : হ্যাঁ, ইউটিএফ -16 ক্ষতিকারক উত্তর হিসাবে বিবেচনা করা উচিত ।

একটি সামান্য সংশোধন:

char*উইন্ডোজ-এপিআই ফাংশনগুলির এএনএসআই-স্ট্রিং সংস্করণগুলিতে দুর্ঘটনাক্রমে কোনও ইউটিএফ -8 পাস করা থেকে রোধ করার জন্য, কোনওটিকে সংজ্ঞায়িত করা উচিত UNICODE, নয় _UNICODE। _UNICODEমত মানচিত্রগুলি ফাংশন _tcslenথেকে wcslen, না MessageBoxকরার MessageBoxW। পরিবর্তে, UNICODEসংজ্ঞায়িত পরবর্তীটির যত্ন নেয়। প্রমাণের জন্য, এটি এমএস ভিজ্যুয়াল স্টুডিও 2005 এর WinUser.hশিরোনাম থেকে এসেছে:

#ifdef UNICODE
#define MessageBox  MessageBoxW
#else
#define MessageBox  MessageBoxA
#endif // !UNICODE

খুব কমপক্ষে, এই ত্রুটিটি সংশোধন করা উচিত utf8everywhere.org।

একটি পরামর্শ:

এটিকে মিস / ভুলে যাওয়া কম সহজ করার জন্য গাইডের কোনও ডেটা স্ট্রাকচারের ওয়াইড-স্ট্রিং ভার্সনের সুস্পষ্ট ব্যবহারের উদাহরণ থাকতে পারে। ফাংশনের ওয়াইড-স্ট্রিং সংস্করণ ব্যবহারের শীর্ষে ডেটা স্ট্রাকচারের ওয়াইড-স্ট্রিং সংস্করণগুলি ব্যবহার করা এটিকে আরও কম সম্ভাবনা দেয় যে ঘটনাক্রমে কেউ এই জাতীয় ফাংশনের একটি এএনএসআই-স্ট্রিং সংস্করণ বলে।

উদাহরণের উদাহরণ:

WIN32_FIND_DATAW data; // Note the W at the end.
HANDLE hSearch = FindFirstFileW(widen("*.txt").c_str(), &data);
if (hSearch != INVALID_HANDLE_VALUE)
{
    FindClose(hSearch);
    MessageBoxW(nullptr, data.cFileName, nullptr, MB_OK);
}
— জেল গের্টস
সূত্র
একমত; ধন্যবাদ! আমরা দলিলটি আপডেট করব। ডকুমেন্টটির এখনও আরও বিকাশ এবং ডাটাবেসগুলি সম্পর্কিত তথ্য যুক্ত করা দরকার। আমরা শব্দের অবদান পেয়ে খুশি।
— পাভেল রদজিভিলভস্কি
@ পাভেলর্যাডজিভিলভস্কি _UNICODEএখনও রয়েছেন :(
— কিউবস্প্ল 42
মনে রাখার জন্য ধন্যবাদ. কিউবস, জেলি, আপনি কি আমাদের এসভিএন-এর কোনও ব্যবহারকারী চান?
— পাভেল রদজিভিলভস্কি
@ পাভেল শিওর, এটির প্রশংসা করবে!
— জেলি গের্টস
@ জেলজিটারস: আমি এই বিলম্বের জন্য ক্ষমা চাইছি। আপনি আমাদের ইমেলগুলি (মেনিফেস্টো থেকে লিঙ্কিত) বা ফেসবুকের মাধ্যমে সর্বদা আমাদের সাথে যোগাযোগ করতে পারেন। আমরা খুঁজে পাওয়া সহজ। যদিও আমি বিশ্বাস করি যে আপনি এখানে এনেছেন তা আমরা স্থির করেছি (এবং আমি আপনাকে সেখানে জমা দিয়েছি), পুরো ইউটিএফ -8 বনাম ইউটিএফ -16 বিতর্কগুলি এখনও প্রাসঙ্গিক। আপনার যদি অবদানের আরও কিছু থাকে তবে নির্দ্বিধায় those ব্যক্তিগত চ্যানেলগুলির মাধ্যমে আমাদের সাথে যোগাযোগ করুন।
— ybungalobill
5

কেউ বলেছেন ইউসিএস 4 এবং ইউটিএফ -32 একই ছিল। না, তবে আমি জানি আপনি কী বোঝাতে চেয়েছেন। এর মধ্যে একটি হ'ল অন্যটির এনকোডিং। আমি আশা করি তারা প্রথম থেকেই পরিণতি নির্দিষ্ট করার চিন্তা করত তাই আমাদের এখানেও শেষ লড়াইয়ের লড়াই না ঘটে। তারা কি আসতে পারত না? কমপক্ষে ইউটিএফ -8 সর্বত্র একরকম (যদি না কেউ 6 টি বাইটের সাথে আসল স্পেস অনুসরণ না করে)।

আপনি হল UTF-16 ব্যবহার করেন তাহলে আপনি আছে multibyte অক্ষর জন্য হ্যান্ডলিং অন্তর্ভুক্ত করা। বাইট অ্যারেতে 2N ইনডেক্স করে আপনি Nth অক্ষরে যেতে পারবেন না। আপনার এটি চলতে হবে, বা চরিত্র সূচক থাকতে হবে। অন্যথায় আপনি একটি বাগ লিখেছেন।

সি ++ এর বর্তমান খসড়াটি বলছে যে ইউটিএফ -32 এবং ইউটিএফ -16 এ স্বল্প-এন্ডিয়ান, বিগ-এন্ডিয়ান এবং অনির্ধারিত রূপগুলি থাকতে পারে। সত্যি? যদি ইউনিকোড নির্দিষ্ট করে দিয়েছিল যে প্রত্যেককে শুরু থেকেই লিটল এন্ডিয়ান করতে হয় তবে এটি সবই সহজ been (আমি বিগ-এন্ডিয়ানগুলির সাথেও ভাল হয়ে উঠতে পারি)) পরিবর্তে, কিছু লোক এটিকে এক উপায়ে প্রয়োগ করেছিল, অন্যটি কিছু, এবং এখন আমরা কিছুই করার জন্য নির্বিকার সাথে আটকে আছি। কখনও কখনও এটি সফটওয়্যার ইঞ্জিনিয়ার হতে বিব্রতকর হয়।

— রেভস , 2 ব্যবহারকারী 71% ব্যবহারকারী 22815
সূত্র
অনির্ধারিত পরিণতিটি বিওএমকে প্রথম অক্ষর হিসাবে অন্তর্ভুক্ত করার কথা, যা স্ট্রিংটি পড়তে হবে তা নির্ধারণের জন্য ব্যবহৃত হয়। ইউসিএস -4 এবং ইউটিএফ -32 প্রকৃতপক্ষে আজকাল একই, অর্থাত্ একটি 32 বিট পূর্ণসংখ্যায় 0 এবং 0x10FFFF এর মধ্যে একটি সংখ্যাসূচক ইউসিএস মান।
5
@ ট্রনিক: প্রযুক্তিগতভাবে, এটি সত্য নয়। যদিও ইউসিএস -4 যে কোনও 32-বিট পূর্ণসংখ্যার সঞ্চয় করতে পারে, ইউটিএফ -32-তে অক্ষরবিহীন কোড পয়েন্টগুলি সংরক্ষণ করা নিষিদ্ধ যা ইন্টারচেঞ্জের জন্য অবৈধ, যেমন 0xFFFF, 0xFFFE, এবং সমস্ত সার্গেটস। ইউটিএফ একটি পরিবহন এনকোডিং, অভ্যন্তরীণ নয়।
— tchrist
যতক্ষণ না বিভিন্ন প্রসেসরের বিভিন্ন বাইট অর্ডার ব্যবহার করা অব্যাহত থাকে ততক্ষণ এন্ডিয়নেস ইস্যুগুলি অনিবার্য। তবে, ইউটিএফ -16 এর ফাইল স্টোরেজ করার জন্য যদি "পছন্দের" বাইট অর্ডার থাকত তবে এটি ভাল লাগত।
— কিওয়ার্টি
যদিও ইউটিএফ -32 কোড পয়েন্টগুলির জন্য নির্দিষ্ট-প্রস্থ , এটি অক্ষরের জন্য নির্দিষ্ট-প্রস্থ নয় । ("অক্ষরগুলির সংমিশ্রণ" নামে পরিচিত এমন কিছু শুনেছেন?) সুতরাং আপনি 4N বাইট অ্যারেতে সূচক করে N'th চরিত্রটিতে যেতে পারবেন না ।
— মুসিফিল
2

বিকাশকারী যথেষ্ট যত্নবান হলে এটি ক্ষতিকারক বলে মনে করি না।
এবং তারা ভাল জানেন যদি তাদের এই বাণিজ্য বন্ধ গ্রহণ করা উচিত।

একজন জাপানী সফ্টওয়্যার বিকাশকারী হিসাবে, আমি ইউসিএস -২ যথেষ্ট বড় খুঁজে পেয়েছি এবং স্থান সীমাবদ্ধ করা আপাতদৃষ্টিতে যুক্তিটিকে সহজ করে তোলে এবং রানটাইম মেমরি হ্রাস করে, তাই ইউসিএস -২ সীমাবদ্ধতার অধীনে utf-16 ব্যবহার করা যথেষ্ট ভাল good

ফাইল সিস্টেম বা অন্যান্য অ্যাপ্লিকেশন রয়েছে যা কোডপয়েন্টগুলি এবং বাইটগুলি আনুপাতিক হিসাবে ধরে নিয়েছে, যাতে কাঁচা কোডপয়েন্ট নম্বরটি কিছু স্থির আকারের স্টোরেজ অনুযায়ী ফিট হওয়ার গ্যারান্টিযুক্ত হতে পারে।

একটি উদাহরণ হ'ল এনটিএফএস এবং ভিএফএটি ইউসিএস -২ কে তাদের ফাইলের নাম স্টোরেজ এনকোডিং হিসাবে উল্লেখ করে ।

এই উদাহরণগুলি যদি সত্যিই ইউসিএস -4 সমর্থন করার জন্য প্রসারিত করতে চায় তবে আমি যাইহোক যাইহোক সবকিছুর জন্য utf-8 ব্যবহার করতে সম্মত হতে পারি, তবে নির্দিষ্ট দৈর্ঘ্যের মতো ভাল পয়েন্ট রয়েছে:

  1. দৈর্ঘ্য দ্বারা আকার গ্যারান্টি দিতে পারেন (তথ্য আকার এবং কোডপয়েন্ট দৈর্ঘ্য আনুপাতিক)
  2. হ্যাশ দেখার জন্য এনকোডিং নম্বর ব্যবহার করতে পারেন
  3. সঙ্কুচিত নয় এমন ডেটা যুক্তিসঙ্গত আকারযুক্ত (utf-32 / UCS-4 এর তুলনায়)

ভবিষ্যতে যখন কোনও এম্বেড থাকা ডিভাইসে মেমরি / প্রসেসিং শক্তি সস্তার হয় তখন আমরা অতিরিক্ত ক্যাশে মিস করা বা পৃষ্ঠা ত্রুটিগুলি এবং অতিরিক্ত মেমরির ব্যবহারের জন্য ডিভাইসটি কিছুটা ধীর গতিতে গ্রহণ করতে পারি তবে অদূর ভবিষ্যতে আমার ধারণা হবে না ...

— holmes
সূত্র
3
যারা এই মন্তব্যটি পড়ছেন তাদের জন্য, এটি লক্ষণীয় যে ইউসিএস -2 ইউটিএফ -16 এর মতো জিনিস নয়। দয়া করে বুঝতে পার্থক্যগুলি দেখুন।
— মাইকবাবকক
1

"সবচেয়ে জনপ্রিয় এনকোডিংগুলি ইউটিএফ -16 কে ক্ষতিকারক হিসাবে বিবেচনা করা উচিত?"

বেশ সম্ভবত, তবে বিকল্পগুলি অবশ্যই আরও বেশি ভাল হিসাবে দেখা উচিত নয়।

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

কেবলমাত্র ইউটিএফ -16 এর বিপরীতে ক্ষতিকারক হিসাবে বিবেচিত হতে পারে, বলুন, ইউটিএফ -8 হ'ল এটি বিএমপির বাইরে (সারোগেটের এক জোড়া হিসাবে) কোড পয়েন্টগুলির আলাদা পদ্ধতি রয়েছে। কোড যদি কোড পয়েন্ট দ্বারা অ্যাক্সেস বা পুনরাবৃত্তি করতে ইচ্ছুক হয় তবে এর অর্থ এটির পার্থক্য সম্পর্কে সচেতন হওয়া দরকার। OTOH, এর অর্থ হ'ল বিদ্যমান কোডগুলির একটি যথেষ্ট পরিমাণ যা "অক্ষরগুলি" ধরে নেয় তা সর্বদা দ্বি-বাইট পরিমাণে ফিট হতে পারে - মোটামুটি সাধারণ, যদি ভুল হয়, অনুমান - কমপক্ষে এগুলি পুনর্নির্মাণ না করেই কাজ চালিয়ে যেতে পারে। অন্য কথায়, কমপক্ষে আপনি সেই চরিত্রগুলি দেখতে পাবেন যা সঠিকভাবে পরিচালনা করা হচ্ছে না!

আমি আপনার প্রশ্নটি তার মাথা ঘুরিয়ে দিয়ে বলব যে ইউনিকোডের সম্পূর্ণ জঘন্য শেবাংকে ক্ষতিকারক হিসাবে বিবেচনা করা উচিত এবং প্রত্যেককে 8 বিট এনকোডিং ব্যবহার করা উচিত, আমি দেখেছি (গত 20 বছরে) যেখানে নেতৃত্ব দেয়: ভয়াবহ বিভিন্ন আইএসও 8859 এনকোডিংগুলি, এবং সিরিলিকের জন্য ব্যবহৃত পুরো সেট এবং ইবিসিডিক স্যুট এবং ... ভাল, ইউনিকোড এর সমস্ত ত্রুটিগুলির জন্য বিভ্রান্তি। কেবল যদি এটি বিভিন্ন দেশের ভুল বোঝাবুঝির মধ্যে এমন বাজে আপোষ না হত।

— ডোনাল ফেলো
সূত্র
আমাদের ভাগ্য জেনে, কয়েক বছরের মধ্যে আমরা ইউটিএফ -16 এ নিজেদেরকে স্থানের বাইরে চলে যাব। সাধরণ।
— ডোনাল ফেলো
3
মূল বিষয়টি হ'ল পাঠটি ছলচাতুরির সাথে শক্ত। ডিজিটাল উপায়ে সেই তথ্য উপস্থাপনের কোনও পদ্ধতিকে জটিল করা যায় না। এটি একই কারণে যে তারিখগুলি শক্ত, ক্যালেন্ডারগুলি শক্ত, সময় কঠোর, ব্যক্তিগত নামগুলি কঠোর, ডাক ঠিকানাগুলি শক্ত: যখনই ডিজিটাল মেশিনগুলি মানুষের সাংস্কৃতিক গঠনগুলির সাথে ছেদ করে, জটিলতা ফেটে যায়। এটা জীবনের একটি সত্য। মানুষ ডিজিটাল যুক্তিতে কাজ করে না।
— অ্যারিস্টটল পাগাল্টজিস
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.