A couple of days ago I made Rekall work with MySQL on OS X. And now I’m not really using it!
There is a big showstopper for maintaining german content (or in any other language that uses more than the 7 bit ASCII character set): Rekall (on the Mac) doesn’t handle Unicode correctly. Here’s a short sample: to the left the expected display (from phpMyAdmin), to the right the screen shot from Rekall:
![]() |
![]() |
What if I entered the umlaut in Rekall? Then phpMyAdmin shows the content as if it wouldn’t know how to display UTF-8 codes:
![]() |
![]() |
What happens is that the transformation takes place twice:
- The UTF-8 transformation of ‘ä’ (
0xE4) is ‘ä’ (0xC3 0xA4) as shown in the second phpMyAdmin screen shot. - The UTF-8 transformation of ‘ä’ is
0xC3 0x83 0xC2 0xA4, which is what is stored in the database, as a hexdump shows.
I have seen the same strange glyphs for umlauts in another Mac port of a multi platform program: Perforce P4V in Version 2005.1 has the same problem:

Because Rekall and P4V both are based on the Qt library, I think it’s actually a bug in the Mac port of Qt; I have never used Rekall on other platforms, but I know that the Windows port of the same version of P4V shows the umlaut as expected:





Hello!
It seems to me that all versions of Rekall has this problem as I’ve tested it under Linux (Ubuntu and Mepis) and Windows –although I have problems with spanish characters like Ñ or “tildes”: á.
I’ll keep trying to find the info on how to solve the problem, and if I do I guess i’ll write it here and on any other page that could help others
Bye
Hello KkrodD!
Thanks for your information, you’re welcome to post new facts here.
In addition, knoda (another OS database frontend) has troubles with umlauts as well, although not these problems. I think it might actually be a mysql 4.1 + problem, not something to do with any of these.
Oh, and that’s on linux.