プルーフはPHPのソースコードにあります。
いつでも自分でこの種のことを自分で見つける方法の簡単なプロセスを説明します。気を付けてください。Cソースコードはたくさん読み飛ばすことができます（説明します）。Cをブラッシュアップしたい場合は、SO wikiから始めるのが良いでしょう。
ソースをダウンロードして（またはhttp://lxr.php.net/を使用してオンラインで閲覧します）、関数名のすべてのファイルをgrepすると、次のようなものが見つかります。
PHP 5.3.6（執筆時点で最新）は、ファイルurl.cのネイティブCコードの2つの関数について説明しています。
RawUrlEncode（）
PHP_FUNCTION(rawurlencode)
{
char *in_str, *out_str;
int in_str_len, out_str_len;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &in_str,
&in_str_len) == FAILURE) {
return;
}
out_str = php_raw_url_encode(in_str, in_str_len, &out_str_len);
RETURN_STRINGL(out_str, out_str_len, 0);
}
UrlEncode（）
PHP_FUNCTION(urlencode)
{
char *in_str, *out_str;
int in_str_len, out_str_len;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &in_str,
&in_str_len) == FAILURE) {
return;
}
out_str = php_url_encode(in_str, in_str_len, &out_str_len);
RETURN_STRINGL(out_str, out_str_len, 0);
}
では、ここで何が違うのですか？
どちらも本質的に、2つの異なる内部関数をそれぞれ呼び出しています：php_raw_url_encodeとphp_url_encode
だから、それらの関数を探しに行ってください！
php_raw_url_encodeを見てみましょう
PHPAPI char *php_raw_url_encode(char const *s, int len, int *new_length)
{
register int x, y;
unsigned char *str;
str = (unsigned char *) safe_emalloc(3, len, 1);
for (x = 0, y = 0; len--; x++, y++) {
str[y] = (unsigned char) s[x];
#ifndef CHARSET_EBCDIC
if ((str[y] < '0' && str[y] != '-' && str[y] != '.') ||
(str[y] < 'A' && str[y] > '9') ||
(str[y] > 'Z' && str[y] < 'a' && str[y] != '_') ||
(str[y] > 'z' && str[y] != '~')) {
str[y++] = '%';
str[y++] = hexchars[(unsigned char) s[x] >> 4];
str[y] = hexchars[(unsigned char) s[x] & 15];
#else /*CHARSET_EBCDIC*/
if (!isalnum(str[y]) && strchr("_-.~", str[y]) != NULL) {
str[y++] = '%';
str[y++] = hexchars[os_toascii[(unsigned char) s[x]] >> 4];
str[y] = hexchars[os_toascii[(unsigned char) s[x]] & 15];
#endif /*CHARSET_EBCDIC*/
}
}
str[y] = '\0';
if (new_length) {
*new_length = y;
}
return ((char *) str);
}
そしてもちろん、php_url_encode：
PHPAPI char *php_url_encode(char const *s, int len, int *new_length)
{
register unsigned char c;
unsigned char *to, *start;
unsigned char const *from, *end;
from = (unsigned char *)s;
end = (unsigned char *)s + len;
start = to = (unsigned char *) safe_emalloc(3, len, 1);
while (from < end) {
c = *from++;
if (c == ' ') {
*to++ = '+';
#ifndef CHARSET_EBCDIC
} else if ((c < '0' && c != '-' && c != '.') ||
(c < 'A' && c > '9') ||
(c > 'Z' && c < 'a' && c != '_') ||
(c > 'z')) {
to[0] = '%';
to[1] = hexchars[c >> 4];
to[2] = hexchars[c & 15];
to += 3;
#else /*CHARSET_EBCDIC*/
} else if (!isalnum(c) && strchr("_-.", c) == NULL) {
/* Allow only alphanumeric chars and '_', '-', '.'; escape the rest */
to[0] = '%';
to[1] = hexchars[os_toascii[c] >> 4];
to[2] = hexchars[os_toascii[c] & 15];
to += 3;
#endif /*CHARSET_EBCDIC*/
} else {
*to++ = c;
}
}
*to = 0;
if (new_length) {
*new_length = to - start;
}
return (char *) start;
}
次に進む前に、EBCDICは ASCIIに似た別の文字セットですが、完全な競争相手です。PHPは両方を処理しようとします。しかし基本的に、これはバイトEBCDIC 0x4cバイトがLASCIIではなく、実際にはであることを意味します<。きっとあなたはここで混乱を目にするでしょう。
Webサーバーで定義されている場合、これらの関数はどちらもEBCDICを管理します。
また、どちらも文字の配列（文字列型と考えます）のhexcharsルックアップを使用していくつかの値を取得します。配列は次のように記述されます。
/* rfc1738:
...The characters ";",
"/", "?", ":", "@", "=" and "&" are the characters which may be
reserved for special meaning within a scheme...
...Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
reserved characters used for their reserved purposes may be used
unencoded within a URL...
For added safety, we only leave -_. unencoded.
*/
static unsigned char hexchars[] = "0123456789ABCDEF";
それ以外は、機能が本当に異なるので、ASCIIとEBCDICで説明します。
ASCIIの違い：
URLENCODE：
- 入力文字列の開始/終了の長さを計算し、メモリを割り当てます
- 文字列の終わりに達するまで、whileループをインクリメントします
- 現在のキャラクターをつかむ
- 文字がASCII Char 0x20（つまり、「スペース」）に等しい場合は
+、出力文字列に符号を追加します。
- それはスペースはありません、それはまた、（英数字ではない場合
isalnum(c)）、またしていない_、-または.文字は、我々は、出力%配列の位置0に記号を、に配列ルックアップを行うhexcharsためのルックアップのための配列os_toascii（配列（現在の文字）のキーに対して、charを16進コードに変換するApacheの配列。c次に、ビット単位で右に4シフトし、その値を文字1に割り当て、位置2に、プリフォームを除いて同じルックアップを割り当てます。論理値で、値が15（0xF）かどうかを確認し、その場合は1を返し、そうでない場合は0を返します。最後に、エンコードされたものになります。
- 最終的にスペースではない場合、それは英数字または文字の1つであり、
_-.正確に何であるかを出力します。
RAWURLENCODE：
- 文字列にメモリを割り当てます
- 関数呼び出しで提供された長さに基づいて反復します（URLENCODEのように関数で計算されません）。
注：多くのプログラマは、おそらくループの反復処理をこのように見たことがない、それは、注意を払うループのために最もに使用される標準的な慣習ややハックだといない、それが割り当てxとy、上の終了をチェックlen0に到達し、インクリメントの両方xとy。それはあなたが期待するものではありませんが、それは有効なコードです。
- 現在の文字をの一致する文字位置に割り当て
strます。
- これは、現在の文字が英数字または文字の1つであるかどうかをチェックし
_-.、そうでない場合は、ルックアップを実行するURLENCODEとほぼ同じ割り当てを行いますが、y++ではなくを使用して、異なる方法でインクリメントしますto[1]。これは、文字列はさまざまな方法で構築されていますが、いずれにしても最終的に同じ目標に到達します。
- ループが終了して長さがなくなったとき、実際には文字列を終了して
\0バイトを割り当てます。
- エンコードされた文字列を返します。
違い：
- UrlEncodeはスペースをチェックし、+記号を割り当てますが、RawURLEncodeはしません。
- UrlEncodeは
\0文字列にバイトを割り当てませんが、RawUrlEncodeは割り当てます（これは問題になる可能性があります）
- 彼らは異なって反復します、1つは不正な形式の文字列でオーバーフローする傾向があるかもしれません、私はこれを示唆しているだけで、実際には調査していません。
それらは基本的に異なって反復し、ASCII 20のイベントでは+記号を割り当てます。
EBCDICの違い：
URLENCODE：
- ASCIIと同じ反復セットアップ
- それでも「スペース」文字を+ 記号に変換します。注-これはEBCDICでコンパイルする必要があると思います。そうしないと、バグが発生しますか？誰かがこれを編集して確認できますか？
- それチェック本チャーは前チャーであるか
0であることを除いて、.または-、OR未満Aしかしチャーより大きい9、ORより大きいZ未満aではありません_。またはより大きいz（そうです、EBCDICは動作するように少し混乱しています）。それらのいずれかに一致する場合は、ASCIIバージョンにあるのと同様のルックアップを実行します（os_toasciiでのルックアップは必要ありません）。
RAWURLENCODE：
- ASCIIと同じ反復セットアップ
- EBCDICバージョンのURLエンコードで説明されているものと同じチェックですが、それがより大きい場合
z、~URLエンコードから除外されます。
- ASCII RawUrlEncodeと同じ割り当て
\0返される前に、バイトを文字列に追加します。
グランドサマリー
- どちらも同じhexcharsルックアップテーブルを使用します
- URIEncodeは文字列を\ 0で終了しませんが、rawは終了します。
- EBCDICで作業している場合は
~、UrlEncodeが管理しないRawUrlEncode を使用することをお勧めします（これは報告されている問題です）。ASCIIとEBCDIC 0x20はどちらもスペースであることは注目に値します。
- それらは異なる方法で反復し、1つはより速く、1つはメモリまたは文字列ベースのエクスプロイトになりやすいかもしれません。
- URIEncodeはスペースを
+に作り、RawUrlEncodeは%20配列ルックアップを介してスペースを作ります。
免責事項：私は何年もCに触れていません。また、EBCDICを本当に長い間見ていません。どこか間違っている場合はお知らせください。
推奨される実装
これらすべてに基づいて、rawurlencodeはほとんどの場合に行く方法です。Jonathan Finglandの答えに見られるように、ほとんどの場合それを使います。これは、URIコンポーネントの最新のスキームを扱います。urlencodeは昔ながらの方法で+は「スペース」を意味します。
古い形式と新しい形式の間で変換しようとしている場合は、コードが失敗して、デコードされた+記号であるものを誤ってダブルエンコードすることによってスペースに変換しないようにしてください。スペース/ 20％/ +問題。
新しいフォーマットを好まない古いソフトウェアを備えた古いシステムで作業している場合は、urlencodeを使用してください。ただし、古い標準では％20が機能していたので、％20は実際には下位互換性があると思います優先。あなたが遊んでいるなら、それを試してみてください、それがあなたのためにどのようにうまくいったかを教えてください。
基本的に、EBCDICシステムが本当に嫌いでない限り、生のままにしておくべきです。ほとんどのプログラマーは、2000年以降、おそらく1990年以降に作成されたシステムでEBCDICに出くわすことはありません（これは推進中ですが、おそらく私の考えではそうです）。