What I find more interesting is how emoji (a small digital image or icon)
was ever interpreted as encodable text for the Unicode Standard. If our
German newspaper friends have made a mistake in interpreting emoji as
speech, I think the Unicode consortium has made an even bigger mistake.
Regards,
J
As a response to all the issues I've learned from everyone, my immediate
recommendation for my company's current policy is to constrain our
passwords to printable ASCII now in order to buy time to learn more about
all the issues that you and others have mentioned.
I appreciate all the feedback on
mmend any documents to help me understand potential issues (if
any) for password policies and validation methods that allow characters
from more "exotic" portions of the Unicode space?
Best regards,
John O'Conner
>
> If it were up to me alone, I would put that proposal in the bin of things
> that have been politely refused. The fact that it has not yet gone to the
> great bit-bucket in the sky probably reflects the general esteem in which
> the gentlebeing who proposed it is held.
Yes, I think we all hig
t; into
software products. Yes, people will find it, see it; some will smile at it,
maybe laugh; promoters will elbow each other and point out their
contribution; others will wonder why anyone wasted their time.
Put me in the last category,
John O'Conner
t, however. I simply wanted to
correct the statements about what can and what cannot go into a bundle.
Regards,
John O'Conner
- Original Message -
From: "Richard, Francois M" <[EMAIL PROTECTED]>
To: "Unicode List" <[EMAIL PROTECTED]>
Sent:
ar that it reads a "modified" UTF-8, but
the doc
also says it can throw an UnsupportedDataFormatException if the input stream isn't
valid
UTF-8. The error is that it says UTF-8, not "modified" UTF-8 or FSS_UTF.
Later,
John O'Conner
Tex Texin wrote:
> John,
&
ntation! I'll submit
all
3...if they don't already exist in the db.
Regards,
John O'Conner
John Cowan wrote:
> The internal encoding is exposed by the regrettably named readUTF and
> writeUTF methods of java.io.Data{Input,Output}Stream, which should have
> been named read
is UTF-8 in any of its API
documentation.
Any component or converter that claims to produce a UTF-8 encoding should not
behave as you describe. For example, Java's UTF-8 converter does not encode U+
as 0xC0 0x80. If it ever does, please file a bug.
Regards,
John O'Conner
[EMAIL
t the only oddity, so what
resources does one have to find out these quirks other than stories and comments
passed along via mailing lists. If I had read the Unicode Standard more closely,
would I have found this?
Regards,
John O'Conner
o?
2118;SCRIPT CAPITAL P;So;0;ON;N;SCRIPT P
Regards,
John O'Conner
" block. Are they? Or are they not part of the "Specials" block
of special character/non-character code values.
Regards,
John O'Conner
bit
value...the fact that the Unicode Consortium itself has promoted and defined
Unicode as a 16-bit coded character set for so long is probably the biggest.
-- John O'Conner
In a recent post I said something like this:
There is no explicit support for surrogate pairs in Unicode at this
time.
I meant to say this:
There is no explicit support for surrogate pairs in Java at this time.
Sorry for the confusion,
John O'Conner
. There is no
explicit support for surrogate pairs in Unicode at this time, although you can
certainly find out if a code unit is a surrogate unit.
In the future, as characters beyond 0x become more important, you can
expect that more robust, official support will ollow.
-- John O'Conner
I intend on testing this with a few perl scripts later using the db, but
thought I'd pose the question to see if anyone has a quick answer:
Is it true that if a character's general category is neither Ll nor Lt,
then the uppercase character is simply the character itself?
Regards,
John O'Conner
Should an isLetter() implementation return true for "Nl" characters as
well as the usual "L*"?
Regards,
John
that only understands CP 1252 results in garbage on the
display of some text fields and areas.
2. Compiling your app as a UNICODE application means that all Win32 API calls
use Unicode-enabled versions of the API. Text areas expect you to pass
Unicode, and it displays correctly when an appropriate font is used.
-- John O'Conner
, this seems
unreasonably difficult. If you are in a Java environment, why not pass UTF-8
or UTF-16 values around everywhere?
-- John O'Conner
I believe IBM has a library called ICU that is free. Of course, you should check it
yourself. I believe you can find it at the following URL:
http://oss.software.ibm.com/developerworks/opensource/icu/project/
-- John O'Conner
Mike Newhall wrote:
> For internationalizing string
pairs?
-- John O'Conner
last Unicode conference in Amsterdam, there was a session that mentioned
future enhancements that would make keyboard layouts easier to manage and use
in Java. It might be worth your time to look those up...at least for a glimpse
into the future of Java.
-- John O'Conner
Nicolas Toussaint wrote:
ppointed or frustrated even. Are these bugs in the spec? Or do I
just need to think about them a little differently?
Best regards,
John O'Conner
23 matches
Mail list logo
