SQLite और UNICODE

पहला भाग एक परिचय है ।
दूसरा भाग एक त्वरित शुरुआत है ।
तीसरा भाग है विशेषताएं ।

इस तथ्य के बावजूद कि इस विषय पर Habré पर पहले भी चर्चा की जा चुकी है, कुछ प्रमुख चीजों को नहीं देखा गया है। यह लेख "विषय को बंद करने का प्रयास करता है।" परिवर्धन / सुधार पर टिप्पणियां स्वागत योग्य हैं।

डेटाबेस में स्ट्रिंग्स को फॉर्मेट करें

SQLite डेटाबेस UTF-8 प्रारूप में या UTF-16 प्रारूप में पाठ (स्ट्रिंग मान) को संग्रहीत कर सकता है। 16-बिट UTF-16 वर्णों में बाइट ऑर्डर छोटे-एंडियन या बड़े-एंडियन हो सकते हैं।

यही है, वास्तव में तीन अलग-अलग SQLite डेटाबेस प्रारूप हैं: UTF-8, UTF-16le, UTF-16be ।

इनमें से किसी भी प्रारूप का किसी भी प्लेटफ़ॉर्म पर उपयोग किया जा सकता है (यानी, कुछ भी नहीं है कि x86 पर UTF-16be प्रारूप के साथ एक आधार बनाने से रोकता है, हालांकि यह अनुचित है, नीचे देखें)।

स्ट्रिंग्स का प्रारूप एक डेटाबेस सेटिंग है जिसे डेटाबेस बनाने से पहले सेट किया जाता है। डेटाबेस बनाने के बाद, आप प्रारूप को नहीं बदल सकते हैं ; इसे चुपचाप करने के प्रयासों को SQLite कर्नेल द्वारा अनदेखा किया जाता है।

इस प्रकार,
SQLite डेटाबेस पंक्ति प्रारूप निम्न में से एक हो सकता है:
- UTF-8 (डिफ़ॉल्ट रूप से उपयोग किया जाता है);
- UTF-16le (x86 का मूल);
- UTF-16be
और आप डेटाबेस बनाने के बाद इसे बदल नहीं सकते।

नोट

1. UTF-8 और UTF-16 ("सरोगेट पेयर" देखें) एक वर्ण को संग्रहीत करने के लिए बाइट्स की एक चर (गैर-निश्चित) संख्या का उपयोग करें।

2. डेटाबेस के लिए, आप केवल एक ही स्ट्रिंग प्रारूप के साथ आधार कर सकते हैं, अन्यथा एक त्रुटि होगी।

3. SQLite के आपके संस्करण से, UTF-16 समर्थन असेंबली के दौरान "हटा दिया गया" हो सकता है ( SQLITE_OMIT_UTF16 के लिए sqlite3.c देखें)।

एपीआई कॉल करने के लिए तार गुजर रहा है

SQLite API कॉल (सी भाषा में) को दो प्रकारों में विभाजित किया गया है: UTF-16 प्रारूप में स्ट्रिंग्स प्राप्त करना (प्लेटफॉर्म के लिए देशी बाइट ऑर्डर) और UTF-8 प्रारूप में तार प्राप्त करना। उदाहरण के लिए:

int sqlite3_prepare_v2( sqlite3 *db, /* Database handle */ const char *zSql, /* SQL statement, UTF-8 encoded */ int nByte, /* Maximum length of zSql in bytes. */ sqlite3_stmt **ppStmt, /* OUT: Statement handle */ const char **pzTail /* OUT: Pointer to unused portion of zSql */ ); int sqlite3_prepare16_v2( sqlite3 *db, /* Database handle */ const void *zSql, /* SQL statement, UTF-16 encoded */ int nByte, /* Maximum length of zSql in bytes. */ sqlite3_stmt **ppStmt, /* OUT: Statement handle */ const void **pzTail /* OUT: Pointer to unused portion of zSql */ ); 

यदि बेस स्ट्रिंग का प्रारूप एपीआई में पास किए गए स्ट्रिंग के प्रारूप से मेल नहीं खाता है, तो प्रेषित स्ट्रिंग मक्खी पर बेस प्रारूप में परिवर्तित हो जाती है। यह प्रक्रिया खराब है क्योंकि यह संसाधनों का उपभोग करता है और निश्चित रूप से, इसे बचा जाना चाहिए। हालांकि, यह केवल इस वजह से बुरा नहीं है, नीचे देखें।

Collation: स्ट्रिंग तुलना विधि

अगला विषय एक-दूसरे के सापेक्ष लाइनों के क्रम से संबंधित है (आरोही या अवरोही) और प्रश्न का उत्तर प्राप्त करने के लिए "क्या ये दोनों रेखाएं समान हैं?" दो लाइनों की तुलना करने का कोई "प्राकृतिक" तरीका नहीं है। कम से कम, सवाल उठता है: मामला-संवेदनशील या केस-असंवेदनशील तुलना? इसके अलावा, एक ही डेटाबेस में विभिन्न क्षेत्रों के लिए इस तरह की तुलना दोनों का उपयोग किया जा सकता है।

SQLite में (और किसी भी डेटाबेस में) टकराव की अवधारणा पेश की गई है: एक दूसरे के साथ दो पंक्तियों की तुलना करने का तरीका। मानक (अंतर्निहित) टकराव हैं और आप किसी भी मात्रा में अपना खुद का बना सकते हैं।

टकराव अनिवार्य रूप से एक विधि है जो स्ट्रिंग ए और बी प्राप्त करती है और तीन परिणामों में से एक लौटाती है:
"पंक्ति A पंक्ति B से कम है",
"लाइन्स ए और बी बराबर हैं",
"पंक्ति A पंक्ति B से अधिक है"।

लेकिन यह सब नहीं है। तार की तुलना सकर्मक होनी चाहिए, अन्यथा यह कुछ मान्यताओं से आने वाले खोज तंत्र को "तोड़" देगा। अधिक सख्ती से: सभी लाइनों ए, बी और सी के लिए, इसकी गारंटी होनी चाहिए:
1. यदि = = बी, तो बी == ए।
2. यदि == बी और बी == सी, तो ए == सी।
3. यदि <B तो B> A।
4 यदि ए <बी और बी <सी, तो ए <सी।
यदि यह मामला नहीं है (यानी, आपने एक ऐसा कोलाज बनाया है जो किसी एक नियम का उल्लंघन करता है और उसका उपयोग करता है), तो "SQLite का व्यवहार अपरिभाषित है" ।

आमतौर पर, टकराव एक टेबल कॉलम के लिए सेट किया जाता है और यह निर्धारित करता है कि उस कॉलम के मूल्यों के लिए किस प्रकार की तुलना का उपयोग किया जाता है।

और आपको स्ट्रिंग तुलना का उपयोग करने की आवश्यकता कब है?
1. स्ट्रिंग मानों द्वारा सूचकांक बनाने और अपडेट करने के लिए;
2. "=", "<", ">" के साथ स्ट्रिंग मानों के साथ SQL अभिव्यक्तियों की गणना के दौरान
( ... जहां नाम = 'ऐलिस') ।

इस प्रकार,
जब SQLite को दो पंक्तियों की तुलना करने की आवश्यकता होती है, तो यह तुलना हमेशा किसी न किसी तरह के टकराव पर आधारित होती है।

यदि तुलना किए गए तारों का टकराव मेल नहीं खाता है, तो दूसरे पर एक टकराव की वरीयता के चालाक तंत्र का उपयोग किया जाता है, जो बेहतर नहीं है।

मानक (एम्बेडेड) टकराव

किसी भी UNICODE वर्ण (केस असंवेदनशील) की तुलना करने के लिए पूर्ण समर्थन के लिए बहुत अधिक अतिरिक्त डेटा (तालिकाओं) की आवश्यकता होती है। SQLite डेवलपर्स ने कर्नेल को "फुलाया" नहीं किया और सबसे सरल तुलना विधियों में बनाया।

तीन अंतर्निहित टकराव हैं:
द्विआधारी : दो मेमोरी ब्लॉक की सामान्य बाइट-वार तुलना: पुराना, अच्छा मेमचम्प ()
(डिफ़ॉल्ट रूप से तब तक उपयोग किया जाता है जब तक कि एक और टकराव निर्दिष्ट न हो);
RTRIM : BINARY के समान, लेकिन अनुगामी रिक्त स्थान ('abc' = 'abc') को अनदेखा करता है;
NOCASE : BINARY के समान, लेकिन 26 लैटिन अक्षरों (और केवल उनके लिए) के लिए मामले को अनदेखा करता है।

मानक टकराव का कार्यान्वयन

SQLite के अंदर एक नज़र डालें और विभिन्न टकराव के लिए तुलना कार्यों के कार्यान्वयन को देखें।

BinCollFunc () फ़ंक्शन। यदि पैडफ्लैग <> 0 है , तो यह RTRIM तुलना करता है, अन्यथा BINARY :

 /* ** Return true if the buffer z[0..n-1] contains all spaces. */ static int allSpaces(const char *z, int n){ while( n>0 && z[n-1]==' ' ){ n--; } return n==0; } /* ** This is the default collating function named "BINARY" which is always ** available. ** ** If the padFlag argument is not NULL then space padding at the end ** of strings is ignored. This implements the RTRIM collation. */ static int binCollFunc( void *padFlag, int nKey1, const void *pKey1, int nKey2, const void *pKey2 ){ int rc, n; n = nKey1<nKey2 ? nKey1 : nKey2; rc = memcmp(pKey1, pKey2, n); if( rc==0 ){ if( padFlag && allSpaces(((char*)pKey1)+n, nKey1-n) && allSpaces(((char*)pKey2)+n, nKey2-n) ){ /* Leave rc unchanged at 0 */ }else{ rc = nKey1 - nKey2; } } return rc; } 

और यहाँ टकराव के लिए स्ट्रिंग तुलना समारोह है NOCASE :

 /* ** ** IMPLEMENTATION-OF: R-30243-02494 The sqlite3_stricmp() and ** sqlite3_strnicmp() APIs allow applications and extensions to compare ** the contents of two buffers containing UTF-8 strings in a ** case-independent fashion, using the same definition of "case ** independence" that SQLite uses internally when comparing identifiers. */ SQLITE_API int sqlite3_stricmp(const char *zLeft, const char *zRight){ register unsigned char *a, *b; a = (unsigned char *)zLeft; b = (unsigned char *)zRight; while( *a!=0 && UpperToLower[*a]==UpperToLower[*b]){ a++; b++; } return UpperToLower[*a] - UpperToLower[*b]; } SQLITE_API int sqlite3_strnicmp(const char *zLeft, const char *zRight, int N){ register unsigned char *a, *b; a = (unsigned char *)zLeft; b = (unsigned char *)zRight; while( N-- > 0 && *a!=0 && UpperToLower[*a]==UpperToLower[*b]){ a++; b++; } return N<0 ? 0 : UpperToLower[*a] - UpperToLower[*b]; } // UpperToLower -  ,    " "     'A'..'Z' (   'a'..'z') 

क्या ध्यान आकर्षित करता है? यह स्ट्रिंग माना जाता है कि UTF-8 प्रारूप है, लेकिन स्ट्रिंग के सभी वर्णों को एक पंक्ति में संसाधित किया जाता है: UTF-32 में वर्णों का निष्कर्षण और रूपांतरण नहीं होता है।

यदि आप लंबे समय तक इस कोड पर ध्यान देते हैं, तो आप समझ सकते हैं कि, विचित्र रूप से पर्याप्त है, यह UTF-8 स्ट्रिंग्स और किसी भी अन्य एकल-वर्ण एन्कोडिंग (उदाहरण के लिए, विंडोज़ -1251 ) दोनों पर सही ढंग से काम करता है। "ऐसा क्यों" की समझ में खुलासे टिप्पणियों में साझा किए जा सकते हैं :)।

यह सुचारू रूप से हमें महत्वपूर्ण थीसिस की समझ में लाता है

SQLite को UTF-8 स्ट्रिंग के वास्तविक प्रारूप में कोई दिलचस्पी नहीं है, जब तक कि इसे स्ट्रिंग को UTF-16 में बदलने की आवश्यकता न हो ।

बेशक, मानक टकराव के साथ वास्तविक यूटीएफ -8 तार की व्यवस्था करने से अजीब परिणाम उत्पन्न होंगे। लेकिन समानता सही ढंग से काम करेगी, और तुलना सकर्मक होगी और SQLite को बाधित नहीं करेगी।

यह पता चला है, वास्तव में, आप SQLite डेटाबेस में एन्कोडिंग को स्टोर कर सकते हैं, कह सकते हैं, विंडोज़ -1251 के एन्कोडिंग में, बशर्ते कि आप कहीं भी यूटीएफ -16 का उपयोग नहीं कर रहे हों। यह SQL के अंदर दोनों स्ट्रिंग शाब्दिकों पर लागू होता है और पैरामीटर बाइंडिंग के माध्यम से पारित तार।

डिफ़ॉल्ट प्रारूप के रूप में UTF-8 प्रारूप के पक्ष में तर्क

चलो sqlite3Prepare16 () API फ़ंक्शन कोड पर एक नज़र डालें, जो SQL स्टेटमेंट को पार्स और संकलित करता है। हम फ़ंक्शन बॉडी की शुरुआत में टिप्पणी में रुचि रखते हैं।

 /* ** Compile the UTF-16 encoded SQL statement zSql into a statement handle. */ static int sqlite3Prepare16( sqlite3 *db, /* Database handle. */ const void *zSql, /* UTF-16 encoded SQL statement. */ int nBytes, /* Length of zSql in bytes. */ int saveSqlFlag, /* True to save SQL text into the sqlite3_stmt */ sqlite3_stmt **ppStmt, /* OUT: A pointer to the prepared statement */ const void **pzTail /* OUT: End of parsed string */ ){ /* This function currently works by first transforming the UTF-16 ** encoded string to UTF-8, then invoking sqlite3_prepare(). The ** tricky bit is figuring out the pointer to return in *pzTail. */ ... //  } 

वह है,

UTF-16 प्रारूप में SQL कथनों का पार्सर वर्तमान में SQLite कर्नेल में मौजूद नहीं है (जो भविष्य में इसके स्वरूप को बाहर नहीं करता है) ।

इसलिए, यदि SQL स्टेटमेंट वाला स्ट्रिंग UTF-16 प्रारूप में प्रसारित होता है, तो इसे हमेशा UTF-8 प्रारूप में परिवर्तित किया जाता है।

इस प्रकार, UTF-8 प्रारूप के पक्ष में:
- SQL संकलित करते समय कोई अतिरिक्त रूपांतरण नहीं होते हैं;
- डेटा (आमतौर पर) कम डिस्क स्थान लेता है;
- यदि आप UTF-16 कहीं भी उपयोग नहीं किए गए हैं (और स्व-लिखित टकराव नए स्ट्रिंग प्रारूप को ध्यान में रखता है) तो आप किसी भी बाइट-बाय-कैरेक्टर एन्कोडिंग में डेटा स्टोर कर सकते हैं।

कैसे बनाएं और अपने स्वयं के टकराव का उपयोग करें

हम sqlite3_create_collation_v2 () API फ़ंक्शन का उपयोग करते हैं:

  int sqlite3_create_collation_v2( sqlite3*, //    const char *zName, //  int eTextRep, //      void *pArg, // custom- int(*xCompare)(void*,int,const void*,int,const void*), //    void(*xDestroy)(void*) ); 

ETextRep पैरामीटर में, आपको यह निर्दिष्ट करना होगा कि किस प्रारूप में लाइनें अपेक्षित हैं:

  SQLITE_UTF8 = 1; SQLITE_UTF16 = 2; SQLITE_UTF16BE = 3; SQLITE_UTF16LE = 4; SQLITE_ANY = 5; 

आप एक ही टकराव के लिए कई कार्य निर्दिष्ट कर सकते हैं, लेकिन विभिन्न स्वरूपों को स्वीकार करना।

SQLite प्रारूप के लिए एक विधि चुनने की कोशिश करता है, अन्यथा (यदि संचरित स्ट्रिंग और पंजीकृत फ़ंक्शन के प्रारूप अलग हैं), तो रूपांतरण फिर से मक्खी पर किया जाता है। तुलनात्मक फ़ंक्शन को एक ऋणात्मक संख्या लौटानी चाहिए यदि पहली पंक्ति दूसरी से कम हो; शून्य - यदि रेखाएं समान हैं; एक सकारात्मक संख्या अगर पहली पंक्ति दूसरी से बड़ी है। तुलना, जैसा कि पहले ही उल्लेख किया गया है, सकर्मक होना चाहिए।

एक कोलाज बनाएं ("RU" नाम) जो हमें देगा:
- सिरिलिक और लैटिन अक्षरों के लिए केस-असंवेदनशील तुलना
- अन्य सभी पात्रों के लिए सामान्य तुलना;
- अक्षर "(" की वर्णमाला में सही स्थिति (अधिक सटीक, "position" को "ई" के बराबर माना जाता है)।

यह, अब तक, पूर्ण UNICODE समर्थन नहीं है, लेकिन यह एक सरल समाधान है जो 95% मामलों में उपयुक्त है।

डेल्फी पर उदाहरण होंगे, घबराएं नहीं।

 unit UnicodeUnit; interface //        UTF-8    UTF-32   -1,     function GetCharUTF8(var P: PByte; var L: integer): integer; //    UTF-32    (    !) function LowerUTF32(ACode: integer): integer; //   UTF-8  (case-insensitive    ) function CompareUTF8IgnoreCase(L1: integer; P1: PByte; L2: integer; P2: PByte): integer; implementation uses SysUtils; //    UTF-8 type TParseItem = record Mask: integer; Count: integer; end; var //    UTF-8 ParseTable: array[0..255] of TParseItem; //      LowerTable: array[0..65535] of integer; function CompareUTF8IgnoreCase(L1: integer; P1: PByte; L2: integer; P2: PByte): integer; var C1, C2: integer; begin repeat if (L1 = 0) and (L2 = 0) then begin result := 0; exit; end; //     C1 := GetCharUTF8(P1, L1); if C1 < 0 then begin result := -1; exit; end; C2 := GetCharUTF8(P2, L2); if C2 < 0 then begin result := +1; exit; end; //         if C1 < 65536 then C1 := LowerTable[C1]; if C2 < 65536 then C2 := LowerTable[C2]; if C1 < C2 then begin result := -1; exit; end else if C1 > C2 then begin result := +1; exit; end; until false; end; function LowerUTF32(ACode: integer): integer; begin case ACode of 1105, 1025: // ,  result := 1077; //  1040..1071: result := ACode + 32; //  Ord('A')..Ord('Z'): result := ACode + 32; //  else result := ACode; end; end; function GetCharUTF8(var P: PByte; var L: integer): integer; var B: byte; I: integer; begin if L > 0 then begin B := P^; Inc(P); Dec(L); with ParseTable[B] do if Count > 0 then begin //      result := B and Mask; //      for I := 1 to Count - 1 do if L > 0 then begin result := (result shl 6) or (P^ and $3F); Inc(P); Dec(L); end else begin result := -1; exit; end; exit; end; end; result := -1; end; var I: integer; initialization //    UTF-8 for I := 0 to 255 do with ParseTable[I] do if I <= 127 then begin Mask := $7F; Count := 1; end else if I >= 248 then begin Mask := 0; Count := 0; end else if I >= 240 then begin Mask := 7; Count := 4; end else if I >= 224 then begin Mask := 15; Count := 3; end else if I >= 192 then begin Mask := $1F; Count := 2; end else begin Mask := 0; Count := 0; end; //  Lower for I := 0 to 65535 do LowerTable[I] := LowerUTF32(I); end. 

कोड, सामान्य रूप से, सरल है और शायद अतिरिक्त स्पष्टीकरण की आवश्यकता नहीं है।

कैसे उपयोग करें:

 //       function RU_CollationCompare(UserData: pointer; l1: integer; p1: pointer; l2: integer; p2: pointer): integer; cdecl; begin result := CompareUTF8IgnoreCase(L1, P1, L2, P2); end; ... //     collation RU sqlite3_create_collation(Fdb, 'RU', SQLITE_UTF8, nil, RU_CollationCompare); 

तालिका बनाते समय, हम नाम स्तंभ के लिए तुलना प्रकार सेट करते हैं:

 CREATE TABLE foo( name TEXT COLLATE RU, ... ) 

महत्वपूर्ण! डेटाबेस के संबंध में कोलाज़ पंजीकरण किया जाता है (डेटाबेस में ही नहीं)। यह अनिवार्य रूप से आपके कोड को SQLite कोड में संलग्न कर रहा है। एक और कनेक्शन जो समान कोलाज निर्दिष्ट नहीं करता था, वह इस आधार का उपयोग करने में सक्षम नहीं होगा।

LIKE, अपर (), लोअर (), आदि।

बेशक, "RU" कोड, अन्य वर्णमालाओं का समर्थन करने के लिए संशोधित करना आसान है। और आप एक (लगभग) पूर्ण UNICODE तुलना कर सकते हैं यदि आप लोअरटेबल टेबल को आबाद करने के लिए विंडोज एपीआई कॉल का उपयोग करते हैं।

क्यों "लगभग"? UNICODE के "सामान्यीकरण" के रूप में ऐसी एक चीज है, जो कि एक अस्पष्ट प्रतिनिधित्व में कमी है। बचाव के लिए गूगल!

हालाँकि, UNICODE का समर्थन केवल कोलाजेशन में ही नहीं मिला है। यह भी है:
- LIKE ऑपरेटर (पैटर्न मिलान);
- SQL फंक्शन लोअर () और अपर () (स्ट्रिंग कैरेक्टर को लोअर / अपर केस में कन्वर्ट करता है)।

और कुछ अन्य स्ट्रिंग हेरफेर फ़ंक्शन: गुना (), शीर्षक () , आदि।

ये अलग-अलग तंत्र हैं जो किसी भी तरह से टकराव का उपयोग नहीं करते हैं।

हालाँकि, SQLite इन फ़ंक्शन को ओवरराइड करने की अनुमति देता है (LIKE भी एक फ़ंक्शन है)।

ऐसा करने के लिए, sqlite3_create_function_v2 () API कॉल का उपयोग करें।

लगभग पूर्ण रूप से छोटे खून से भरे हुए

पिछले लेखों में आईसीयू पुस्तकालयों का उल्लेख किया गया था : यूनिकोड के लिए अंतर्राष्ट्रीय घटक । यह UNICODE का पूर्ण समर्थन है। हालांकि, परेशानी यह है कि यह एक विशाल मात्रा में कोड और डेटा खींचता है, जो कि 95% मामलों में आवश्यक नहीं है। यदि आपकी SQLite में पहले से अंतर्निहित ICU है, तो आप आगे पढ़ना छोड़ सकते हैं।

तो, एक स्मार्ट लड़का था जिसने इस कोड से क्या जरूरत थी, यह देखा और आईसीयू से एक तरह का "निचोड़" बनाया।

उनका मूल संदेश, जाहिरा तौर पर, यह है ।

यह इसी बारे में है। ICU कोड के आधार पर, उन्होंने sqlite3_unicode.c फ़ाइल बनाई, जो DLL (आमतौर पर sqlite3u.dll ) में संकलित होती है। परिणामस्वरूप DLL sqlite3_unicode_init () फ़ंक्शन का निर्यात करता है:

 function sqlite3_unicode_init(db: TSQLiteDB): Integer; cdecl; external 'sqlite3u.dll' name 'sqlite3_unicode_init'; 

यदि आप इस फ़ंक्शन को कनेक्ट करने के लिए कहते हैं, तो यह:
- निचले, ऊपरी, गुना, शीर्षक, अस्वीकार्य कार्यों के लगभग पूर्ण UNICODE संस्करणों को पंजीकृत करता है;
- एक लगभग पूर्ण UNICODE केस-असंवेदनशील LIKE का परिचय देता है।

इस DLL का आकार केवल 80 Kb है और यह जल्दी से काम करता है (तालिकाओं का उपयोग किया जाता है)। खंड "लगभग" महत्वपूर्ण है - यह एक पूर्ण UNICODE नहीं है, लेकिन 95% मामलों में यह पुस्तकालय पर्याप्त है।

नोट्स।

1. यदि LIKE ओवरराइड हो गया है, तो SQLite इंडेक्स द्वारा इसे ऑप्टिमाइज़ नहीं कर पाएगा (A LIKE 'XXX%', A द्वारा इंडेक्स का उपयोग नहीं करेगा, यदि कोई हो)।

2. फ़ंक्शंस लोअर (), अपर (), आदि, आम तौर पर बोलना, डेटाबेस इंजन में होना आवश्यक नहीं है, इन परिवर्तनों को एप्लिकेशन कोड में निष्पादित करना संभव है।

Yuz zis librari et yor oun जोखिम , अर्थात् , इस लेख के लेखक कभी भी किसी चीज के लिए जिम्मेदार नहीं हैं।