Description:
------------
Per RFC 3548 (http://www.ietf.org/rfc/rfc3548.txt) , there is an alternate alphabet for base64 encoding and decoding,addressing the issue of unfriendliness of the '/' to filesystems and URLs.

<snip>

Table 2: The "URL and Filename safe" Base 64 Alphabet

    Value Encoding  Value Encoding  Value Encoding  Value Encoding
       0 A            17 R            34 i            51 z
       1 B            18 S            35 j            52 0
       2 C            19 T            36 k            53 1
       3 D            20 U            37 l            54 2
       4 E            21 V            38 m            55 3
       5 F            22 W            39 n            56 4
       6 G            23 X            40 o            57 5
       7 H            24 Y            41 p            58 6
       8 I            25 Z            42 q            59 7
       9 J            26 a            43 r            60 8
      10 K            27 b            44 s            61 9
      11 L            28 c            45 t            62 - (minus)
      12 M            29 d            46 u            63 _ (understrike)
      13 N            30 e            47 v
      14 O            31 f            48 w         (pad) =
      15 P            32 g            49 x
      16 Q            33 h            50 y

</snip>

As you can see, the only difference is that the last two characters (+ and /) are substituted by '-' (minus) and '_' (underscore). It should be trivial for base64_encode to have a flag so that the message can be encoded with the alternate  alphabet. since there is no clash between alphabet, olny the substitution of two characters for other chars which were not part of it, base64_decode should recognize both without the need of an additional parameter. My suggestion is to add an optional flag as a second parameter to tell base64_encode that it should use the URL-friendly encoding. Its absence will indicate the traditional behaviour.