PHP - Plus sign with GET query











up vote
24
down vote

favorite
6












I have a PHP script that does basic encryption of a string through the method below:



<?php
$key = 'secretkey';
$string = $_GET['str'];

if ($_GET['method'] == "decrypt")
{
$output = rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, md5($key), base64_decode($string), MCRYPT_MODE_CBC, md5(md5($key))), "");
}

if ($_GET['method'] == "encrypt")
{
$output= base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, md5($key), $string, MCRYPT_MODE_CBC, md5(md5($key))));
}

echo $output;
?>


An example of a URL to encrypt a string would look like this:



Encrypt.php?method=encrypt&str=the quick fox



Which would return this as the encrypted string:



LCuT/ieVa6cl3/4VtzE+jd9QPT3kvHYYJFqG6tY3P0Q=



Now to decrypt the string all you have to do is change the "method" query to "decrypt", like so:



Encrypt.php?method=decrypt&str=LCuT/ieVa6cl3/4VtzE+jd9QPT3kvHYYJFqG6tY3P0Q=



The only problem is that when that encrypted string is decrypted it returns this:



¬ƒ§rYV}̳5Äš·nßì(ñïX8Þ;b



I have narrowed down the problem to the plus sign that is in the encrypted string. PHP's GET method seems to translate a plus sign into a blank space. I have searched this bug and found out that it has already been filed here. I have tried different methods listed on that page and others with no success. The closest I got is by using this:



$fixedstring = str_replace(" ", "+", $string);


and then using $fixedstring in the encryption methods, the problem is, upon decryption, all blank spaces are converted to plus signs. Any ideas?



I know using POST would make more sense but I am using GET for specific reasons. I will spare the details.










share|improve this question




























    up vote
    24
    down vote

    favorite
    6












    I have a PHP script that does basic encryption of a string through the method below:



    <?php
    $key = 'secretkey';
    $string = $_GET['str'];

    if ($_GET['method'] == "decrypt")
    {
    $output = rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, md5($key), base64_decode($string), MCRYPT_MODE_CBC, md5(md5($key))), "");
    }

    if ($_GET['method'] == "encrypt")
    {
    $output= base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, md5($key), $string, MCRYPT_MODE_CBC, md5(md5($key))));
    }

    echo $output;
    ?>


    An example of a URL to encrypt a string would look like this:



    Encrypt.php?method=encrypt&str=the quick fox



    Which would return this as the encrypted string:



    LCuT/ieVa6cl3/4VtzE+jd9QPT3kvHYYJFqG6tY3P0Q=



    Now to decrypt the string all you have to do is change the "method" query to "decrypt", like so:



    Encrypt.php?method=decrypt&str=LCuT/ieVa6cl3/4VtzE+jd9QPT3kvHYYJFqG6tY3P0Q=



    The only problem is that when that encrypted string is decrypted it returns this:



    ¬ƒ§rYV}̳5Äš·nßì(ñïX8Þ;b



    I have narrowed down the problem to the plus sign that is in the encrypted string. PHP's GET method seems to translate a plus sign into a blank space. I have searched this bug and found out that it has already been filed here. I have tried different methods listed on that page and others with no success. The closest I got is by using this:



    $fixedstring = str_replace(" ", "+", $string);


    and then using $fixedstring in the encryption methods, the problem is, upon decryption, all blank spaces are converted to plus signs. Any ideas?



    I know using POST would make more sense but I am using GET for specific reasons. I will spare the details.










    share|improve this question


























      up vote
      24
      down vote

      favorite
      6









      up vote
      24
      down vote

      favorite
      6






      6





      I have a PHP script that does basic encryption of a string through the method below:



      <?php
      $key = 'secretkey';
      $string = $_GET['str'];

      if ($_GET['method'] == "decrypt")
      {
      $output = rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, md5($key), base64_decode($string), MCRYPT_MODE_CBC, md5(md5($key))), "");
      }

      if ($_GET['method'] == "encrypt")
      {
      $output= base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, md5($key), $string, MCRYPT_MODE_CBC, md5(md5($key))));
      }

      echo $output;
      ?>


      An example of a URL to encrypt a string would look like this:



      Encrypt.php?method=encrypt&str=the quick fox



      Which would return this as the encrypted string:



      LCuT/ieVa6cl3/4VtzE+jd9QPT3kvHYYJFqG6tY3P0Q=



      Now to decrypt the string all you have to do is change the "method" query to "decrypt", like so:



      Encrypt.php?method=decrypt&str=LCuT/ieVa6cl3/4VtzE+jd9QPT3kvHYYJFqG6tY3P0Q=



      The only problem is that when that encrypted string is decrypted it returns this:



      ¬ƒ§rYV}̳5Äš·nßì(ñïX8Þ;b



      I have narrowed down the problem to the plus sign that is in the encrypted string. PHP's GET method seems to translate a plus sign into a blank space. I have searched this bug and found out that it has already been filed here. I have tried different methods listed on that page and others with no success. The closest I got is by using this:



      $fixedstring = str_replace(" ", "+", $string);


      and then using $fixedstring in the encryption methods, the problem is, upon decryption, all blank spaces are converted to plus signs. Any ideas?



      I know using POST would make more sense but I am using GET for specific reasons. I will spare the details.










      share|improve this question















      I have a PHP script that does basic encryption of a string through the method below:



      <?php
      $key = 'secretkey';
      $string = $_GET['str'];

      if ($_GET['method'] == "decrypt")
      {
      $output = rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, md5($key), base64_decode($string), MCRYPT_MODE_CBC, md5(md5($key))), "");
      }

      if ($_GET['method'] == "encrypt")
      {
      $output= base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, md5($key), $string, MCRYPT_MODE_CBC, md5(md5($key))));
      }

      echo $output;
      ?>


      An example of a URL to encrypt a string would look like this:



      Encrypt.php?method=encrypt&str=the quick fox



      Which would return this as the encrypted string:



      LCuT/ieVa6cl3/4VtzE+jd9QPT3kvHYYJFqG6tY3P0Q=



      Now to decrypt the string all you have to do is change the "method" query to "decrypt", like so:



      Encrypt.php?method=decrypt&str=LCuT/ieVa6cl3/4VtzE+jd9QPT3kvHYYJFqG6tY3P0Q=



      The only problem is that when that encrypted string is decrypted it returns this:



      ¬ƒ§rYV}̳5Äš·nßì(ñïX8Þ;b



      I have narrowed down the problem to the plus sign that is in the encrypted string. PHP's GET method seems to translate a plus sign into a blank space. I have searched this bug and found out that it has already been filed here. I have tried different methods listed on that page and others with no success. The closest I got is by using this:



      $fixedstring = str_replace(" ", "+", $string);


      and then using $fixedstring in the encryption methods, the problem is, upon decryption, all blank spaces are converted to plus signs. Any ideas?



      I know using POST would make more sense but I am using GET for specific reasons. I will spare the details.







      php get






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Apr 20 '10 at 0:57

























      asked Apr 20 '10 at 0:46









      user

      6,484267093




      6,484267093
























          4 Answers
          4






          active

          oldest

          votes

















          up vote
          33
          down vote



          accepted










          If you'll read the entirety of that bug report you'll see a reference to RFC 2396. Which states that + is reserved. PHP is correct in translating an unencoded + sign to a space.



          You could use urlencode() the ciphertext when returning it to the user. Thus, when the user submits the ciphertext for decryption, you can urldecode() it. PHP will do this automatically for you if it comes in via the GET string as well.



          Bottom line: The + must be submitted to PHP as the encoded value: %2B






          share|improve this answer























          • I know that's a simple answer but I'm sending via GET for a certain reason.
            – user
            Apr 20 '10 at 0:53






          • 2




            This is the correct answer to your problem. If you want to use a literal plus sign anywhere in a URL, regardless of the server-side language used, it MUST be encoded, such as by replacing it with "%2B". This is because plus signs in URLs are used as a stand in for space characters, and any server-side scripts will interpret them correctly as space characters.
            – thomasrutter
            Apr 20 '10 at 2:51










          • ah whoops I see this answer has been edited. Oh well, it's correct now. +1
            – thomasrutter
            Apr 20 '10 at 2:52










          • WRONG. RFC 2396 was made obsolete by RFC 3986 in 2005, which states that query strings in uri's are composed of pchars, and pchars include all unreserved characters as well as the "sub delimiters" of which the "+" character is included. rfc-editor.org/rfc/rfc3986.txt see section 2.2 reserved characters section 3.3 path section 3.4 query
            – Noishe
            Oct 1 at 17:58




















          up vote
          10
          down vote













          I realize that this is an old question, but I was looking for a solution to a similar problem with + signs in a GET string. I stumble upon this page and thought I would share the solution I came up with.



          <?php
          $key = 'secretkey';
          $string = $_GET['str'];

          if ($_GET['method'] == "decrypt")
          {
          $string = urlencode($string);
          $string = str_replace("+", "%2B",$string);
          $string = urldecode($string);
          $output = rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, md5($key), base64_decode($string), MCRYPT_MODE_CBC, md5(md5($key))), "");
          }

          if ($_GET['method'] == "encrypt")
          {
          $output= base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, md5($key), $string, MCRYPT_MODE_CBC, md5(md5($key))));
          }

          echo $output;
          ?>





          share|improve this answer

















          • 1




            Thanks! Seeing the code laid out helped me. I needed to preserve the plus character in the query variable for use in a script that passed the query variable in a header for an API request. Simply encoding, replacing + with %2B, and then decoding the variable does just that.
            – Raam Dev
            Feb 9 '14 at 21:54


















          up vote
          4
          down vote













          You should be using urlencode() before putting the encrypted string on the query string, which will "escape" any special characters (including +) and then call urldecode() before decrypting it, to revert them back to their original form.






          share|improve this answer





















          • Simple; to the point. Thank you!
            – Ryan Mortensen
            May 23 '13 at 5:33


















          up vote
          2
          down vote













          none of the above answers worked for me, I fixed the "+" sign problem using



          rawurldecode() 


          and



           rawurlencode() 





          share|improve this answer





















          • Yes, this is the solution! Thanks.
            – user5510975
            Sep 29 at 7:27











          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f2671840%2fphp-plus-sign-with-get-query%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          4 Answers
          4






          active

          oldest

          votes








          4 Answers
          4






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          33
          down vote



          accepted










          If you'll read the entirety of that bug report you'll see a reference to RFC 2396. Which states that + is reserved. PHP is correct in translating an unencoded + sign to a space.



          You could use urlencode() the ciphertext when returning it to the user. Thus, when the user submits the ciphertext for decryption, you can urldecode() it. PHP will do this automatically for you if it comes in via the GET string as well.



          Bottom line: The + must be submitted to PHP as the encoded value: %2B






          share|improve this answer























          • I know that's a simple answer but I'm sending via GET for a certain reason.
            – user
            Apr 20 '10 at 0:53






          • 2




            This is the correct answer to your problem. If you want to use a literal plus sign anywhere in a URL, regardless of the server-side language used, it MUST be encoded, such as by replacing it with "%2B". This is because plus signs in URLs are used as a stand in for space characters, and any server-side scripts will interpret them correctly as space characters.
            – thomasrutter
            Apr 20 '10 at 2:51










          • ah whoops I see this answer has been edited. Oh well, it's correct now. +1
            – thomasrutter
            Apr 20 '10 at 2:52










          • WRONG. RFC 2396 was made obsolete by RFC 3986 in 2005, which states that query strings in uri's are composed of pchars, and pchars include all unreserved characters as well as the "sub delimiters" of which the "+" character is included. rfc-editor.org/rfc/rfc3986.txt see section 2.2 reserved characters section 3.3 path section 3.4 query
            – Noishe
            Oct 1 at 17:58

















          up vote
          33
          down vote



          accepted










          If you'll read the entirety of that bug report you'll see a reference to RFC 2396. Which states that + is reserved. PHP is correct in translating an unencoded + sign to a space.



          You could use urlencode() the ciphertext when returning it to the user. Thus, when the user submits the ciphertext for decryption, you can urldecode() it. PHP will do this automatically for you if it comes in via the GET string as well.



          Bottom line: The + must be submitted to PHP as the encoded value: %2B






          share|improve this answer























          • I know that's a simple answer but I'm sending via GET for a certain reason.
            – user
            Apr 20 '10 at 0:53






          • 2




            This is the correct answer to your problem. If you want to use a literal plus sign anywhere in a URL, regardless of the server-side language used, it MUST be encoded, such as by replacing it with "%2B". This is because plus signs in URLs are used as a stand in for space characters, and any server-side scripts will interpret them correctly as space characters.
            – thomasrutter
            Apr 20 '10 at 2:51










          • ah whoops I see this answer has been edited. Oh well, it's correct now. +1
            – thomasrutter
            Apr 20 '10 at 2:52










          • WRONG. RFC 2396 was made obsolete by RFC 3986 in 2005, which states that query strings in uri's are composed of pchars, and pchars include all unreserved characters as well as the "sub delimiters" of which the "+" character is included. rfc-editor.org/rfc/rfc3986.txt see section 2.2 reserved characters section 3.3 path section 3.4 query
            – Noishe
            Oct 1 at 17:58















          up vote
          33
          down vote



          accepted







          up vote
          33
          down vote



          accepted






          If you'll read the entirety of that bug report you'll see a reference to RFC 2396. Which states that + is reserved. PHP is correct in translating an unencoded + sign to a space.



          You could use urlencode() the ciphertext when returning it to the user. Thus, when the user submits the ciphertext for decryption, you can urldecode() it. PHP will do this automatically for you if it comes in via the GET string as well.



          Bottom line: The + must be submitted to PHP as the encoded value: %2B






          share|improve this answer














          If you'll read the entirety of that bug report you'll see a reference to RFC 2396. Which states that + is reserved. PHP is correct in translating an unencoded + sign to a space.



          You could use urlencode() the ciphertext when returning it to the user. Thus, when the user submits the ciphertext for decryption, you can urldecode() it. PHP will do this automatically for you if it comes in via the GET string as well.



          Bottom line: The + must be submitted to PHP as the encoded value: %2B







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Apr 20 '10 at 1:04

























          answered Apr 20 '10 at 0:51









          hobodave

          24k46373




          24k46373












          • I know that's a simple answer but I'm sending via GET for a certain reason.
            – user
            Apr 20 '10 at 0:53






          • 2




            This is the correct answer to your problem. If you want to use a literal plus sign anywhere in a URL, regardless of the server-side language used, it MUST be encoded, such as by replacing it with "%2B". This is because plus signs in URLs are used as a stand in for space characters, and any server-side scripts will interpret them correctly as space characters.
            – thomasrutter
            Apr 20 '10 at 2:51










          • ah whoops I see this answer has been edited. Oh well, it's correct now. +1
            – thomasrutter
            Apr 20 '10 at 2:52










          • WRONG. RFC 2396 was made obsolete by RFC 3986 in 2005, which states that query strings in uri's are composed of pchars, and pchars include all unreserved characters as well as the "sub delimiters" of which the "+" character is included. rfc-editor.org/rfc/rfc3986.txt see section 2.2 reserved characters section 3.3 path section 3.4 query
            – Noishe
            Oct 1 at 17:58




















          • I know that's a simple answer but I'm sending via GET for a certain reason.
            – user
            Apr 20 '10 at 0:53






          • 2




            This is the correct answer to your problem. If you want to use a literal plus sign anywhere in a URL, regardless of the server-side language used, it MUST be encoded, such as by replacing it with "%2B". This is because plus signs in URLs are used as a stand in for space characters, and any server-side scripts will interpret them correctly as space characters.
            – thomasrutter
            Apr 20 '10 at 2:51










          • ah whoops I see this answer has been edited. Oh well, it's correct now. +1
            – thomasrutter
            Apr 20 '10 at 2:52










          • WRONG. RFC 2396 was made obsolete by RFC 3986 in 2005, which states that query strings in uri's are composed of pchars, and pchars include all unreserved characters as well as the "sub delimiters" of which the "+" character is included. rfc-editor.org/rfc/rfc3986.txt see section 2.2 reserved characters section 3.3 path section 3.4 query
            – Noishe
            Oct 1 at 17:58


















          I know that's a simple answer but I'm sending via GET for a certain reason.
          – user
          Apr 20 '10 at 0:53




          I know that's a simple answer but I'm sending via GET for a certain reason.
          – user
          Apr 20 '10 at 0:53




          2




          2




          This is the correct answer to your problem. If you want to use a literal plus sign anywhere in a URL, regardless of the server-side language used, it MUST be encoded, such as by replacing it with "%2B". This is because plus signs in URLs are used as a stand in for space characters, and any server-side scripts will interpret them correctly as space characters.
          – thomasrutter
          Apr 20 '10 at 2:51




          This is the correct answer to your problem. If you want to use a literal plus sign anywhere in a URL, regardless of the server-side language used, it MUST be encoded, such as by replacing it with "%2B". This is because plus signs in URLs are used as a stand in for space characters, and any server-side scripts will interpret them correctly as space characters.
          – thomasrutter
          Apr 20 '10 at 2:51












          ah whoops I see this answer has been edited. Oh well, it's correct now. +1
          – thomasrutter
          Apr 20 '10 at 2:52




          ah whoops I see this answer has been edited. Oh well, it's correct now. +1
          – thomasrutter
          Apr 20 '10 at 2:52












          WRONG. RFC 2396 was made obsolete by RFC 3986 in 2005, which states that query strings in uri's are composed of pchars, and pchars include all unreserved characters as well as the "sub delimiters" of which the "+" character is included. rfc-editor.org/rfc/rfc3986.txt see section 2.2 reserved characters section 3.3 path section 3.4 query
          – Noishe
          Oct 1 at 17:58






          WRONG. RFC 2396 was made obsolete by RFC 3986 in 2005, which states that query strings in uri's are composed of pchars, and pchars include all unreserved characters as well as the "sub delimiters" of which the "+" character is included. rfc-editor.org/rfc/rfc3986.txt see section 2.2 reserved characters section 3.3 path section 3.4 query
          – Noishe
          Oct 1 at 17:58














          up vote
          10
          down vote













          I realize that this is an old question, but I was looking for a solution to a similar problem with + signs in a GET string. I stumble upon this page and thought I would share the solution I came up with.



          <?php
          $key = 'secretkey';
          $string = $_GET['str'];

          if ($_GET['method'] == "decrypt")
          {
          $string = urlencode($string);
          $string = str_replace("+", "%2B",$string);
          $string = urldecode($string);
          $output = rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, md5($key), base64_decode($string), MCRYPT_MODE_CBC, md5(md5($key))), "");
          }

          if ($_GET['method'] == "encrypt")
          {
          $output= base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, md5($key), $string, MCRYPT_MODE_CBC, md5(md5($key))));
          }

          echo $output;
          ?>





          share|improve this answer

















          • 1




            Thanks! Seeing the code laid out helped me. I needed to preserve the plus character in the query variable for use in a script that passed the query variable in a header for an API request. Simply encoding, replacing + with %2B, and then decoding the variable does just that.
            – Raam Dev
            Feb 9 '14 at 21:54















          up vote
          10
          down vote













          I realize that this is an old question, but I was looking for a solution to a similar problem with + signs in a GET string. I stumble upon this page and thought I would share the solution I came up with.



          <?php
          $key = 'secretkey';
          $string = $_GET['str'];

          if ($_GET['method'] == "decrypt")
          {
          $string = urlencode($string);
          $string = str_replace("+", "%2B",$string);
          $string = urldecode($string);
          $output = rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, md5($key), base64_decode($string), MCRYPT_MODE_CBC, md5(md5($key))), "");
          }

          if ($_GET['method'] == "encrypt")
          {
          $output= base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, md5($key), $string, MCRYPT_MODE_CBC, md5(md5($key))));
          }

          echo $output;
          ?>





          share|improve this answer

















          • 1




            Thanks! Seeing the code laid out helped me. I needed to preserve the plus character in the query variable for use in a script that passed the query variable in a header for an API request. Simply encoding, replacing + with %2B, and then decoding the variable does just that.
            – Raam Dev
            Feb 9 '14 at 21:54













          up vote
          10
          down vote










          up vote
          10
          down vote









          I realize that this is an old question, but I was looking for a solution to a similar problem with + signs in a GET string. I stumble upon this page and thought I would share the solution I came up with.



          <?php
          $key = 'secretkey';
          $string = $_GET['str'];

          if ($_GET['method'] == "decrypt")
          {
          $string = urlencode($string);
          $string = str_replace("+", "%2B",$string);
          $string = urldecode($string);
          $output = rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, md5($key), base64_decode($string), MCRYPT_MODE_CBC, md5(md5($key))), "");
          }

          if ($_GET['method'] == "encrypt")
          {
          $output= base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, md5($key), $string, MCRYPT_MODE_CBC, md5(md5($key))));
          }

          echo $output;
          ?>





          share|improve this answer












          I realize that this is an old question, but I was looking for a solution to a similar problem with + signs in a GET string. I stumble upon this page and thought I would share the solution I came up with.



          <?php
          $key = 'secretkey';
          $string = $_GET['str'];

          if ($_GET['method'] == "decrypt")
          {
          $string = urlencode($string);
          $string = str_replace("+", "%2B",$string);
          $string = urldecode($string);
          $output = rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, md5($key), base64_decode($string), MCRYPT_MODE_CBC, md5(md5($key))), "");
          }

          if ($_GET['method'] == "encrypt")
          {
          $output= base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, md5($key), $string, MCRYPT_MODE_CBC, md5(md5($key))));
          }

          echo $output;
          ?>






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Aug 17 '11 at 14:20









          Andrew

          180318




          180318








          • 1




            Thanks! Seeing the code laid out helped me. I needed to preserve the plus character in the query variable for use in a script that passed the query variable in a header for an API request. Simply encoding, replacing + with %2B, and then decoding the variable does just that.
            – Raam Dev
            Feb 9 '14 at 21:54














          • 1




            Thanks! Seeing the code laid out helped me. I needed to preserve the plus character in the query variable for use in a script that passed the query variable in a header for an API request. Simply encoding, replacing + with %2B, and then decoding the variable does just that.
            – Raam Dev
            Feb 9 '14 at 21:54








          1




          1




          Thanks! Seeing the code laid out helped me. I needed to preserve the plus character in the query variable for use in a script that passed the query variable in a header for an API request. Simply encoding, replacing + with %2B, and then decoding the variable does just that.
          – Raam Dev
          Feb 9 '14 at 21:54




          Thanks! Seeing the code laid out helped me. I needed to preserve the plus character in the query variable for use in a script that passed the query variable in a header for an API request. Simply encoding, replacing + with %2B, and then decoding the variable does just that.
          – Raam Dev
          Feb 9 '14 at 21:54










          up vote
          4
          down vote













          You should be using urlencode() before putting the encrypted string on the query string, which will "escape" any special characters (including +) and then call urldecode() before decrypting it, to revert them back to their original form.






          share|improve this answer





















          • Simple; to the point. Thank you!
            – Ryan Mortensen
            May 23 '13 at 5:33















          up vote
          4
          down vote













          You should be using urlencode() before putting the encrypted string on the query string, which will "escape" any special characters (including +) and then call urldecode() before decrypting it, to revert them back to their original form.






          share|improve this answer





















          • Simple; to the point. Thank you!
            – Ryan Mortensen
            May 23 '13 at 5:33













          up vote
          4
          down vote










          up vote
          4
          down vote









          You should be using urlencode() before putting the encrypted string on the query string, which will "escape" any special characters (including +) and then call urldecode() before decrypting it, to revert them back to their original form.






          share|improve this answer












          You should be using urlencode() before putting the encrypted string on the query string, which will "escape" any special characters (including +) and then call urldecode() before decrypting it, to revert them back to their original form.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Apr 20 '10 at 1:08









          Chad Birch

          60.2k18136145




          60.2k18136145












          • Simple; to the point. Thank you!
            – Ryan Mortensen
            May 23 '13 at 5:33


















          • Simple; to the point. Thank you!
            – Ryan Mortensen
            May 23 '13 at 5:33
















          Simple; to the point. Thank you!
          – Ryan Mortensen
          May 23 '13 at 5:33




          Simple; to the point. Thank you!
          – Ryan Mortensen
          May 23 '13 at 5:33










          up vote
          2
          down vote













          none of the above answers worked for me, I fixed the "+" sign problem using



          rawurldecode() 


          and



           rawurlencode() 





          share|improve this answer





















          • Yes, this is the solution! Thanks.
            – user5510975
            Sep 29 at 7:27















          up vote
          2
          down vote













          none of the above answers worked for me, I fixed the "+" sign problem using



          rawurldecode() 


          and



           rawurlencode() 





          share|improve this answer





















          • Yes, this is the solution! Thanks.
            – user5510975
            Sep 29 at 7:27













          up vote
          2
          down vote










          up vote
          2
          down vote









          none of the above answers worked for me, I fixed the "+" sign problem using



          rawurldecode() 


          and



           rawurlencode() 





          share|improve this answer












          none of the above answers worked for me, I fixed the "+" sign problem using



          rawurldecode() 


          and



           rawurlencode() 






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered May 24 at 22:36









          Alex Angelico

          1,59741937




          1,59741937












          • Yes, this is the solution! Thanks.
            – user5510975
            Sep 29 at 7:27


















          • Yes, this is the solution! Thanks.
            – user5510975
            Sep 29 at 7:27
















          Yes, this is the solution! Thanks.
          – user5510975
          Sep 29 at 7:27




          Yes, this is the solution! Thanks.
          – user5510975
          Sep 29 at 7:27


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.





          Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


          Please pay close attention to the following guidance:


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f2671840%2fphp-plus-sign-with-get-query%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Trompette piccolo

          Slow SSRS Report in dynamic grouping and multiple parameters

          Simon Yates (cyclisme)