Should use CGI.pm's header method to output the Content-Type header?
If I'm using the CGI module in Perl, I can do this
$cgi = CGI->new();
$cgi->header(-type=>"text/html");
Or go for the classic
print "Content-Type: text/html\r\n\r\n开发者_运维百科";
Does it matter which we use? Is there any difference between the two? Both seem to work.
For me I'd go for the first if I was using CGI anyway, but if not then I wouldn't bother loading the module for just one action. But just wondering if there is any thing on the subject?
Psy
Strictly speaking, you have to print \r characters:
print "Content-Type: text/html\r\n\r\n"
is a legal way to express what you want to say.
Generally, I'd stick with what CGI offers. It allows much more concise and readable code, and CGI knows a lot more about such details than you do.
Strictly speaking, you have to print CRLF
pairs. That is not the same thing as "\r\n\r\n" unless you use binmode STDOUT
first.
print "Content-Type: text/html\r\n\r\n";
C:\Temp> t | xxd 0000000: 436f 6e74 656e 742d 5479 7065 3a20 7465 Content-Type: te 0000010: 7874 2f68 746d 6c0d 0d0a 0d0d 0a xt/html......
You should use CGI.pm. Or, if, like me, you do not want all the historical baggage, use CGI::Simple.
In perl, the escape codes "\r" and "\n" are NOT guaranteed to be identical to "\015" and "\012".
If you want to print a CRLF for a network protocol, you should use "\015\012" or "\cM\cJ".
Here's the quote, direcly from perldoc perlop:
All systems use the virtual "\n" to represent a line terminator, called a "newline". There is no such thing as an unvarying, physical newline character. It is only an illusion that the operating system, device drivers, C libraries, and Perl all conspire to preserve. Not all systems read "\r" as ASCII CR and "\n" as ASCII LF. For example, on the ancient Macs (pre-MacOS X) of yesteryear, these used to be reversed, and on systems without line terminator, printing "\n" might emit no actual data. In general, use "\n" when you mean a "newline" for your system, but use the literal ASCII when you need an exact character. For example, most networking protocols expect and prefer a CR+LF ("\015\012" or "\cM\cJ" ) for line terminators, and although they often accept just "\012" , they seldom tolerate just "\015" . If you get in the habit of using "\n" for networking, you may be burned some day.
And more, similar info, from perldoc -f binmode:
The operating system, device drivers, C libraries, and Perl run-time system all conspire to let the programmer treat a single character (\n ) as the line terminator, irrespective of external representation. On many operating systems, the native text file representation matches the internal representation, but on some platforms the external representation of \n is made up of more than one character.
All variants of Unix, Mac OS (old and new), and Stream_LF files on VMS use a single character to end each line in the external representation of text (even though that single character is CARRIAGE RETURN on old, pre-Darwin flavors of Mac OS, and is LINE FEED on Unix and most VMS files). In other systems like OS/2, DOS, and the various flavors of MS-Windows, your program sees a \n as a simple \cJ , but what's stored in text files are the two characters \cM\cJ . That means that if you don't use binmode() on these systems, \cM\cJ sequences on disk will be converted to \n on input, and any \n in your program will be converted back to \cM\cJ on output. This is what you want for text files, but it can be disastrous for binary files.
the bad using
print "Content-Type: text/html\r\n\r\n"
you can't add another header, here working example solution if you want to add Content-Type and Cookies using CGI
my $cgi = CGI->new;
my $cookie = $cgi->cookie(-name => 'CookieName', -value => 'CookieValue');
print $cgi->header( -cookie => $cookie,
-type => 'text/html',
-charset => 'charset=UTF-8');
精彩评论