>>Invalid UTF-8 code. (bytes: 0xfffffff6 0x6e)
The error message shows the result of converting signed bytes to ints
before printing them as hex. (That's bug number one. :) The codes it is
complaining about are probably 0xf6 0x6e. This is the start of a perfectly
valid UFT-8 code, but it's a four-byte code that will produce a value that
won't fit in 16 bits. The JRun process method either has a bug or is trying
to translate the UTF-8 to 16-bit Unicode, e.g., in Java. Java can't handle
a Unicode character that won't fit in one char (16-bit) variable.
Assuming it's not just a bug, the message should read:
Can't handle UTF-8 code greater than 16 bits (bytes: 0xf6 0x6e 0x?? 0x??)
This is going to be true for lot of software! It is best to stick to the
16-bit Unicode subset. But the JRun software may have better options than
barfing. For example, it might just ignore the four-byte code and leave it
in the text; it is undoubtedly in template text that will just be copied to
the output, anyway. (Of course, the user agent down the road might not
recognize the code, either, but that's not JRun's problem.)
>Didn't you use some special characters, like �, �, �, ... Those are not
>included in the UTF-8 code.
Well, yeah, they are.
>I had to remove them entireliy, which is a big problem in my language
>(french).
That would be a big problem! However, characters like �, �, � (and anything
else you need to write French) _are_ in 16-bit Unicode, are representable
by UTF-8 in three bytes or less. This must be another problem.
Both these issues should be directed to LiveSoftware's technical
support.
Bob Foster
Symantec Internet Tools http://www.visualcafe.com/
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
