Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-12151

Lotus Notes email client doesn't understand HTML numeric entities

XMLWordPrintable

    • 11
    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      In JIRA's HTML emails, all characters between 128 and 255 (that is, all non-ASCII) are escaped as numeric entities (eg. ä for ä). This is normally no problem - character entities were specified in HTML 4 over 10 years ago - except that at least one version of Lotus Notes (7.0.2) does not understand them, rendering the '&' as '?':

        1. charfix.diff
          0.7 kB
        2. charfix_jira37.jar
          1 kB
        3. templatefix.diff
          1 kB
        4. summary-topleft.vm
          10 kB
        5. notes_brokenchars.png
          notes_brokenchars.png
          339 kB
        6. summary-topleft.vm.JIRA_3.11
          12 kB
        7. DefaultTextRenderer.java
          14 kB
        8. DefaultTextRenderer.java
          14 kB
        9. Email.java
          14 kB
        10. Email.java
          19 kB

            [JRASERVER-12151] Lotus Notes email client doesn't understand HTML numeric entities

            Stefan Hansel added a comment -

            sorry, I misunderstood your latest comment then. I'll watch and wait (actually for Confluence, not for JIRA).

            Stefan Hansel added a comment - sorry, I misunderstood your latest comment then. I'll watch and wait (actually for Confluence, not for JIRA).

            Mark Lassau (Inactive) added a comment -

            So why do you keep escaping with hex-values instead of decimal-values ?

            The next version of JIRA (v4.1.2) will NOT escape with hex-values.
            It will not escape with decimal-values either - it will simply pass characters 128-255 unescaped.

            If you are worried about the proposed solution, I can send you some test emails to confirm the fix works for you.

            Mark Lassau (Inactive) added a comment - So why do you keep escaping with hex-values instead of decimal-values ? The next version of JIRA (v4.1.2) will NOT escape with hex-values. It will not escape with decimal-values either - it will simply pass characters 128-255 unescaped. If you are worried about the proposed solution, I can send you some test emails to confirm the fix works for you.

            Stefan Hansel added a comment -

            I'm a bit disappointed for your E-Mail solution: "This is normally no problem"

            Actually entities like 

            ä

            ARE a problem in Lotus Notes email clients (which this bug-report is about).

            As written in http://jira.atlassian.com/browse/CONF-16221 Lotus notes would be able to
            render 

            ã

            correctly !

            So why do you keep escaping with hex-values instead of decimal-values ?

            Stefan Hansel added a comment - I'm a bit disappointed for your E-Mail solution: "This is normally no problem" Actually entities like ä ARE a problem in Lotus Notes email clients (which this bug-report is about). As written in http://jira.atlassian.com/browse/CONF-16221 Lotus notes would be able to render ã correctly ! So why do you keep escaping with hex-values instead of decimal-values ?

            Mark Lassau (Inactive) added a comment -

            Turned off the encoding of characters 128-255 in the TextUtils.htmlEncode(String) method.

            This was unnecessary because:
            1) The page is encoded in UTF-8

                <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

            2) This encoding was only ever applied to select parts of any given HTML page.
            If you look at the HTML source code of this very "View Issue" page right now (on v4.1.1) you can see that the Description does not include this encoding:

            <p>In JIRA's HTML emails, all characters between 128 and 255 (that is, all non-ASCII) are escaped as numeric entities (eg. &amp;#xE4; for ä). This is normally no problem ...

            The ä is included here verbatim, and not encoded as &#xE4;

            Mark Lassau (Inactive) added a comment - Turned off the encoding of characters 128-255 in the TextUtils.htmlEncode(String) method. This was unnecessary because: 1) The page is encoded in UTF-8 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> 2) This encoding was only ever applied to select parts of any given HTML page. If you look at the HTML source code of this very "View Issue" page right now (on v4.1.1) you can see that the Description does not include this encoding: <p>In JIRA's HTML emails, all characters between 128 and 255 (that is, all non-ASCII) are escaped as numeric entities (eg. &amp;#xE4; for ä). This is normally no problem ... The ä is included here verbatim, and not encoded as &#xE4;

            Mark Lassau (Inactive) added a comment -

            We are exploring changing the behaviour of OSCore TextUtils.htmlencode to not escape characters 128-255.
            This seems to no longer be useful now that we expect to use Unicode encoding on HTML pages.

            Mark Lassau (Inactive) added a comment - We are exploring changing the behaviour of OSCore TextUtils.htmlencode to not escape characters 128-255. This seems to no longer be useful now that we expect to use Unicode encoding on HTML pages.

            Stefan Hansel added a comment - - edited

            Just some sidenotes, as we currently face the same with confluence mails (CONF-16221).

            Lotus Notes (v8) does understand HTML entities, but they need to be written in decimal instead of hexadecimal (see CONF-16221) for an example.
            Also <br /> is understood. Please note the whitespace! <br/> withouth whitespace is invalid (X)HTML and thus not recognized by lotus notes.

            A common solution using escaped Unicode and <br /> without breaking anything should be easily possible.

            Stefan Hansel added a comment - - edited Just some sidenotes, as we currently face the same with confluence mails ( CONF-16221 ). Lotus Notes (v8) does understand HTML entities, but they need to be written in decimal instead of hexadecimal (see CONF-16221 ) for an example. Also <br /> is understood. Please note the whitespace! <br/> withouth whitespace is invalid (X)HTML and thus not recognized by lotus notes. A common solution using escaped Unicode and <br /> without breaking anything should be easily possible.

            Maria Maria added a comment -

            Thank you arno.

            Maria Maria added a comment - Thank you arno.

            aschuma added a comment -

            The patch for 3.13.2 should also work for jira 3.13.1.

            aschuma added a comment - The patch for 3.13.2 should also work for jira 3.13.1.

            Maria Maria added a comment -

            Hi,
            We are having the same issue with lotus notes, is there a patch available for 3.13.1?
            Thanks
            MeM

            Maria Maria added a comment - Hi, We are having the same issue with lotus notes, is there a patch available for 3.13.1? Thanks MeM

            Karoui, Kais added a comment -

            Hi,
            Thank you for this patch,
            Yet one question...is this patch appliable to the standalone version of JIRA 3.13.1 ?
            Regards,
            Kais

            Karoui, Kais added a comment - Hi, Thank you for this patch, Yet one question...is this patch appliable to the standalone version of JIRA 3.13.1 ? Regards, Kais

              mlassau Mark Lassau (Inactive)
              7ee5c68a815f Jeff Turner
              Votes:
              9 Vote for this issue
              Watchers:
              11 Start watching this issue

                Created:
                Updated:
                Resolved: