UTF-16 හානිකර ලෙස සැලකිය යුතුද?

බොහෝ විට මතභේදාත්මක ප්‍රශ්නයක් වන්නේ කුමක්දැයි මම විමසීමට යන්නෙමි: "වඩාත් ජනප්‍රිය කේතන ක්‍රමයක් වන යූටීඑෆ් -16 හානිකර යැයි සැලකිය යුතුද?"

මා මෙම ප්‍රශ්නය අසන්නේ ඇයි?

UTF-16 ඇත්ත වශයෙන්ම විචල්‍ය දිග කේතීකරණයක් බව ක්‍රමලේඛකයින් කීදෙනෙක් දැනුවත්ද? මෙයින් මා අදහස් කරන්නේ අන්‍යාගමික යුගල ලෙස නිරූපණය වන කේත ලක්ෂ්‍යයන් එකකට වඩා වැඩි ගණනක් ගන්නා බවයි.

මම දන්නවා; බොහෝ යෙදුම්, රාමු සහ ඒපීඅයි යූටීඑෆ් -16 භාවිතා කරයි, එනම් ජාවා ස්ට්‍රිං, සී # ස්ට්‍රිං, වින් 32 ඒපීඅයි, Qt GUI පුස්තකාල, ICU යුනිකෝඩ් පුස්තකාලය යනාදිය. කෙසේ වෙතත්, මේ සියල්ල සමඟම, සැකසීමේදී මූලික දෝෂ රාශියක් ඇත. BMP වලින් පිටත අක්ෂර (UTF-16 මූලද්‍රව්‍ය දෙකක් භාවිතා කර කේතනය කළ යුතු අක්ෂර).

උදාහරණයක් ලෙස, මෙම අක්ෂර වලින් එකක් සංස්කරණය කිරීමට උත්සාහ කරන්න:

• U ( U + 1D11E ) MUSICAL SYMBOL G CLEF
• U ( U + 1D565 ) ගණිතමය ඩබල්-ස්ට්‍රක් කුඩා ටී
• U ( U + 1D7F6 ) ගණිතමය මොනොස්පේස් ඩිජිටල් ශුන්‍යය
• 𠂊 ( U + 2008A ) හැන් චරිතය

ඔබ ස්ථාපනය කර ඇති අකුරු මත පදනම්ව ඔබට සමහරක් මග හැරෙනු ඇත. මෙම අක්ෂර සියල්ලම BMP (මූලික බහුභාෂා ගුවන්යානය) වලින් පිටත ය. ඔබට මෙම අක්ෂර දැකිය නොහැකි නම්, ඔබට යුනිකෝඩ් අක්ෂර යොමුව තුළ ඒවා බැලීමට උත්සාහ කළ හැකිය .

උදාහරණයක් ලෙස, වින්ඩෝස් හි මෙම අක්ෂර ඇතුළත් ගොනු නාම සෑදීමට උත්සාහ කරන්න; UTF-16 භාවිතා කරන විවිධ යෙදුම්වල මෙම චරිත හැසිරෙන ආකාරය බැලීමට "බැක්ස්පේස්" සමඟ මෙම අක්ෂර මකා දැමීමට උත්සාහ කරන්න. මම පරීක්ෂණ කිහිපයක් කළ අතර ප්‍රති results ල තරමක් නරක ය:

• ඔපෙරා ඒවා සංස්කරණය කිරීමේදී ගැටළුවක් ඇත (අවශ්‍ය වන්නේ මුද්‍රණ 2 ක් බැක්ස්පේස් හි මකන්න)
• නොට්පෑඩ් සමඟ ඒවා නිවැරදිව ගනුදෙනු කළ නොහැක (බැක්ස්පේස් හි අවශ්‍ය මුද්‍රණ 2 මකන්න)
• ගොනු නාම සංස්කරණ කවුළු සංවාද වල කැඩී බිඳී ඇත (බැක්ස්පේස් හි අවශ්‍ය මුද්‍රණ 2 මකන්න)
• සියලුම QT3 යෙදුම් සමඟ ඒවා සමඟ ගනුදෙනු කළ නොහැක - එක් සංකේතයක් වෙනුවට හිස් කොටු දෙකක් පෙන්වන්න .
• u'X'!=unicode('X','utf-16')BMP වලින් පිටත X අක්ෂර ඇති විට සමහර වේදිකාවල කෙලින්ම භාවිතා කරන විට පයිතන් එවැනි අක්ෂර වැරදි ලෙස සංකේතවත් කරයි.
• පයිතන් යූටීඑෆ් -16 යුනිකෝඩ් නූල් සමඟ සම්පාදනය කරන විට පයිතන් 2.5 යුනිකෝඩෙටාටා එවැනි අක්ෂරවල ගුණාංග ලබා ගැනීමට අසමත් වේ.
• ස්ටැක් ඕවර්ෆ්ලෝ යුනිකෝඩ් අක්ෂර ලෙස කෙලින්ම සංස්කරණය කළ හොත් මෙම අක්ෂර පෙළෙන් ඉවත් කරන බව පෙනේ (මෙම අක්ෂර HTML යුනිකෝඩ් ගැලවී යාමෙන් පෙන්වනු ලැබේ).
• WinForms TextBox මැක්ස්ලෙන්ග් සමඟ සීමා වූ විට අවලංගු නූල් ජනනය කළ හැකිය .

UTF-16 භාවිතා කරන බොහෝ යෙදුම්වල එවැනි දෝෂ සොයා ගැනීම අතිශයින්ම පහසු බව පෙනේ.

ඉතින් ... යූටීඑෆ් -16 හානිකර යැයි සැලකිය යුතු යැයි ඔබ සිතනවාද?

මෙය පැරණි පිළිතුරකි. නවතම යාවත්කාලීන කිරීම් සඳහා සෑම තැනකම UTF-8
බලන්න .

මතය: ඔව්, යූටීඑෆ් -16 හානිකර යැයි සැලකිය යුතුය . එය පැවතීමට හේතුව මීට කලකට පෙර යූසීඑස් -4 යනු කුමක්දැයි පුළුල් චාර් එකක් වනු ඇතැයි නොමඟ ගිය විශ්වාසයක් පැවතුනි.

යූටීඑෆ් -8 හි “ඇන්ග්ලෝ-කේන්ද්‍රීයතාව” තිබියදීත්, එය පෙළ සඳහා ඇති එකම ප්‍රයෝජනවත් කේතන ක්‍රමය ලෙස සැලකිය යුතුය. වැඩසටහන්, වෙබ් පිටු සහ එක්ස්එම්එල් ලිපිගොනු, ඕඑස් ගොනු නාම සහ වෙනත් පරිගණකයෙන් පරිගණකයට පෙළ අතුරුමුහුණත් කිසි විටෙකත් නොතිබිය යුතු යැයි කෙනෙකුට තර්ක කළ හැකිය. නමුත් ඒවා සිදු වූ විට, පෙළ මිනිස් පා .කයන්ට පමණක් නොවේ.

අනෙක් අතට, යූටීඑෆ් -8 පොදු කාර්ය පිරිවැය සැලකිය යුතු වාසි ඇති අතර ගෙවිය යුතු කුඩා මිලකි. නූල් පසුකර යන නොදන්නා කේත සමඟ අනුකූල වීම වැනි වාසි char*. මෙය විශිෂ්ට දෙයකි. UTF-8 හි ඇති ඒවාට වඩා UTF-16 හි කෙටි වන ප්‍රයෝජනවත් අක්ෂර කිහිපයක් තිබේ.

අනෙක් සියලුම කේතන ක්‍රම අවසානයේදී මිය යනු ඇතැයි මම විශ්වාස කරමි. එම්එස්-වින්ඩෝස්, ජාවා, අයිසීයූ, පයිතන් එය ඔවුන්ගේ ප්‍රියතම ලෙස භාවිතා කිරීම නැවැත්වීම මෙයට සම්බන්ධ වේ. දිගු පර්යේෂණ හා සාකච්ඡාවලින් පසුව, මගේ සමාගමේ සංවර්ධන සම්මුතීන් OS API ඇමතුම් හැර වෙනත් ඕනෑම තැනක UTF-16 භාවිතා කිරීම තහනම් කර ඇති අතර මෙය අපගේ යෙදුම්වල ක්‍රියාකාරීත්වයේ වැදගත්කම සහ අප වින්ඩෝස් භාවිතා කරන කාරණය තිබියදීත්. සෑම විටම උපකල්පනය කරන ලද-යූටීඑෆ් 8 std::stringස්වදේශීය යූටීඑෆ් -16 බවට පරිවර්තනය කිරීම සඳහා පරිවර්තන කාර්යයන් සංවර්ධනය කරන ලද අතර එය වින්ඩෝස් විසින්ම නිසි ලෙස සහාය නොදක්වයි .

" අවශ්‍ය දේ අවශ්‍ය තැන භාවිතා කරන්න " යැයි පවසන අයට , මම කියන්නේ: සෑම තැනකම එකම කේතන ක්‍රමයක් භාවිතා කිරීමෙන් විශාල වාසියක් ඇති අතර, වෙනත් ආකාරයකින් කිරීමට ප්‍රමාණවත් හේතුවක් මා දකින්නේ නැත. විශේෂයෙන්, මම සිතන්නේ wchar_tC ++ ට එකතු කිරීම වැරැද්දක් වන අතර C ++ 0x සඳහා යුනිකෝඩ් එකතු කිරීම් ද එසේමය. එස්ටීඑල් ක්‍රියාවට නැංවීමෙන් ඉල්ලා සිටිය යුතු දෙය නම් සෑම std::stringහෝ char*පරාමිතියක්ම යුනිකෝඩ්-අනුකූල ලෙස සලකනු ලැබේ.

" ඔබට අවශ්‍ය දේ භාවිතා කරන්න " ප්‍රවේශයට මම විරුද්ධ වෙමි . එවැනි නිදහසක් සඳහා කිසිදු හේතුවක් මා දකින්නේ නැහැ. පෙළ විෂය පිළිබඳ ප්‍රමාණවත් ව්‍යාකූලතාවයක් ඇති අතර එහි ප්‍රති all ලයක් ලෙස මෙම සියලු බිඳුණු මෘදුකාංග ඇතිවේ. ඉහත සඳහන් කිරීමෙන් පසුව, ක්‍රමලේඛකයින් එක් සුදුසු ක්‍රමයක් ලෙස යූටීඑෆ් -8 පිළිබඳ එකඟතාවකට පැමිණිය යුතු බව මට විශ්වාසයි. (මම ආසියා භාෂාව කතා නොකරන රටකින් පැමිණ වින්ඩෝස් මත හැදී වැඩුණු නිසා ආගමික හේතූන් මත යූටීඑෆ් -16 ට පහර දීමට මා බලාපොරොත්තු වනු ඇත).

මම වින්ඩෝස් හි පෙළ කරන්නේ කෙසේද යන්න පිළිබඳ වැඩි විස්තර බෙදා ගැනීමට කැමතියි, සහ සංයුක්ත වේලාව පරීක්ෂා කරන ලද යුනිකෝඩ් නිරවද්‍යතාවය, භාවිතයේ පහසුව සහ කේතයේ වඩා හොඳ බහු-වේදිකාගත කිරීම සඳහා මම අනෙක් සියල්ලන්ට නිර්දේශ කරමි. කවුළුවල යුනිකෝඩ් භාවිතා කිරීමේ නිසි ක්‍රමය ලෙස සාමාන්‍යයෙන් නිර්දේශිත දෙයට වඩා යෝජනාව සැලකිය යුතු ලෙස වෙනස් වේ. එහෙත්, මෙම නිර්දේශයන් පිළිබඳ ගැඹුරු පර්යේෂණවල ප්‍රති ulted ලය වූයේ එකම නිගමනයකි. ඉතින් මෙන්න:

• භාවිතා නොකරන්න wchar_tහෝ std::wstringUTF-16 පිළිගැනීම ඒපීඅයි යාබදව ස්ථානය හැර වෙනත් ස්ථානයක.
• භාවිතා නොකරන්න _T("")හෝ L""UTF-16 literals (මෙම එක් රටකින් UTF-16 deprecation කොටසක් ලෙස, සම්මත ඉවත් කල යුතුය).
• වර්ග, කාර්යයන් හෝ සංවේදී බව එම ව ත්පන්න භාවිතා නොකරන්න _UNICODEවැනි, නිරන්තර LPTSTRහෝ CreateWindow().
• එහෙත්, _UNICODEසෑම විටම නිර්වචනය කර ඇත්තේ, char*විනෝපී වෙත නූල් නොයැවීම සඳහා නිහ ly ව සම්පාදනය කිරීමයි
• std::stringsහා char*වැඩසටහන ඕනෑම තැනක (නැත්නම් පවසයි නොවේ නම්) UTF-8 ලෙස සලකනු ලැබේ
• මගේ සියලු නූල් std::stringඔබට වර්‍ග * හෝ වචනාර්ථයෙන් සම්මත කළ හැකි වුවද convert(const std::string &).

• පුළුල් චාර් ( LPWSTR) පිළිගන්නා Win32 ශ්‍රිත පමණක් භාවිතා කරන්න . කිසි විටෙකත් පිළිගන්නා LPTSTRහෝ පිළිගන්නේ නැත LPSTR. පරාමිතීන් මේ ආකාරයෙන් සම්මත කරන්න:

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

  (ප්‍රතිපත්තිය පහත පරිවර්තන කාර්යයන් භාවිතා කරයි.)

• MFC නූල් සමඟ:

  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);
  

• වින්ඩෝස් හි ගොනු, ගොනු නාම සහ fstream සමඟ වැඩ කිරීම:

  • සමත් නැහැ std::stringහෝ const char*කිරීමට ගොනු තර්ක fstreamපවුල. MSVC STL UTF-8 තර්ක සඳහා සහය නොදක්වයි, නමුත් සම්මත නොවන දිගුවක් ඇති අතර එය පහත පරිදි භාවිතා කළ යුතුය:

  • සමඟ std::stringතර්ක පරිවර්තනය කරන්න :std::wstringUtils::Convert

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

    MSVC හි ආකල්ප fstreamවෙනස් වන විට අපට පරිවර්තනය අතින් ඉවත් කිරීමට සිදුවේ .

  • මෙම කේතය බහු-වේදිකාවක් නොවන අතර අනාගතයේදී එය අතින් වෙනස් කිරීමට සිදුවනු ඇත
  • වැඩි විස්තර සඳහා fstreamයුනිකෝඩ් පර්යේෂණ / සාකච්ඡා නඩුව 4215 බලන්න .
  • UTF8 නොවන අන්තර්ගතයන් සහිත පෙළ ප්‍රතිදාන ගොනු කිසි විටෙකත් නිෂ්පාදනය නොකරන්න
  • 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
}

යුනිකෝඩ් කේත ලක්ෂ්‍ය අක්ෂර නොවේ! සමහර විට ඒවා ග්ලයිෆස් (දෘශ්‍ය ආකෘති) පවා නොවේ.

උදාහරණ කිහිපයක්:

• "Ⅲ" වැනි රෝම සංඛ්‍යා කේත ලක්ෂ්‍ය. ("Iii" ලෙස පෙනෙන තනි අක්‍ෂරයකි.)
• "Á" වැනි උච්චාරණය කරන ලද අක්ෂර තනි ඒකාබද්ධ අක්ෂරයක් ලෙස දැක්විය හැකිය "\ u00e1" හෝ අක්ෂරයක් සහ වෙන් කළ ඩයක්‍රිටික් "\ u0061 \ u0301".
• ග්‍රීක සිම්පල් සිග්මා වැනි අක්ෂර, වචන ස්ථානවල මැද ("σ") සහ අවසානය ("ς") සඳහා විවිධ ස්වරූප ඇති නමුත් ඒවා සෙවීම සඳහා සමාන පද ලෙස සැලකිය යුතුය.
• යුනිකෝඩ් අභිමතය පරිදි හයිපනය U + 00AD, එය සන්දර්භය මත පදනම්ව දෘශ්‍ය ලෙස දර්ශනය විය හැකි හෝ නොවිය හැකි අතර අර්ථකථන සෙවීම සඳහා නොසලකා හරිනු ලැබේ.

යුනිකෝඩ් සංස්කරණය නිවැරදිව ලබා ගත හැකි එකම ක්‍රමය වන්නේ විශේෂ expert යෙකු විසින් ලියන ලද පුස්තකාලයක් භාවිතා කිරීම හෝ විශේෂ expert යෙකු වී ඔබම ලිවීමයි. ඔබ හුදෙක් කේත ලකුණු ගණනය කරන්නේ නම්, ඔබ ජීවත් වන්නේ පාප තත්වයක ය.

යුනිකෝඩ් ට්‍රාන්ස්ෆෝමර් පෝරමය (යූටීඑෆ්) භාවිතා කළ යුතු දේ පිළිබඳ සරල රීතියක් ඇත: - ගබඩා කිරීම සහ සන්නිවේදනය සඳහා utf-8 - දත්ත සැකසීම සඳහා utf-16 - ඔබ භාවිතා කරන බොහෝ වේදිකා API නම් ඔබට utf-32 සමඟ යා හැකිය. utf-32 (යුනික්ස් ලෝකයේ පොදු).

අද බොහෝ පද්ධති භාවිතා කරන්නේ utf-16 (Windows, Mac OS, Java, .NET, ICU, Qt). මෙම ලේඛනයද බලන්න: http://unicode.org/notes/tn12/

"UTF-16 හානිකර ලෙස" වෙත ආපසු, මම කියන්නේ: අනිවාර්යයෙන්ම නැත.

අන්‍යාගමිකයන්ට බිය වන පුද්ගලයින්ට (ඔවුන් යුනිකෝඩ් විචල්ය-දිග කේතීකරණයක් බවට පරිවර්තනය කරයි යැයි සිතමින්) අක්ෂර සහ යුනිකෝඩ් කේත ලක්ෂ්‍ය අතර සිතියම් ගත කරන අනෙක් (වඩා විශාල) සංකීර්ණතා තේරුම් නොගනී: අක්ෂර, බන්ධන, විචල්‍යතා තේරීම් ඒකාබද්ධ කිරීම , පාලක අක්ෂර ආදිය.

මෙම ලිපි මාලාව මෙතැනින් කියවන්න http://www.siao2.com/2009/06/29/9800913.aspx සහ UTF-16 පහසු ගැටළුවක් වන්නේ කෙසේදැයි බලන්න.

ඔව්, ඇත්තෙන්ම.

මන්ද? එය ව්‍යායාම කේතය සමඟ කළ යුතුය .

ටොම් ක්‍රිස්ටියන්සන් විසින් මෙම කෝඩ්පොයින්ට් භාවිත සංඛ්‍යාලේඛන දෙස බැලුවහොත්, ට්‍රාන්ස් -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

TDD ආ ict ාව ගන්න: "පරීක්ෂා නොකළ කේතය බිඳුණු කේතය", එය "අනවසර කේතය කැඩුණු කේතය" ලෙස නැවත මුද්‍රණය කරන්න, සහ BMP නොවන කේත ලක්ෂ්‍ය සමඟ ක්‍රමලේඛකයන්ට කොපමණ වාර ගණනක් ගනුදෙනු කළ යුතුදැයි සිතා බලන්න.

විචල්ය-පළල කේතන ක්‍රමයක් ලෙස UTF-16 සමඟ ගනුදෙනු නොකිරීමට අදාළ දෝෂ UTF-8 හි සමාන දෝෂ වලට වඩා නොදැනීමට ඉඩ ඇත . සමහර ක්‍රමලේඛන භාෂාවන් ඔබට UCS-2 වෙනුවට UTF-16 ලබා දීමට තවමත් සහතික වී නැති අතර සමහර ඊනියා ඉහළ මට්ටමේ ක්‍රමලේඛන භාෂා කේත ලකුණු වෙනුවට කේත ඒකක වෙත ප්‍රවේශය ලබා දෙයි (C පවා ඔබට ප්‍රවේශය ලබා දෙනු ඇත wchar_tසමහර වේදිකා කුමක් කළත් ඔබ භාවිතා කරන්නේ නම් කේත ලකුණු ).

යූටීඑෆ් -16 සිතීම හානිකර යැයි සිතිය හැකි යැයි මම යෝජනා කරමි, ඔබ යුනිකෝඩ් පිළිබඳ වැඩි අවබෝධයක් ලබා ගත යුතු බව පවසයි .

විෂයානුබද්ධ ප්‍රශ්නයක් සම්බන්ධයෙන් මගේ මතය ඉදිරිපත් කිරීම නිසා මා පහත් කොට ඇති හෙයින්, මට විස්තාරනය කිරීමට ඉඩ දෙන්න. යූටීඑෆ් -16 ගැන ඔබට කරදර වන්නේ හරියටම කුමක්ද? සෑම දෙයක්ම UTF-8 හි කේතනය කර ඇත්නම් ඔබ කැමතිද? UTF-7? නැත්නම් UCS-4 ගැන කොහොමද? ඇත්ත වශයෙන්ම සමහර යෙදුම් එහි සෑම අක්ෂර කේතයක්ම හැසිරවීමට නිර්මාණය කර නැත - නමුත් ඒවා අන්තර්ජාතික සීමාවන් අතර සන්නිවේදනය සඳහා විශේෂයෙන් වර්තමාන ගෝලීය තොරතුරු වසමේදී අවශ්‍ය වේ.

නමුත් ඇත්ත වශයෙන්ම, යූටීඑෆ් -16 හානිකර යැයි සිතිය යුතු නම් එය අවුල් සහගත හෝ අනිසි ලෙස ක්‍රියාත්මක කළ හැකිය (යුනිකෝඩ් නිසැකවම විය හැකිය), එවිට හානිකර නොවන ලෙස සලකනු ලබන චරිත කේතීකරණ ක්‍රමය කුමක්ද?

සංස්කරණය කරන්න: පැහැදිලි කිරීම සඳහා: ප්‍රමිතියක් අනිසි ලෙස ක්‍රියාත්මක කිරීම ප්‍රමිතියේ ගුණාත්මකභාවය පිළිබිඹු කිරීමක් ලෙස සලකන්නේ ඇයි? අනෙක් අය පසුව සඳහන් කළ පරිදි, යෙදුමක් නුසුදුසු ලෙස මෙවලමක් භාවිතා කරන නිසා, මෙවලම දෝෂ සහිත බව එයින් අදහස් නොවේ. එය එසේ නම්, අපට බොහෝ විට "var keyword හානිකර යැයි සැලකේ" හෝ "නූල් කිරීම හානිකර යැයි සැලකේ" වැනි දේවල් පැවසිය හැකිය. බොහෝ ක්‍රමලේඛකයින්ට එය නිසි ලෙස ක්‍රියාත්මක කිරීමට හා භාවිතා කිරීමට ඇති දුෂ්කරතා සමඟ ප්‍රශ්නය ප්‍රමිතියේ ගුණාත්මකභාවය හා ස්වභාවය ව්‍යාකූල කරවන බව මම සිතමි.

Utf-16 කේතීකරණයේ කිසිදු වරදක් නොමැත. නමුත් බිටු 16 ඒකක අක්ෂර ලෙස සලකන භාෂාවන් බොහෝ විට නරක ලෙස නිර්මාණය කර ඇති බව සැලකිය යුතුය. 'නමින් වර්ගයක් තිබීමcharසෑම විටම චරිතයක් නිරූපණය නොකරන ' තරමක් අවුල් සහගතය. බොහෝ සංවර්ධකයින් විසින් වර්‍ග වර්ගයක් කේත ලක්ෂ්‍යයක් හෝ අක්ෂරයක් නිරූපණය කරනු ඇතැයි අපේක්ෂා කරන හෙයින්, BMP වලින් ඔබ්බට අක්ෂරවලට නිරාවරණය වන විට බොහෝ කේත කැඩී යනු ඇත.

කෙසේ වෙතත්, utf-32 භාවිතා කිරීමෙන් පවා සෑම බිට් 32 කේත ලක්ෂ්‍යයක්ම අක්‍ෂරයක් නිරූපණය කරන බවක් අදහස් නොකෙරේ. අක්ෂර ඒකාබද්ධ කිරීම නිසා සත්‍ය අක්‍ෂරයක් කේත ලක්ෂ්‍ය කිහිපයකින් සමන්විත විය හැකිය. යුනිකෝඩ් කිසි විටෙකත් සුළුපටු නොවේ.

BTW. යූටීඑෆ් -8 පෝෂණය කරන අක්ෂර 8-බිට් යැයි අපේක්ෂා කරන වේදිකා සහ යෙදුම් සහිත එකම පන්තියේ දෝෂ තිබේ.

මගේ පුද්ගලික තේරීම සෑම විටම UTF-8 භාවිතා කිරීමයි. සෑම දෙයකටම පාහේ ලිනක්ස් වල ප්‍රමිතිය එයයි. එය බොහෝ පැරණි යෙදුම් සමඟ පසුපසට අනුකූල වේ. අනෙක් යූටීඑෆ් ආකෘතීන්ට එදිරිව ලතින් නොවන අක්ෂර සඳහා භාවිතා කරන අමතර ඉඩ ප්‍රමාණය අනුව ඉතා අවම පොදු කාර්යයක් ඇති අතර ලතින් අක්ෂර සඳහා අවකාශයේ සැලකිය යුතු ඉතිරියක් ඇත. වෙබයේ, ලතින් භාෂාවන් උත්තරීතර වන අතර, මම සිතන්නේ ඒවා අපේක්ෂා කළ හැකි අනාගතයක් සඳහා වනු ඇත. මුල් පෝස්ට් එකේ එක් ප්‍රධාන තර්කයක් ආමන්ත්‍රණය කිරීම සඳහා: යූටීඑෆ් -8 සමහර විට එහි බහු-බයිට් අක්ෂර ඇති බව සෑම ක්‍රමලේඛකයෙකුම පාහේ දනී. සෑම කෙනෙකුම මෙය නිවැරදිව ගනුදෙනු නොකරන නමුත් ඔවුන් සාමාන්‍යයෙන් දැනුවත්ව සිටින අතර එය UTF-16 සඳහා පැවසිය හැකි ප්‍රමාණයට වඩා වැඩිය. එහෙත්, ඇත්ත වශයෙන්ම, ඔබ ඔබේ යෙදුම සඳහා වඩාත් සුදුසු එකක් තෝරා ගත යුතුය. පළමු ස්ථානයේ එකකට වඩා ඇත්තේ එබැවිනි.

හොඳයි, ස්ථාවර ප්‍රමාණයේ සංකේත භාවිතා කරන කේතන ක්‍රමයක් ඇත. මම නිසැකවම අදහස් කළේ යූටීඑෆ් -32 ය. නමුත් සෑම සංකේතයක් සඳහාම බයිට් 4 ක් අපතේ යන ඉඩ ප්‍රමාණය වැඩිය , එදිනෙදා අවස්ථාවන්හිදී අප එය භාවිතා කරන්නේ ඇයි?

මගේ මතකයට අනුව, බොහෝ ගැටලු පෙනෙන්නේ සමහර මෘදුකාංග යුනිකෝඩ් ප්‍රමිතියට වඩා පහත වැටී ඇති නමුත් තත්වය නිවැරදි කිරීමට ඉක්මන් නොවීමයි. ඔපෙරා, වින්ඩෝස්, පයිතන්, Qt - මේ සියල්ලම යූටීඑෆ් -16 පුළුල් ලෙස ප්‍රසිද්ධියට පත්වීමට හෝ පැවැත්මට පෙර පෙනී සිටියේය. ඔපෙරා, වින්ඩෝස් එක්ස්ප්ලෝරර් සහ නොට්පෑඩ් වල BMP වලින් පිටත අක්ෂර සමඟ කිසිදු ගැටළුවක් නොමැති බව මට තහවුරු කළ හැකිය (අවම වශයෙන් මගේ පරිගණකයේ). කෙසේ වෙතත්, වැඩසටහන් මඟින් අන්වාදේශ යුගල හඳුනා නොගන්නේ නම්, ඔවුන් UTF-16 භාවිතා නොකරයි. එවැනි වැඩසටහන් සමඟ කටයුතු කිරීමේදී කුමන ගැටළු ඇති වුවද, ඔවුන්ට UTF-16 සමඟ කිසිදු සම්බන්ධයක් නැත.

කෙසේ වෙතත්, BMP සහය පමණක් ඇති පැරණි මෘදුකාංගවල ගැටළු තරමක් අතිශයෝක්තියට නංවා ඇතැයි මම සිතමි. BMP වලින් පිටත අක්ෂර හමු වන්නේ ඉතා නිශ්චිත අවස්ථා සහ ප්‍රදේශ වල පමණි. අනුව යුනිකෝඩ් නිල නිතර අසන ප්රශ්න , "පවා නැගෙනහිර ආසියානු පෙළ, අන්වාදේශ යුගල වැනි සිදුවීම් සියල්ල පෙළ ගබඩා 1 හොඳින්% ට වඩා අඩු සාමාන්ය විය යුතුයි". ඇත්ත වශයෙන්ම, BMP වලින් පිටත අක්ෂර නොසලකා හැරිය යුතු නොවේ මන්දයත් වෙනත් ආකාරයකින් වැඩසටහනක් යුනිකෝඩ්-අනුකූල නොවන නමුත් බොහෝ වැඩසටහන් එවැනි අක්ෂර අඩංගු පෙළ සමඟ වැඩ කිරීමට අදහස් නොකෙරේ. ඔවුන් එයට සහාය නොදක්වන්නේ නම් එය අප්‍රසන්න ය, නමුත් ව්‍යසනයක් නොවේ.

දැන් අපි විකල්පය සලකා බලමු. යූටීඑෆ් -16 නොපවතින නම්, අපට ASCII නොවන පෙළ සඳහා හොඳින් ගැලපෙන කේතීකරණයක් නොතිබෙනු ඇති අතර, යූසීඑස් -2 සඳහා නිර්මාණය කරන ලද සියලුම මෘදුකාංග යුනිකෝඩ් අනුකූලතාවයට පත්වීම සඳහා සම්පූර්ණයෙන්ම ප්‍රතිනිර්මාණය කළ යුතුය. දෙවැන්න බොහෝ දුරට සිදුවන්නේ යුනිකෝඩ් භාවිතය මන්දගාමී වීම පමණි. ASCII ට සාපේක්ෂව UTF-8 මෙන් UCS-2 හි පෙළ සමඟ අනුකූලතාව පවත්වා ගැනීමට අපට නොහැකි වනු ඇත.

දැන්, සියලු උරුම ගැටළු පසෙකට දමා, කේතීකරණයට එරෙහි තර්ක මොනවාද? යූටීඑෆ් -16 විචල්‍ය දිග බව වර්තමානයේ සංවර්ධකයින් නොදන්නා බවට මට සැකයක් ඇත, එය විකිපීඩියාව සමඟ ගැටෙන සෑම තැනකම ලියා ඇත. යූටීඑෆ් -8 යූටීඑෆ් -8 ට වඩා විග්‍රහ කිරීම අසීරු ය, යමෙකු සංකීර්ණතාවයක් ඇති බව පෙන්වා දුන්නේ නම්. UTF-16 හි පමණක් නූල් දිග තීරණය කිරීම අවුල් කිරීම පහසු යැයි සිතීම වැරදිය. ඔබ UTF-8 හෝ UTF-32 භාවිතා කරන්නේ නම්, එක් යුනිකෝඩ් කේත ලක්ෂ්‍යයක් අනිවාර්යයෙන්ම එක් අක්ෂරයක් අදහස් නොකරන බව ඔබ දැන සිටිය යුතුය. ඒ හැරෙන්නට, කේතීකරණයට එරෙහිව සැලකිය යුතු කිසිවක් ඇතැයි මම නොසිතමි.

එබැවින් කේතනය කිරීම හානිකර යැයි සැලකිය යුතු යැයි මම නොසිතමි. UTF-16 යනු සරල බව සහ සංයුක්තතාවය අතර සම්මුතියක් වන අතර, අවශ්‍ය දේ භාවිතා කිරීමේදී කිසිදු හානියක් නොමැත . සමහර අවස්ථා වලදී ඔබ ASCII සමඟ අනුකූලව සිටිය යුතු අතර ඔබට UTF-8 අවශ්‍ය වේ, සමහර අවස්ථාවලදී ඔබට හැන් දෘෂ්ටි කෝණයන් සමඟ වැඩ කිරීමට සහ UTF-16 භාවිතා කරමින් අවකාශය සංරක්ෂණය කිරීමට අවශ්‍යය, සමහර අවස්ථාවලදී ඔබට ස්ථිර ලෙස භාවිතා කරන අක්ෂරවල විශ්වීය නිරූපණයන් අවශ්‍ය වේ. දිග කේතනය. වඩාත් සුදුසු දේ භාවිතා කරන්න, එය නිසි ලෙස කරන්න.

වින්ඩෝස් අන්තර්ජාතිකකරණයේ වසර ගණනාව විශේෂයෙන් නැගෙනහිර ආසියානු භාෂාවලින් මා දූෂිත වන්නට ඇත, නමුත් මම නූල් වල අභ්‍යන්තරයෙන් වැඩසටහන් නිරූපණය සඳහා යූටීඑෆ් -16 වෙත නැඹුරු වන අතර, යූටීඑෆ් -8 ජාලය හෝ සරල පෙළ වැනි ලේඛන ගබඩා කිරීම සඳහා ය. UTF-16 සාමාන්‍යයෙන් වින්ඩෝස් මත වේගයෙන් සැකසිය හැක, එනමුත් වින්ඩෝස් හි UTF-16 භාවිතා කිරීමේ මූලික වාසිය එයයි.

යූටීඑෆ් -16 වෙත පිම්මක් පැනීම ජාත්‍යන්තර පෙළ හැසිරවීමේ සාමාන්‍ය නිෂ්පාදනවල ප්‍රමාණවත් බව නාටකාකාර ලෙස වැඩි දියුණු කළේය. අන්වාදේශ යුගල සලකා බැලිය යුතු විට ඇත්තේ පටු අවස්ථා කිහිපයක් පමණි (මකාදැමීම්, ඇතුළත් කිරීම් සහ රේඛා බිඳීම, මූලික වශයෙන්) සහ සාමාන්‍ය නඩුව බොහෝ දුරට කෙළින්ම ගමන් කරයි. මීට පෙර JIS ප්‍රභේද වැනි කේතන ක්‍රම මෙන් නොව, UTF-16 අන්‍යාගමික යුගල ඉතා පටු පරාසයකට සීමා කරයි, එබැවින් චෙක්පත සැබවින්ම ඉක්මන් වන අතර ඉදිරියට හා පසුපසට ක්‍රියා කරයි.

නිවැරදිව කේතනය කරන ලද යූටීඑෆ් -8 ද දළ වශයෙන් ඉක්මන් බව පිළිගත යුතුය. නමුත් යූටීඑෆ් -8 අනුපිළිවෙලවල් දෙකක් ලෙස අන්වාදේශ යුගල වැරදි ලෙස සංකේතවත් කරන බොහෝ බිඳුණු යූටීඑෆ් -8 යෙදුම් ද ඇත. එබැවින් යූටීඑෆ් -8 ගැලවීම සහතික නොකරයි.

සාමාන්‍යයෙන් UTF-8 පිටු වලින් අභ්‍යන්තර UTF-16 නිරූපණයකට පරිවර්තනය කළද, 2000 හෝ ඊට වැඩි කාලයක සිට IE විසින් අන්වාදේශ යුගල සාධාරණව හසුරුවයි; ෆයර්ෆොක්ස් එය නිවැරදිව ලබාගෙන ඇති බව මට විශ්වාසයි, එබැවින් ඔපෙරා කරන දේ මට ප්‍රශ්නයක් නොවේ.

UTF-32 (aka UCS4) බොහෝ යෙදුම් සඳහා අර්ථ විරහිත බැවින් එය එතරම් ඉඩ ප්‍රමාණයක් ඉල්ලුම් කරයි, එබැවින් එය තරු රහිත ය.

UTF-8 අනිවාර්යයෙන්ම යා යුතු මාර්ගයයි, සමහර විට UTF-32 සමඟ ඉහළ කාර්ය සාධනයක් සහිත අහඹු ප්‍රවේශයක් අවශ්‍ය ඇල්ගොරිතම වල අභ්‍යන්තර භාවිතය සඳහා (නමුත් එය ඒකාබද්ධ අක්ෂර නොසලකා හරියි).

UTF-16 සහ UTF-32 (මෙන්ම ඒවායේ LE / BE ප්‍රභේද) ද අන්තරාසර්ග ගැටලුවලින් පීඩා විඳිති, එබැවින් ඒවා කිසි විටෙකත් බාහිරව භාවිතා නොකළ යුතුය.

යූටීඑෆ් -16? අනිවාර්යයෙන්ම හානිකරයි. මගේ ලුණු ධාන්ය මෙහි ඇත, නමුත් වැඩසටහනක පෙළ සඳහා පිළිගත හැකි කේතීකරණ තුනක් තිබේ:

• ASCII: වඩා හොඳ කිසිවක් ලබා ගත නොහැකි පහත් මට්ටමේ දේවල් සමඟ (උදා: මයික්‍රොකොන්ට්රෝලර්) කටයුතු කරන විට
• UTF8: ලිපිගොනු වැනි ස්ථාවර පළල මාධ්‍යවල ගබඩා කිරීම

• නිඛිල කේත ලක්ෂ්‍ය ("සීපී"?): ඔබේ ක්‍රමලේඛන භාෂාව සහ වේදිකාව සඳහා පහසු වන විශාලතම නිඛිල සමූහයකි (අඩු අනුනාදක සීමාව තුළ ASCII වෙත දිරාපත් වේ). පැරණි පරිගණකවල int32 සහ 64-bit ලිපින සහිත ඕනෑම දෙයක් සඳහා int64 විය යුතුය.

• පැරණි කේත නිවැරදිව ක්‍රියාත්මක කිරීම සඳහා අවශ්‍ය කේතනාංකය භාවිතා කරයි.

යුනිකෝඩ් 0x10FFFF (කේත 1,114,112) දක්වා කේත ලකුණු අර්ථ දක්වයි, බහු භාෂා පරිසරය තුළ ධාවනය වන සියලුම යෙදුම් නූල් / ගොනු නාම ආදිය සමඟ කටයුතු කරයි.

Utf-16 : ආවරණය කරන්නේ කේත 1,112,064 ක් පමණි. යුනිකෝඩ් අවසානයේ ඇති අය 15-16 ගුවන් යානා වලින් වුවද (පුද්ගලික භාවිත ප්‍රදේශය). Utf-16 බිඳ දැමීම හැර අනාගතයේ දී එය තවදුරටත් වර්ධනය විය නොහැක සංකල්පය .

Utf-8 : න්‍යායාත්මකව කේත 2,216,757,376 ක් ආවරණය කරයි. වර්තමාන යුනිකෝඩ් කේත පරාසය උපරිම වශයෙන් බයිට් 4 කින් නිරූපණය කළ හැකිය. එය බයිට් අනුපිළිවෙලින් පීඩා විඳින්නේ නැත ගැටලුවකින් , එය ascii සමඟ "අනුකූල වේ".

Utf-32 : න්‍යායාත්මකව 2 ^ 32 = 4,294,967,296 කේත ආවරණය කරයි. දැනට එය විචල්ය දිග කේතනය කර නොමැති අතර අනාගතයේදී බොහෝ විට එසේ නොවනු ඇත.

එම කරුණු ස්වයං පැහැදිලි කිරීමකි. Utf-16 හි සාමාන්‍ය භාවිතය වෙනුවෙන් පෙනී සිටීම මට තේරෙන්නේ නැත . එය විචල්ය දිග කේතනය කර ඇත (දර්ශකයට ප්‍රවේශ විය නොහැක), වර්තමානයේදී පවා සමස්ත යුනිකෝඩ් පරාසය ආවරණය කිරීමට එය ගැටළු ඇත , බයිට් අනුපිළිවෙල හැසිරවිය යුතුය. ආදිය වින්ඩෝස් සහ සමහරක් වෙනත් ස්ථාන. බහු-වේදිකා කේත ලිවීමේදී යූටීඑෆ් -8 ස්වදේශීයව භාවිතා කිරීම වඩා හොඳ වන අතර වේදිකා මත යැපෙන ආකාරයෙන් (දැනටමත් යෝජනා කර ඇති පරිදි) අවසාන ස්ථානවල පමණක් පරිවර්තන සිදු කිරීම හොඳය . දර්ශකය මඟින් access ජු ප්‍රවේශය අවශ්‍ය වන විට සහ මතකය ගැටළුවක් නොවන විට, Utf-32 භාවිතා කළ යුතුය.

ප්‍රධාන ගැටළුව වන්නේ වින්ඩෝස් යුනිකෝඩ් = යූටීඑෆ් -16 සමඟ කටයුතු කරන බොහෝ ක්‍රමලේඛකයින් එය විචල්‍ය දිග කේතනය කර ඇති බව නොදැන හෝ නොසලකා හැරීමයි .

සාමාන්‍යයෙන් * නික්ස් වේදිකාවේ ඇති ආකාරය ඉතා හොඳයි, c නූල් (char *) Utf-8 කේතනය කර ඇති, පුළුල් c නූල් (wchar_t *) ලෙස අර්ථකථනය කර ඇත්තේ Utf-32 ලෙසිනි .

මෙය ලැයිස්තුවට එක් කරන්න:

ඉදිරිපත් කරන ලද අවස්ථාව ඉතා සරලයි (මුලින් තිබුනාට වඩා මම එය මෙහි ඉදිරිපත් කරමි.): 1.A WinForms TextBox හිස් පෝරමයක වාඩි වී සිටී. එහි උපරිම දිග 20 ක් වේ.

2. පරිශීලකයා ටෙක්ස්ට් බොක්ස් තුළට ටයිප් කරයි, නැතහොත් පෙළ එයට ඇලවිය හැක.

3. ඔබ ටෙක්ස්ට් බොක්ස් තුළට ටයිප් කරන හෝ ඇලවූ දේ කුමක් වුවත්, ඔබ 20 ට සීමා වේ, නමුත් එය සානුකම්පිතව 20 න් ඔබ්බට පෙළ දෙස බලනු ඇත (YMMV මෙහි; මම මගේ ශබ්ද ක්‍රමය වෙනස් කළෙමි!).

4. කුඩා පෙළ පැකට්ටුව වෙනත් තැනකට යවනු ලැබේ.

දැන් මෙය පහසු අවස්ථාවක් වන අතර ඕනෑම කෙනෙකුට ඔවුන්ගේ විවේක කාලය තුළ මෙය ලිවිය හැකිය. වින් ෆෝම්ස් භාවිතා කරමින් මම එය ක්‍රමලේඛන භාෂා කිහිපයකින්ම ලියා තැබුවෙමි, මන්ද මා කම්මැලි වී ඇති අතර මීට පෙර කිසි දිනෙක එය අත්හදා බලා නැත. සත්‍ය භාෂාවන් කිහිපයකින් පෙළ සමඟ මා රැහැන්ගත වී ඇති නිසාත්, මුළු විශ්වයේම සිටින ඕනෑම කෙනෙකුට වඩා යතුරුපුවරු පිරිසැලසුමක් ඇති නිසාත් ය.

කම්මැලිකම සමනය කිරීම සඳහා මම මැජික් කාපට් රයිඩ් යන ස්වරූපය පවා නම් කළෙමි .

මෙය ක්‍රියාත්මක වූයේ නැත, එය වටින දේ සඳහා.

ඒ වෙනුවට, මම පහත දැක්වෙන අක්ෂර 20 මගේ මැජික් කාපට් රයිඩ් ආකෘතියට ඇතුළත් කළෙමි :

0123401234012340123

අහ්.

එම අන්තිම චරිතය වන්නේ යුනිකෝඩ් හි පළමු විස්තාරණ බී දෘෂ්ටි කෝණය වන යූකා +000 (අකා යූ + ඩී 840 යූ + ඩීසී 100, එහි කිට්ටු මිතුරන්ට, ඔහු ඉදිරියේ දී මෙන්, එය ප්‍රතික්ෂේප කිරීමට ලැජ්ජා නොවන) ....

දැන් අපට බෝල ක්‍රීඩාවක් තිබේ.

කරන විට TextBox.MaxLength ගැන කතා

පෙළ කොටුවට අතින් ඇතුල් කළ හැකි උපරිම අක්ෂර ගණන ලබා ගනී හෝ සකසයි.

එය සැබවින්ම අදහස් කරන්නේ එයයි

පෙළ කොටුවට අතින් ඇතුල් කළ හැකි උපරිම UTF-16 LE කේත ඒකක ලබා ගැනීම හෝ සැකසීම සහ භාෂාමය චරිත සංකල්පය සමඟ හුරුබුහුටි ක්‍රීඩා කිරීමට උත්සාහ කරන ඕනෑම නූලකින් අනුකම්පා විරහිතව ජීවමාන කප්පාදු කරනු ඇත. කැප්ලාන් සහෝදරයා ආක්‍රමණශීලී බව සොයා ගනීවි (ගීස් ඔහුට තවත් ඉවත් වීමට අවශ්‍යයි!).

ලේඛනය යාවත්කාලීන කිරීම ගැන මම උත්සාහ කර බලන්නම් ....
මගේ UCS-2 සිට UTF-16 ශ්‍රේණිය මතක තබා ගන්නා නිතිපතා පා readers කයින් TextBox.MaxLength පිළිබඳ සරල සංකල්පය හා එය අවම වශයෙන් මෙම නඩුව සමඟ කටයුතු කළ යුතු ආකාරය පිළිබඳ මගේ නොසතුට සටහන් කරනු ඇත. එහි කුරිරු හැසිරීම නීති විරෝධී අනුක්‍රමයක් නිර්මාණය කරයි .නෙට් රාමුවේ අනෙක් කොටස් a

• System.Text.EncoderFallbackException: දර්ශක 0 හි යුනිකෝඩ් අක්ෂර \ uD850 නිශ්චිත කේත පිටුවට පරිවර්තනය කළ නොහැක. *

ව්‍යතිරේකය ඔබ .Net Framework හි වෙනත් තැනකින් සමත් වුවහොත් (මගේ සගයා වන ඩෑන් තොම්සන් කරමින් සිටි පරිදි).

දැන් හරි, සමහර විට සම්පූර්ණ UCS-2 සිට UTF-16 ශ්‍රේණිය බොහෝ දෙනෙකුට ලබා ගත නොහැක.
නමුත් TextBox.Text මඟින් නිෂ්පාදනය නොකෙරේ යැයි අපේක්ෂා කිරීම සාධාරණ නොවේ නොවේද?.නෙට් රාමුවේ තවත් කොටසක් විසි කිරීමට එය හේතු නොවේද? මම අදහස් කළේ, පාලනයේ යම් සිදුවීමක ස්වරූපයෙන් අවස්ථාවක් ඇති බවක් නොපෙනෙන අතර, ඉදිරියේදී කප්පාදු කිරීම ගැන ඔබට පවසන අතර එහිදී ඔබට වඩාත් පහසුවෙන් වලංගු භාවය එකතු කළ හැකිය. මෙම පන්ක් පාලනය ආරක්ෂිත කොන්ත්‍රාත්තුවක් කඩ කරන බව පැවසීමට තරම් දුරක් යන අතර, ඔබට අනාරක්ෂිත ව්‍යතිරේක ඇති කරමින් පංතියක් කළ හැකි නම්, අනාරක්ෂිත ආකාරයේ සේවා ප්‍රතික්ෂේප කිරීමක් ලෙස යෙදුමක් අවසන් කිරීමට ඔබට හැකිය. ඕනෑම WinForms ක්‍රියාවලියක් හෝ ක්‍රමයක් හෝ ඇල්ගොරිතමයක් හෝ තාක්ෂණයක් අවලංගු ප්‍රති results ල ලබා දිය යුත්තේ ඇයි?

මුලාශ්‍රය: මයිකල් එස්. කැප්ලාන් එම්එස්ඩීඑන් බ්ලොග් අඩවිය

UTF-16 හානිකර යැයි මම නොකියමි. එය අලංකාර නොවේ, නමුත් එය GB18030 GB2312 සමඟ කරන ආකාරයටම UCS-2 සමඟ පසුගාමී අනුකූලතාවයේ අරමුණ ඉටු කරයි, සහ UTF-8 ASCII සමඟ කරයි.

මයික්‍රොසොෆ්ට් සහ සන් විසින් බිට් 16 අක්ෂර වටා විශාල ඒපීඅයි සෑදීමෙන් පසුව, යුනිකෝඩ් ව්‍යුහයේ මූලික වෙනසක් සිදු කිරීම හානිකර විය. වෙනස පිළිබඳව දැනුවත් කිරීම අසමත් වීම වඩාත් හානිකර විය.

UTF-16 යනු හැසිරවීම සහ අවකාශය අතර ඇති හොඳම සම්මුතිය වන අතර බොහෝ ප්‍රධාන වේදිකා (Win32, Java, .NET) එය නූල්වල අභ්‍යන්තර නිරූපණය සඳහා භාවිතා කරයි.

UTF-16 හි කාරණය මා කිසි විටෙකත් තේරුම් ගෙන නොමැත. ඔබට වඩාත්ම අභ්‍යවකාශ-කාර්යක්ෂම නිරූපණය අවශ්‍ය නම්, UTF-8 භාවිතා කරන්න. පෙළ ස්ථාවර දිගක් ලෙස සැලකීමට ඔබට අවශ්‍ය නම්, UTF-32 භාවිතා කරන්න. ඔබට අවශ්‍ය නැතිනම් UTF-16 භාවිතා කරන්න. ඊටත් වඩා භයානක දෙය නම්, යූටීඑෆ් -16 හි ඇති පොදු (මූලික බහුභාෂා තලය) අක්ෂර සියල්ලම එකම කේත ලක්ෂ්‍යයකට ගැලපෙන හෙයින්, යූටීඑෆ් -16 ස්ථාවර දිග යැයි උපකල්පනය කරන දෝෂ සියුම් හා සොයා ගැනීම දුෂ්කර වන අතර ඔබ එසේ කිරීමට උත්සාහ කරන්නේ නම් මෙය UTF-8 සමඟ, ඔබ ජාත්‍යන්තරකරණය කිරීමට උත්සාහ කළ විගස ඔබේ කේතය වේගයෙන් හා හයියෙන් අසමත් වනු ඇත.

_{මට තවම අදහස් දැක්විය නොහැකි බැවින්, මම මෙය පිළිතුරක් ලෙස පළ කරමි, මන්ද මට වෙනත් ආකාරයකින් කතුවරුන් සම්බන්ධ කර ගත නොහැකි බව පෙනේ utf8everywhere.org . මට වෙනත් කොටස් හුවමාරුවලට ප්‍රමාණවත් කීර්තියක් ඇති බැවින් මට ස්වයංක්‍රීයව අදහස් දැක්වීමේ වරප්‍රසාදය නොලැබීම ලැජ්ජාවකි.}

මෙය අදහස් දැක්වීමක් ලෙස අදහස් කෙරේ : ඔව්, යූටීඑෆ් -16 හානිකර පිළිතුරක් ලෙස සැලකිය යුතුය .

එක් කුඩා නිවැරදි කිරීමක්:

අහම්බෙන් UTF-8 පසුකර එක් වැළැක්වීම සඳහා char*Windows-API කාර්යයන් ANSI-string සංස්කරණ බවට එක් අර්ථ යුතු UNICODEනැහැ, _UNICODE. _UNICODEවැනි කාර්යයන් සිතියම් _tcslenකිරීමට wcslenනොව, MessageBoxකිරීමට MessageBoxW. ඒ වෙනුවට, UNICODEනිර්වචනය දෙවැන්න ගැන සැලකිලිමත් වේ. සාක්ෂි සඳහා, මෙය MS Visual Studio 2005 හි WinUser.hශීර්ෂයෙන්:

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

අවම වශයෙන්, මෙම දෝෂය නිවැරදි කළ යුතුය utf8everywhere.org .

යෝජනාවක්:

දත්ත ව්‍යුහයක පුළුල්-නූල් අනුවාදය පැහැදිලිව භාවිතා කිරීම පිළිබඳ උදාහරණයක් මාර්ගෝපදේශයේ අඩංගු විය හැකිය, එය අතපසු කිරීම / අමතක කිරීම අඩු කිරීම සඳහා. පුළුල් පරාසයක පවතින දත්ත ව්‍යුහයන්හි පුළුල්-නූල් අනුවාදයන් භාවිතා කිරීම මඟින් එවැනි ශ්‍රිතයක අහම්බෙන් ANSI-string අනුවාදයක් ඇමතීමට ඇති ඉඩකඩ අඩු වේ.

උදාහරණයේ උදාහරණය:

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);
}

කවුරුහරි කිව්වා UCS4 සහ UTF-32 එක සමානයි කියලා. නැත, නමුත් ඔබ අදහස් කරන දේ මම දනිමි. ඒවායින් එකක් නම් අනෙකාගේ කේතනයකි. මම ප්‍රාර්ථනා කරනවා ඔවුන් මුල සිටම එන්ඩියන්ස් බව සඳහන් කිරීමට සිතුවා නම් අපට මෙහි ද එන්ඩියනස් සටන නොතිබෙනු ඇත. එය එන්නේ ඔවුන් දැක නැතිද? අවම වශයෙන් UTF-8 සෑම තැනකම සමාන වේ (යමෙකු මුල් පිරිවිතර බයිට් 6 ක් අනුගමනය නොකරන්නේ නම්).

ඔබ UTF-16 භාවිතා කරන්නේ නම් ඔබ සතුව ඇත multibyte chars සඳහා කටයුතු ඇතුළත් කිරීමට. 2N බයිට් අරාවකට සුචිගත කිරීමෙන් ඔබට Nth අක්‍ෂරයට යා නොහැක. ඔබට එය ගමන් කළ යුතුය, නැතහොත් චරිත දර්ශක තිබිය යුතුය. නැතිනම් ඔබ දෝෂයක් ලියා ඇත.

C ++ හි වර්තමාන කෙටුම්පත් පිරිවිතරයට අනුව UTF-32 සහ UTF-16 කුඩා-එන්ඩියන්, බිග්-එන්ඩියන් සහ නිශ්චිත නොවන ප්‍රභේද තිබිය හැකිය. ඇත්තටම? සෑම කෙනෙකුටම මුල සිටම කුඩා එන්ඩියන් කළ යුතු බව යුනිකෝඩ් විසින් නියම කර තිබුනේ නම්, ඒ සියල්ල සරල වනු ඇත. . සමහර විට මෘදුකාංග ඉංජිනේරුවෙකු වීම ලැජ්ජාවට කරුණකි.

සංවර්ධකයා ප්‍රමාණවත් ලෙස සැලකිලිමත් වන්නේ නම් එය හානිකර යැයි මම නොසිතමි.
ඔවුන් ද හොඳින් දන්නේ නම් ඔවුන් මෙම වෙළඳාම භාර ගත යුතුය.

ජපන් මෘදුකාංග සංවර්ධකයෙකු ලෙස, මම UCS-2 ප්‍රමාණවත් තරම් විශාල වන අතර අවකාශය සීමා කිරීම පෙනෙන ආකාරයට තර්කනය සරල කරන අතර ධාවන කාල මතකය අඩු කරයි, එබැවින් UCS-2 සීමාව යටතේ utf-16 භාවිතා කිරීම ප්‍රමාණවත්ය.

කේත ලක්ෂ්‍ය සහ බයිට් සමානුපාතික යැයි උපකල්පනය කරන ගොනු පද්ධතියක් හෝ වෙනත් යෙදුමක් ඇත, එවිට අමු කේත ලක්ෂ්‍ය අංකය යම් ස්ථාවර ප්‍රමාණයේ ගබඩාවකට ගැලපෙන බවට සහතික විය හැකිය.

එක් උදාහරණයක් වන්නේ UCS-2 නියම කරන NTFS සහ VFAT ය ඔවුන්ගේ ගොනු නාම ගබඩා කේතන ක්‍රමයක් ලෙස සඳහන් කිරීමයි.

එම උදාහරණය ඇත්ත වශයෙන්ම UCS-4 සඳහා සහය දැක්වීමට අවශ්‍ය නම්, කෙසේ හෝ සෑම දෙයක් සඳහාම utf-8 භාවිතා කිරීමට මට එකඟ විය හැකිය, නමුත් ස්ථාවර දිගට හොඳ ලකුණු ඇත:

1. දිග අනුව ප්‍රමාණය සහතික කළ හැකිය (දත්ත ප්‍රමාණය සහ කේත ලක්ෂ්‍ය දිග සමානුපාතික වේ)
2. හැෂ් බැලීම සඳහා කේතීකරණ අංකය භාවිතා කළ හැකිය
3. සම්පීඩිත නොවන දත්ත සාධාරණ ප්‍රමාණයේ (utf-32 / UCS-4 හා සසඳන විට)

අනාගතයේ දී ඕනෑම කාවැද්දූ උපාංගයක පවා මතකය / සැකසුම් බලය ලාභදායී වන විට, අමතර හැඹිලි මග හැරීම් හෝ පිටු දෝෂ සහ අමතර මතක භාවිතය සඳහා උපාංගය ටිකක් මන්දගාමී බව අපි පිළිගනිමු, නමුත් නුදුරු අනාගතයේදී මෙය සිදු නොවනු ඇතැයි මම අනුමාන කරමි ...

"වඩාත් ජනප්‍රිය කේතන ක්‍රමයක් වන යූටීඑෆ් -16 හානිකර යැයි සැලකිය යුතුද?"

බොහෝ දුරට ඉඩ ඇත, නමුත් විකල්පයන් වඩා හොඳ යැයි නොසිතිය යුතුය.

මූලික ගැටළුව වන්නේ ග්ලයිෆස්, අක්ෂර, කේත ලක්ෂ්‍ය සහ බයිට් අනුක්‍රම පිළිබඳ විවිධ සංකල්පයන් තිබීමයි. සාමාන්‍යකරණ පුස්තකාලයක ආධාරයෙන් වුවද මේ සෑම එකක් අතර සිතියම්ගත කිරීම සුළුපටු නොවේ. . දුෂ්කර; විකාර දෝෂ අපේක්ෂා කළ යුතුය (ඒවා ගැන මෙහි හ aning ා වැලපෙනවා වෙනුවට , අදාළ මෘදුකාංගයේ නඩත්තු කරන්නන්ට කියන්න ).

යූටීඑෆ් -16 හානිදායක යැයි සැලකිය හැකි එකම ක්‍රමය නම්, යූටීඑෆ් -8 යනු බීඑම්පීයෙන් පිටත කේත ලක්ෂ්‍ය කේතනය කිරීමේ වෙනස් ක්‍රමයක් ඇති බවයි (අන්‍යාගමික යුගලයක් ලෙස). කේත ලක්ෂ්‍යය අනුව ප්‍රවේශ වීමට හෝ නැවත යෙදීමට අපේක්ෂා කරන්නේ නම්, එයින් අදහස් වන්නේ එය වෙනස පිළිබඳව දැනුවත් විය යුතු බවයි. OTOH, එයින් අදහස් කරන්නේ "අක්ෂර" උපකල්පනය කරන දැනට පවතින කේතයේ සැලකිය යුතු ප්‍රමාණයක් සෑම විටම බයිට් දෙකකට ප්‍රමාණවත් විය හැකි බවයි - තරමක් පොදු, වැරදි නම්, උපකල්පනය - අවම වශයෙන් ඒ සියල්ල නැවත ගොඩනඟා නොගෙන දිගටම වැඩ කළ හැකිය. වෙනත් වචන වලින් කිවහොත්, අවම වශයෙන් නිවැරදිව හසුරුවනු නොලබන එම චරිත ඔබට දැකගත හැකිය !

මම ඔබේ ප්‍රශ්නය හිස මතට හරවා යුනිකෝඩ් හි මුළු ෂෙබාං හානිකර යැයි සැලකිය යුතු බවත්, සෑම කෙනෙක්ම බිටු 8 කේතීකරණයක් භාවිතා කළ යුතු බවත් මම දුටුවෙමි (පසුගිය අවුරුදු 20 තුළ) එය මඟ පෙන්වන ස්ථානය: භයානක විවිධ අයිඑස්ඕ 8859 කේතන ක්‍රම පිළිබඳ ව්යාකූලත්වය, සිරිලික් සඳහා භාවිතා කරන ලද මුළු කට්ටලයම සහ ඊබීසීඩීසී කට්ටලය, සහ… හොඳයි, යුනිකෝඩ් එහි සියලු වැරදි සඳහා පහර දෙයි. එය විවිධ රටවල වැරදි වැටහීම් අතර එතරම් නපුරු සම්මුතියක් නොවේ නම්.