Re: charset of ext3 drives
Am Dienstag, 8. Juni 2004 20:01 schrieb Nicos Gollan:
> > Seems that I found a bit more infos on my system: I cannot enter
> > cyrillic chars neither in konqi nor in kate. So I installed
> > xfree-cyrillic (a really good idea, but I bet I selected this by first
> > install... anyway).
> I guess you mean xfonts-cyrillic? Did you check if those fonts are
> really available to X and KDE via xfontsel and some KDE font selector?
> Did you make sure both applications are set tu use proper fonts? At
> least Kate does not use standard font setups.
*buhuuuuuhuhuhu* Anyone has a gun for me? Yes, kate did show me umlauts, but
now it doesnt. Dont know why, maybe I clicked its menues too fast :-( In the
kde configuration I saw some cyrillic fonts, but if they were used.. dont
> By the way, there is a package "console-cyrillic" that you probably
> already installed, but it seems important if you ever need to do some
> work on a console...
Yep, saw it - installed it. It does not show me what I want to see, but its
there if I know how I'll need it.
> > But if it is a problem of the fonts... why can juk display the song
> > infos correctly????
> I guess that if JuK pulls info not from the filename but from the file
> tags, it's using the proper encoding. IIRC, OGG explicitly specifies
> UTF8 as encoding; I don't know how MP3 handles things, but I guess it
> would be a good idea to try Windows charsets.
nonono! not something like cp1251! Thats ugly!
Btw I did not ment the way it knows whats going on, but it uses somehow the
right font to display infos. And konqi doesnt.
> > The FS is the last thing I dont understand: if the file name is a
> > double wide charset, how can the file name be stored without loosing
> > information? Do you know what I mean?
> I don't really know what you mean, but I think you need to know a bit
> about the UTF8 encoding. It is not exactly "double-wide", that's what
> UTF16 is (each character is encoded as a 16bit value). UTF8 encodes the
> low-ASCII and some more characters the usual way, as 8bit values. Then,
> there are certain "escape" characters that start the encoding of a
> "longer" character that can be 2, 3 or 4 bytes wide. The effect is that
> control characters are untouched and a great lot of text can be used
> without modification. There's a great lot of information about that at
So if I would use ioctl calls with utf16, only escape sequences are exchanged,
and no driver needs to know that this is a specialfile name. Thats why I have
to rename wrong file(name)s, to send the right sequences to the driver. The
only problem is to display the names the right way, and thats exactly my
current problem. Mmmh. Cool. I could ask you so much more about this...
(hint: latest kdevelop and umlauts/utf8 encoding of files...) but thats not
part of this list :-( and unicode.org wouldn't help me). Thank you!