[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