|
Buck,
Thanks for testing.
I create a file with EDTF, or from RDi.
I change the CCSID to 1208 with option 13.
Etc
I didn't see the "properties" window where you can change the encoding of
the file.
When i go to RSE and right-click on the file i get a properties window
only showing some attributes such as encoding but i can't change it.
However, when i choose File->Properties the i get the full window where i
ca change the encoding. But i seem to get this window not always.
Sometimes it's disabled, sometimes a just get the small properties window.
Pff
However, i'm trying all things but it keep saying to me "just use another
tool for this".
Howver, 800 bucks a year is a lot of money for something you can't even
use to edit xml docs.
The locally cached file is encoded ok in UTF-8, after i save the document.
For example ř is translated to C5 99.
But the file on the IFS is not, although it's CCSID is 1208.
This also happens when i create the file from RDP.
Another file with another name, no avail, still having the same problems.
Clearing the cache does not help.
I clear the cache regularly because i had some problems before that RDP
wouldn't load the - NEWER - remote source member but instead loaded the old
source in the cache.
So nothing helps, local file is encoded ok, but remote is not, no matter
what i do.
I can't even reproduce the situation from yesterday that i create a new
file (with EDTF file or whatever) and let it save explicitly to UTF-8.
Local file is ok but remote file is not.
The ř is translated to C5 99.
But the file on the IFS is not, although it's CCSID is 1208.
It's translated to a question mark (3F).
And the other characters (ö and ä which have a representation in Cp1252)
are translated to EF BF BD which is the UTF-8 replacement character.
So it seems after translating correctly to UTF-8 locally, when it uploads
the file it then translates to characters in the 437 codepage but with
UTF-8 representation. So if a character does not exist it becomes a
question mark or replecament character.
Complicate all this... yes.. but thats the situation.
But now comes a surprise. Whe i create a file on the IFS from RDP 0 but
WITHOUT .xml extension, then it does encode correctly in UTF-8 on the IFS.
So maybe there some config setting associated with .xml but all settings
specify UTF-8.
I give up.
I use another free xml tool to create them on the PC and then upload
binary to the IFS.
That will work.
But what a shitty product, RDP, really.
I did some more testing but it's really annoying.
On Tue, Jul 9, 2013 at 7:10 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:
Replies inline.
On 7/9/2013 11:49 AM, whatt sson wrote:
I'm trying to edit an xml document on the ifs using RDP (8.5) but itseems
to have some trouble converting to/from UTF-8.
I have created the file on the IFS with CCSID 1208.
How? I used EDTF to create a file with a blank line, save it, exit
EDTF, re-run EDTF, F15 option 3 CCSID 1208, then paste <?xml
version="1.0" encoding="utf-8" ?> into the first line and saved it.
WRKLNK shows CCSID 1208.
Then i edit the file in RDP and put some text in it with latin-1
characters, such as ä.
Then i save the file but RDP converts to 1252 instead of 1208.
I opened my test.xml in RDP 8.5.1, changed to Source view and added
this: <test>Hélène says bonjour.</test> I am in the US, with a US
keyboard, so I typed the accented letters by holding down the Alt key
and pressing the numbers on the number pad: Alt+130 for é and Alt+138
for è. Then I saved the file. No warnings in RDP.
WRKLNK still shows CCSID 1208. EDTF shows a warning:
CPF9897 1 INVALID CHARCTERS FOR CCSID 01208 ENCOUNTERED IN DISPLAY
RECORD 3. IF THE RECORD IS CHANGED, THEY WILL BE REPLACED WITH
BLANKS.
Cause . . . . . : No additional online help information is available.
Exit EDTF.
Back to RDP, in RSE, right click the XML file -> Properties. I see that
file encoding is set to Default(Cp1252). I set it to Other UTF-8.
Apply, OK. I see funny characters in my RDP editor where my accents
used to be. I fix them and save.
WRKLNK shows 1208 and EDTF shows the accented characters properly. In
hex they are:
<test>
3C746573743E
Hélène
48C3A96CC3A86E65
When i put a latin-2 character in the text such as ř and then save totext
RDP complains and asks to convert it to UTF-8 (which i want it to do).
When I paste that character into my RDP editor and save, I see no
warnings in RDP. WRKLNK shows 1208, EDTF shows a non-displayable
character on my US English 5250 (CCSID 37) session. In hex it is:
<test2>
3C74657374323E
ř
C599
</test2>
3C2F74657374323E
How can i set RDP to always save in UTF-8 format.
Or even better, to respect to CCSID attribute of the IFS file.
I did not see a preference for this in regular RDP 8.5.1. Maybe it's
because RDP is not the web developer version - I think that is Rational
Business Developer? Just a guess.
In the general settings i have set the default CCSID to 1208 for XMLfiles
(*.xml).
But this does not have any effect it seems.
General -> Appearance -> Content types. My XML type was set to UTF-8
(which is the default).
XML -> XML Files has what to do when /creating/ an XML file. Mine was
set to UTF-8 (which is the default).
RDP also behaves rather quirky with this.converts
When i explicitly choose to save to UTF-8 (when asked for it) it
incorrectly to the existing file (CCSID 1208).
When i create a new file with CCSID 1208 and save the same text then it
does convert to UTF-8.
RDP (or RDi) seems to be completely broken on this.
I'm not sure what is different between our setups. In my case, I must
remember to change the properties to UTF-8. That's clumsy but I
wouldn't call it completely broken. I hope this was some help; if only
to show where RDP ends and RBD begins.
--buck
--
This is the Rational Developer for IBM i / Websphere Development Studio
Client for System i & iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/wdsci-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.