• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Coversion of string to EBCDIC format.

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,
I have done one program in java, which converts string to EBCDIC format. But when i'm sending that data to server side its giving me unicode values for the same.
I need help regarding this. May i know where is exact problem.
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't know that this is the right forum to ask that question in, but maybe this will help.

java.lang.String is defined as Unicode. It is the native way to deal with strings in Java apps. It's better NOT to work with EBCDIC internally in an application because of that. So the only times you should normally convert to EBCDIC are at the peripherals edges, unless you're doing EBCDIC-specific character/byte manipulations. In other words, when you read and write to disk files and do similar tasks. Not, however, necessarily when you talk to databases, because the actual periphery is inside the JDBC driver layer, so JDBC prefers Unicode on the application side as well.

The Internet was designed in the days when it was common to link IBM mainframes (EBCDIC) with minicomputer and non-IBM mainframes (ASCII). Therefore many of its protocols are text-based, including HTTP, FTP (except binary mode), SMTP/POP/IMAP, TN3270 and other popular servers. When using these protocols, you normally use a client app that works in the native character set of the machine it's running on. To facilitate transport, the MIME encoding uses a character-mode encoding that ensure that binary data is transported without being corrupted by text data transports. So an HTTP email could potentially be translated between ASCII and EBCDIC multiple times as it hops between servers, yet neither the sender nor the recipient would realize that the native character set of the other was not the same.

Thanks to the above mechanisms, your actual need to work with EBCDIC, as opposed to abstract text (in Unicode) is fairly limited. The main exception, as I mentioned, is when you open text files (or data streams) in binary. Most commonly you'll see this when, for example, you open files written by COBOL apps which mix text fields with packed decimal.

Of course, converting packed decimal - or even worse, the rather unique floating-point binary form originally developed for the IBM System/360 - has its own headaches.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic