I'm currently struggling with a procedure where form data sometimes contains special characters, such as '°' (the degree symbol).

Browsers tend to sent the form data as utf-8 (which is according to the encoding I specified for the page), but the fex seems to ignore the encoding that came with the POST-request and sends the value to the database in some encoding it decided on by itself...
It's not surprising that no data matching that value gets found then.

Dev Studio doesn't appear to be able to display the values properly as utf-8 and there doesn't seem to be a knob to set the encoding of the tool. I had to edit the file with an external editor to get the appropriately encoded characters in...

I also tried to encode the HTML page as win-1252, but at least one browser (Chrome) sent the form data as utf-8 regardless.

Are you looking for a data cleaning routine? A display Routine? Or, other? Can you post a simpliefied version of your code, within the "< / >" brackets?

I think you need to look at codepages for the WF server.

From what I understand about character encoding you have to configure a lot of things. Read the documentation here first.
http://documentation.informati...1/source/topic79.htm

1) WebFocus Reporting Server
2) WebFocus Client
3) Apache Tomcat
4) Report Caster
5) Oracle Client

Here are some more links to look at

Set Codepage on WF Server, WF Client, and ReportCaster to 65001 (UTF-8).
http://forums.informationbuild...=649105204#649105204

Setup UTF-8 on the Application Server (Tomcat)
https://techsupport.ibi.com/sps/50762547.html
https://techsupport.informatio...om/sps/80412538.html

Setup an environment variable NLS_LANG. On the server that WebFocus is installed on.
http://documentation.informati.../source/topic221.htm
https://techsupport.informatio...om/sps/51742565.html
http://documentation.informati...1/source/topic83.htm

Also you can't store UTF-8 encoded data unless the database is setup that way. You're signature says Oracle. Here is a query you can run. SELECT * FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET';

Well, for example a dropdown list option in my launch-page has value="E-modulus at 23°C".
The degree symbol in the browser is encoded in utf-8 as C2 B0.

The values in that dropdown list (in the browser) are the result of calling the adhoc-fex via an xmlHTTP POST-request with a snippet of DM/FOCUS code, returned as PCHOLD FORMAT XML:

Form Data (decoded):
ST  : FOC_NONE
SS  : FOC_NONE
COA : FOC_NONE
START_DATE : FOC_NONE
END_DATE   : FOC_NONE
PG  : FOC_NONE
IBIF_adhocfex : SET ONLINE-FMT = XML
SET PANEL = 9000

-SET &COA2 = IF &COA EQ FOC_NONE OR '' THEN 'no' ELSE &COA;

TABLE FILE UNI00008H_PARAMETERS
BY PA
BY PA_DESCRIPTION
WHERE ST EQ '&ST';
WHERE SS EQ &SS;
WHERE ('&COA2' EQ 'yes' AND PG EQ 'CoA') OR ('&COA2' NE 'yes' AND PG NE 'CoA');
WHERE END_DATE FROM '&START_DATE' TO '&END_DATE';
WHERE PG EQ '&PG';
WHERE PA NE '/';
END

In Dev Studio I edit the fex that gets called by the HTML form. If I paste a degree symbol in there it ends up as B0, not C2 B0. Apparently Dev Studio uses latin1 for encoding.
There doesn't appear to be a method to change the encoding in there so that the characters in both environments at least look the same. That's a bit problematic, but if you're aware of that you can work around it.
I ended up opening the fex on the remote file system in a real editor, in which I could choose in what encoding (utf-8) to edit the file.

In the next step the data-value (as selected in the dropdown) is used in the WHERE-clause of an SQL query back to Oracle, and it turns out that the value doesn't match the same value in Oracle any more.
It would appear that something along the way isn't transforming the encoding appropriately. That's the real problem.

The data went through this route:

Oracle -> WebFOCUS server -> WebFOCUS client -> IIS7 -> Client browser -> WebFOCUS server -> Oracle

I'm fairly certain this must be a bug in WebFOCUS somewhere, because:

• The browser tells what encoding its using (utf-8) - verified
  
• The webFOCUS server should know its own encoding
  
• The webFOCUS server should pass its encoding information on to the database session
  
• Oracle converts the data to its local encoding

If all that happens correctly, the value would have been the same at the start and the end.

Now I am perfectly aware that not all characters in utf-8 can be converted between all character sets, but I don't think that's the case for a character as common as the degree symbol. That should have been exactly the same once it got back to Oracle.