Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • It seems to me that email is just what you want to use the module for. I don’t see how the module’s operation actually has anything whatsoever to do with email. “Best” doesn’t really say anything; maybe Encode::MinCharsetPicker?

    (Btw, I’d have the module only suggest the minimal applicable charset, but not actually do the encoding itself (or only if you ask for it by way of a convenience function). Probably the main function should simply take a list of encodings and the

    • As said in the other comment replies, the actual code doesn't have anything to do with email, other than the default "list of encodings known to be safe in emails" are almost specific to email (which is the point of this module) obviously.

      I'd probably make two functions, one is compatible as encode() (and does encoding itself) and other one like detect_best_encoding(), which returns the name of the encoding but doesn'nt encode itself.
      • The easiest way to detect the "best" encoding would be to just encode it, with a CHECK argument to make it fail if impossible. Why create a utility function to throw away the encoded string, if the user can easily choose to do so himself?

        my ($enc) = encode_first(...);

        Or, have you found another efficient way of finding a suitable encoding?
        • Yes, I was thinking of the exact same logic, as well as using charset tables like the one used in Encode::InCharset. I prefer the easiest, if not the most efficient, so I guess that'll be same as what you described.

          The reason we want the encoding itself back it that we'd like to use it in the Email header. If we return the encoded string only, the caller doesn't know which encoding it's actually encoded in.
        • The reason I suggested that sort of interface is that some APIs expect to receive character strings that they will then encode themselves; XML serialisers come to mind. In such a case, giving the caller an encoded string is pretty useless.