[KPhotoAlbum] [PATCH] Re: EXIF db vs. non-ascii chracters in file name
Tuomas Suutari
thsuut at utu.fi
Wed May 9 08:29:10 BST 2007
On Sunday 29 April 2007 21:47, Jan Kundrát wrote:
> What's the status of this?
Now it's applied. I added also check for Unicode support in Qt's SQLite
driver, because if it's compiled with Unicode on, then the driver will
do that conversion and we shouldn't.
> The only problem I can think about is following: *if* the "to string"
> cast in QSqlQuery::bindValue uses iso8859-1 as default encoding
> (rather that "ascii"), people who use non-ascii yet iso8859-1
> characters will suddenly have non-existent items in their EXIF DB.
> This will consume some space, but can be easily solved by deleting
> the DB file and letting KPA re-create it. IMHO it's still better than
> not allowing those searches at all...
Previously it used ISO-8859-1. Driver's code that converts the query is
this:
------------------------------------------------------------------------
int res = sqlite_compile
(d->access,
d->utf8 ? (const char*)query.utf8().data() : query.ascii(),
&(d->currentTail),
&(d->currentMachine),
&err);
------------------------------------------------------------------------
And this is from QString::ascii() documentation:
------------------------------------------------------------------------
Returns an 8-bit ASCII representation of the string.
If a codec has been set using QTextCodec::codecForCStrings(), it is used
to convert Unicode to 8-bit char. Otherwise, this function does the
same as latin1().
------------------------------------------------------------------------
AFAIK KPA doesn't set codec for C-strings, so latin1() was used.
> Perhaps we could use another file name with "version" component for
> the new DB?
I don't think this is needed. Rebuilding the Exif database is so easy.
--
Tuomas Suutari | +358 50 3806983 | thsuut at utu.fi
More information about the Kphotoalbum
mailing list