I was wondering if anyone has been able to work with Google Chrome history_index files.
Here is the problem
Basically these are sqlite3 databases but one Table ("Pages") is a virtual table using FTS3 and an (to me unknown) icu tokenizer.
This table seem to contain alot of data (concerning the size of the database and by looking into the hex data)
i didnt manage to query this table…usually i use pysqlite or different sqlite-viewer tools.
None of them was able to handle fts3+icu
So that raises a few questions
Does anyone know a way to view the contents of that table ?
Is anyone aware of a compiled sqlite.dll with activatet icu+fts3 ?
If not - is there a way to convert the structure of such a table or remove the tokenizer tags ?
My last option would be to bruttally extract the raw hexdata of these records and write it into a "normal" sqlite database…but i`d like to skip that. roll
Best regards
Zergling
Zergling,
Try SQLite Expert Professional http//
Regards,
Jesse
Thank you very much for the response. At least they promise this specific support.
I'll try that.
But iam also happy with any open source software/libraries )
Have you tried querying the underlying content table created by FTS3?
Try
SELECT * FROM Pages_content;
(I've capitalised the P because you have - the name before "_content" should be identical to the virtual table name).
DO you see the data that way?
Ive managed to get the query working with updated/recompiled .dll files (icu, sqlite)
Since iam using pysqlite i only needed to override the dlls inside the python folder.
@ AlexC
Yes. Querying "normal" tables works fine.
But now i realize that they virtually have the same content - a fact i didnt know before. oops
So i guess that virtual table is just used for providing fts3 and this icu extension and points to the same records ? idea
I think, strictly speaking (and I haven't looked at this part of SQLite for a while, so don't take anything here as gospel) a virtual table is just a mechanism for SQLite to expose an object that looks like a Table, but actually behind the scenes other functions are being called rather than the usual store and recall stuff. So the virtual table itself doesn't really store anything.
Just to repeat the caveat - it's not an area I've revisited for a long time, so don't take that explanation as gospel!
Well, before i start to jump to any conclusions ill run a couple of tests with these virtual tables.
Thanks for all the answers.
This Topic can be considered as closed.