Revision bbb2383f
Von Moritz Bunkus vor mehr als 5 Jahren hinzugefügt
| SL/Mailer.pm | ||
|---|---|---|
| 25 | 25 |
|
| 26 | 26 |
use Email::Address; |
| 27 | 27 |
use Email::MIME::Creator; |
| 28 |
use Encode; |
|
| 28 | 29 |
use File::MimeInfo::Magic; |
| 29 | 30 |
use File::Slurp; |
| 30 | 31 |
use List::UtilsBy qw(bundle_by); |
| ... | ... | |
| 181 | 182 |
my $ent; |
| 182 | 183 |
if ( $attributes{content_type} eq 'message/rfc822' ) {
|
| 183 | 184 |
$ent = Email::MIME->new($attachment_content); |
| 184 |
$ent->header_str_set('Content-disposition' => 'attachment; filename='.$attributes{filename});
|
|
| 185 | 185 |
} else {
|
| 186 | 186 |
$ent = Email::MIME->create( |
| 187 | 187 |
attributes => \%attributes, |
| ... | ... | |
| 189 | 189 |
); |
| 190 | 190 |
} |
| 191 | 191 |
|
| 192 |
# Due to a bug in Email::MIME it's not enough to hand over the encoded file name in the "attributes" hash in the |
|
| 193 |
# "create" call. Email::MIME iterates over the keys in the hash, and depending on which key it has already seen during |
|
| 194 |
# the iteration it might revert the encoding. As Perl's hash key order is randomized for each Perl run, this means |
|
| 195 |
# that the file name stays unencoded sometimes. |
|
| 196 |
# Setting the header manually after the "create" call circumvents this problem. |
|
| 197 |
$ent->header_set('Content-disposition' => 'attachment; filename="' . encode('MIME-Q', $attributes{filename}) . '"');
|
|
| 198 |
|
|
| 192 | 199 |
push @{ $self->{mail_attachments}} , SL::DB::EmailJournalAttachment->new(
|
| 193 | 200 |
name => $attributes{filename},
|
| 194 | 201 |
mime_type => $attributes{content_type},
|
Auch abrufbar als: Unified diff
Mailer: Encoding der Namen von Dateianhängen gefixt
Email::MIME encodiert den Dateinamen, der im »Content-Disposition«-
Header enthalten ist, nicht selber. Daher muss der Aufrufer das
tun. Andernfalls kann es bei Nicht-ASCII-Zeichen dann dazu kommen,
dass das empfangene Mail-Programm diese in einem anderen Zeichensatz
interpretiert (z.B. ISO-8859-1), obwohl wir immer UTF-8 senden. Ein
Halleluja für Legacy-Standards.
Weiterhin gibt es einen subtilen Bug in Email::MIME. Eigentlich steht
der Dateiname ja bereits im »attributes«-Hash, das an
»Email::MIME->create()« übergeben wird. Hier könnte man den Dateinamen
schon encodiert reinschreiben.
Das funktioniert auch — aber nur manchmal. Intern scheint das Modul
über die Hash-Keys von »attributes« zu iterieren und je nachdem,
welche Keys es schon gesehen hat, das vom Aufrufer vorgenommene
Encoding rückgängig zu machen. Da die Hash-Key-Reihenfolge aber bei
jedem Aufruf von Perl zufällig gewählt wird, passiert es halt
manchmal, dass diese Keys bereits gesehen wurden und Email::MIME das
Encoding rückgängig macht.
Daher muss der »Content-Disposition«-Header unbedingt nach dem
Erzeugen mit »create« gesetzt werden. Dann lässt Email::MIME ihn auch
genau so, wie er sein soll.