Bug 195006 - SQLITE : UTF8 characters not accepted in database file path
Summary: SQLITE : UTF8 characters not accepted in database file path
Status: RESOLVED INTENTIONAL
Alias: None
Product: digikam
Classification: Applications
Component: Database-Sqlite (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-02 18:31 UTC by Andrzej
Modified: 2017-07-25 10:45 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.3.0
Sentry Crash Report:


Attachments
error message (31.67 KB, image/png)
2009-06-02 18:34 UTC, Andrzej
Details
konsole output (166.72 KB, image/png)
2012-01-25 07:52 UTC, Andrzej
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrzej 2009-06-02 18:31:00 UTC
Version:           0.10.0 (rev.: wyeksportowane) (using 4.2.3 (KDE 4.2.3), volkerdi@slackware.com)
Compiler:          gcc
OS:                Linux (i686) release 2.6.28.10

in 0.10 series it is not possible to use national characters in database file path.
It is however possible to use national characters in collection path.
I'm attaching screen-shoot of error message when someone is trying to use national characters in database file path.
Comment 1 Andrzej 2009-06-02 18:34:20 UTC
Created attachment 34203 [details]
error message
Comment 2 caulier.gilles 2009-06-19 12:01:18 UTC
Andrzej,

What do you mean by "national characters" ?

Gilles Caulier
Comment 3 Andrzej 2009-06-19 14:19:30 UTC
in my case Polish characters like: ąćęłńśóżź
e.g. "photos" in Polish is "zdjęcia" and I cannot place database file in a directory named like this.
Comment 4 caulier.gilles 2009-06-19 14:44:52 UTC
I confirm dysfunction

Gilles Caulier
Comment 5 caulier.gilles 2009-06-19 15:10:56 UTC
Marcel, 

I cannot found where digiKam code is weird here. We pass dtabase path as QString... So the problem must be in sqlite or Qt4 Database driver...

Gilles Caulier
Comment 6 Marcel Wiesweg 2009-07-31 22:23:32 UTC
I have just tested to create a database in my russian-polish testing directory "Мои рисунки ąćęłńśóżź" and this worked without any problem. My system is Opensuse, system charset is UTF8. Maybe this is a problem at a lower level?
Comment 7 Andrzej 2009-08-03 22:18:19 UTC
I use LANG=pl_PL that by default uses ISO 8859-2
Comment 8 Francesco Riosa 2011-06-29 12:54:39 UTC
2.0.0-rc is out, please re-open if needed
Comment 9 Andrzej 2011-10-06 22:00:10 UTC
Still present in Digikam 2.2.o
Comment 10 Marcel Wiesweg 2011-10-07 16:14:19 UTC
Andrezej: SQLite or MySQL?
Comment 11 Andrzej 2011-10-07 23:08:16 UTC
SQLite
Comment 12 Marcel Wiesweg 2011-10-29 15:38:55 UTC
Qt is internally 100% UTF-16, and the filename in the database driver is passed to sqlite3_open_v2 as UTF-8. So I dont see anything we can do in digikam about this. I have only used UTF-8 systems in the last years, perhaps someone with experience in non-UTF-8 can help us here.
Comment 13 caulier.gilles 2011-12-15 08:51:54 UTC
Andrzej,

It still valid using digiKam 2.4 ?

Gilles Caulier
Comment 14 Andrzej 2012-01-12 22:26:37 UTC
Gilles,

Yes it is still valid using digiKam 2.4.

I know where exactly problem is:
In digikamrc database location is stored in UTF8.

in my case:
/D/zdjęcia/

is stored like this:
Database Name=/D/zdjÄcia/
Database Name Thumbnails=/D/zdjÄcia/

This is UTF8 encodings seen in ISO 8859-2 locale.

so the solution would be convert the path stored in UTF8 in to current locale encodings just before accessing the database. In my case UTF8 -> ISO 8859-2.

Apparently now digiKam instead of looking for /D/zdjęcia/ is looking for /D/zdjÄcia/ that does not exit.

To confirm this I created symlink to /D/zdjęcia/ called /D/zdjÄcia/ and digiKam had no problem in finding the location.
Comment 15 Marcel Wiesweg 2012-01-13 09:16:47 UTC
If you start digikam on the console, it will output the database parameters:
digikam(9021)/digikam (core) Digikam::AlbumManager::setDatabase: DatabaseParameters: [ Type "QSQLITE", Name "/media/fotos/digikam4.db" (Thumbnails Name "/media/fotos/thumbnails-digikam.db"); ]

What does it say for you?
Comment 16 Andrzej 2012-01-19 07:58:27 UTC
digikam(1786)/digikam (core): Error while opening the database. Error details [ QSqlError(-1, "Błąd podczas otwierania bazy danych", "unable to open database file") ]
digikam(1786)/digikam (core): Error while opening the database. Error details [ QSqlError(-1, "Błąd podczas otwierania bazy danych", "unable to open database file") ]
digikam(1786)/digikam (core): Error while opening the database. Error details [ QSqlError(-1, "Błąd podczas otwierania bazy danych", "unable to open database file") ]

and so on
Comment 17 Marcel Wiesweg 2012-01-19 21:21:14 UTC
ensure 50003 is enabled in kdebugdialog. It must be among the first few lines, before any db errors.
Comment 18 Andrzej 2012-01-22 23:43:44 UTC
there is no kdebugdialog.
The:
digikam(1786)/digikam (core): Error while opening the database. Error details [
QSqlError(-1, "Błąd podczas otwierania bazy danych", "unable to open database
file") ]
error is the first message being displayed.

I've compiled digiKam with -DCMAKE_BUILD_TYPE=Release.
I will compile digiKam with more debug info.

I'll let you know.
Comment 19 caulier.gilles 2012-01-23 07:49:30 UTC
kdebugdialog is a program from KDE :

http://www.youtube.com/watch?v=uw8FdebrIJs

You need to install it on your system...

Gilles Caulier
Comment 20 Andrzej 2012-01-25 07:52:12 UTC
Created attachment 68155 [details]
konsole output
Comment 21 Andrzej 2012-01-25 07:59:31 UTC
50003 was enabled in kdebugdialog.
I also compiled with -DCMAKE_BUILD_TYPE=relwithdebinfo.
But output is the same.

when I click on "cancel" there is plenty o repeated messages like below: 

QSqlDatabase: available drivers: QSQLITE QSQLITE3 QMYSQL3 QMYSQL
QSqlDatabase:  driver not loaded
QSqlDatabase: available drivers: QSQLITE QSQLITE3 QMYSQL3 QMYSQL
QSqlDatabasePrivate::removeDatabase: connection 'digikamDatabase-168059104' is still in use, all queries will cease to work.
QSqlDatabasePrivate::addDatabase: duplicate connection name 'digikamDatabase-168059104', old connection removed.
QSqlQuery::prepare: database not open
QSqlDatabase:  driver not loaded
QSqlDatabase: available drivers: QSQLITE QSQLITE3 QMYSQL3 QMYSQL
QSqlQuery::prepare: database not open
QSqlDatabase:  driver not loaded
QSqlDatabase: available drivers: QSQLITE QSQLITE3 QMYSQL3 QMYSQL
QSqlQuery::prepare: database not open
QSqlDatabase:  driver not loaded
QSqlDatabase: available drivers: QSQLITE QSQLITE3 QMYSQL3 QMYSQL
QSqlDatabase:  driver not loaded
QSqlDatabase: available drivers: QSQLITE QSQLITE3 QMYSQL3 QMYSQL
Comment 22 Andrzej 2012-02-27 21:54:22 UTC
Marcel,

I compiled with -DCMAKE_BUILD_TYPE=debugfull and I have the output you asked for.
the paths are displayed OK:
-> digikam
digikam(2426)/digikam (core) Digikam::KInotify::Private::open: Successfully opened connection to inotify: 10
digikam(2426)/digikam (core) Digikam::AlbumManager::setDatabase: DatabaseParameters: [ Type "QSQLITE", Name "/D/zdjęcia/digikam4.db" (Thumbnails Name "/D/zdjęcia/thumbnails-digikam.db"); ]

still digiKam is looking for database in nonexistent location because of wrong encoding.

Andrzej
Comment 23 Marcel Wiesweg 2012-03-01 20:46:28 UTC
"/D/zdjęcia/digikam4.db" seems to be the correct file name, and this one is read from the config file and passed as UTF-8 to the Qt SQL driver.
Well, I cannot find out from here where exactly something is wrong.
Comment 24 Andrzej 2012-03-15 22:47:23 UTC
Marcel,

Database file name is read correctly from the config file but it it seems that it shouldn't be passed as UTF-8 to the Qt SQL driver but depending on locale settings because Qt SQL driver seems to be using it directly without taking locale settings in to account.

As I mentioned before:
To confirm this I created symlink to /D/zdjęcia/ called /D/zdjÄcia/ and digiKam i.e  Qt SQL driver had no problem in finding the location.

So the solution should be to pass the database path to Qt SQL driver depending on locale settings i.e. on UTF-8 systems settings it should be passed as UTF-8 but
on ISO 8859-2 systems it should be passed as ISO 8859-2.

I know that digiKam is checking what are locale settings so this information is already available.

Andrzej
Comment 25 Marcel Wiesweg 2012-03-18 17:22:01 UTC
If you have a look at
http://sqlite.org/c3ref/open.html
passing the filename as UTF-8 to sqlite_open_v2 is explicitly required, any other attempt would be a violation of the API documentation. See the note at the bottom of the page, even though it is only directed at Windows users: "The encoding used for the filename argument of sqlite3_open() and sqlite3_open_v2() must be UTF-8, not whatever codepage is currently defined. Filenames containing international characters must be converted to UTF-8 prior to passing them into sqlite3_open() or sqlite3_open_v2()"

This is what I mean: we have a 100% unicode passthrough of the filename through digikam and Qt, and obviously the data we have in digikam is correct.
Comment 26 Andrzej 2012-03-24 23:24:27 UTC
Requirement that: "The encoding used for the filename argument of sqlite3_open() and sqlite3_open_v2() must be UTF-8" is from sqlite.

As far as understand there is an intermediary between digiKam and sqlite: Qt SQL driver.

Maybe Qt SQL driver does not have this requirement and non UTF-8 encoding can be passed.

The error message suggest that it is Qt SQL driver that is confused.

Which element should checked system locale and access database file accordingly?
Qt SQL driver or sqlite?

Either database path is provided as UTF-8 and then converted to local setting encoding by the element accessing database
or it should be possible to provide database path also as non UTF-8 if no locale settings are checked afterwards 

Andrzej
Comment 27 Marcel Wiesweg 2012-03-25 19:13:36 UTC
qsql_slite.cpp:508
bool QSQLiteDriver::open(const QString & db, const QString &, const QString &, const QString &, int, const QString &conOpts)
...
    if (sqlite3_open_v2(db.toUtf8().constData(), &d->access, openMode, NULL) == SQLITE_OK) {
...

QString is UTF-16 internally. So if the QString we pass in the beginning is correct Unicode, it is not changed in any way I can see. This is what I mean by 100% unicode.
Obviously something goes wrong, but I dont know where and particularly, I dont know what we could change.
Comment 28 caulier.gilles 2014-08-07 05:52:54 UTC
We suspect a low problem to Qt sqlite plugin...

Gilles Caulier
Comment 29 Christoph Feck 2014-08-16 11:57:51 UTC
Comment #14 says digiKam writes wrong configuration files, because the current locale isn't UTF-8.

There are too many issues with locale conversion, and Unicode has been invented to prevent those, so please change your locale to UTF-8.
Comment 30 caulier.gilles 2014-08-16 15:31:02 UTC
Thanks Christoph for your feedback.

I move back this file into digiKam, for archiving purpose.

Gilles Caulier