Hi,

We are using the OEngineserver for communicating with an IPAD App, isnt that cool?

We have set the encoding to UTF8 because some characters did not arrive well in OI.

But stil the single quote char(39) arrives as &qt in OI.

What's wrong?

Ed Keeman

Hi Ed,

Those characters have been html escaped That allows the browser to display characters which it would otherwise interpret.

The brute force fix is to swap "&qt" with char(39) and use similar swap statements for other escaped characters.

Hi,

In the list you refer, char(39) is not present as &qt, there is actually char(34) and that character is encoded as "

Can you provide a correct list with the encoded characters for Oengineserver?

Regards

Ed Keeman

Hi Ed,

I apologize for my misleading typos.

OI does not use a different set of characters. escape codes, they are an html standard.

The list at http://www.theukwebdesigncompany.com/articles/entity-escape-characters.php is the correct list.

AFAIK OI does not add escape those characters automatically. If you are receiving them from the Ipad I believe the ipad is doing the encoding.

Hi,

Before the data goes to the oengineserver by a php script, i have dumped the data to a textfile.

In that textfile i don't see any &qt only char(39), so the encoding is done bij the Oengineservice.

Ed Keeman

Hi Ed,

You are correct - it looks like something happens inside the socket server.

If I call RUN_OECGI_REQUEST from OI the signel quotes are not corrupted.

But if I make a web calll to the same OI, I get $qt; for the single quotes.

Hi,

Here in the Netherlands we are in the "Euro" zone, so the euro sign is very important …

If i set the encoding to UTF8, we loose the euro-sign "€" in the return value from the OEngineserver.

The char is converted to nothing…

regards

Ed Keeman

Hi,

Here in the Netherlands we are in the "Euro" zone, so the euro sign is very important …

If i set the encoding to UTF8, we loose the euro-sign "€" in the return value from the OEngineserver.

The char is converted to nothing…

regards

Ed Keeman

Hi, Ed. Can you tell me, first, what method of communication you're using with the engine server - is it indeed OECGI3, or NetOI, or …?

Second, what do you have specified as the "listener" or "dispatch routine"? When running from OECGI3, for example, the default is RUN_OECGI_REQUEST.

The quote substitution you're seeing is a "side effect" of how the engine server actually runs the the dispatch routine, and passes in the parameters. You can imagine that the engine server runs your dispatch routine almost as though you were invoking it at the System Monitor line, with the command

RUN <dispatchroutine> 'PARAM1','PARAM2','PARAM3'

Note that the entire string any parameters are wrapped in single quotes. Therefore, any single quotes that are present in the parameters have to be "escaped" so they do not interfere with the OEngine processing, and that's where the &qt comes from. Your dispatch routine should, for each parameter, just swap &qt with ' (or alternatively, you should not pass in single quoted strings… )

Re: the Euro symbol and UTF8. Using UTF8 in the engine server - and in the OEngine - is actually very complex. It appears that UTF8 mode is set by the "client" (normally, the OINSIGHT.EXE) in conjunction with the oengine. If you're returning html, you can fix the problem by ensuring that the return html is marked as being in UTF8 (rather than ANSI) - that is, having a line like this:

<meta http-equiv="Content-Type" content="text/html; charset=UTF8" />

instead of

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

If you're _not_ returning HTML, then you may want to (or need to) wait until the 9.4.0 release, when the Engine Server will support connection via a different port specifically for UTF8 mode…

Hope that helps,

- Bryan Shumsky

Revelation Software, Inc.

Bryan,

Thank you for clear answering!

I am communicating directy with the socket (ip). We use php script on apache.

The data format in and out is JSON.

Within OI I created a function, from php i do calls to that function..

On the socket char(1) is used as delimitter between the parameters.

We are busy building the app so we hope that 9.4 will be on time.

The engine converts the euro sign to nothing, so it doesn't matter wich charset is set.

The company that's building the app wants to do UTF8, but maybe 8859-1 is an alternative, because i have a scanner-warehousesolution, also with php, and that runs on 8859-1, with euro signs.

regards

Ed Keeman

Hi

Can you please tell me what the best settings are is for eserver.cfg for UTF-8

We discovered that if the service runs on UTF-8, and "starnge signs" (è ę ė ē ') pass through, next data strings get truncated.

regards

Ed Keeman

Hi

Can you please tell me what the best settings are is for eserver.cfg for UTF-8

We discovered that if the service runs on UTF-8, and "starnge signs" (è ę ė ē ') pass through, next data strings get truncated.

regards

Ed Keeman

Hi, Ed. I haven't seen that problem, myself. As I mentioned in the earlier post, though, it may be best to try out the new EngineServer which will have support for an actual UTF8 connection; if you're interested in trying this as part of the upcoming beta for 9.4, please be sure to contact our office.

- Bryan Shumsky

Revelation Software, Inc.

View this thread on the Works forum...