RE: httpapi - problem with french special characters

[Julius Kaj <Kaj.Julius@xxxxxx>]

Hi Nicolas,

You mention that your problem with the incorrect translation of the special characters used in the French language surfaced in a program that is responsible for sending out emails.

I may be wrong, but I'm assuming this means that you're not using Scott's HTTPAPI in its normal capacity of http client. Most likely you are using some of the lower level procedures from the library.

That's what I did when I ran into trouble. I was trying to cut a few corners (or some may say, trying not to reinvent the wheel), and therefore wanted to use Scott's code to translate some text before sending it to a streamfile. I looked though the code of HTTPAPI and when I found the http_xlate procedure, I said to myself: Ahh, just what I need! (maybe you've done the same?).

Well, it worked - sort of. Just not when I tried to output to CCSID 1208 (UTF-8).

With the help of Scott I was pointed in the right direction: http_xlatedyn. This procedure uses a scheme of dynamically allocating extra space for the output if needed. In contrast the "old" http_xlate procedure simply assumes that the number of characters will always be the same as the input. That's not always the case when using UTF-8.

The tricky part in using http_xlate with UTF-8 stems from one af the even lower level procedures called by it (CCSIDxlate) that doesn't capture the error code E2BIG returned by iconv (a simple callp to iconv is used) and therefore the error indication isn't propagated back to your program and you never get to know that the conversion actually failed.

I'm not quite sure, why the old http_xlate procedure hasn't been depricated. I think Scott has explained his reasoning for this in a post somewhere in the archives. Obviously he has coded his higher-level functionality in such a way that he can ensure that the best procedure for the job is chosen. I don't think he anticipated that people would be using his code in the way I did, ie. call lower-level procedures directly.

If I'm correct in assuming that your program does use Scott's low-level procedures, ie. http_xlate or http_xlatep, then you too will have to change your code to use http_xlatedyn in stead of http_xlate. In fact http_xlatedyn will always return the correct translated string, whatever CCSID you're converting from/to. It's perfectly safe to always use this procedure. It may allocate a little more memory than strictly needed, though. When the originally allocated buffer isn't enough, it allocates an additional 64 Kbytes chunk until the conversion goes through without failing with the E2BIG error code. 

But as others have already told you, until you tell us a little more about what you're doing in your program, it's a little hard to guess what help you need.

Best of luck!

Regards,
Kaj



-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of MAZO Nicolas
Sent: Tuesday, January 25, 2011 12:05 PM
To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
Subject: httpapi - problem with french special characters

Hi,

Here (CBP solution in France) we have used many times httpapi without any problem, so thank you to Scott Klement for such a good  job.

Now we try to use it to pass the needed parameters (from/to/object/text..) to a service who has in charge to send emails.

We encountered problems withe special characters only used in French language like (é,è, à..).

We first try to mention 1208 as CCSID, but without any success (characters are omitted from the text).

We have found a ver y interesting post, posted by Kaj Julius talking about http_xlatedyn, we've just tried it and it works perfectly.

We now have a major interrogation, how (where) are we supposed to use it with httpapi ???

Thanks for your answer. May be Kaj could help us ?

Best regards

Nicolas MAZO





**********************************************************************
La diffusion de ce message s'effectuant sur un réseau non protégé, nous déclinons toute responsabilité en cas d'altération ou de falsification.
As this message is sent through a non protected network, we decline any responsibility should it be altered or falsified
**********************************************************************
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------