Eric E Johnson wrote:
As for why these functions exist, I keep thinking along these lines -
imagine you want to encode foreign language characters in a URL. The
way to do it is to convert your string into bytes, and then URL encode
the bytes as if it were ASCII. Reversing the process, take
Ortwin Glück wrote:
This correct modulo all the phrases with the word ASCII in it. It's
just about a sequence of bytes and has nothing to to with ASCII (which
is 7-bit only by the way).
Yes, of course. I'm not very good with the names of my encodings, just
some of the issues surrounding
Oleg,
I can't say I comletely agree with your point (or understand it), but so be it.
Feel free to ask for clarification.
Basically I was trying (in my wordy way) to say that toUsingCharset
seems to do two things:
- Convert the Unicode string to an array of bytes using the converter
for
How about if we just deprecate the @#% thing and the two URIUtil methods
that call it?
For what it's worth, Laura and Oleg, you are completely correct. The
toUsingCharset method is 100% guaranteed to screw up characters, the only
question is which characters.
I would depreciate the code and
oh no!
You should keep your name as is since you were here
first. But are you sure I'm not really one of your
split personalities ;)
EJJ
(who changed his send line in order to avoid
masquerading as the 'good' Eric)
-eej.
P.S. I changed my name on send line, so as to avoid
being
Thanks Laura for this excellent explanation. This really helps to clear
things up! I am glad to have you and your indepth Unicode knowledge on
the list.
I always thought you could roundtrip any charset to Unicode and get the
same thing back. This is obviously wrong. It should be easy to write
Sung-Gu wrote:
There isn't any uni-one to support the various charsets.(Let you regard it!)
Then, once it was tranformed, it should be tranformed back to the original.
That makes the transformed one to the original one.
Sung-Gu,
I have problems understanding your English and I can only guess
- Original Message -
From: Ortwin Glück [EMAIL PROTECTED]
Arrrg... again... :(
Not surprising though... :(((
by the String class. You must use byte[] in this case.
It was...
You speak of transformation. What sort of transformation is that? The
import sun.nio.cs.StandardCharsets;
Hi Sung-Gu
On Tue, 2003-02-04 at 11:37, Sung-Gu wrote:
Hi Oleg,
Again... well..
Ok... let me try to make you understand it again. HmmHmm...
Let's assume I am stupid
BTW, sorry to bother you that I haven't got you to get it right away
at that time even with a diagram and still... :(
Sung-Gu wrote:
- Original Message -
From: Ortwin Glück [EMAIL PROTECTED]
Arrrg... again... :(
Not surprising though... :(((
Sung-Gu, I don't want to upset you. I just want to understand the
problem that you are trying to solve with toUsingCharset. Your
explanations did not help so
Hi Sung-Gu,
Actually, that's very easy...
And not that important unless it's not going to be support multilinqual.
As you see the diagram, bytes informations created from the original charset
should be restored. That's all.
My understanding of what you're saying is that if someone
- Original Message -
From: Laura Werner [EMAIL PROTECTED]
Hi Sung-Gu,
Actually, that's very easy...
And not that important unless it's not going to be support multilinqual.
As you see the diagram, bytes informations created from the original
charset
should be restored. That's
Laura
Finally, there's someone who can read Sung-Gu's mind!
All right. A simple phrase There are charsets that are not adequately
represented in Unicode by Sung-Gu would have put the discussion into a
completely different perspective. And of course, Sung-Gu's stoical
refusal to provide a test
Sung-Gu,
From your diagram I do not see anything that is not supported by
standard Java String handling. I still think this method is unnecessary.
Your test case does not contain a single assertion. Printing out
garbage to the console doesn't make sense. PLEASE PROVIDE AN ORDINARY
JUNIT TEST
14 matches
Mail list logo
