APEXExport character set bug?

Hello, I'm having problems with the APEXExport utility. The resulting application is exported into some strange character set ...
The character I am having problems with is U+2019, RIGHT SINGLE QUOTATION MARK, ’
The character is represented in the exported file as (hex) 0xC2 0x92.
This is not UTF-8 where it should be 0xE2 0x80 0x99, nor windows-1252 where it is 0x92.
It is something close to UTF-8 since é is correctly represented as 0xC3 0xA9
A manual export (via that apex web app) shows me the charset "Western European ISO-8859-1". In the file so exported the character is represented by 0x92 (and this also means that it is NOT ISO-8859-1, but windows-1252)
so
1) the export made via APEXExport differs from the one made via the apex web app
2) the export made via APEXExport encodes characters in some stange way.
setting the jvm params (-Dfile.encoding) doesn't seem to change anything.
My guess is that "something" thinks that 0x92 is in ISO-8859-1 (which is unused) and converts it to UTF-8 as 0xC2 0x92. The original 0x92 is instead in windows-1252 and should be converted to UTF-8 as 0xE2 0x80 0x99.
I am using apex 4.2.2.00.11

I managed to find a workaround. I read the exported file as if was UTF8 and write into ISO-8859-1. The resulting file will really be in windows-1252 format.
Since the differences between windows-1252 and ISO-8859-1 are minimal I suppose most people don't notice the difference.
Quoting wikipedia: "It is very common to mislabel Windows-1252 text with the charset label ISO-8859-1. A common result was that all the quotes and apostrophes (produced by “smart quotes” in Microsoft software) were replaced with question marks or boxes on non-Windows operating systems, making text difficult to read. Most modern web browsers and e-mail clients treat the MIME charset ISO-8859-1 as Windows-1252 to accommodate such mislabeling. This is now standard behavior in the draft HTML 5 specification, which requires that documents advertised as ISO-8859-1 actually be parsed with the Windows-1252 encoding"
So this is all very confusing, because java is still correct about this and windows-1252 is NOT ISO-8859-1, and reading the exported file into windows-1252 will throw "UnmappableCharacterException".
What is even more confusing is that when you reimport the windows-1252 file into apex you will have to select the "Western European ISO-8859-1" char set to make it work.
Bottom line: the APEXExport utility is buggy and will generate files that cannot be reimported without some tricky manipulation.

Similar Messages

  • Data load uses wrong character set, where to correct? APEX bug/omission?

    Hi,
    I created a set of Data Load pages in my application, so the users can upload a CSV file.
    But unlike the Load spreadsheet data (under SQL Workshop\Utilities\Data Workshop), where you can set the 'File Character Set', I didn't see where to set the Character set for Data Load pages in my application.
    Now there is a character set mismatch, "m³/h" and "°C" become "m�/h" and "�C"
    Where to set?
    Seems like an APEX bug or at least omission, IMHO the Data Load page should ask for the character set, as clients with different character sets could be uploading CSV.
    Apex 4.1 (testing on the apex.oracle.com website)

    Hello JP,
    Please give us some more details about your database version and its character set, and the character set of the CSV file.
    >> …But unlike the Load spreadsheet data (under SQL Workshop\Utilities\Data Workshop), where you can set the 'File Character Set', I didn't see where to set the Character set for Data Load pages in my application.
    It seems that you are right. I was not able to find any reference to the (expected/default) character set of the uploaded file in the current APEX documentation.
    >> If it's an APEX omission, where could I report that?
    Usually, an entry on this forum is enough as some of the development team members are frequent participants. Just to be sure, I’ll draw the attention of one of them to the thread.
    Regards,
    Arie.
    ♦ Please remember to mark appropriate posts as correct/helpful. For the long run, it will benefit us all.
    ♦ Author of Oracle Application Express 3.2 – The Essentials and More

  • Cdrtools package, support for nls/utf8 character sets

    Hello ppl,
    I've been trying desperetly to burn a cd/dvd(k3b) with greek filenames and directory names. I ended up with file names like "???????????????????? (invalid unicode)"
    After a lot of searching, i managed to isolate and solve the problem. There has been a patch(http://bugs.gentoo.org/attachment.cgi?id=52097) for cdrtools to support nls/utf8 character sets.
    I guess that 90%+ of people using arch and burning cd's/dvd's, ignore the problem cause they just burn cd's/dvd's using standard english characters.
    For all others here it is     :
    # Patched cdrtools to support nls/utf8 character sets
    # Contributor: Akis Maziotis <[email protected]>
    pkgname=cdrtools-utf8support
    pkgver=2.01.01
    pkgrel=3
    pkgdesc="Tools for recording CDs patched for nls/utf8 support!"
    depends=('glibc')
    conflicts=('cdrtools')
    source=(ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-2.01.01a01.tar.gz http://bugs.gentoo.org/attachment.cgi?id=52097)
    md5sums=('fc085b5d287355f59ef85b7a3ccbb298' '1a596f5cae257e97c559716336b30e5b')
    build() {
    cd $startdir/src/cdrtools-2.01.01
    msg "Patching cdrtools ..."
    patch -p1 -i ../attachment.cgi?id=52097
    msg "Patching done "
    make || return 1
    make INS_BASE=$startdir/pkg/usr install
    It's a modified pkgbuild of the official arch cdrtools package (http://cvs.archlinux.org/cgi-bin/viewcv … cvs-markup) patched to support nls/utf8 character sets.
    Worked like a charm. 
    If u want to install it, u should uninstall the cdrtools package
    pacman -Rd cdrtools
    P.S.: I've issued this as a bug in http://bugs.archlinux.org/task/3830 but nobody seemed to care...    :cry:  :cry:  :cry:

    Hi Bharat,
    I have created a Oracle 8.1.7 database with UTF8 character set
    on WINDOWS 2000.
    Now , I want to store and retrieve information in other languages
    say Japanese or Hindi .
    I had set the NLS Language and NLS Terrritory to HINDI and INDIA
    in the SQL*PLUS session but could not see the information.You cannot view Hindi using SQL*Plus. You need iSQL*Plus.
    (Available as a download from OTN, and requiring the Oracle HTTP
    server).
    Then you need the fonts (either Mangal from Microsoft or
    Code2000).
    Have your NLS_LANG settings in your registry to
    AMERICAN_AMERICA.UTF8. (I have not tried with HINDI etc, because
    I need my solution to work with 806,817 and 901, and HINDI was
    not available with 806).
    Install the language pack for Devanagari/Indic languages
    (c_iscii.dll) on Windows NT/2000/XP.
    How can I use the Forms 6i to support this languages ?I am not sure about that.
    Do write back if this does not solve your problem.
    --Shirish

  • Multi character set support

    we plan to implement Interconnect to get new customer records created in many databases (at distributed locations) to be populated into a central system.
    all the databases are running on Oracle Database 9.x and we plan to use DB adapters to access each of them.
    3 of these databases store data in double-byte format (Traditional Chinese, Simplified Chinese, Japanese). others are in standard US/American English
    my questions are:-
    1) does my central system's database have to be set to use a certain character set too ?
    2) do i have to configure Interconnect to ensure that data from non-English systems are retrieved and populated correctly into my central database
    thanks for any response

    Hi,
    We are also facing similar problem. We are using IC version 9.0.2. We have AQ adapter at source and DB adapter at destination. The characterset at DB application database is UTF-8. Where as in AQ application database is AR8MSWIN1256. We are using request/reply scenario. But the reply message which gets enqueued to the queue by AQ adapter contains '??????' (arabic data)
    We have specified the encoding type in both adapter.ini files but no use.
    We also followed the steps as stated in Metalink bug id 2375248. But nothing works. Can somebody help us???
    -Vimala

  • Different Character sets?

    Oracle version: 11.1.0.7.0
    There are any problems if I configure an Oracle Streams Replication between to database with different character set? I have configured a propagation between two database A and B. The A character set is WE8MSWIN1252 and the B character set is WEISO8859P1 but when the propagation passes about 30 minutes configured and ora-07445 begin. Also when I do the same configuration between two database with the same character set the problems does not appear.
    Here I write the error in the alert log:
    ORA-07445: se ha encontrado una excepción: volcado de memoria [kohrsmc()+1484] [SIGSEGV] [ADDR:0x18] [PC:0x7CCC92E] [Address not mapped to object] []
    Incident details in: /opt/oracle/diag/rdbms/bdmdic/bdmdic2/incident/incdir_110004/bdmdic2_j000_18185_i110004.trc
    Fri Aug 06 16:57:31 2010
    Trace dumping is performing id=[cdmp_20100806165731]
    Exception [type: SIGILL, Illegal operand] [ADDR:0x2ACE05EEFE60] [PC:0x2ACE05EEFE60, {empty}]
    Errors in file /opt/oracle/diag/rdbms/bdmdic/bdmdic2/trace/bdmdic2_j000_18185.trc (incident=110005):
    ORA-07445: se ha encontrado una excepción: volcado de memoria [PC:0x2ACE05EEFE60] [SIGILL] [ADDR:0x2ACE05EEFE60] [PC:0x2ACE05EEFE60] [Illegal operand] []
    ORA-07445: se ha encontrado una excepción: volcado de memoria [kohrsmc()+1484] [SIGSEGV] [ADDR:0x18] [PC:0x7CCC92E] [Address not mapped to object] []
    Incident details in: /opt/oracle/diag/rdbms/bdmdic/bdmdic2/incident/incdir_110005/bdmdic2_j000_18185_i110005.trc

    Where did I said that charset is interfering in propogataion? It will not interfere. Char set difference will cause the target database populated with data which it may not understand and will show you as garbage data. As you replication is working find without an issue for sometime, so it looks like you are hitting some bug when you hit replication for some specific data. To confirm this you may have to work with Oracle to find the exact cause or which bug you may be hitting.
    All my suggestions till this point in time is without knowing your proper environment (Server A,B OS and database version, also the error description except english words are all foreign to me). As suggested you will be better off working with Oracle support to find the resolution. Please let us know what fixed your issue when you work with Oracle to help all forum members.
    Regards

  • Are there any plans to fix the misinterpretation of the Exchange ActiveSync policy "Minimum number of character sets"  in IOS5?

    We are testing using IOS5 in our Corporate environment and came across a scenario where IOS5 incorrectly interprets the Exchange 2010 ActiveSync policy "Minimum number of character sets" as the number of special characters required rather than the number of character sets required. Is anyone aware of any plans to correct this in future releases? Here is a thread on Microsoft's forums about the issue:
    http://social.technet.microsoft.com/Forums/en-US/exchangesvrmobility/thread/fe05 1d55-24ba-45e4-b054-67861f28422d/

    Thanks for the responses. I did submit this issue as a bug report earlier this morning also but thought I'd post here in the event any Apple insiders saw this and cared to comment. 
    This really is a significant problem in that our testing shows that the way IOS5 interprets this ActiveSync policy in Exchange 2010 does not allow you to enforce a password using just letters and numbers. This is because  the only valid values for this policy are 1-4. The way IOS5 interprets this requires 1-4 special characters in the password, not 1-4 character sets.

  • Oracle 8.0.6 & 8.1.6 Character set scanners available for download

    The latest version of the character set scanner version 1.0
    (based on the 9.0.1 version) is now available on OTN. Oracle has
    backported this utility to the following RDBMS releases 8.0.6
    (Solaris), 8.1.6 (NT, Solaris) and 8.1.7 (NT, Solaris) .
    For more information, please refer to the following URL
    http://otn.oracle.com/tech/globalization/content.html

    Please feel free to provide any feedback (Bugs, enhancements
    etc.) that you may have on the character set scanner in the
    discussion forum.

  • Problem with character set - Reports 11.1.1.4

    Hi!
    I have a problem with Oracle Reports 11g regarding character set configuration. The default character set WE8ISO8859P1 works, so PDF reports have a regular display except for Eastern European (EE) letters which are replaced by "¿" sign.
    So, when I set any other character set in reports.sh, which would be a normal step to get EE letters, I'm always getting Greek Alphabet in PDF reports. Why Greek Alphabet?
    The character sets I tried to use are: EE8ISO8859P2, UTF8 and AL32UTF8.
    I changed uifont.ali and included PDF Subset with all four Arial font variants and, of course, I placed all fonts in fonts folder which is pointed by REPORTS_FONT_DIRECTORY.
    In Reports Builder everything works fine, but when I have to deploy the report to the Reports Services, the problem occurs.
    Also, when I've tried to execute PDF report using In-Process Reports Server (rep_wls_reports_hostnameasinst1) instead of AS Instance Reports Server (RptSvr_hostnameasinst1, which is a regular server), I'm getting Greek Alphabet in PDF reports even if the default character set is WE8ISO8859P1 in reports.sh. What is wrong with it? Where is Greek Alphabet configured?
    The production environment is 64-bit Oracle Linux 5.6 with Weblogic 10.3.4 and Forms&Reports 11.1.1.4. Forms works fine with character set EE8ISO8859P2 defined in default.env file.
    Thanks in advance!
    Regards,
    Dejan

    Thank you, Denis!
    Doc 300416.1 was very useful but Note 356221.1 - A Practical Methodology on Porting Reports from Windows to Unix with Different Font is actually crucial for configuring Reports on Linux.
    Also, there is a bug in 11.1.1.3 and 11.1.1.4, which can be fixed using the patch ( Note 1138405.1 - PDF Reports With Font Subsetting Raises Error "Bad /Bbox" on 64-Bit Linux ).
    Kind regards!

  • Non supported character set: oracle-character-set-171'  in java XSU

    I cannt update object type CHAR data in table cause Non
    supported character set: oracle-character-set-171'
    NLS lang UTF-8
    database language WIN-1251

    I think it is a bug at JDBC-OCI Driver.
    Now I am useing setPlsqlIndexTable to transfer
    a var to PLSQL procedure, and want to
    retrieve it from out parameter.
    When I transfer English characters, it can
    work correctly, but if I transfer Japnese or
    Chinese characters, the disorderly characters
    were returned. I have not resolved this problem
    yet. Who can tell me how to resolve it.

  • 9iLite and multibyte character set support

    Does 9iLite support a character set that will allow for accented characters?
    for example: i

    "NLS Character Integrity Issues for Consolidator
    When Mobile Sync synchronizes with an Oracle database which has a
    multibyte character set other than UTF8, the character integrity issue
    occurs. Mobile Sync retrieves data from the server database through Oracle
    8.1.7 OCI JDBC Driver for Oracle9iAS version 1.0.2.2, and 9i for Oracle9iAS
    version 2.0. Character sets are converted from database character sets to
    UTF8 by Oracle Servers NLS functions. In the code conversion, some
    multibyte characters are garbled because of the difference of the character
    mapping. This is not a bug of Mobile Sync.
    For more Information, see "Character Integrity Issues in NLS Environment"
    technical paper on Oracle Technology Network (technet.oracle.com)
    Java/SQLJ & JDBC section in Technologies category."
    from the Readme file with the media (read the manual I guess)

  • Reports character set

    I create report using 9iDS with data in English and Russian.
    When i run report on a server, html page do not display correctly Russian data.
    If I look source code of that html-page it contains tag "charset=iso-8859-5".
    I have 9iAS R2 and custom database 8.1.7.
    Database has parameter:
    NLS_CHARACTERSET=CL8ISO8859p5
    and iAS has NLS parameters set:
    NLS_LANG=RUSSIAN_CIS.CL8ISO8859p5
    USER_NLS_LANG=RUSSIAN_CIS.CL8ISO8859p5
    DEVELOPER_NLS_LANG=RUSSIAN_CIS.CL8ISO8859p5
    REPORTS_NLS_XML_CHARSET=CL8ISO8859P5
    Configuration files for reports server include string "encoding=iso-8859-5" or "default_charset=iso-8859-5"
    How can I tuning Reports Server for a correct work with character set CL8ISO8859p5???

    It looks like you're hitting a known bug, which is addressed in the first patch set. This is planned to be available towards the end of October - check on Metalink.
    Thanks,
    Danny

  • Dbassist and character set's

    Hello everyone. I just installed Oracle8i on my Slackware7 linux box and I can not seem to start the dbassist tool that comes with it. When I attempt to start the assistant it throws an JNLS exception, that reads as shown bellow.
    "JNLS Exception:oracle.ntpg.jnls.JNLSException Unable to find any National Character Sets. Please check your Oracle installation."
    Now my question is (obviously) how do I go about fixing this annoyance? Could one of my Enviorment vars. be causeing this to occur? Or am I barking up the wrong tree?
    Any help would be greatly appreciated...
    thanx in advance james...

    The JNLS error is a bug...What u have to do is just ignore the error and go ahead with the database creation...
    I think this should help u out...
    Edwin
    email:[email protected]

  • Dbassist - Character Set Warning

    I finished installing Oracle8i on RedHat
    Linux 6.0. After installing the 81502 patches
    when I started dbassist, I got the following warning:
    JNLSException.ntpg.jnls.JNLSException
    Unable to find National Character Sets
    Please check your Oracle Installation
    dbassist continued to run.
    What am I missing to cause the above warning?

    Nothing. It is a know bug. Just ignore it:
    http://homepages.tig.com.au/~jmsalvo/linux/oracle8i-3.html
    null

  • How can I see KSC5602 character set using JDBC thin driver

    After I change character set from USASCII7 to KO16KSC5601, I
    cannot see korean from the clients
    using JDBC thin driver.
    But, I can see korean clearly using sqlplus at serer, or
    application using SQLNet.
    I use Oracle Enterprise Server 8.0.4.1.0, jdbc thin driver
    8.0.4.0.6 on Windows 98. I read that all bugs realated
    to multibyte language are fixed in Oracle8. What can I do to
    solve this problem?
    PS.server: Oracle 8.0.4.1 on Digital Unix 4.0b, client: jdk1.1.8
    on Windows98. I used the command.
    null

    The easiest thing to do is download it as an archive with your applet.
    Otherwise, you have to have the files on every client machine.
    For netscape, put the classes111.jar in the java classes folder typically:
    c:\ProgramFiles\Netscape\Communicator\Program\java\classes.
    I'd expect that IE would be setup in a similar way.

  • ORA-12714: invalid national character set specified

    i have the following error
    ORA-12714: invalid national character set specified
    when i read a table.
    my database having the below nls parameters
    NLS_LANGUAGE - AMERICAN
    NLS_CHARACTERSET -WE8ISO8859P1
    NLS_NCHAR_CHARACTERSET -AL16UTF16
    i was tried to set the set nls_lang=AMERICAN_AMERICA.WE8ISO8859P1 during the export
    any solution?

    What is your exact database version ?
    What is the complete command that triggered this error ?
    There is a in know bug in some releases < 10.2 about this error:

Maybe you are looking for