|
[EDI-L Mailing List Archive Home]
[Message List]
[Reply To This Message]
Re: Swedish chars in EDIFACT
I am going to defend at this point that the bit patterns were verified
to be correct. This comes from the master UNB interchange produced by
the supplier's EDI system in Sweden. The interchange was emailed as an
attachment (or zipped and mailed - I don't remember now). The received
interchange verified to be correct. Some of the characters were
examined at the hex level and known to be correct.
When the same interchange was received on our end, extended Latin-1
chars were changed. The hex values were different from what they
should have been.
I verified the data with our VAN and as far as we could determine,
they had the same data we did. The evidence shows that something got
messed up in either the supplier's upload (via OFTP) to IBM-EUR or in
IBM's interconnect to our VAN.
Both VANs are EBCDIC systems. I've worked with IBM in the past and I
asked them about how they preserved EDIFACT data over the EBCDIC
threshold and they told me that they processed EDIFACT data in binary
mode.
So we're down to a few possibilities here:
a) OFTP upload is not 8-bit clean, so IBM doesn't even get the right
data from their customer
b) IBM's batching and interconnecting is not 8-bit clean or in binary,
so it is getting mangled there
c) The actual interconnect protocol to our VAN is not 8-bit clean.
I've been trying to get a binary copy of the interchange from IBM, but
have been unsuccessful so far.
Thanks for your input,
Andrew
--- In Bill Chessman <bill.chessman@i...> wrote:
> Ah, the wonders of international character sets. Question: When
you say
> "We have verified that the source data produced by the supplier is
exactly
> correct and coded perfectly for ISO 8859-1, as implied by UNOC," do
you mean
> that all the characters in the interchange appear to be correct or
did you
> verify that the actual bit patterns matched the expectations of ISO
8859-1?
>
> If the former, then the verification is probably of limited value. ISO
> 8859-1 implies not only certain character pictures, but also very
specific
> bit patterns associated with each.
>
> Supposing, and we're getting into pretty murky waters here, that the
Swedish
> sender's system is configured with the Swedish ASCII character code
page and
> the receiver's system is configured with the US ASCII character code
page.
> Assuming further, as you say, everything was sent in binary mode with no
> byte values changed, the character that appeared on the receiver's
US ASCII
> system would probably show some variations in the characters even
though the
> byte values are the same.
>
> One of the big problems with international network traffic is that the
> actual character set designation of the transmitted data is unknown
over the
> transmission medium (particularly if transmission is truly binary in
which
> case you're effectively shipping bytes, not characters per se).
Therefore,
> the endpoints must make assumptions with respect to the most appropriate
> code page (usually the local default is used).
>
> We've encountered similar problems when using simple things like FTP
(binary
> _and_ ASCII modes, actually).
>
> The above discussion in and of itself doesn't provide a solution,
but might
> help spark some ideas on how to approach finding one. Anyone else
find a
> way around this? Are there any protocols out there that actually
work well
> with character code page issues?
>
> Best regards,
> Bill Chessman
> Inovis(tm), Inc.
>
> -----Original Message-----
> From: Andrew BK [mailto:edi_meister@y...]
> Sent: Tuesday, May 13, 2003 2:44 PM
> To:
> Subject: [EDI-L] Swedish chars in EDIFACT
>
>
> Hi everyone,
>
> I'm testing INVOIC coming from a Swedish supplier. We're using
> EDIFACT syntax version 3 and message version D.98A.
>
> UNB+UNOC:3+...
> UNH+...+INVOIC:D:98A:UN'
>
> We have verified that the source data produced by the supplier is
> exactly correct and coded perfectly for ISO 8859-1, as implied by
> UNOC.
>
> The supplier is using IBM Information Exchange (EUR system), and
> interconnecting to our VAN. I think they are using OFTP to upload to
> IBM.
>
> The data is damaged on arrival. We are convinced it is being damaged
> in its pass through IBM. Something somewhere is not 8-bit clean. Is
> this a known deficiency with OFTP? I have previously been told by IBM
> IE that they process EDIFACT data in binary mode. Any recommendations?
>
>
> sent from supplier ABCDXYZÅÄÖ1234567890
> Arrived ABCDXYZ»«þ1234567890
>
>
> Sent from supplier abcdxyzåäö!"#¤%&/()=?@£${[]}|§½EUR
> kom fram abcdxyz|¯Ö!"#á%&/()=?@à${[]}|çËEUR
>
> Thanks,
>
> Andrew
>
>
>
> To unsubscribe from this group, send an email to:
>
> Message Identifiers: <SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>,
> <OFF-TOPIC>
> Access the list online at: http://groups.yahoo.com/group/EDI-L
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
|
 |
Subscribe in XML format
| RSS 2.0 |
|
| Atom 0.3 |
|
|
Cart
