While converting from Oracle to Sybase ASE I encounter the following issue: ASCII function doesn't return code for multi-byte characters properly, it looks like it gets only the first byte.
For example, the following statement returns 34655
select ASCII('㍉') from dual
while in Sybase it returns 63
select ASCII('㍉')
Adaptive Server has the following language settings
Language: Japanese
Character Set: eucjis
Even if I use Sybase uscalar function
select uscalar('㍉')
it returns 63
Only passing to uscalar function hex equivalent of this Japanese symbol gives different result, but not the same as in Oracle
select uscalar(0x875F)
returns 24455
But in this way another issue appears - I'm not able to cast this symbol to hex as
select convert(varbinary,'㍉')
returns only the first byte again (0x3f)
Please help me to find out the appropriate way of getting the correct ASCII code of multi-byte Japanese symbols in Adaptive Server Enterprise.
Related
My database character set is AL32UTF8 and national character set AL16UTF16. I need to store in a table numeric values of some characters according to db character set and later on display a specific character using numeric value. I had some problems with understanding how this encoding works (differences between unistr, chr, ascii functions and so on), but eventually I found website where the following code was used:
chr(ascii(convert(unistr(hex), AL32UTF8)))
And it works fine when hex code is smaller than 1000 when I use for example:
chr(ascii(convert(unistr('\1555'), AL32UTF8)))
chr(ascii(convert(unistr('\1556'), AL32UTF8)))
it returns the same ascii value (ascii(convert(unistr('\hex >= 1000'), AL32UTF8))). Could anyone look at this and try to explain what's the reason? I really thought I understood how it works, but now I'm confused a bit.
I have written a program to read data from a text file and load it into a table using UTL_FILE package in oracle. While reading a few lines some characters are getting converted into special characters, for example:
string in file = 63268982_GHC –EXH PALOMARES EVA
value entered into database = 63268982_GHC âEXH PALOMARES EVA
I tried using Convert function but it did not achieve anything.
My Oracle version is 11gR2 and it's using the nls charset WE8ISO8859P1. Because these strings represent physical file names I get a mismatch when I try to match with the filename.
I tried re-converting the value stored in Oracle in WE charset back to ascii like below:
convert('63268989_GHC âEXH PALOMARES','us7ascii','WE8ISO8859P1')
but the outcome is different from what was there in text file while reading. Can anyone please suggest how this problem can be overcome.
The – character in the file is not a regular hyphen (-, chr(45)) but an En Dash / U+2013 stored as three bytes, decimal 226, 128, 147 or hex e2, 80, 93. Interpreted individually rather than as a single multibyte character, these correspond to – as shown here.
Try opening the file with utl_file.fopen_nchar and reading lines with utl_file.get_line_nchar.
Oracle 11gR2 Database Globalization Support Guide: Programming with Unicode.
I have a table with a column configured as NVARCHAR2, I'm able save the string in UTF-8 without any issues.
But the application the calls the value does not fully support UTF-8.
This means that the string is passed to the database and back after the string is converted into HTML letter code. Each letter in the string is converted to such HTML code.
I'm looking for an easier solution.
I've considered converting it to BASE64, but it contains various characters which are considered illegal in the application.
In addition tried using HEXTORAW & RAWTOHEX.
None of the above helped.
If the column contains 'κόσμε' I need to find a way to convert/encode it to something else, but the decode should be possible to do from the HTML running the application.
Try using ASCIISTR function, it will convert it in something similar as JSON encodes unicode strings (it's actually the same, except "\" is used instead of "\u") and then when you receive it back from front end try using UNISTR to convert it back to unicode.
ASCIISTR: https://docs.oracle.com/cd/B28359_01/server.111/b28286/functions006.htm
UNISTR: https://docs.oracle.com/cd/B19306_01/server.102/b14200/functions204.htm
SELECT ASCIISTR(N'κόσμε') FROM DUAL;
SELECT UNISTR('\03BA\1F79\03C3\03BC\03B5') FROM DUAL;
I am using ADODB with VB6 to select data from Excel. The "Book_Title" column in Excel contains extended ASCII characters (Abreve-Ă).
But when using the following code, I only get "A" instead of Abreve.
sConn = "DRIVER=Microsoft Excel Driver (*.xls);" & "DBQ=D:\sheik\metadata.xls"
rs.Open "SELECT [Book_Title], [Author_Title] FROM [Sheet1$], sConn
The problem here is that the Excel driver is converting the strings to ANSI symbols, for some reason. Some "clever" code is converting the Ă character (258) to A (65).
If you have the JET drivers with the ISAM Excel driver installed, then the following connection string will use them:
sConn = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\sheik\metadata.xls;Extended Properties=""Excel 8.0;"""
You will now get back the unconverted strings. However, you probably will not be able to see them correctly in any of the built-in VB controls, or the IDE, for that matter, because it is unlikely that this character exists in your current code page.
But you can confirm that the first character is correct by using the AscW() function to look at the characters in the string, obtained with Mid$().
Is there any way to use ascii code for value separator in SYS_CONNECT_BY_PATH.
For example in SYS_CONNECT_BY_PATH(columnname,'!'),
I want to use the ASCII value of !(33) instead of actual symbol. Also, can i use the ascii value of ENTER (13) as value separator?
Thank you.
You can use the chr function to replace a character with it's numeric equivalent.
SYS_CONNECT_BY_PATH(column name, chr(33))
Or to use a line feed, which should also be fine:
SYS_CONNECT_BY_PATH(column name, chr(13))
It's not strictly ASCII as it depends on your character set, but it will probably work for you. You can see the numeric values using the reverse ascii function, which also isn't really quite ASCII, but again close enough especially if you're always using the same character set. So ascii('!') would give you 33.
As you've discovered, giving anything except a fixed string literal gives:
SQL Error: ORA-30003: illegal parameter in SYS_CONNECT_BY_PATH
function
30003. 00000 - "illegal parameter in SYS_CONNECT_BY_PATH function"
*Cause:
*Action: use a non-empty constant string as the second argument,
then retry the operation.
This is why I usually test things before posting, but this seemed so simple... You can get around that with replace:
REPLACE(SYS_CONNECT_BY_PATH(column name, '/'), '/', chr(33))
Borrowing an example from the manual:
SELECT LPAD(' ', 2*level-1)
||replace(SYS_CONNECT_BY_PATH(last_name, '/'),'/',chr(33)) "Path"
FROM employees
START WITH last_name = 'Kochhar'
CONNECT BY PRIOR employee_id = manager_id;
Path
--------------------------------------------------
!Kochhar
!Kochhar!Greenberg
!Kochhar!Greenberg!Faviet
!Kochhar!Greenberg!Chen
!Kochhar!Greenberg!Sciarra
!Kochhar!Greenberg!Urman
!Kochhar!Greenberg!Popp
!Kochhar!Whalen
!Kochhar!Mavris
!Kochhar!Baer
!Kochhar!Higgins
!Kochhar!Higgins!Gietz
All the credit goes to Sanjeev Chauhan. Update 7/25/2017: This turned out to be a SQL Developer 4.2.0 and 17.2.0 bug. In SQLPlus and SQL Developer 3.2.2 the statement works fine.
Fix: set secureliterals off;
The source is https://community.oracle.com/thread/4065282
I had changed the version from 4.2.0 to 4.1.1.19 and my piece of code worked. Also be aware that I couldn't find "secureliterals" in version 4.2.0