MacArthur, Ian (SELEX) (UK) wrote:
> Hmmm, I think I'd caution against that approach - that'll only work if
> (a) the characters in your string are from the "ASCII" range and (b) the
> wide chars you get are actually 16-bit.
>
> If any of your characters actually require a value outside the ASCII
> range the MS-byte won't be "null" in that case and odd things will
> happen... You really need to check if the "upper" byte is non-zero and
> process it "properly" if it is (although discarding it, if it is zero,
> is a "valid" hack in many cases.)
Right, a hack to solve most cases for the example where the URL
is pure ascii.
Maybe a sentence or two in the article could point folks to iconv(3)
to handle this "correctly", but use of iconv(3) assumes you know what
the input data type is, and mine is just a guess it's 2 byte wides.
> I'm surprised they were 16-bit actually, I've never checked
> specifically, but I thought firefox was using either UTF-8 (which
> *would* look like straight ASCII in this case) or UCS-4 (which would
> look like 32-bits) on my machines.
Unsure; my observation was purely empirical; every other byte
was zero, so I figured it was 16 bit Unicode in the ascii range.
FWIW, I just added a write(2, urls, 10); at the top of the dnd_open()
and piped stderr of the app into 'od -t x1' to see the resulting
hex code string where every other byte is zero.
> Greg, do you have your locale set fo[r] utf-8 or...?
On my system I have LANG and LOCALE unset.
I made sure firefox (2.0.0.11 in this case) wasn't already running,
and fired it off from the fedora3 command line after first doing
an echo $LANG ; echo $LOCALE which were both undefined.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
