in reply to Character encoding in emails

To try and replicate the issue away from the full production scripts, I've written a test with the sending code copied directly from the production code. A few variables have changed names and a couple of other tweaks to make it run but the sending code is as faithful to production as I can get it. The sending mechanism is extremely similar, so it's unlikely to be that. The sending method is toggled in the code below by setting $METHOD true or false.

Method true stores the message in a database table. The data types and DB engine are the same as the production DB. There's a bit of substitution and then it's sent.

Method false bypasses storing and retrieving from the database. It does a similar substitution and sends.

Running the script in a web environment sends email, in both cases, without the emojis being properly reproduced. So, I set up CRON to run the script...again, both methods produce emails with corrupted emojis.

It appears that it's not the DB that's affecting it, and it's not the CRON vs web environment that's affecting it...

I'm finding this really tricky to debug as I cannot think of a way of inspecting what is happening between the data being passed to MIME::Lite and it appearing in my email client.

#!/usr/bin/perl

use CGI::Carp qw(fatalsToBrowser);

use strict;
use warnings;

use lib "/home/..../..../public_test/cgi-bin";

# Toggle sending method
my $METHOD = 0;

use MIME::Lite;
use incl::HTML;

if ($ENV{'GATEWAY_INTERFACE'}) {
    print "Content-type: text/plain\n\n" ;
}

$/ = undef;
my $subject = 'Testing email';
my $message = <DATA>;

my $fname   = 'Andrew';
my $sname   = 'Test';
my $tomail  = 'ian@l******t.co.uk';

if ($METHOD) {
    
    $dbh->do("CREATE TEMPORARY TABLE Email_Test (
            `from` VARCHAR(100) NULL DEFAULT NULL,
            `email` VARCHAR(100) NULL DEFAULT NULL,
            `subject` VARCHAR(100) NULL DEFAULT NULL,
            `message` BLOB NULL DEFAULT NULL
        ) ENGINE = MyISAM");
        
    $dbh->do("INSERT INTO Email_Test SET `from` = 'Bod', email = 'ian\
+@boddison.com', subject = ?, message = ?",
            undef, $subject, $message);
            
    my ($from, $email, $subject, $message) = $dbh->selectrow_array("SE
+LECT `from`, email, subject, message FROM Email_Test LIMIT 1");
        
    $subject    =~ s/%FNAME%/$fname/g;  # There are
    $subject    =~ s/%SNAME%/$sname/g;  # more of
    $message    =~ s/%FNAME%/$fname/g;  # these in
    $message    =~ s/%SNAME%/$sname/g;  # production

    my $mail = MIME::Lite->new(
        To      => "\"$fname\" <$tomail>",
        From    => "\"$from\" <$email>",
        Subject => "$subject",
        Type    => 'text/html',
        Data    => $message,
    );
    my $check = $mail->send;
    print "Failed to send to $fname $sname ($tomail)\n" unless ($check
+);
    
} else {
    
    my $name  = "$fname $sname";

    $subject=~s/%FNAME%/$fname/g;
    $subject=~s/%SNAME%/$sname/g;
    $message=~s/%FNAME%/$fname/g;
    $message=~s/%SNAME%/$sname/g;
    
    my $mime = MIME::Lite->new(
       From     => "\"Ian Boddison\"<ian\@boddison.com>",
       To       => "\"$name\"<$tomail>",
       Subject  => $subject,
#      Type     => 'multipart/alternative',
#  );
#  $mime->attach(
#      Type     => 'text/plain',
#      Data     => $data{'plaintext'},
#  );
#  $mime->attach(
       Type     => 'text/html',
       Data     => $message,
   );
   my $chk;
   eval { $chk = $mime->send() };

   if ($@) {
       print "Error - $@\n";
   }
}

print "\nComplete...\n";

__DATA__
<html>
<body>
<p>&#129345; <b>Introducing On&nbsp;Radar&nbsp;&#8209;&nbsp;where quir
+k meets&nbsp;impact!</b>&nbsp;&#128640;</p>
</body>
</html>

[download]

Replies are listed 'Best First'.
Re: Test code (was: Re: Character encoding in emails)
by afoken (Chancellor) on Dec 09, 2023 at 10:41 UTC

    You use $dbh without ever defining or initializing it. So that code can't compile, unless incl::HTML exports $dbh. I can't find incl::HTML on cpan, so this example is not self-contained.

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]

      Sorry - you are correct, of course...
      incl::HTML is an internal module that does some of the standard initialisation, including making a connection to the appropriate DB schema and setting $dbh as the DBI database handle.

[reply]
[d/l]
[select]
Re: Test code (was: Re: Character encoding in emails)
by NERDVANA (Priest) on Dec 09, 2023 at 10:53 UTC

    So... for this example you don't actually have any unicode characters at all, right? Your __DATA__ is using html entities written in ASCII, and all the literals are also ASCII. And the emoji still doesn't come through?

    For debugging, you can always "view source" in your mail client (well, usually, or maybe you need to install Thunderbird). The source of the email should reveal if something broke your HTML.

    When you get past this first hurdle though, and go back to using Unicode characters, you should:

    • Decode the CGI parameters into unicode strings
    • Make sure your DBI was connected with option { mysql_enable_utf8 => 1 }
    • Declare your content types as text/html; charset=UTF-8 or text/plain; charset=UTF-8
    • Put use utf8; at the top of the script if any of your literals have a non-ASCII character.
    • Encode the headers (if there's any chance they contain non-ASCII)
[reply]
[d/l]
[select]
      Make sure your DBI was connected with option { mysql_enable_utf8 => 1 }

      That won't help with DBD::MariaDB, see "UNICODE SUPPORT" in its fine manual.

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]
        That won't help with DBD::MariaDB

        We use MariaDB. But I think (I'll check later when I can) we use DBI::mysql as the driver.

[reply]

In Section Seekers of Perl Wisdom