<HTML xmlns:eXclaimer="http://www.exclaimer.co.uk" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:exc="http://www.exclaimer.co.uk/rtf">
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=UTF-16">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1251">
<TITLE>Message</TITLE>
<META content="MSHTML 6.00.2900.3354" name=GENERATOR></HEAD>
<BODY >
<DIV>
<DIV><SPAN class=238463806-29072008><FONT face=Arial size=2>Jacorb it is
controlled with </FONT></SPAN><SPAN class=238463806-29072008><FONT
face=Arial size=2>-Dfile.encoding=ISO_8859_1 on the command
line.</FONT></SPAN></DIV>
<DIV><SPAN class=238463806-29072008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=238463806-29072008><FONT face=Arial size=2>I had to start
using that to get Jacorb to interop with Orbix. Never had any problems with
omniorb or tao, but maybe didn't see the same situation.</FONT></SPAN></DIV>
<DIV><SPAN class=238463806-29072008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=238463806-29072008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=238463806-29072008><FONT face=Arial
size=2>Richard</FONT></SPAN></DIV>
<DIV><SPAN class=238463806-29072008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B>
omniorb-list-bounces@omniorb-support.com
[mailto:omniorb-list-bounces@omniorb-support.com] <B>On Behalf Of </B>William
Bauder<BR><B>Sent:</B> 29 July 2008 00:05<BR><B>To:</B> 'Steven Sauder';
omniorb-list@omniorb-support.com<BR><B>Subject:</B> RE: [omniORB] OmniOrb and
CP1252 (Windows Latin 1) vs. ISO-8859-1<BR><BR></FONT></DIV>
<DIV><SPAN class=555065322-28072008><FONT face=Arial color=#0000ff size=2>I
haven't had to deal with this myself, but it did trigger a memory of something
I saw in OrbConstants:</FONT></SPAN></DIV>
<DIV><SPAN class=555065322-28072008><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=555065322-28072008><FONT face=Arial color=#0000ff
size=2> // The CHAR_CODESETS and WCHAR_CODESETS allow the
user to override the default<BR> // connection code
sets. The value should be a comma separated list of
OSF<BR> // registry numbers. The first number in the
list will be the native code<BR> //
set.<BR> //<BR> // Number can be specified
as hex if preceded by 0x, otherwise they are<BR> //
interpreted as decimal.<BR> //<BR> // Code
sets that we accept currently (see
core/OSFCodeSetRegistry):<BR> //<BR> //
char/string:<BR> //<BR> // ISO8859-1
(Latin-1) 0x00010001<BR> // ISO646
(ASCII)
0x00010020<BR> //
UTF-8
0x05010001<BR> //<BR> //
wchar/string:<BR> //<BR> //
UTF-16
0x00010109<BR> //
UCS-2
0x00010100<BR> //
UTF-8
0x05010001<BR> //<BR> // Note: The
ORB will let you assign any of the above values to<BR> //
either of the following properties, but the above
assignments<BR> // are the only ones that won't get you into
trouble.<BR> public static final String CHAR_CODESETS =
SUN_PREFIX + "codeset.charsets";<BR> public static final
String WCHAR_CODESETS = SUN_PREFIX +
"codeset.wcharsets";<BR></FONT></SPAN></DIV>
<DIV><SPAN class=555065322-28072008><FONT face=Arial color=#0000ff
size=2>Assuming that you're using strings, and the problem isn't in their
ISO-8859 encoding, you might be able to fix on the java side by changing the
default codeset.</FONT></SPAN></DIV>
<DIV><SPAN class=555065322-28072008><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=555065322-28072008><FONT face=Arial color=#0000ff
size=2>-Bill</DIV></FONT></SPAN>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B>
omniorb-list-bounces@omniorb-support.com
[mailto:omniorb-list-bounces@omniorb-support.com] <B>On Behalf Of </B>Steven
Sauder<BR><B>Sent:</B> Monday, July 28, 2008 5:18 PM<BR><B>To:</B>
omniorb-list@omniorb-support.com<BR><B>Subject:</B> [omniORB] OmniOrb and
CP1252 (Windows Latin 1) vs. ISO-8859-1<BR><BR></FONT></DIV><FONT
face=Arial><SPAN style="FONT-SIZE: 12px">Hi all!<BR><BR>We’re a long-time
user of OmniOrb with great success in our applications, but something has
recently come up which is causing problems for our European customers.
Our applications all speak the (full) Windows CP1252 (Windows Latin 1)
character set, in which Microsoft has used the code point 0x80 to represent
the Euro symbol (€). CP1252 and ISO-8859-1 are “almost” the same,
except that CP1252 utilizes the 0x80 code point to represent the Euro, where
ISO-8859-1 leaves this code point blank. <BR><BR>After a bit of
investigation, it seems that OmniOrb by default uses ISO-8859-1 as the
“native” codeset, which I had thought would mean that the Euro symbol (and a
couple of other “special” characters such as the trademark symbol, and the
“curly” printers quotes), which are represented in CP1252, but not in
ISO-8859-1, could not be handled by OmniOrb using its default codeset.
However, digging into cs-8859-1.cc a little more, it looks like the
translation tables ARE passing 0x80 through to UCS as 0x0080, so unless I’m
reading this wrong, any OmniOrb-to-OmniOrb communications (on Windows)
should pass the (Windows-specific) Euro code point 0x80 through without
problem. Am I reading this right?<BR><BR>However, the difficulty
arises because we have several CORBA components which are written using the
standard Java ORB, which (it appears) is not providing the same amount of
leeway with this symbol, and insists on transmitting the Euro symbol in it’s
“true” UCS16 representation (0x20AC), which OmniOrb’s codeset converters end
up turning into a “?” when we receive it on the Windows end.<BR><BR>Has
anyone had any experience with this? From what I’ve read so far, it
seems the only viable solution would be to write our own NCS-C
implementation that handled the CP1252 Euro symbol (0x80) to Unicode
(0x20AC) and back-again conversion through the translation tables as is
currently happening in cs-8859-1.cc, is this correct?<BR><BR>Any help would
be hugely appreciated!<BR>Thanks<BR>Steve.<BR></SPAN></FONT><SPAN
style="FONT-SIZE: 12px"><FONT face="Verdana, Helvetica, Arial">-- <BR>Steve
Sauder<BR>Chief Technology Officer<BR>North Plains Systems
Corp.<BR></FONT></SPAN><FONT face="Verdana, Helvetica, Arial"><FONT
size=2><SPAN style="FONT-SIZE: 10px">510 Front Street West, 4th
Floor<BR>Toronto, ON<BR>Canada M5V 3H3<BR>P: (416)
345-1900 ext. 500<BR>F: (416) 599-0808<BR>W: <A
href="http://www.northplains.com/">http://www.northplains.com/</A><BR>E:
ssauder@northplains.com <BR></SPAN></FONT><FONT
color=#323298><FONT size=5><SPAN
style="FONT-SIZE: 16px"><B><BR></B></SPAN></FONT></FONT><B><FONT
size=2><SPAN style="FONT-SIZE: 10px">Confidentiality
Notice:<BR></SPAN></FONT></B><FONT size=2><SPAN style="FONT-SIZE: 10px">The
information contained herein is confidential and proprietary to North Plains
Systems Corp. ("North Plains") and is intended for review by authorized
persons only. Except as may otherwise be agreed to in writing by North
Plains, any disclosure, circulation, release or use of the information
contained herein is strictly prohibited.<BR><BR><B>Upcoming
Webinar:<BR>Marketing Made Easy With Digital Asset Management <BR></B>August
14th, 2008 – 1:00PM EST (10:00AM PST)<BR>Click to register: <A
href="http://www.northplains.com/news/newsItem.cfm?cms_news_id=191&cms_news_type_id=13">http://www.northplains.com/news/newsItem.cfm?cms_news_id=191&cms_news_type_id=13</A><BR><BR><B>TUG
2008 Conference <BR></B>September 8th & 9th, 2008<BR>Click to register:
<A
href="http://www.northplains.com/en/customer_portal/conference.cfm">http://www.northplains.com/en/customer_portal/conference.cfm</A></SPAN></FONT></FONT><FONT
face=Arial><SPAN
style="FONT-SIZE: 12px"><BR></BLOCKQUOTE></BLOCKQUOTE></SPAN></FONT></DIV>
<DIV>
<HR COLOR="gray">
</DIV>
<DIV><BODY >This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: <A HREF="http://www.ml.com/e-communications_terms/">http://www.ml.com/e-communications_terms/</A>. By messaging with Merrill Lynch you consent to the foregoing.</BODY></DIV>
<DIV>
<HR COLOR="gray">
</DIV>
<DIV> </DIV></BODY></HTML>