音時雨 ~Regentropfen~

♧ Moving to SQLite

There're always things you'll never understand. Such as UTF8 rendering between Perl/CGI, HTML form submission and storing in database files. Even though everything stored in SQL was using UTF8, I kept getting problems about improperly displayed characters, especially the degree sign ° and German umlauts. Although I expected Japanese characters might cause a bigger problem, it wasn't the case. Which is good, looking at a full screen of weird symbols is never a pleasant experience.
I brought this up, simply because I was playing around with them again. Also because of this issue, I'd considered for so many times to completely convert to use PHP. My hunch was it's going to be hard, if not impossible. I'm very aware of its fitfulness with web stuff, but I'm not comfortable at all with PHP, especially while dealing with "undef" strings, and I'm not used to while calling specific piece of data from complex structure (the very annoying "quoting" of every key name -_-'').
So, as a faithful Larry Wall follower, I'm happy that DBI has got it ready for an expected smooth transfer from MySQL to SQLite. Note, it's not because I don't like MySQL. It's very easy to use and fully manageable, however, since my stuff isn't big at all, I'd be very glad to store all my data into a single file, so it becomes portable all the time. (Yet, I'm not planning to write my journals directly with that.. ^^;)
The whole progress indeed was a quick one. I like how DBI served as a wrapper and thus no many edits were needed. Essentially, all checks I needed to do was minor variations between SQL statements. But there are surely something I don't understand well. I can't use "show tables" or "describe table", and I still haven't figured out the correct statement to achieve the same in SQLite. Also, while doing "insert into table", "set xxx=?" doesn't work, and I have to use the more tedious (?) "values(?,?)".
Whatever, the transfer is done. Sometimes there is a need of "encode('UTF-8',$string)" for showing all text correctly. But when I check back contents stored in the SQLite file, everything looks perfect. This means all character issue must be from the crosstalk outside of the original data, which also means I don't need to worry about anything in my submission form at all. If something behaves weirdly, ask "Encode"~
There's more than one way to do it, so what I've done makes sense! ( ˘ω˘)
Plus, with this chance, I also rewrote my css, including splitting out a separate css file for only colour related settings. I perhaps won't change the design layout so frequently, but I do with colours! Moreover, now the main theme is (supposed to be) based on my recent artwork -- maybe someday I shall switch to use my previous "lantern" background for a while, and for fun!