× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Ups,

ghaphical emoji's isn't supported yet they have to be entered as characters.

On Fri, Jul 14, 2017 at 6:27 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

Nathan/John/Vern,

don't throw CCSid 819 out with the bathwater, here is an EBCDIC example
what handles all kind of UTF-8 characters with a SBCS EBCDIC fields as the
intermediate field between input and output in the RPG program.

Try to copy/paste or enter your own characters and put it through my IBM i
at http://5.103.128.110:6382/testutf8.htm

<xmlelement>😃✌️👌👍 あなたねえ 😃✌️👌👍 abcdefg 😃✌️👌👍</xmlelement>


On Fri, Jul 14, 2017 at 6:22 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

I did take a shot at copying an XML to an 819-ccsid file - the characters
that did not convert were replaced with x'1A' - I didn't see an option on
the CPY command to change that - so that would need to have been changed en
masse, since THAT byte also caused a parsing error.

I also thought, why not go for the gusto? Why not copy the original XML
to a file in CCSID37? It would make it impossible to look at the XML in any
standard editor, but maybe that wouldn't matter.

It replaced these non-convertible characters to x;3F; - I don't remember
if I tried this morning to process that - I decided I would continue as I
am with XMLTABLE - I would not easily convince anyone I should change
directions, with again, the risk factor of unknown results.


On 7/13/2017 7:59 PM, Nathan Andelin wrote:

I was under the impression it wouldn't work. Maybe that
impression was mistaken?


It's a suggestion for Vern to try.



What happens to characters that are not
representable in the target CCSID?

I'm not sure. I think it would replace the EMOJI with something
acceptable
to the parser. It would be worth a try.

I suspect that XML parsers load entire documents into memory, and build a
tree structure that references each element, attribute, etc. That would
be
required for validation.

Then, if the document is valid, some sort of API can be used to extract
all, or a filtered selection of content. Different parsers expose
different
APIs, and different capabilities.

I admit that extracting XML content into an SQL cursor might be precisely
what one needs. In other cases, the developer may need to look at each
element, attribute, etc. separately.


--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD




--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>






As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.