I try to send an email using utl_smtp with Oracle including norwegian characters (å æ ø). The characters are stored and displayed correctly in the database otherwise, but shows up as question marks in the email.
My database character set is WE8MSWIN1252
I have tried different Content-Type mime headers in the email including 'text/plain; charset="win-1252"', this does not seem to help.
By default smtp is 7bit ascii (kinda old tech :). You must be using UTL_SMTP.write_data and from the documentation:
Text (VARCHAR2) data sent using
WRITE_DATA is converted to US7ASCII
before it is sent. If the text
contains multibyte characters, each
multibyte character in the text that
cannot be converted to US7ASCII is
replaced by a '?' character. If
8BITMIME extension is negotiated with
the SMTP server using the EHLO
subprogram, multibyte VARCHAR2 data
can be sent by first converting the
text to RAW using the UTL_RAW package,
and then sending the RAW data using
WRITE_RAW_DATA.
There is a sample demo package on OTN that shows how to send multibyte emails.
Related
I need a printable character which is not available in the mobile SMS messages. The reason is that I have a file which has a bunch of data, and one of those data fields is SMS-text. It is dummy data ofcourse.
I need to extract this field. The tool I am using for it asks for a field-separator, on the basis of which it separates fields into a CSV file. And it uses a comma character as the default field separator.
Now the problem is that whenever a comma character occurs in SMS text, it separates the rest of the SMS text and makes it a separate field.
So my question is that how do I find a single character which I can use as a field separater in this case?
I think you can encode the text using Base64 before sending SMS, and then decode after receiving. Please see: https://en.wikipedia.org/wiki/Base64.
You may want to have a look at the GSM charset spec. Be aware about the 7bits / 8bits encoding and the encoding of the different (human) languages.
Trying to save models and i get a:
java.sql.SQLException: Incorrect string value: ...
Saving a text like "jedna dva tři kachna dům a kachní maso"
I'm using default.url="jdbc:mysql://[url]/[database]?characterEncoding=UTF-8"
řů have no encoding in latin1; áõ do. That suggests that CHARACTER SET latin1 is involved somewhere. Let's see SHOW CREATE TABLE.
C599, etc, are valid utf8 encodings for the corresponding characters.
? occurs when the destination character set cannot represent the character. Again, this points to the column/table being latin1, when it should be utf8 (or utf8mb4).
More discussion, and for debugging similar situations: Trouble with utf8 characters; what I see is not what I stored
Probably has some special character, and the UTF-8 encode that you are forcing may cause some error.
This ASCII string has the following text:
String:
jedna dva tři kachna dům a kachní maso
ASCII:
'jedna dva t\xc5\x99i kachna d\xc5\xafm a kachn\xc3\xad maso'
When I try to send sms with the "ó" char I get a blank char instead.
I have read in the doc that:
the default alphabet is the GCM 7-bit, but characters in languages such
as Arabic, Chinese, Korean, Japanese, or Cyrillic alphabet languages
(e.g., Ukrainian, Serbian, Bulgarian, etc.) must be encoded using the
16-bit UCS–2 character encoding.
But if I encode the message with UTF-16 (I have read UCS-2 is UTF-16) I get a 40001 error. So, is posible to send special chars with sinch?
GSM-7 and USC-2 are encodings used by the Sinch backend to send the message over smpp. Currently Latin1 (iso-8859-1) is also used, and this is probably why you're getting this missing character since some sms providers do not support it and therefore decode the message using a different decoder. Sinch are removing Latin1 (which result in a shorter encoded short message than USC-2) support and will use USC-2 instead for messages that cannot be encoded with GSM-7 or ASCII.
I'm interested in the 40001 that you're getting. If you're setting the charset to utf-16 on the http request you should not do that. If you're doing something else please post your code (without appKey and secret) so I see more clearly how you generate that error.
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 need to send an email with the Subject containing cyrillic letters. But my recipients sometimes receive incorrect letters due to some problems with mail server and/or client. I always send emails in windows-1251 encoding, but sometimes a mail client shows letter's Subject and Sender in another encoding (KOI-8R) and our users can't understand the message.
I tried to use an encoded-word tag as described in RFC 2047 Standard. For example, my Subject field in the email now looks like:
Subject: =?WINDOWS-1251?B?wiDt5eTw4PUg8vPt5PD7IOL75PD7IOIg4+Xy8OD1IPL78P/yIOIg4uXk8OAg/+Tw?=
=?WINDOWS-1251?B?4CDq5eTw4C4gwvvw4uDiIPEg4vvk8Psg4iDy8+3k8OUg4+Xy?=
=?WINDOWS-1251?B?8PssIOL78vDzIOL75PDu6SD/5PDgIOrl5PDgLCDi+/Lw8yDj?=
=?WINDOWS-1251?B?5fLw7ukg4vvk8OUg7O7w5PMsIP/k8OAg4iDi5eTw4Cwg4vvk?=
=?WINDOWS-1251?B?8PMg4iDy8+3k8PMu?=
These lines was generated by Oracle function UTL_ENCODE.MIMEHEADER_ENCODE.
All mail clients (Lotus Notes, gmail.com) show only the first line of such email subject (only first 48 symbols).
What is the problem with my mail subject?
The problem is, that you do not fold correctly, according to RFC 2822. To make a multi line field in the header each line has to start with a white space.
What you need to do is:
replace(UTL_ENCODE.MIMEHEADER_ENCODE(subject, 'UTF8', UTL_ENCODE.BASE64), UTL_TCP.CRLF, UTL_TCP.CRLF || ' ')
This should solve your problem.