1

I'm writing some code to look at PTO assignment data, and noticed a strange problem where the URL didn't work when I generated it from my database entry, but did work when I entered the same string manually. When I echo them both strings look the same exactly, but when I equate them they are different. Is there some kind of hidden character or something with the encoding I can't see, and if so how do I fix it? I'm running the code using WAMPSERVER. 

$pto = "assignments.uspto.gov/assignments/q?db=pat&reel=";
$row = mysql_fetch_assoc($result);

$ReelFrame = $row['ReelFrame'];       // Should be "007358/0006" and looks to be correct.
$reelframearray = explode("/",$ReelFrame);
$gourla = $pto . $reelframearray[0] . "&frame=". $reelframearray[1];
$gourl = "assignments.uspto.gov/assignments/q?db=pat&reel=007358&frame=0006";
echo "$gourla <br>";
echo "$gourl <br>";
if ($gourl === $gourla){
 echo "same string";
} else {
 echo "different";
}

This is what the results look like:

assignments.uspto.gov/assignments/q?db=pat&reel=007358&frame=0006 
assignments.uspto.gov/assignments/q?db=pat&reel=007358&frame=0006 
different

I've narrowed it down to the mysql entry since replacing that with this:

$ReelFrame = "007358/0006";

Makes the strings the same.

Thanks for any help. The column for ReelFrame is a VARCHAR if that makes any difference.

Palantir
  • 23,820
  • 10
  • 76
  • 86
Don
  • 11
  • 1
  • I can guarantee you that the two lines in your example are equal. Which means that the problem might be somewhere else. It could be an encoding issue, although this seems far fetched because the data you provided is not data that's usually encoding-sensitive. In what waydo you determine the equality (that is, the nonexisting) of these two character strings? – 0xCAFEBABE Nov 05 '10 at 07:41
  • I don't use PHP that often, but doesn't '===' mean you're comparing two objects by their position in the heap? and since the two strings are built differently they won't have the same address. why not just use '=='? – jcomeau_ictx Nov 05 '10 at 07:48

3 Answers3

2

please try to var_dump() your both variables instead of echoing them - maybe there are some leading/trailing whitespaces, linebreaks or something like that.

EDIT: just as a note: you realy shouldn't save multiple values in one database-coumn. if ReelFrame consits of two values, make two colums out of it: Reel and Frame - and don't use charchar for this, it looks like they should be ints (and that will avoid you from saving whitespaces linebreaks or something like that accidentally)

oezi
  • 51,017
  • 10
  • 98
  • 115
1

The first thought that comes to my mind is \n character.

Try this:

$ReelFrame = trim($row['ReelFrame']);
Donatas Olsevičius
  • 1,350
  • 8
  • 13
0

I tried the trim() suggestion, but it doesn't seem to work. I'm not sure what kind of character it is inserting, but I guess trim isn't removing it.

I just tried the var_dump, and it does show the strings are different lengths though nothing else looks different. vardump of a ReelFrame entity compared with manual string:
string(20) "007358/0006"
string(11) "007358/0006"

likewise for the final string:
string(81) "assignments.uspto.gov/assignments/q?db=pat&reel=007358&frame=0006"
string(72) "assignments.uspto.gov/assignments/q?db=pat&reel=007358&frame=0006"

trim() doesn't seem to make any difference on the entity so it's still showing 20. Are there any other invisible characters that trim might miss?

GDP
  • 8,109
  • 6
  • 45
  • 82
Don
  • 1
  • just use rawurlencode() instead of var_dump() and you will see them all. looking into page source also helps. – Your Common Sense Nov 05 '10 at 08:04
  • and listen to what oezi said. don't be lame – Your Common Sense Nov 05 '10 at 08:07
  • %3CASSL_RF%3E007358%2F006 for mysql entry just 007358%2F006 for manual entry. – Don Nov 05 '10 at 08:11
  • Thanks for the help looks like an xml tag somehow got into the entry. I'll look into splitting it into ints for the final version. Part of what I wanted to do is compare results from an xml source with pto data so I wanted to capture the whole field instead of parsing it then. – Don Nov 05 '10 at 08:22