Accented characters in exported images getting munged

Lightroom 2.x, OS X 10.5.6, G5, Nikon D80, Raw/NEF/DNG
I'm trying to sort out a problem I'm having that looks similar to other issues with international characters, but is a little different. My problem is specific to keywords.
I don't think this should matter, but I generally import as DNG and never save metadata to XMP. I mainly export to JPEG (to a folder that I zip up) in order to upload photos (outside of Lr) to a sharing site.
What I'm finding is that if I tag my photos (in Lr) with keywords that have accented characters (which I use a fair amount because I often travel to Francophone areas to take photos, and my IPTC data and keywords use correct French spelling) upon upload to any photosharing site I try, the keywords will be munged, duplicated and/or generally messed up. For example, I have a keyword "café". Upon export I can see this correctly in the IPTC Keyword metadata (via a third party EXIF/IPTC viewer, and also using "Get Info" in the Finder). However, as soon as I upload this JPEG to any photo sharing site the photo will end up with a series of keywords applied to it: "caf, cafe, cafã©"
Similarly, a keyword like "naïve" will end up as two keywords: "naã¯ve, nave" I get similar results with HTTP uploaders as well as uploader plugins inside Lr. And so on for è, ô &etc. In the case of Flickr, there will be one "copy" of the keyword that is correct. The others will still be present.
I've read hints that suggest that the IPTC metadata stored in the exported file by Lr might not be Unicode-clean, which causes anything that parses and normalizes select metadata (as all online sharing sites will want to do) to choke. I've heard rumours that the XMP data is properly Unicode clean, but most sharing sites ignore that data, since they are pretty much interested only in EXIF or IPTC metadata (and rightly so, I suppose.)
Is this a defect in the way Lr creates metadata in exported images? Or is is a problem with the way all these sites suck in and normalize the metadata stored in the image? Or is it a subtle interaction between the two that results in incompatibilities?
I haven't tried experimenting with creating or finding a JPEG with no keywords at all and manually inserting IPTC keywords with accents, just to see what Flickr (et al) do upon upload. I've also tried various permutations of the keyword options in the Lr export dialogue with no significant change in behaviour.
I'm interested in who else might be seeing this problem. Is it a Lr only thing, or is it Lr-on-Mac? Or something specific to the two sites I upload photos to?
I should point out that I've been seeing this behaviour since Lr 1.x.

(Jao, AdobeRGB is an experiment. I have a colour managed browser, so I wanted to see if I could tell the difference. This is a test photo from my junk pile.)
I think I see the problem. With something like ExifTool you can see that the keywords are stored in a number of places in the EXIF/IPTC header: Keywords, Subject and Hierarchical Subject. It is the Keywords section that is not Unicode clean, apparently. This is even more apparent if you show the output encoded in HTML entities:
Keywords : Franais, Test Shots, Wings of Paradise Butterfly Conservatory, butterfly, cafŽ, l'h™tel, na•ve, tests
Subject : Français, Test Shots, Wings of Paradise Butterfly Conservatory, butterfly, café, l'hôtel, naïve, tests
Hierarchical Subject : Français, Test Shots|tests, Wings of Paradise Butterfly Conservatory, butterfly, café, l'hôtel, naïve
So, it depends on what section the keywords are taken from. It appears that both Flickr and 23 will try to find the keywords in as many places as possible. This explains the many duplicates I am seeing.
So, now I just have to figure out why Subject is so wrong, and how to correct it (or leave it blank.)

Similar Messages

  • Accent Characters

    Hi,
    I am having a hard time getting accent characters to work in a web app that is running on solaris 10 (T1000s and M2200s). When I run the same app on an OS X server, accent characters from web forms display correctly. Are forms are using ISO-8859-1 and the solaris server reports that the character set it is using is ISO-8859-1. Accent characters (such as �) still get displayed as "?" however.
    Anybody know the trick to get solaris to work with accent chars? Our locale settings are:
    LANG=
    LC_CTYPE=iso_8859_1
    LC_NUMERIC="C"
    LC_TIME="C"
    LC_COLLATE="C"
    LC_MONETARY="C"
    LC_MESSAGES="C"
    LC_ALL=

    Hi Jason,
    Thank you for your reply.
    We currently use the supplied default Collation "1252LATIN1" and the Character Set "cp1252" for Language "us_english". This Character Set has all the characters we need.
    Doesn't the supplied ASA Collation '1252LATIN1' meet the requirement you have mentioned.
    Also isn't this Collation recommended for Western European Languages (like English, French, German, & Spanish) as it provides the most likely match to the Character Set 'cp1252'.
    Is there a specific Collation you'd want me to try during database creation.
    Thanks for all your input.
    Tejo

  • I am using Lightroom 5.7, 64 bit with Windows 7 Professional. For no apparent reason, I now get an error message when I export a photo, say a raw image to a JPG. However, the exported image seems to be OK. But now I notice that my LR directory of folders

    I am using Lightroom 5.7, 64 bit with Windows 7 Professional. For no apparent reason, I now get an error message when I export a photo, say a raw image to a JPG. However, the exported image seems to be OK. But now I notice that my LR directory of folders in Library view does not show images correctly: If there is a folder with sub-folder(s), the folder will indicate 0 images, but the sub-folders show the proper number of images. What happened and is there a fix? I tried uninstalling Lightroom and re-installing, but problem persists.
    Here is a screen shot of the error message:
    Message was edited by: Joseph Costanza, Jr.

    See here for a solution.

  • I use Adobe lightroom to export images to Facebook - I am now getting error message related to this process address not understood- how to correct?

    I am using Win & Home edition / Mozilla Firefox on my HP laptop. On Oct 8 I used Lightroom to export images to Facebook. Now when I try to repeat this, authentication fails as The address wasn't understood
    Firefox doesn't know how to open this address, because one of the following protocols (lightroom) isn't associated with any program or is not allowed in this context.
    The export process was working, but isn't now. I have ben having problems with Firefox - I wasn't able to retain the settings for opening with my own Homepage (kept going back to Firefox default. So I have done a reset. Seems that this has somehow disrupted the authentication process. Can you help please.

    I just dropped into the forums to see if other people were getting the DVD burning verification error (Error code 0x80020063). I've been holding off on the Tiger to Leopard upgrade until very recently. All of my must-have apps were anecdotally stable and I was under the impression that 10.5 was too. Apparently reliable DVD burning is Tiger only, at least on my systems.
    We've been burning Taiyo Yuden DVD's almost daily with Tiger with incredibly low failure rates. After what seemed to be a smooth upgrade of a Mac Pro tower & 2 MacBook Pro laptops (one is a Core Duo and the other is a Core 2 Duo) I've spent the entire afternoon troubleshooting until I ended up here. Some searching on the board leads me to conclude that this will be a bigger headache than I imagined.
    I've done all the obvious stuff (varied the burn speed, moved the files to a different drive, reset PRAM & SMC, used a different account, deleted finder.plist, tried repairing the system with DU on the Leopard install disc and then I tried burning on different computers with different media). What I'm finding is that over 50% of my DVD's are throwing the error code during verification across 3 different models all running Leopard 10.5.2. CD burning seems to work as before (but we don't use this as much so ?). I saw that some people had posted that closing the finder window helped, but that didn't improve my overall failure rate. The DVD's appear (indentical byte size and item numbers) to be burned correctly and usable, but I need to be sure so I can't trust them.
    We need reliable DVD burning for our business and this is a real problem. I was going to trudge over to the Apple store, but it doesn't sound like there's a real fix yet.

  • Exporting accented characters (Unicode) in metadata

    Hi,
    I wrote a little script to export the metadata to an xml file. I am having some problems where the tags contain accented characters (áéö etc.).
    I managed to write the xml file with unicode encoding and the unicode characters contained in the script are transferred correctly.
    However the special characters in the metadata tags are being transformed to some unreadable characters.
    Is there any way to make sure these characters are transferred correctly?
    Thank you
    Balint

    David,
    Thank you for the help.
    I tried setting the output file encoding to UTF-8 or UTF-16, with or without setting the BOM. The accented characters still come out unreadable. I tried the examples that came with the SDK (output set to the console) and they too scramble the accented characters.
    In other cases, where using the iterator function, the fields that contain accented characters are completely ignored.
    Finally i found the .rawData function in Photoshop that could export the accented characters. This is a much slower solution, because Photoshop has to open all the files to read the metadata.
    I also experimented with my own XML files in Bridge. I can open these, do my transformations, save them and all the characters are well preserved.
    Balint

  • Accented characters do not display correctly if there is a variable beside it

    Hello,
    We are experiencing a problem when we have text with accented characters an a variable beside it within the same text box.
    The problem is that the accented characters in the text do not display correctly in the preview or publised course to Flash9
    These characters display correctly in Captivate in edit mode.
    This is the process we have followed:
    Export to XML
    Translated
    Import XML
    Publish to Flash9
    Captivate version:  4
    OS: Windows Vista SP2
    We have tried to work with locale in Spanish with no luck, the only solution we have found is to put the text and the variable in different text boxes
    I have pasted an image of the preview and also of the text in Captivate edit mode.
    Any help will be very welcomed !
    Tess

    Hi there
    I agree with Lilybiri that you should definitely file a Bug Report.
    However, a thought occurs here. Have you tried placing the accented text in a User Defined variable?
    Assuming this is a workaround, my thought is that you could then just have a caption with two variables. The User Defined variable containing the accented text followed immediately by the system variable providing the Project Name.
    Cheers... Rick
    Helpful and Handy Links
    Captivate Wish Form/Bug Reporting Form
    Adobe Certified Captivate Training
    SorcerStone Blog
    Captivate eBooks

  • How do I stop Indesign from changing letters to accented characters

    When working in Indesign letters are randomly changed to accented characters. The only way to remove them once this happened is to save the job, close it and then reopen it.
    Any help would be appreciated.

    Hi Willi
    Thank you for your repsonse and sorry I did not get back to you sooner.
    See the screenshots below
    Note the tilde on top of the N
    In the following images, fi turns into fl and retail turns into RetaiO(cap O with a tilde accent).
    Let me know if you need more information.
    Regards,
    Johan

  • Critical issue with exporting images in iPhoto 08?

    I have been exporting selected photos to a thumb drive under iPhoto 06. I then take the thumb drive and put it in a pioneer palsma and go to GALLERY mode. Works fantastic and I can then review the images with my clients. Never had a problem with iPhoto 06. I upgraded to iPhoto 08 recently and export selected photos to the thumbdrive under the new upgrade. When I go to Gallery mode on the plasma the photos do not come up and it hangs up the plasma..... ??? Seems to be a problem somewhere with what "08" does with the photos? I ran a number of different test with two different thumb drives using photos from iPhoto 08 and cannot get them to work. I go back to an old iMac that was not upgraded to iPhoto 08 and both thumb drives they work fine on the plasma. In fact it is almost impossible to mess the operation up with "06". I have tried to export the photos in "08" in all the various size options and still no success. I would appreciate any help to this critical problem I am facing since I use this function of showing my images on a plasma on a daily basis . After about 10 to 12 hours of working htis problem I am totally loss as what to do. Thanks for your time.

    Thanks for your reply.
    1. I select the photos from iPhoto - varied between 5 and 20 (ran different test)
    2. Click on FILE
    3. Select EXPORT
    4. Under the FILE EXPORT tab I have tried all the various options with no success
    5. KIND - I make sure they are JPEG files - I have tried the Original also which is actually JPEG files
    6. JPEG QUALITY - I have tried all 4 options from LOW to MAX
    7. SIZE - I tried all 4 size options from SMALL to FULL
    8. FILE NAME - I use filename
    9. Select EXPORT tab
    10. I export to the thumbdrive and I chcek and they are on the thumbdrive
    11. I also tried to EXPORT to the desktop and copy them to the thumbdrive
    I click on the photos on the exported images I placed on the thumb drive and they come up fine on PREVIEW on my MAC. No prroblem with the images until I try to use them on the plasma. I go back and use images from iPhoto 06 that I did not call up with the "08" program and they work fine.
    Hope that explains what I do. Thanks again

  • Image in Lightroom doesn't match exported image viewed in Photoshop

    After all my hard work in Lightroom, I export the image to a folder on my hard drive. When I open this exported image in Photoshop and view it alongside the Lightroom version of its "twin" in Lightroom, there is a significant difference. Why is this? I want to use these images in my books, but my time is wasted if I end up with anything other than what I created in Lightroom. Shouldn't these images match exactly?

    Thanks Jao and Michael...the color management idea makes a lot of sense.
    Adding to this idea, when I open the Pshop file I get a message about the doc having an embedded profile that doesn't match current RGB working space, and the usual 3 options: Use the embedded profile, Convert color to the working space, or discard embedded profile. No matter which option I choose, none of the opened docs match the Lightroom version.
    The color balance is fine, but the colors aren't as vibrant. The Pshop photo is dull and lifeless compared to the Lightroom version. I used Clarity which added subtle brightness, and Vibrance to crank up the color in LR which added wonderful dimensionality and punch to the landscape scene, but the Pshop version has dulled these back down.

  • Why are most of my keywords not included when I export images?

    Why are most of my keywords not included when I export images?
    Since starting with Lightroom 1, I've entered keywords into either of the two fields between "keyword tags" and "keyword suggestions" in the keywording panel.  I was unaware that some keywords are more equal than others, or that Lightroom offered (or has added?) hierarchy support.
    I recently stumbled into the news (to me) that Lightroom tags can be organized into a hierarchy, so I exported my keywords to a text file to examine.  I hadn't unwittingly created any hierarchies, but an astounding fraction of the keywords were within square brackets.  Sure enough, if I export an image, keywords within square brackets are omitted from the output (jpeg) file.  How nice.  Since I began with Lightroom 1, I've added nearly 1600 keywords.. Too bad most of them are coded wrong... so as not to accompany output that I create.
    1.     What was I supposed to do, as a photographer beginning to use Lightroom, to enter keywords simply but reliably:  what I type is what I get? I'd expected that's what the "just type here" interface would provide.
    I especially dislike obtaining erratic results:  most keywords are in square brackets, but a few are not.  Of course, when I use a simplified interface, I should expect not to have access to some of the options or features.  However, I shouldn't inadvertently trigger undocumented behavior.
    2.     Does the Adobe reference help system say how to enter keywords simply and reliably, in its documentation of the keywording panel? I don't find my answer under the Keywords topic, within Home / Using Photoshop Lightroom 3 / Organizing photos in the catalog.
    (I NOW realize that the instructions for the "Create/Edit keyword tags" dialog mention exporting. However, that's not the method I was using.)
    Dick Rawson

    I'm afraid that I distracted you with my background mention of hierarcharial keywords; I'm not asking about them.
    I've entered keywords for several years of using Lightroom.  Suddenly, this week, I find that most (yet not all) of them have the attribute of "don't include the keyword in an exported file's metadata."  I never intended to ask for that; I thought all keywords will stay with the file and its offspring, and that's what I wanted.
    So I'm asking:
    1.     What did I do "wrong" to induce Lightroom to give the keywords that attribute? I never intended to ask it to.
    2.     Where does Adobe document how to enter keywords reliably so that they stay with the file on output?  I can't find that Adobe does.
    > Can you be more clear about keywords in square brackets? I know when you export the keywords as a list you can get a normalized data file that uses punctuation and tabs as delimiters...
    I did export the keywords into such a list:  most keywords in the plain-text list have square brackets surrounding them, indicating keywords that will be omitted from metadata of any image that Lightroom exports.
    My concern is not that the brackets are there.  They encode the attribute of "don't include the keyword in an exported file's metadata," and recognizing that attribute concerns me.
    > ...but I've never seen keywords in image files or in the interface rendered so.
    I haven't, either.
    Dick Rawson

  • When I convert a file from PDF to word it is all in characters how do I get it in english text

    Please could someone help me with a converted file. I have bought the adobe acrobat and tried to convert my PDF to word and it just comes up with characters how to I get it in normal text?

    Hello,
    because you wrote in the Reader forum, so I think we talk about it, or? In my case I can change the text there (screenshot of my German AR):
    I hope the image is selfexplanatory and I understood you in the reight way. If not please come back to set right.
    Hans-Günter

  • 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.

  • Accented characters showing up as ? in JRE1.3 but ok in 1.2

    I'm implementing a database web interface product that utilizes JSPs (on SunOS 5.7).
    The problem is in the search form. When using accented characters (French language), the JSP calls on URLEncode, but all accented characters show up as '?'.
    However, when editing a record, using accented characters is not a problem (i.e., the accented characters are properly stored in the fields).
    Back on the server, I ran a small program to output accented characters and also to call java.net.URLEncoder to convert the characters.
    The default JDK is J2SE (1.3.1). Compiliing and running the program results in question marks.
    Using JDK 1.2, the accented characters show up fine.
    It would appear that URLEncoder is not at fault, but instead, JDK 1.3.1 doesn't seem to handle the accented characters.
    I figure there must be a setting somewhere, but I'm not sure where.
    Here's the program I used (written in Win98, using standard Win-based character set and Unicode format \u00xx; in Unix, "more" displays the Win accented characters fine but "vi" displays them as \xxx; compiles and displays perfectly when using JDK 1.2):
    import java.net.*;
    class mine {
    public static void main(String args[]) {
    System.out.println("�����������") ;
    System.out.println(URLEncoder.encode("�����������")) ;
    System.out.println("\u00e0\u00e2\u00e4");
    System.out.println("\351");
    System.out.println("\351\347\356\364\373\340\350\342\344\374\357") ;
    The output with JDK 1.2 is:
    �����������
    %E9%E7%EE%F4%FB%E0%E8%E2%E4%FC%EF
    ���
    The output with JDK 1.3.1 is:
    %3F%3F%3F%3F%3F%3F%3F%3F%3F%3F%3F

    Between jdk1.2 and jdk 1.3 the default encoding of the vm changed.
    You can get it by executing:
    System.out.println("Default Encoding:" + System.getProperty("file.encoding"));
    or
    System.out.println("Default Encoding:" + (new java.io.InputStreamReader(System.in)).getEncoding());
    The default encoding is used during the conversion of bytes to strings and vice verca.
    Assume your default encoding is ISO8859_1. Then calling new String(byte[]) is equivalent to calling
    new String(byte[], "ISO8859_1")
    Now if you are converting a character from one encoding scheme to another and there is no mapping
    for this character in the target scheme. Then the character will be replaced by a default character
    which is (quite often) the question mark.
    You can set the default encoding for a vm by passing it as a command line parameter
    java -Dfile.encoding=ISO8859_1
    java -Dfile.encoding=Cp1252

  • Problems with input accented characters after moving JInitiator to JDK 1.5

    After upgrading from JInitiator 1.3.1.18 to JDK 1.5.0_06 (jdk plugin in IE), the input of accented characters (in our case portuguese) isn't working anymore in text areas on the forms (Forms 10g).
    So, if you push first the "´" key and then the "a" key, you should get as result "á" (worked correctly with JInitiator), but after upgrading to JDK 1.5 you will get simply a letter "a".
    Pressing Alt + 160 shows correctly "á".
    Somebody can give a clue about this problem please?
    Downgrading again to JInitiator is no option for us, as we need a more modern JVM (for a Dicom viewer applet we developed), and IE crashes if you have an Oracle form running with JInitiator, and then try to open another IE page with an applet requesting JVM 1.5 ...
    Thanks a lot for your comments.
    Alberto A.Smulders
    HostDat Lda. - Portugal

    In IE, the server must be in the Trusted Sites list & the security for Trusted Sites set to low
    Tools -> Internet Options
    Security Tab
    Sites button
    Add all Forms servers, or use a wildcard to get your entire domain. If you are not using SSL, uncheck the "Require server verification (https:) for all sites in this zone"
    Set the Security Level for this zone to Low. If the slider bar is not there, click the Default Level button, then slide the security setting to low.

  • Colour Profiles on exported images causing major problems

    I've been exporting keynote slides as png's to use in video presentations. The problem is that the png's are saved with colour profiles, which means if I export the images from diferent macs, or even the same mac but with a different monitor attached (therefore a diferent monitor colour profile active), the images have very noticeable colour variations.
    This is a major problem. I exported 1,000 slide transitions to import into Adobe Premiere, then about 500 slide updates that when imported, were in some cases darker or lighter even though I was using the same keynote and original images. I had to create a batch job in Photoshop to open, ignore the stored profile and save the images using a new default colour profile to try and get all the images consistent.
    There needs to be an option in either the Keynote preferences or export options to save exported images without colour profiles.

    There needs to be an option in either the Keynote preferences or export options to save exported images without colour profiles.
    No, there needs to be documentation on the ICC architecture and how ICC profiles are applied. Stripping out embedded ICC profiles will colour manage the objects (images) in the system, but when the images pass outside the system they will not be colour managed any more. In this scenario, either they will have to be rendered as deviceColor by the numbers, without a definition of the colours their colourants should form, or a source ICC profile will have to be assigned by the following system/application.
    I've been exporting keynote slides as png's to use in video presentations. The problem is that the png's are saved with colour profiles, which means if I export the images from diferent macs, or even the same mac but with a different monitor attached (therefore a diferent monitor colour profile active), the images have very noticeable colour variations.
    I could be considered an unconditional bug in Keynote if it embedded the current monitor profile and not the system RGB colour working space profile (: Generic RGB Profile). If indeed Keynote embeds the current monitor profile, it could be considered an unconditional bug in your understanding if you start by stripping the source profiles. You should be doing a profile to profile conversion in order to get into the RGB colour working space you want in Photoshop.
    Sorry, but it helps to have a basic understanding of media independent colour matching (even if the developers don't sometimes -:)).
    /hh

Maybe you are looking for