And see too: # LANG=C aptitude show libunistring0 Package: libunistring0 New: yes State: not installed Version: 0.9.3-3 Priority: optional Section: libs Maintainer: Andreas Rottmann <ro...@debian.org> Uncompressed Size: 1221 k Depends: libc6 (>= 2.3) Description: Unicode string library for C The 'libunistring' library implements Unicode strings (in the UTF-8, UTF-16, and UTF-32 encodings), together with functions for Unicode characters (character names, classifications, properties) and functions for string processing (formatted output, width, word breaks, line breaks, normalization, case folding, regular expressions).
This package contains the shared library. Homepage: http://www.gnu.org/software/libunistring/ 2012/4/2 Nico Williams <n...@cryptonector.com> > On Mon, Apr 2, 2012 at 1:25 PM, Richard Hipp <d...@sqlite.org> wrote: > > On Mon, Apr 2, 2012 at 2:03 PM, Simon Slavin <slav...@bigfraud.org> > wrote: > >> I think ... a higher priority than that would be handling Unicode > >> correctly. And having Unicode support would be useful in writing the > code > >> which handles dates. > >> > >> > > size of SQLite library: approx 500 KB > > size of ICU library: approx 21,919 KB > > > > The ICU library (needed to handle Unicode "correctly") is over 40x larger > > than SQLite. Can you understand then why we don't want to make SQLite > > dependent upon ICU? > > I completely agree. It'd be nice if SQLite3 could have an option for > a weak dependency on ICU. I.e., if it can be found with dlopen(), > then use it, else not; a pragma could be used by applications to check > whether SQLite3 found ICU, or to require that it always be found for > any given DB file. Along these lines it'd be nice if a DB file could > record required loadable extensions and provide a single pragma to > load them all, with errors returned when compiling or running > statements other than pragmas until the required extensions are > loaded. > > > If you really need correct ICU support, SQLite will optionally link with > > ICU and use it. But *requiring* SQLite to link against ICU is a > > deal-breaker for many users. > > FYI, the OpenSolaris Unicode library is significantly smaller, most > likely because it deals only with normalization, case conversion, and > codepoint prohibitions -- everything needed for "stringprep" and > normalization- and case-insensitive string comparison. The data > tables reside in a header file and are 1.8 MB. The code is 55KB, + > 3KB of headers. The license for this is CDDL (a per-file copyleft, as > opposed to project-wide copyleft), which is not quite as free as ICU's > license (which is essentially a two-clause BSD license), but probably > good enough for most projects that use SQLite3. FreeBSD, for example, > includes u8_textprep, probably because it also includes ZFS (which > depends on u8_textprep). This is still many times larger than > SQLite3, but still more than ten times smaller than ICU. > > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/common/unicode/ > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/ > (scroll down to u8_textprep.h and u8_textprep_data.h) > > Nico > -- > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- Best regards, Alexey Pechnikov. http://pechnikov.tel/ _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
