An ISO-8852-2 Java String? Does such a thing exist?

[Craig]

We have a vendor supplied Java API which takes a String as an argument
(for transmission). The supplier has instructed that we must send a
ISO-8859-2 encoded String to make this work. My argument to them has
been that there is no such thing, and that while we can send a String,
Java maintains its own internal format, and that encoding only comes
into play when converting to/from bytes. Am I incorrect?

We pull this data out of the db as UTF-8 bytes (they are persisted as
a blob). They suggest something like this:

String = new String(bytes, "ISO-8859-2");

where bytes is the byte array from the db. My suggestion to them is
that we still end up with a plain old Java String, and that this
statement may actually corrupt any extended characters, as we are
telling the String constructor that the byte array is encoded as
ISO-8859-2, when actually it is UTF-8.

They have comprimised and instructed us to send them UTF-8 encoded
Strings. But I'm guessing the same issue applies.

Can anyone shed some light?

Thanks

 

[Michael Borgwardt]

We have a vendor supplied Java API which takes a String as an argument
(for transmission). The supplier has instructed that we must send a
ISO-8859-2 encoded String to make this work. My argument to them has
been that there is no such thing, and that while we can send a String,
Java maintains its own internal format, and that encoding only comes
into play when converting to/from bytes. Am I incorrect?

Nope, you're entirely correct.

 

[Steve Horsley]

We have a vendor supplied Java API which takes a String as an argument
(for transmission). The supplier has instructed that we must send a
ISO-8859-2 encoded String to make this work. My argument to them has
been that there is no such thing, and that while we can send a String,
Java maintains its own internal format, and that encoding only comes
into play when converting to/from bytes. Am I incorrect?

We pull this data out of the db as UTF-8 bytes (they are persisted as
a blob). They suggest something like this:

String = new String(bytes, "ISO-8859-2");

where bytes is the byte array from the db. My suggestion to them is
that we still end up with a plain old Java String, and that this
statement may actually corrupt any extended characters, as we are
telling the String constructor that the byte array is encoded as
ISO-8859-2, when actually it is UTF-8.

They have comprimised and instructed us to send them UTF-8 encoded
Strings. But I'm guessing the same issue applies.

Can anyone shed some light?

Thanks

I'm with you on this one.

A java String is a java String - sequence of characters. ISO-8859
describes assorted ways of encoding characters as a series of
bytes. They need to decide whether they want a string, or a
sequence of bytes. They're different, like cash, or an IOU.
But I think you know that.

Steve

 

[Roedy Green]

Can anyone shed some light?

see http://mindprod.com/jgloss/encoding.html

Internally Java uses a 16-bit format. Externally, most of the time it
uses an 8-bit format. However some external encodings are 16-bit too,
e.g. big/little ending with/without/optional BOM marks.

They are just telling you that sorts of strings they want to exchange
with you. Inside you will use standard Java strings and convert on
the way in and out. For how to do the i/o see
http://mindprod.com/fileio.html

 

[Craig]

They are just telling you that sorts of strings they want to exchange
with you. Inside you will use standard Java strings and convert on
the way in and out.

No, thats not what they are telling us. They have given us a Java
class with a method that takes a Java String, and are insisting that
the reason the code is not working is that we are not encoding the
String to ISO-8859-2 before calling the method. I've tried to tell
them several times that we can send them an encoded byte array, but
not an encoded String.

Thanks

 

[Sudsy]

Craig wrote:

No, thats not what they are telling us. They have given us a Java
class with a method that takes a Java String, and are insisting that
the reason the code is not working is that we are not encoding the
String to ISO-8859-2 before calling the method. I've tried to tell
them several times that we can send them an encoded byte array, but
not an encoded String.

An important distinction! You're right, of course, as if you didn't
already know that. They're trying to cover up some deficiencies in
their code, i.e. it's WRONG.
Stick to your guns on this one.

 

[Roedy Green]

I've tried to tell
them several times that we can send them an encoded byte array, but
not an encoded String.

String has special meaning in Java it does not have to the programmers
of other languages. It can mean a number of things to them, including
a string of bytes null terminated

 

[Larry Barowski]

Craig wrote:


An important distinction! You're right, of course, as if you didn't
already know that. They're trying to cover up some deficiencies in
their code, i.e. it's WRONG.
Stick to your guns on this one.

Looks like they are expecting a String made up of characters where
the the low bytes represent ISO-8859-2 characters. Not a good
idea.

 

[John C. Bollinger]

No, thats not what they are telling us. They have given us a Java
class with a method that takes a Java String, and are insisting that
the reason the code is not working is that we are not encoding the
String to ISO-8859-2 before calling the method. I've tried to tell
them several times that we can send them an encoded byte array, but
not an encoded String.

Perhaps the external package is treating the String as if it were a char
array, and assuming that the chars have integer values corresponding
to ISO-8852-2 encoded characters. If you are not giving them such
strings then that might indeed be the reason that things are not
working. If that is the case, however, then drop that package like a
hot potato -- the developers have no clue what they are doing, and who
can guess what other "interesting" surprises you'll run into.


John Bollinger
(e-mail address removed)