There's a couple of areas where you could be bit by encodings in this chain -- percent-encoding, HTML_entities, and Linux/Windows issues. That you are also rolling a web server into the mix does not simplify the issue. Did you perform the ord test I described before? The working accented link is resolved by the browser as
http://www.1604.ca/espanol/images/n%C3%BAmero.png
which means you're using UTF codepoint U+00FA, or 250. This is possibly subject to some major high-bit code page malarkey. What happens when you run
perl -le 'print -e sprintf "n%smero.png", chr 250'
in the target directory? Usually, this sort of problem comes down to figuring out where you've forgotten to encode/decode a string. My copy of perl 5.8.9 handles this just fine.
#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.
| [reply]
[d/l]
[select] |
Thanks to all for the feedback. I am just programming as a hobby - not a pro. I have saved these suggestions and will work on this in the coming week. Thanks again.
| [reply] |
Thanks for all the help. I just want to mention that I don't own the server. The site is being hosted by the company SiteGround (which I think is in the USA). The data file is also located on that same server. My Perl script is able to read the word "número" (from that data file) and store it into its variable $mes. Then, the Perl script prints that variable $mes to my browser and my browser displays the correct word. I tried this on my Win7 computer running Google Chrome, and also on my son's iPad using Safari. Perhaps, Perl stores n%C3%BAmero into that variable which browsers can resolve as you mentioned, but Perl is not able to resolve. The strange thing is that my local Perl (running through Apache) is able to resolve this. I'm fairly new to Perl, I didn't understand the ord test. I don't have access to a perl prompt (command prompt) if that's what you meant. I did add this code to my website, not sure if it's what you were hoping to see.
for $i ( 0 .. 23 )
{
$mfr=$info[$i]{'MFR'};
$mes=$info[$i]{'MES'};
my @array = split //,$mes;
@array = map(ord, @array);
my @chars = map(chr, @array);
my @array2 = unpack("C*", $mes);
my @chars2 = map(chr, @array2);
$c="$dpmg/$mes.$epng";
if (-e $c) { $c2=$c; } else { $c2="$dpmg/_x2.png"; }
$d="$dpmg/$mes.$epng";
print "<DIV>$mfr</DIV>
<DIV>$mes</DIV>
<DIV>$c</DIV>
<IMG src='$c2'>
<DIV>$d</DIV>
<IMG src='$d'>
<DIV>@array</DIV>
<DIV>@chars</DIV>
<DIV>@array2</DIV>
<DIV>@chars2</DIV>
<BR>\n";
}
| [reply]
[d/l] |
I note you stated you've resolved the issue in Re^4: -e not working Perl 5.008008. Let me know if you are still having trouble.
#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.
| [reply] |
But the image is in fact there by looking at the next column where I don't check for its existence.
Well that's weird cause in my browser I don't see exactly the three images for which Perl can't find the filenames. Anyway, $info[$i]{'MES'} (or whatever) contains Latin-1 strings. Which your OS can't find, presumably because the real filenames are in UTF-8. OTOH, Windows can, because of some legacy codepage nonsense or some such.
| [reply]
[d/l] |
Well that's weird cause in my browser I don't see exactly the three images for which Perl can't find the filenames.
(cause it doesn't fall back to ISO-8859-1)
| [reply] |
