Base64 encoded attachments misunderstood by recipients

My boss uses Mail.app, and a number of people have reported that they can never open her attachments. When I look at the files they receive from her, they appear to be base64 encoded, and indeed decoding them makes them perfectly readable. Unfortunately, I don't think any of the built-in apps in OS X can do this decoding. Also, not all of the recipients use Macs.
At first I thought that the issue might be that she was not using the 'Windows friendly attachments'. However, I tried sending a message from another coworker's computer without selecting that option, and it worked fine. I then discovered that the problem is that if she drags her attachments into the message rather than selecting them via 'add attachment', they don't work. Basically, if the attachment is inline rather than at the end of the message.
I still thought that using 'Windows friendly attachments' would fix the problem, so on another Mac I tried setting Mail.app to always send Windows Friendly attachments (To do this, just open Mail.app, make sure you aren't composing an e-mail, and then under Edit > Attachments, select 'Always send Windows Friendly attachments'). However, this didn't work, either.
So, I think that the solution is just to tell her either to use the 'Add Attachment' button or to drag the file to the end of the message.
It's a shame that inline attachments don't work for so many e-mail clients (notably Gmail). I don't think that this is an Apple innovation... is it?
I hope that helps someone,
Greg

Did you ever this to work ?

Similar Messages

Base64 encode attachments but not xml payload

Hi Everyone,
Using the soap adapter I know that I can use an adapter module and base64 encode everything. Is it possible to base64 encode the attachments but leave the soap/xml payload as text/xml?
Regards,
Joe

> Using the soap adapter I know that I can use an adapter module and base64 encode everything. Is it possible to base64 encode the attachments but leave the soap/xml payload as text/xml?
Do you want to have attachments of type base64, or do you want to have transfer-encoding base64? The latter is not possible with adapter modules.
Regards
Stefan

Improper decoding of base64 encoded attachment on Exchange 2007 SP1

I'm using Exchange 2007 SP1. My java application sends email to users of exchange 2007 SP1. The email contains an email as an attachment which is base64 encoded . This email when sent to users on exchange 2007 SP1 shows blank attachment. The same email when sent to users on different exchange (e.g. Exchange 2003) shows the correct attachment i.e. the attachments are not blank. While sending the mail i'm setting name of the attachment in Content-Type header but it is not there when we look at the rfc contents of the mail received on ex 2007 SP1. It seems exchange 2007 is not able to decode the base 64 contents properly. Below are the rfc contents of the mail which show few headers in the attachment part instead of the base64 content. Please suggest some solution to it. It's urgent.
Received: from test80.psjpr.com (192.168.0.243) by exchange01.psjpr.com
(192.168.0.138) with Microsoft SMTP Server id 8.1.263.0; Fri, 11 Apr 2008
18:53:12 +0530
From: Admin <[email protected]>
To: test test1 <[email protected]>
Date: Fri, 11 Apr 2008 18:53:12 +0530
Subject: Retrieved from : testingggggg
Thread-Topic: Retrieved from : testingggggg
Thread-Index: Acib1zFeboxSL6S4RuaeI0AaCou0pQ==
Message-ID: <[email protected]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: exchange01.psjpr.com
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/mixed;
boundary="_002_9c2e5956bc9b49efbbc61a358f61698bexchange01psjprcom_"
MIME-Version: 1.0
--_002_9c2e5956bc9b49efbbc61a358f61698bexchange01psjprcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
The message you requested is attached.
--_002_9c2e5956bc9b49efbbc61a358f61698bexchange01psjprcom_
Content-Type: message/rfc822
Subject:
Thread-Index: Acib1zFexS+KMQAOSD+lcMut076Wyg==
Accept-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
--_002_9c2e5956bc9b49efbbc61a358f61698bexchange01psjprcom_--

Did you ever this to work ?

Handling of base64 encoded body for message/rfc822

As I understand the mime spec allows only "7bit", "8bit", or "binary" for the body of a "message/rfc822" entity
However, it looks like Outlook is generating these under some circumstances (I have supplied a sample below). When attempting to read these via the JavaMail API the message content is empty and instead ends up in the header fields.
Is there a workaround or setting to handle these base64 RFC822 attachments in JavaMail?
Here's a stripped down sample of the message with the RFC822 attachment that I'm trying to handle:
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-Type: multipart/mixed; boundary=00235400e66249e8d9047d9b2ab3
--00235400e66249e8d9047d9b2ab3
Content-Type: multipart/alternative;
     boundary=00235400e66249e8cf047d9b2ab1
--00235400e66249e8cf047d9b2ab1
Content-Type: text/plain;
     charset=iso-8859-1
Content-Transfer-Encoding: 8bit
... [plain text version of message]
--00235400e66249e8cf047d9b2ab1
Content-Type: text/html;
     charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
... [html version of message]
--00235400e66249e8cf047d9b2ab1--
--00235400e66249e8d9047d9b2ab3
Content-Disposition: attachment
Content-Type: message/rfc822
Content-Transfer-Encoding: base64
UmVjZW...
--00235400e66249e8d9047d9b2ab3--

Thanks for the info and suggested workaround. Would be neat to have a configurable option in 1.4.4 since info on the web suggests there are other email systems generating this rubbish.
The customer who generated the emails is using Outlook 2007 with the Google Apps Sync for Outlook. I haven't been able to replicate in Outlook 2007 so might be related to the connector. I'll do some more testing before reporting the problem to the appropriate organization!

Data is not Base64 encoded - error when starting Weblogic connecting to IS

I get the following error trying to connect to Identity Server from weblogic 7.0 via the weblogic java policy agent from Sun:
java.lang.ExceptionInInitializerError: java.lang.RuntimeException: Data is not Base64 encoded.
I have set the encode cookie to true on both the policy agent side and the Identity Server side. I have also restarted both, but still receiving this error.
Has anyone had similar problems? Any soluitions?

Hello,
I am getting the same error for a tomcat policy agent . Ihave installed Identity server on Solaris 9 and Tomcat 4.1.27 on the same machine. I set followinf property in policy agent's AMAgent.properties-
com.iplanet.am.cookie.encode=true
However, it doesn't help :-(
what else is to be done? The documentation says that modify AMConfig.properties file on the client side for this property. Howveer, i do not have AMConfig fil on tomcat side. so i modified AMAgent.property.
Is that ok?

Problem with base64 encoding an xml file with accented characters

Oracle 10.2.0.1.0 Enterprise Edition running under windows 2003 server
DB Characterset UTF-8
I have a routine which takes an xml file and base64 encodes it, and the base64encoded text is stored in a clob column of a table.
The xml file is stored in UTF-8 format.
The routine works correctly, except when there are accented characters.
I am using dbms_lob.loadclobfrom file to load the file.
DBMS_LOB.OPEN(src_clob, DBMS_LOB.LOB_READONLY);
    DBMS_LOB.LoadCLOBFromFile(
          DEST_LOB     => dest_clob
        , SRC_BFILE    => src_clob
        , AMOUNT       => DBMS_LOB.GETLENGTH(src_clob)
        , DEST_OFFSET => dst_offset
        , SRC_OFFSET   => src_offset
        , BFILE_CSID   =>dbms_lob.default_csid
        , LANG_CONTEXT => lang_ctx
        , WARNING      => warning
    DBMS_LOB.CLOSE(src_clob);base 64 encoded xml with accented character -- incorrect
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxncDpBcHBs
aWNhdGlvblByb2ZpbGUgeG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAx
L1hNTFNjaGVtYS1pbnN0YW5jZSINCiAgICB4c2k6c2NoZW1hTG9jYXRpb249Imh0
dHA6Ly9uYW1lc3BhY2VzLmdsb2JhbHBsYXRmb3JtLm9yZy9zeXN0ZW1zLXByb2Zp
bGVzLzEuMS4wIGh0dHA6Ly9uYW1lc3BhY2VzLmdsb2JhbHBsYXRmb3JtLm9yZy9z
eXN0ZW1zLXByb2ZpbGVzLzEuMS4wL0dQLnN5c3RlbXMucHJvZmlsZXMuMS4xLjAu
QXBwbGljYXRpb25Qcm9maWxlLnhzZCINCiAgICB4bWxuczpncD0iaHR0cDovL25h
bWVzcGFjZXMuZ2xvYmFscGxhdGZvcm0ub3JnL3N5c3RlbXMtcHJvZmlsZXMvMS4x
LjAiDQogICAgVW5pcXVlSUQ9Ik1FIiBQcm9maWxlVmVyc2lvbj0iMS4xLjAiIEVy
cmF0YVZlcnNpb249IjAiPg0KICAgIDxncDpEZXNjcmlwdGlvbj5Gb3J1bSBUZXN0
PC9ncDpEZXNjcmlwdGlvbj4NCiAgICA8Z3A6RGF0YUVsZW1lbnQgTmFtZT0iw6Fj
Y2VudCIgRXh0ZXJuYWw9InRydWUiIFR5cGU9IkJ5dGVTdHJpbmciIEVuY29kaW5n
PSJIRVgiIEZpeGVkTGVuZ3RoPSJmYWxzZSIgTGVuZ3RoPSIxNiIgUmVhZFdyaXRl
PSJ0cnVlIiBVcGRhdGU9InRydWUiIE9wdGlvbmFsPSJ0cnVlIiAvPiAgICANCjwv
Z3A6QXBwbGljYXRpb25Qcm9maWxlPg0Kbase 64 encoded xml without accented character -- correct
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxncDpBcHBs
aWNhdGlvblByb2ZpbGUgeG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAx
L1hNTFNjaGVtYS1pbnN0YW5jZSINCiAgICB4c2k6c2NoZW1hTG9jYXRpb249Imh0
dHA6Ly9uYW1lc3BhY2VzLmdsb2JhbHBsYXRmb3JtLm9yZy9zeXN0ZW1zLXByb2Zp
bGVzLzEuMS4wIGh0dHA6Ly9uYW1lc3BhY2VzLmdsb2JhbHBsYXRmb3JtLm9yZy9z
eXN0ZW1zLXByb2ZpbGVzLzEuMS4wL0dQLnN5c3RlbXMucHJvZmlsZXMuMS4xLjAu
QXBwbGljYXRpb25Qcm9maWxlLnhzZCINCiAgICB4bWxuczpncD0iaHR0cDovL25h
bWVzcGFjZXMuZ2xvYmFscGxhdGZvcm0ub3JnL3N5c3RlbXMtcHJvZmlsZXMvMS4x
LjAiDQogICAgVW5pcXVlSUQ9Ik1FIiBQcm9maWxlVmVyc2lvbj0iMS4xLjAiIEVy
cmF0YVZlcnNpb249IjAiPg0KICAgIDxncDpEZXNjcmlwdGlvbj5Gb3J1bSBUZXN0
PC9ncDpEZXNjcmlwdGlvbj4NCiAgICA8Z3A6RGF0YUVsZW1lbnQgTmFtZT0iYWNj
ZW50IiBFeHRlcm5hbD0idHJ1ZSIgVHlwZT0iQnl0ZVN0cmluZyIgRW5jb2Rpbmc9
IkhFWCIgRml4ZWRMZW5ndGg9ImZhbHNlIiBMZW5ndGg9IjE2IiBSZWFkV3JpdGU9
InRydWUiIFVwZGF0ZT0idHJ1ZSIgT3B0aW9uYWw9InRydWUiIC8+ICAgIA0KPC9n
cDpBcHBsaWNhdGlvblByb2ZpbGU+DQo=the xml file in use is
<?xml version="1.0" encoding="UTF-8"?>
<gp:ApplicationProfile xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://namespaces.globalplatform.org/systems-profiles/1.1.0 http://namespaces.globalplatform.org/systems-profiles/1.1.0/GP.systems.profiles.1.1.0.ApplicationProfile.xsd"
    xmlns:gp="http://namespaces.globalplatform.org/systems-profiles/1.1.0"
    UniqueID="ME" ProfileVersion="1.1.0" ErrataVersion="0">
    <gp:Description>Forum Test</gp:Description>
    <gp:DataElement Name="áccent" External="true" Type="ByteString" Encoding="HEX" FixedLength="false" Length="16" ReadWrite="true" Update="true" Optional="true" />
</gp:ApplicationProfile>The file is being loaded from a windows xp professional 32 bit system.
If I just convert the xml text of the file using
select utl_raw.cast_to_varchar2(
utl_encode.base64_encode(
utl_raw.cast_to_raw(
'<?xml version="1.0" encoding="UTF-8"?>
<gp:ApplicationProfile xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://namespaces.globalplatform.org/systems-profiles/1.1.0 http://namespaces.globalplatform.org/systems-profiles/1.1.0/GP.systems.profiles.1.1.0.ApplicationProfile.xsd"
    xmlns:gp="http://namespaces.globalplatform.org/systems-profiles/1.1.0"
    UniqueID="ME" ProfileVersion="1.1.0" ErrataVersion="0">
    <gp:Description>Forum Test</gp:Description>
    <gp:DataElement Name="áccent" External="true" Type="ByteString" Encoding="HEX" FixedLength="false" Length="16" ReadWrite="true" Update="true" Optional="true" />
</gp:applicationprofile>'
))) from dual;I get the following
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPGdwOkFwcGxp
Y2F0aW9uUHJvZmlsZSB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEv
WE1MU2NoZW1hLWluc3RhbmNlIgogICAgeHNpOnNjaGVtYUxvY2F0aW9uPSJodHRw
Oi8vbmFtZXNwYWNlcy5nbG9iYWxwbGF0Zm9ybS5vcmcvc3lzdGVtcy1wcm9maWxl
cy8xLjEuMCBodHRwOi8vbmFtZXNwYWNlcy5nbG9iYWxwbGF0Zm9ybS5vcmcvc3lz
dGVtcy1wcm9maWxlcy8xLjEuMC9HUC5zeXN0ZW1zLnByb2ZpbGVzLjEuMS4wLkFw
cGxpY2F0aW9uUHJvZmlsZS54c2QiCiAgICB4bWxuczpncD0iaHR0cDovL25hbWVz
cGFjZXMuZ2xvYmFscGxhdGZvcm0ub3JnL3N5c3RlbXMtcHJvZmlsZXMvMS4xLjAi
CiAgICBVbmlxdWVJRD0iTUUiIFByb2ZpbGVWZXJzaW9uPSIxLjEuMCIgRXJyYXRh
VmVyc2lvbj0iMCI+CiAgICA8Z3A6RGVzY3JpcHRpb24+Rm9ydW0gVGVzdDwvZ3A6
RGVzY3JpcHRpb24+CiAgICA8Z3A6RGF0YUVsZW1lbnQgTmFtZT0iw6FjY2VudCIg
RXh0ZXJuYWw9InRydWUiIFR5cGU9IkJ5dGVTdHJpbmciIEVuY29kaW5nPSJIRVgi
IEZpeGVkTGVuZ3RoPSJmYWxzZSIgTGVuZ3RoPSIxNiIgUmVhZFdyaXRlPSJ0cnVl
IiBVcGRhdGU9InRydWUiIE9wdGlvbmFsPSJ0cnVlIiAvPiAgICAKPC9ncDphcHBs
aWNhdGlvbnByb2ZpbGU+Edited by: Keith Jamieson on Jul 13, 2012 9:59 AM
added code tag for last base64 encoded object

Not sure if utl_i18n is already there in version prior to 11.2.0.2.
But on above mentioned version I can do the simplified method
SQL> SELECT utl_i18n.raw_to_char (
         utl_encode.base64_encode (
           xmltype (
             '<?xml version="1.0" encoding="UTF-8"?>
<gp:ApplicationProfile xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://namespaces.globalplatform.org/systems-profiles/1.1.0 http://namespaces.globalplatform.org/systems-profiles/1.1.0/GP.systems.profiles.1.1.0.ApplicationProfile.xsd"
    xmlns:gp="http://namespaces.globalplatform.org/systems-profiles/1.1.0"
    UniqueID="ME" ProfileVersion="1.1.0" ErrataVersion="0">
    <gp:Description>Forum Test</gp:Description>
    <gp:DataElement Name="áccent" External="true" Type="ByteString" Encoding="HEX" FixedLength="false" Length="16" ReadWrite="true" Update="true" Optional="true" />
</gp:ApplicationProfile>').getblobval (
             NLS_CHARSET_ID ('utf8'))),
         'utf8')
         x
FROM DUAL
X
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPGdwOkFwcGxp
Y2F0aW9uUHJvZmlsZSB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEv
WE1MU2NoZW1hLWluc3RhbmNlIiB4c2k6c2NoZW1hTG9jYXRpb249Imh0dHA6Ly9u
YW1lc3BhY2VzLmdsb2JhbHBsYXRmb3JtLm9yZy9zeXN0ZW1zLXByb2ZpbGVzLzEu
MS4wIGh0dHA6Ly9uYW1lc3BhY2VzLmdsb2JhbHBsYXRmb3JtLm9yZy9zeXN0ZW1z
LXByb2ZpbGVzLzEuMS4wL0dQLnN5c3RlbXMucHJvZmlsZXMuMS4xLjAuQXBwbGlj
YXRpb25Qcm9maWxlLnhzZCIgeG1sbnM6Z3A9Imh0dHA6Ly9uYW1lc3BhY2VzLmds
b2JhbHBsYXRmb3JtLm9yZy9zeXN0ZW1zLXByb2ZpbGVzLzEuMS4wIiBVbmlxdWVJ
RD0iTUUiIFByb2ZpbGVWZXJzaW9uPSIxLjEuMCIgRXJyYXRhVmVyc2lvbj0iMCI+
CiAgPGdwOkRlc2NyaXB0aW9uPkZvcnVtIFRlc3Q8L2dwOkRlc2NyaXB0aW9uPgog
IDxncDpEYXRhRWxlbWVudCBOYW1lPSLDoWNjZW50IiBFeHRlcm5hbD0idHJ1ZSIg
VHlwZT0iQnl0ZVN0cmluZyIgRW5jb2Rpbmc9IkhFWCIgRml4ZWRMZW5ndGg9ImZh
bHNlIiBMZW5ndGg9IjE2IiBSZWFkV3JpdGU9InRydWUiIFVwZGF0ZT0idHJ1ZSIg
T3B0aW9uYWw9InRydWUiLz4KPC9ncDpBcHBsaWNhdGlvblByb2ZpbGU+Cg==
1 row selected.which encodes and decodes properly on my system even with accented characters.

Problem with My Base64 Encoding CLOB Routine.

I have written a program which reads an xml file into the database
and makes it Base64encoded.
This needs to work on 10g and above
If the read length specified in the code below is greater than the length of the xml_file, then I get the expected result(output).
However if the read length is less than the length of the file, then I get a lot of '==' in the file and as a result, incorrect encoding which means that the file will not be readable through the application.
I'm pretty sure I'm reading the blob lengths correctly, and the problem is somehow related to the base64 encoding.Any help appreciated
[create or replace profile_dir as &profile_dir;
create global temporary table load_xml
(profile_text clob)
on commit delete rows;
create or replace
procedure encode_xml_clobs(p_file_in in varchar2,
                             p_clob_out out nocopy clob )
as
pragma autonomous_transaction;
    dest_clob   CLOB;
    src_clob    BFILE := BFILENAME('PROFILE_DIR', p_file_in);
    dst_offset number := 1 ;
    src_offset number := 1 ;
    lang_ctx    number := DBMS_LOB.DEFAULT_LANG_CTX;
    warning     number;
-- processing declarations for encoding base64 --
v_xml_string varchar2(32767);
v_string varchar2(32767);
v_start_pos number := 0;
v_read_length number := 1000;
v_final_start_pos number;
v_clob_length number;
type clob_array_type is table of clob index by binary_integer;
clob_array clob_array_type;
v_index number :=0;
-- Declarations for converting base64encoded string to a clob
v_encoded_length number;
v_temp_clob clob;
BEGIN
    -- THE FOLLOWING BLOCK OF CODE WILL ATTEMPT TO INSERT / WRITE THE CONTENTS
    -- OF AN XML FILE TO A CLOB COLUMN. IN THIS CASE, WE WILL USE THE NEW
    -- DBMS_LOB.LoadCLOBFromFile() API WHICH *DOES* SUPPORT MULTI-BYTE
    -- CHARACTER SET DATA.
-- load_xml should be a Global temporary table with on commit delete rows
    INSERT INTO load_xml(profile_text)
        VALUES( empty_clob())
        RETURNING profile_text INTO dest_clob;
    -- OPENING THE SOURCE BFILE IS MANDATORY
    DBMS_LOB.OPEN(src_clob, DBMS_LOB.LOB_READONLY);
    DBMS_LOB.LoadCLOBFromFile(
          DEST_LOB     => dest_clob
        , SRC_BFILE    => src_clob
        , AMOUNT       => DBMS_LOB.GETLENGTH(src_clob)
        , DEST_OFFSET => dst_offset
        , SRC_OFFSET   => src_offset
        , BFILE_CSID   => DBMS_LOB.DEFAULT_CSID
        , LANG_CONTEXT => lang_ctx
        , WARNING      => warning
    DBMS_LOB.CLOSE(src_clob);
--    DBMS_OUTPUT.PUT_LINE('Loaded XML File using DBMS_LOB.LoadCLOBFromFile: (ID=1');
-- file now successfully loaded
select dbms_lob.GETLENGTH(profile_text)
into v_clob_length
from load_xml;
-- File now loaded in temporary table
-- we now need to take the clob , convert it to varchar2
v_read_length :=64;
v_xml_string := '';
while v_start_pos <= v_clob_length
loop
v_index := v_index + 1;
v_string := '';
--dbms_output.put_line('Start_pos=>'||(v_start_pos+1)||' Read Length=>'||v_read_length);
--encode base64
select utl_raw.cast_to_varchar2(
utl_encode.base64_encode(
utl_raw.cast_to_raw(dbms_lob.substr(profile_text,least(v_read_length,v_clob_length-v_start_pos),v_start_pos+1))
into v_string
from load_xml;
--dbms_output.put_line(v_string);
v_start_pos := v_start_pos+v_read_length;
clob_array(v_index) := v_string;
end loop;
p_clob_out := clob_array(1);
for i in 2 .. v_index
loop
dbms_lob.append(p_clob_out,clob_array(i));
end loop;
commit;
END;

Base64 encoding encodes every 3 bytes of input data into 4 bytes of output data. It uses equal signs to indicate nodata and only at the end of the encoded sequence. Try chaning your v_read_length parameter to a multiple of 3 e.g. 960 or 1008 instead of the current 1000. I'm using multiples of 48 because the utl_encode.base64_encode function adds a linebreak for every 48 bytes of input data (64 bytes of output). If you use a value that's not divisible by 48 you will still get a legitimate encoding as long as it's divisible by 3, but you will get some lines longer than others when you append them together.

Since Firefox 4, I can get a background image to work using base64 encoded, but not a local file, this worked in Firefox 3, how do I resolve this.

Using either of the 4 examples shown below, to have a background image display inside about:blank worked in Firefox 3.x (using Stylish add-on), however since Firefox 4, only using the base64 encoded version of images works. Is there any way to fix this so I don't have to encode every image I wish to use? Encoding the image makes the stylish file absolutely huge, & a real pain to keep encoding whenever I want to change the image.
body:empty { background: url("resource:/res/images/OnFire.jpg")
body { background-image: url("resource:/res/images/OnFire.jpg")
body:empty { background:url("data:
body { background-image: url("data:
I've also previously disabled most of the add-ons, except for Status-4-Evar, Stylish, & Firebug, in an attempt to see if something else was interfering, but no change.
I can supply a copy of the previously working (FF 3.x) code to some of the about:blank styles if needed for testing purposes.

Type '''about:addons'''<enter> in the address bar to open the '''Add-ons Manager.'''
Hot key; '''<Control>''(Mac:<Command>)'' <Shift> A)'''
On the left side of the page, select '''Plugins.'''
Is it listed here? Select '''Disable.'''

Base64 Encoding in SOA 11.1.1.5.0

Hi All,
For writing a String to a Flat File(Opaque Schema) using FileAdapter the string needs to be converted to Base64 Encoding
I am not able to Encode the string to base64 in BPEL 11g.
JDEVELOPER VERSION.Studio Edition Version 11.1.1.5.0
SOA Suite Version 11.1.1.5.0
I tried with BPEL1.1 specification and BPEL2.0 specification with no luck
Steps carried out
a) Created a variable "input1" with String type
b) Assigned a custom message to input1 variable
c) In Java Embedding activity wrote the below snippet
String input = (String)getVariableData("input1");
addAuditTrailEntry(input);
String encodeData = oracle.soa.common.util.Base64Encoder.encode(input);
addAuditTrailEntry(encodeData);
I am getting different errors while using BPEL 1.1 spec and 2.0 spec
BPEL 1.1 Spec
Jdeveloper doesnt compile.
Error is Error: SCAC-50012
BPEL 2.0 Spec
Jdeveloper compile's but while deploying am getting the below error
Error deploying BPEL suitcase.
error while attempting to deploy the BPEL component file "/dtrb5o/admin/soa_domain/mserver/soa_domain/servers/soa_server1/dc/soa_04c5e5c5-eeb1-49da-841a-c793206a0285";
the exception reported is:java.lang.RuntimeException: failed to compile execlets of BPELProcess1
This error contained an exception thrown by the underlying deployment module.
Verify the exception trace in the log (with logging level set to debug mode).
+[05:40:21 PM] Check server log for more details.+
+[05:40:21 PM] Error deploying archive sca_Base64_2_rev1.0.jar to partition "default" on server soa_server1 [] +
+[05:40:21 PM] #### Deployment incomplete. ####+
+[05:40:21 PM] Error deploying archive file:/C:/JdevHome/Users/c_anishi/mywork/BPELApplication/Base64_2/deploy/sca_Base64_2_rev1.0.jar +
+(oracle.tip.tools.ide.fabric.deploy.common.SOARemoteDeployer)+
The SOA RunTime Library is already added to the project. I even tried explicitly adding fabric-common.jar and fabric-runtime.jar to the project library with no luck
Please let me know if any one has acheived the base64 encoding in 11.1.1.5.0

Check this out,
http://yatanveersingh.blogspot.com/2011/08/how-to-call-java-method-inside-bpel.html
-Yatan

Base64 encoding in SOAP adapter

Hi,
Is it possible to transform outgoing messages to Base64 encoding format in XI using module processors and security encryption? I'm using receiver SOAP adapter (without SOAP header) and using PayloadZipBean module processor to zip the outgoing message. Also I need to add digital signature and base64 encryption to the zipped message. Please let me know how this can be achieved.
Thanks,
Dipankar

hi dipankar
check the below blog
How to use Digital Certificates for Signing & Encrypting Messages in XI
How to use Digital Certificates for Signing & Encrypting Messages in XI
hope this resolves your issue
additionally check this
How to use Client Authentication with SOAP Adapter
How to use Client Authentication with SOAP Adapter
also
How XML Encryption can be done using web services security in SAP NetWeaver XI
How XML Encryption can be done using web services security in SAP NetWeaver XI
reward points if helpfull
regards
kummari
Edited by: kummari on Jul 19, 2008 7:24 AM

Get canvas.toDataURL('image/jpeg') and convert base64 encoding to java.sql.Blob

Convert canvas.toDataURL('image/jpeg') to java.sql.Blob.
I am using oracle adf so I am able to action a backing bean from javascript and pass in parameters as a map. I pass in the canvas.toDataURL('image/jpeg') which I then try to decode in my bean. Using BASE64Decoder and the converting the bytearray to a file I can see the image is corrupted as I can't open the file thus converting the bytearray to blob is also a waste.
Has anyone any ideas on base64 encoding from canvas.toDataURL to file or Blob?

Use Case:
A jsf page that enables a user to take photos using the HTML5 canvas feature - interact with webcam -, take photos and upload to profile
1. I have created the jsf page with the javascript below; this pops up as a dialog and works okay and onclick an upload image, triggers the snapImage javascript function below and sends the imgURL parameter to the serverside managedbean

function snapImage(event){
                var canvas = AdfPage.PAGE.findComponent('canvas');
                AdfCustomEvent.queue(event.getSource(),"getCamImage",{imgURL:canvas.toDataURL('image/jpeg'),true);
                event.cancel();

public void getCamImage(ClientEvent ce){
String url=(String)ce.getAttributes().get("imgURL");
decodeBase64URLToBlob(url);
private BlobDomain decodeBaseB4URLToBlob(String url64){
                BASE64Decoder de=new BASE64Decoder();
                byte[] bytes=de.decode(url64);
                File file=new File("abc.jpg");
                InputStream in = new ByteArrayInputStream(bytes);
                BufferedImage bImageFromConvert = ImageIO.read(in);
                in.close();
                ImageIO.write(bImageFromConvert, "jpg", file);
                return createBlobDomainFromFile(file);
----problem---
Accessing the generated jpeg file shows the image is corrupted, probably missing bytes or encode/decoder issues.and the blob image after uploading to database is saved as a binary stream which ondownload doesnt render as an image or anything i know of.
Is there anyways of achieving the conversion without errors?

Support on 'Base64 encoding in XML gateway Web service SOAP content'

Hi Experts,
IHAC who's requirement is as follows:
They are currently using Web service protocol to send order information from Oracle Applications to their trading partner.
But need to encode the payload in base64 encoding in the SOAP request.
Further details:
=====================================================================
Current SOAP request is,
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:bac="http://backend.ws.gtas.gridnode.com">
<soapenv:Header/>
<soapenv:Body>
<bac:backendImport4>
<bac:username>?</bac:username>
<bac:password>?</bac:password>
<bac:recipient>?</bac:recipient>
<bac:contentFileName>?</bac:contentFileName>
<bac:content>
<EMPLOYEE>
<EMPLOYEE_DATA>
<EMAIL_ADDRESS/>
<EMPLOYEE_ID>81</EMPLOYEE_ID>
<EMPLOYEE_NUM>2</EMPLOYEE_NUM>
<FIRST_NAME/>
<FULL_NAME>Eddi.S,</FULL_NAME>
<LAST_NAME>Eddi.S</LAST_NAME>
<MIDDLE_NAME/>
</EMPLOYEE_DATA>
</EMPLOYEE>
</bac:content>
<bac:docType>?</bac:docType>
</bac:backendImport4>
</soapenv:Body>
</soapenv:Envelope>
Required SOAP request with base64 encoding is:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:bac="http://backend.ws.gtas.gridnode.com">
<soapenv:Header/>
<soapenv:Body>
<bac:backendImport4>
<bac:username>?</bac:username>
<bac:password>?</bac:password>
<bac:recipient>?</bac:recipient>
<bac:contentFileName>?</bac:contentFileName>
<bac:content>
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9J25vJz8+DQo8IURPQ1RZUEUgRU1QTE9ZRUU+DQo8IS0tIE9yYWNsZSBlWHRlbnNpYmxlIE1hcmt1cCBMYW5ndWFnZSBHYXRld2F5IFNlcnZlciAgLS0+DQo8RU1QTE9ZRUU+DQogIDxFTVBMT1lFRV9EQVRBPg0KICAgIDxFTUFJTF9BRERSRVNTLz4NCiAgICA8RU1QTE9ZRUVfSUQ+ODE8L0VNUExPWUVFX0lEPg0KICAgIDxFTVBMT1lFRV9OVU0+MjwvRU1QTE9ZRUVfTlVNPg0KICAgIDxGSVJTVF9OQU1FLz4NCiAgICA8RlVMTF9OQU1FPkVkZGkuUyw8L0ZVTExfTkFNRT4NCiAgICA8TEFTVF9OQU1FPkVkZGkuUzwvTEFTVF9OQU1FPg0KICAgIDxNSURETEVfTkFNRS8+DQogIDwvRU1QTE9ZRUVfREFUQT4NCjwvRU1QTE9ZRUU+DQo=
</bac:content>
<bac:docType>?</bac:docType>
</bac:backendImport4>
</soapenv:Body>
</soapenv:Envelope>
The issue in question is the content within the element <bac:content>.
Base64 encoding of the payload
<EMPLOYEE>
<EMPLOYEE_DATA>
<EMAIL_ADDRESS/>
<EMPLOYEE_ID>81</EMPLOYEE_ID>
<EMPLOYEE_NUM>2</EMPLOYEE_NUM>
<FIRST_NAME/>
<FULL_NAME>Eddi.S,</FULL_NAME>
<LAST_NAME>Eddi.S</LAST_NAME>
<MIDDLE_NAME/>
</EMPLOYEE_DATA>
</EMPLOYEE>
is
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9J25vJz8+DQo8IURPQ1RZUEUgRU1QTE9ZRUU+DQo8IS0tIE9yYWNsZSBlWHRlbnNpYmxlIE1hcmt1cCBMYW5ndWFnZSBHYXRld2F5IFNlcnZlciAgLS0+DQo8RU1QTE9ZRUU+DQogIDxFTVBMT1lFRV9EQVRBPg0KICAgIDxFTUFJTF9BRERSRVNTLz4NCiAgICA8RU1QTE9ZRUVfSUQ+ODE8L0VNUExPWUVFX0lEPg0KICAgIDxFTVBMT1lFRV9OVU0+MjwvRU1QTE9ZRUVfTlVNPg0KICAgIDxGSVJTVF9OQU1FLz4NCiAgICA8RlVMTF9OQU1FPkVkZGkuUyw8L0ZVTExfTkFNRT4NCiAgICA8TEFTVF9OQU1FPkVkZGkuUzwvTEFTVF9OQU1FPg0KICAgIDxNSURETEVfTkFNRS8+DQogIDwvRU1QTE9ZRUVfREFUQT4NCjwvRU1QTE9ZRUU+DQo=
========================================================================
Is there a way in XML gateway to encode the payload automatically to base64 encoding so that it can accommodate the unicode
Is there any way to encode the order information from EBS tables to base64 format in the outbound SOAP request ? Is this supported . If yes, how.?
Does this involve customization. Is it possible to use encoder/decoder provided in sites such as XSL on top of XML : http://gandhimukul.tripod.com/xslt/base64-xslt.html
Basically, They are trying to use XML Gateway to send and receive messages to a Trading Partner via SOAP. The issues is
1. Outbound: The TP web service can only receive xml content that is encoded in base 64 binary format. How do we configure to encode content using base64
2. Inbound: They want to receive messages using the SOAP architecture into XML gateway.
Please let us know if you have any detailed configuration document for this purpose. Please advise and share relevant details.
regards,
Ajith

Hi Gurvinder,
Thanks for looking into this. Just to clarify again.
example XML content:
<?xml version="1.0" encoding="UTF-8" standalone='no'?>
<!DOCTYPE EMPLOYEE>

<EMPLOYEE>
<EMPLOYEE_DATA>
<EMAIL_ADDRESS/>
<EMPLOYEE_ID>81</EMPLOYEE_ID>
<EMPLOYEE_NUM>2</EMPLOYEE_NUM>
<FIRST_NAME/>
<FULL_NAME>Eddi.S,</FULL_NAME>
<LAST_NAME>Eddi.S</LAST_NAME>
<MIDDLE_NAME/>
</EMPLOYEE_DATA>
</EMPLOYEE>
Sample Soap message that needs to be sent to our service provider is as follows
<?xml version="1.0" encoding="UTF-8" ?>
- <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
- <soapenv:Body>
- <ns5:backendImport5 xmlns:ns5="http://backend.ws.gtas.gridnode.com">
<ns5:username>admin</ns5:username>
<ns5:password>admin1</ns5:password>
<ns5:recipient>GT424</ns5:recipient>
<ns5:contentFileName>cabotTest.xml</ns5:contentFileName>
<ns5:content>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9J25vJz8+DQo8IURPQ1RZUEUgRU1QTE9ZRUU+DQo8IS0tIE9yYWNsZSBlWHRlbnNpYmxlIE1hcmt1cCBMYW5ndWFnZSBHYXRld2F5IFNlcnZlciAgLS0+DQo8RU1QTE9ZRUU+DQogIDxFTVBMT1lFRV9EQVRBPg0KICAgIDxFTUFJTF9BRERSRVNTLz4NCiAgICA8RU1QTE9ZRUVfSUQ+ODE8L0VNUExPWUVFX0lEPg0KICAgIDxFTVBMT1lFRV9OVU0+MjwvRU1QTE9ZRUVfTlVNPg0KICAgIDxGSVJTVF9OQU1FLz4NCiAgICA8RlVMTF9OQU1FPkVkZGkuUyw8L0ZVTExfTkFNRT4NCiAgICA8TEFTVF9OQU1FPkVkZGkuUzwvTEFTVF9OQU1FPg0KICAgIDxNSURETEVfTkFNRS8+DQogIDwvRU1QTE9ZRUVfREFUQT4NCjwvRU1QTE9ZRUU+DQo=</ns5:content>
<ns5:docType>3C3RN</ns5:docType>
</ns5:backendImport5>
</soapenv:Body>
</soapenv:Envelope>
. The xml content provided need to be encoded as base 64 encoding. The following is the equivalent of above xml content.
<ns5:content>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9J25vJz8+DQo8IURPQ1RZUEUgRU1QTE9ZRUU+DQo8IS0tIE9yYWNsZSBlWHRlbnNpYmxlIE1hcmt1cCBMYW5ndWFnZSBHYXRld2F5IFNlcnZlciAgLS0+DQo8RU1QTE9ZRUU+DQogIDxFTVBMT1lFRV9EQVRBPg0KICAgIDxFTUFJTF9BRERSRVNTLz4NCiAgICA8RU1QTE9ZRUVfSUQ+ODE8L0VNUExPWUVFX0lEPg0KICAgIDxFTVBMT1lFRV9OVU0+MjwvRU1QTE9ZRUVfTlVNPg0KICAgIDxGSVJTVF9OQU1FLz4NCiAgICA8RlVMTF9OQU1FPkVkZGkuUyw8L0ZVTExfTkFNRT4NCiAgICA8TEFTVF9OQU1FPkVkZGkuUzwvTEFTVF9OQU1FPg0KICAgIDxNSURETEVfTkFNRS8+DQogIDwvRU1QTE9ZRUVfREFUQT4NCjwvRU1QTE9ZRUU+DQo=</ns5:content>
See that the content is encoded using the base64 format.
Please help us to know how we can configure XML gateway to achieve this.
Regards,
Ajith

EEM ::base64::encode unknown to the router...

An error occurs on an XR device :
invalid command name "::base64::encode"
while executing
"::base64::encode [read $fd]"
It seems that b64 encoding is not properly declare by default.
How could I fix that ?

I don't have access to IOS-XR at the moment with which to test, but I'm not sure the same EEM libraries exist in XR that exist in IOS. However, there's nothing to keep you from adding them. At the very least, you can take the tmpsys:/lib/tcl/base64.tcl file from an IOS device, and paste that into your EEM script. You can also use the EEM user library directory on XR. Create a directory on the device to hold your library files (e.g. disk0:/lib). Copy the base64.tcl file to this directory, then configure:
event manager directory user library disk0:/lib
Then you can use the ::base64 namespace in your script.

Yet another Base64 encoder / decoder

Hi, I would like introduce a different Base64 encoding scheme which yields slightly more compact results when encoding international characters.
        This is an implementation of BASE64UTF9 encoder and decoder.
        Common practice converts Java strings to UTF8 before Base64 encoding.
        UTF8 is not so space efficient in representing non-ASCII characters.
        While UTF9 is impractical as raw data in most 8 bit machines, it fits
        well within Base64 streams since 3 symbols can represent 2 UTF9 nonets.
        In this implementation, a modified UTF9 (flipped bit 9) is chosen to
        ensure nonet '0x000' never appear but maybe be inserted if needed.
        This implementation is also coded in such a way that it is possible to
        use Base100 encoding. When run from command line, it will perform a
        test with random strings and display encoding compactness compared to
        to other existing schemes.
public class B64utf9 {
        private static final String look =
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_";
//"\u0010\u0011\u0012\u0013\u0014!\"#$%&'()*+,-./ 0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~";
        private static final int BASE = look.length();
        private static final int SYMB = (int)java.lang.Math.pow(BASE, 1.5) / 2;
        public static String decode(String str) {
                long j = 1, k = 0, q = 0;
                StringBuffer buf = new StringBuffer();
                for(int p = 0; p < str.length(); p++) {
                        k += look.indexOf(str.charAt(p)) * j;
                        for(j *= BASE; j >= SYMB * 2; j /= SYMB * 2) {
                                q = q * SYMB + k % SYMB;
                                if(k % (SYMB * 2) >= SYMB) {
                                        buf.append((char)q);
                                        q = 0;
                                k /= SYMB * 2;
                return buf.toString();
        public static String encode(String str) {
                long j = 1, k = 0;
                StringBuffer buf = new StringBuffer();
                for(int p = 0; p < str.length(); p++) {
                        long r, q = str.charAt(p);
                        for(r = 1; r * SYMB <= q; r *= SYMB);
                        for(; r > 0; r /= SYMB) {
                                k += ((q / r) % SYMB + (r > 1 ? 0 : SYMB)) * j;
                                for(j *= SYMB * 2; j >= BASE; j /= BASE) {
                                        buf.append(look.charAt((int)k % BASE));
                                        k /= BASE;
                if(j > 1) buf.append(look.charAt((int)k));
                return buf.toString();
        public static void main(String arg[]) throws Exception {
                java.util.Random rnd = new java.util.Random();
                for(double q = 1; q < 9; q++) {
                        int x = 0, y = 0, z = 0;
                        int r = (int)java.lang.Math.pow(Character.MAX_VALUE, 1 / q);
                        for(int p = 0; p < 999; p++) {
                                StringBuffer buf = new StringBuffer();
                                while(rnd.nextInt(99) > 0) {
                                        char k = 1;
// varying ASCII density
                                        for(int j = 0; j < q; j++)
                                                k *= rnd.nextInt(r);
                                        buf.append(k);
                                String str = buf.toString();
// regression
                                if(!decode(encode(str)).equals(str))
                                        System.out.println(str);
// count encoded length
                                x += encode(str).length();
                                y += new sun.misc.BASE64Encoder().encode(str.getBytes("utf8")).length();
                                z += new sun.misc.BASE64Encoder().encode(str.getBytes("gb18030")).length();
                        System.out.println(x +","+ y +","+ z);
}{code}

Good idea! Sometimes it depends on what you want to encode too, however.
I suppose there is a case where general purpose compression does not work very well - random generated data.
Here's how I tested it:
class Count {
        private static String enc(String src, String set) throws Exception {
                return new String(src.getBytes(set), "iso-8859-1");
        private static byte[] dec(byte[] src, String set) throws Exception {
                return new String(src, set).getBytes("iso-8859-1");
        public static void main(String[] arg) throws Exception {
                java.util.Random rnd = new java.util.Random();
                int x = 0, y = 0;
                for(int k = 0; k < 99; k++) {
                        byte[] raw = new byte[rnd.nextInt(99)];
                        for(int z = 0; z < raw.length; z++)
                                raw[z] = (byte)(rnd.nextInt(256));
                        String str = new String(raw, "utf16");
                        byte[] b6u = str.getBytes("x-base64utf9");
                        byte[] gz2 = enc(enc(str, "utf8"), "x-gzip").getBytes("x-base64");
                        x += b6u.length;
                        y += gz2.length;
                        if(!str.equals(new String(b6u, "x-base64utf9")))
                                System.out.println(str);
                        if(!str.equals(new String(dec(dec(gz2, "x-base64"), "x-gzip"), "utf8")))
                                System.out.println(str);
                System.out.println(x +","+ y);
}The above code does not include my my encoders, I put my encoders code as nio.charset package and can be downloaded from [SF.|http://sourceforge.net/project/showfiles.php?group_id=248737]
PS: sorry about the confusion, please allow me to clarify that the UTF9 encoder is not interchangeable with existing Base64 encoders. There is a compatible (hopefully) encoder in my package, however.

Base64 Encoding Problem

I have a String representation of an hexadecimal number such
that :
var s:String = "5300ca"; // 0x53, 0x00, 0xca
I want to cut this string into 3 bytes (0x53, 0x00, 0xca) to
use base64 encoding (3 x 8 bits returns 4 characters with base64
encoding). Here is my code :
import mx.utils.*;
import flash.utils.*;
var byte1:int = parseInt("0x53");
var byte2:int = parseInt("0x00");
var byte3:int = parseInt("0xca");
var b:ByteArray = new ByteArray();
b.writeMultiByte(String.fromCharCode(byte1) +
String.fromCharCode(byte2) + String.fromCharCode(byte3), "utf-16");
var base64Encoder:Base64Encoder = new Base64Encoder();
base64Encoder.encodeBytes(b);
var result:String = base64Encoder.drain(); // result = "Uw=="
The result string is "Uw==" whereas it should be "UwDK"
according to the normalized base64-encoding !
Is it a bug in the base-64 encoding ?

Very important because this limitation is very blocking
according to me. Nobody has an answer ?

Base64 encoded attachments misunderstood by recipients

Similar Messages

Maybe you are looking for