× 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.



On Tue, Mar 14, 2017 at 5:42 PM, Scott Klement
<midrange-l@xxxxxxxxxxxxxxxx> wrote:
The best solution, here, is for the python process to be fixed to understand
UTF-8 with a BOM.

I agree with this. And it's a trivial adjustment. Python has an
encoding called utf-8-sig specifically to handle UTF-8 with BOM.

So the fact that it is failing and forcing him to change the CCSID to
1208 is a GOOD THING.

Definitely agree that setting the CCSID correctly is a good thing.
Don't know who would disagree with this.

(It would be even better if the file transfer
process detected the BOM and automatically made it 1208... but that is not
ACS's problem. Sounds like he's using NetServer, I would consider asking
IBM to change NetServer to detect the BOM and set the CCSID correctly.
(Which would be impossible if ACS didn't put the BOM in there... so, again,
it is a GOOD thing)

Here there is definitely disagreement. Not from me personally, but the
consensus interpretation of the Unicode standard is that the BOM is
discouraged for UTF-8. Microsoft in particular goes against this
sentiment and requires the BOM, using it roughly analogously to the
way IBM i uses CCSID.

I will point out (without making any recommendation one way or the
other) that it's not impossible to set the CCSID correctly, even
without the BOM. You gave the example of Notepad++ which already does
this. (Well, it's Windows software, so doesn't directly use CCSID, but
the point is it doesn't need the BOM to detect UTF-8.)

John Y.

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.