I am working with the programmer on this but we are having a hard time figuring out where the problem is exactly (local, cgi script or smtp).
The application is mailing list script that connects to a smtp server to send the email. The emails are written in french with accents. When we receive the email it is garbled in our email program and webmail. Changing character encoding in our browser or gui to UTF-8 makes the accents readable. The standard in browsers and gui's would seem to be iso-8559-1.
This script writes the email to a text file first and then sends it. Its running on a Fedora Core 3 server with Apache 2.0. Is the problem with the way the file is encoded ? or is it a local problem on the server ?
Something i noticed is that when i vi the text file on the server the french accents are garbled.
does anyone have experience with this ?
regards
Denny
dont ever again ever ever pay money for software
pay for someone to code for you custom- or to help you with code. but if you pay for a piece of software.. SUCKER- serves you right. hahahahaha.
look for an alternative solution to your problem- if yours was an open source script then it would probably not be all f&&ed up like that to begin with, and if it were, it would get fixed by sundown at no cost to your silly &ss- i mean.. it's one thing if you mother buys a copy of windows xp or her latest 'make your own barby' program.. but here ?
This is more the uhmm.. open source community. I think you should start by telling us what your problem is .. then someone can suggest where to look. Sorry you made a mistake paying for software. Don't do it again.
you come to perl, perl come to yoo- you pay mulah for software perl no likey, but we help yoo..
just STOP paying money for sofware.
Is this forum for helping people or bashing them ??!
FYI the script is not all f&&ed up as you say, you are just wasting my time with your nonsense.
there is a case to be made for the advantages of open source over commercially developed software. But you aren't making it, and you certainly aren't helping it by being borderline abusive and deliberately unhelpful. You can find a pretty good summary in the Richard Stallman quote from DigitalKitty's homenode:
"Proprietary software is unethical, because it denies the user the basic freedom to control his/her own computer and to cooperate. The problem with proprietary software is that a specific developer controls its development--you, the user, do not."There are many reasons why someone would show up here looking for help with a piece of code they've paid for - perhaps the OP is looking at a piece of code that a freelancer has written? Or perhaps (he|she) or (his|her) boss has made a (possibly ill advised) choice to buy a piece of code that provides a particular solution.
-- Richard Stallman
I'm as much an open source zealot as the next monk, but perlmonks is a site about perl, not necessarily open source. Please bear that in mind, and either try to be polite and helpful to people asking for help, or if you can't, hold your tongue.
--------------------------------------------------------------
"If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing."
John Brunner, "The Shockwave Rider".
You'll need to set the charset as unicode (you can do this with a meta tag in the head ) btw. you can find more info at unicode.org (check out the FAQs.
First of all, where does your source document come from? Which factors determine its encoding?
Ultimately the best course of action is to ensure that you're using utf8 everywhere (and advertising that to the viewing programs). You can tell the web browser that your content is in utf8 by sending an additional "charset" header attribute like this:
use CGI; my $cgi = CGI->new; ... print $cgi->header(-type=>'text/html', -charset=>'utf-8');You can do the same for emails, by giving them the appropriate MIME headers:
Content-Type: text/plain; charset="utf-8"How you do that depends on how your email-sending code is designed.
I'd like to point out that in recent perls (version 5.8), under most circumstances, strings are encoded internally as utf8. So it makes sense to be consistent about that in the rest of your application.
I've found on several occasions that it's necessary to manually upgrade form input to utf8. For some reason, CGI returns raw byte strings, and those might end up being upgraded to utf once more, resulting in lots of squiggly characters. I did this like so:
use Encode;
my $email_body = $cgi->param( 'email_body' );
$email_body = decode_utf8( $email_body );
After this, most conversions and display issues are a snap.
If you would prefer your email output to be iso-8859-1, use the Encode module on the text data, or PerlIO control on the output file handle, in order to assure that the text is written with that encoding; assuming the email text is going out via a file handle the easiest thing would probably be:
binmode $fh, ":encoding(iso-8859-1)"; # convert internal utf8 to latin1 on outputIf you do this, you should still heed thesa's advice, and explicitly declare what character set you're using in the MIME header.
I've had similar problems recently when upgrading an existing content management system from Latin-1 to UTF-8. After extensive testing we have decided to display all website content in UTF-8 encoding, but send emails in Latin-1, because many freemail websites seem to ignore the charset directives.
If your provider happens to run an older Perl version, the Encode module might not support UTF-8 or it might not be there at all. In that case, have a look at the sub latin1 in the following example: Converting character encodings.