aboutsummaryrefslogtreecommitdiff
path: root/doc/bugs/password_reset_fails_with___34__Wide_character_in_subroutine_entry__34__.mdwn
diff options
context:
space:
mode:
authorhttp://smcv.pseudorandom.co.uk/ <smcv@web>2014-03-03 12:19:44 -0400
committeradmin <admin@branchable.com>2014-03-03 12:19:44 -0400
commit383364be6acddb5185856cd29893ec635e0ef786 (patch)
treee0f870fa0cb66b7c059ab576ab8f51eb4c8cbf99 /doc/bugs/password_reset_fails_with___34__Wide_character_in_subroutine_entry__34__.mdwn
parent6a683800a4ff470f97dcadd89e5949afeadb34c2 (diff)
downloadikiwiki-383364be6acddb5185856cd29893ec635e0ef786.tar
ikiwiki-383364be6acddb5185856cd29893ec635e0ef786.tar.gz
diagnosis
Diffstat (limited to 'doc/bugs/password_reset_fails_with___34__Wide_character_in_subroutine_entry__34__.mdwn')
-rw-r--r--doc/bugs/password_reset_fails_with___34__Wide_character_in_subroutine_entry__34__.mdwn19
1 files changed, 19 insertions, 0 deletions
diff --git a/doc/bugs/password_reset_fails_with___34__Wide_character_in_subroutine_entry__34__.mdwn b/doc/bugs/password_reset_fails_with___34__Wide_character_in_subroutine_entry__34__.mdwn
index b68843036..b49fdb50c 100644
--- a/doc/bugs/password_reset_fails_with___34__Wide_character_in_subroutine_entry__34__.mdwn
+++ b/doc/bugs/password_reset_fails_with___34__Wide_character_in_subroutine_entry__34__.mdwn
@@ -5,3 +5,22 @@ We get the following error in a password reset:
Error: Wide character in subroutine entry at /usr/share/perl5/Mail/Sendmail.pm line 308.
Help! :) --[[anarcat]]
+
+> I assume this means Mail::Sendmail doesn't know how to send Unicode
+> strings, so any string passed to it (or any message body, or something?)
+> will need to be passed through `encode_utf8()`. It looks as though
+> Mail::Sendmail also defaults to
+>
+> Content-Type: 'text/plain; charset="iso-8859-1"'
+>
+> so it'll need a `'Content-Type' => 'text/plain; charset="utf-8"'`
+> too.
+>
+> I'm disappointed to see how many of the library modules used by ikiwiki
+> are not Unicode-clean... but then again, Mail::Sendmail was last released
+> in 2003 so it's hardly surprising. I wonder whether [[!cpan Email::Sender]]
+> is any better?
+>
+> (If you know Python 2, the analogous situation would be "doesn't
+> know how to send unicode objects, so you have to get a str object
+> with `a_unicode_object.encode('utf-8')`".) --[[smcv]]