<p>addslashes() 應(yīng)避免用於SQL轉(zhuǎn)義,因?yàn)樗话踩也环繱QL注入;htmlspecialchars() 用於HTML輸出以防止XSS攻擊;mysqli_real_escape_string() 可用於MySQL查詢(xún)中的字符串轉(zhuǎn)義,但僅在無(wú)法使用預(yù)處理語(yǔ)句時(shí)作為次優(yōu)選擇。 1. addslashes() 是過(guò)時(shí)且不安全的,不應(yīng)在現(xiàn)代應(yīng)用中用於SQL轉(zhuǎn)義;2. htmlspecialchars() 應(yīng)在將用戶(hù)輸入輸出到HTML時(shí)使用,以防止XSS;3. mysqli_real_escape_string() 雖比addslashes() 更安全,但仍不如預(yù)處理語(yǔ)句可靠。最佳實(shí)踐是:使用預(yù)處理語(yǔ)句防止SQL注入,使用htmlspecialchars() 防止XSS,絕不使用addslashes() 進(jìn)行安全防護(hù)。 </p>
<p><img src=&quot;/static/imghw/default1.png&quot; data-src=&quot;https://img.php.cn/upload/article/000/000/000/175356165337848.jpg&quot; class=&quot;lazy&quot; alt=&quot;A Comparative Analysis: `addslashes()` vs. `htmlspecialchars()` vs. `mysqli_real_escape_string()`&quot;></p>
<p> When handling user input in PHP, especially when interacting with databases or rendering content in HTML, it's crucial to properly sanitize and escape data. Three commonly used functions— <code>addslashes()</code> , <code>htmlspecialchars()</code> , and <code>mysqli_real_escape_string()</code> —are often confused due to their similar-sounding purposes. However, they serve very different roles. Let's break down each one and compare them in terms of purpose, use cases, and security implications. </p>
<img src=&quot;/static/imghw/default1.png&quot; data-src=&quot;https://img.php.cn/upload/article/000/000/000/175356165448986.jpeg&quot; class=&quot;lazy&quot; alt=&quot;A Comparative Analysis: `addslashes()` vs. `htmlspecialchars()` vs. `mysqli_real_escape_string()`&quot;><hr>
<h3> 1. <strong><code>addslashes()</code> – Add Backslashes Before Special Characters</strong>
</h3>
<p> <strong>Purpose:</strong><br> <code>addslashes()</code> adds backslashes before predefined characters: single quote ( <code>'</code> ), double quote ( <code>&quot;</code> ), backslash ( <code>\</code> ), and NULL bytes.</p><pre class='brush:php;toolbar:false;'> $input = &quot;O&amp;#39;Reilly&quot;;
echo addslashes($input); // Output: O\&amp;#39;Reilly</pre><p> <strong>Use Case:</strong><br /> Historically used to escape strings before inserting them into SQL queries— <strong>but this is outdated and unsafe</strong> . </p><img src=&quot;/static/imghw/default1.png&quot; data-src=&quot;https://img.php.cn/upload/article/000/000/000/175356165665555.jpeg&quot; class=&quot;lazy&quot; alt=&quot;A Comparative Analysis: `addslashes()` vs. `htmlspecialchars()` vs. `mysqli_real_escape_string()`&quot; /><p> <strong>Problems:</strong></p><ul><li> Doesn&#39;t account for character encodings (eg, multi-byte issues).</li><li> Not SQL injection-proof.</li><li> Database-agnostic but not reliable.</li></ul><p> <strong>Bottom Line:</strong><br /> ? <strong>Avoid for SQL escaping.</strong> It&#39;s a naive approach and should not be used in modern applications. </p><img src=&quot;/static/imghw/default1.png&quot; data-src=&quot;https://img.php.cn/upload/article/000/000/000/175356165714072.jpeg&quot; class=&quot;lazy&quot; alt=&quot;A Comparative Analysis: `addslashes()` vs. `htmlspecialchars()` vs. `mysqli_real_escape_string()`&quot; /><hr /><h3 id=&quot;strong-code-htmlspecialchars-code-Convert-Special-Characters-to-HTML-Entities-strong&quot;> 2. <strong><code>htmlspecialchars()</code> – Convert Special Characters to HTML Entities</strong></h3><p> <strong>Purpose:</strong><br /> Converts specific HTML characters to their corresponding HTML entities to prevent XSS (Cross-Site Scripting) attacks when outputting data in HTML.</p><pre class='brush:php;toolbar:false;'> $input = &amp;#39;&lt;script&gt;alert(&quot;XSS&quot;)&lt;/script&gt;&amp;#39;;
echo htmlspecialchars($input);
// Output: &lt;script&gt;alert(&quot;XSS&quot;)&lt;/script&gt;</pre><p> <strong>Escapes These Characters:</strong></p><ul><li> <code>&</code> → <code>&</code></li><li> <code>&quot;</code> → <code>&quot;</code></li><li> <code>&#39;</code> → <code>&#039;</code></li><li> <code><</code> → <code><</code></li><li> <code>></code> → <code>></code></li></ul><p> <strong>Use Case:</strong><br /> ? Use when <strong>displaying user input in HTML</strong> (eg, in forms, comments, profiles).</p><p> <strong>Does NOT protect against SQL injection.</strong><br /> It&#39;s for <strong>output escaping in HTML</strong> , not for database queries.</p><hr /><h3 id=&quot;strong-code-mysqli-real-escape-string-code-Escape-Special-Characters-for-MySQL-strong&quot;> 3. <strong><code>mysqli_real_escape_string()</code> – Escape Special Characters for MySQL</strong></h3><p> <strong>Purpose:</strong><br /> Escapes characters that have special meaning in SQL (like quotes, backslashes, etc.) <strong>in the context of the current MySQL connection&#39;s character set</strong> .</p><pre class='brush:php;toolbar:false;'> $escaped = mysqli_real_escape_string($connection, $input);</pre><p> <strong>Why It&#39;s Better Than <code>addslashes()</code> :</strong></p><ul><li> Aware of the connection&#39;s character set (prevents encoding-based SQL injection).</li><li> Properly handles multi-byte characters.</li><li> Designed specifically for MySQL.</li></ul><p> <strong>Use Case:</strong><br /> ? Acceptable for escaping strings in dynamic SQL queries—if you&#39;re not using prepared statements.</p><p> <strong>But Note:</strong><br /> ?? Still not as secure or clean as <strong>prepared statements</strong> .</p><hr /><h3 id=&quot;Key-Comparison-Table&quot;> Key Comparison Table</h3><table><thead><tr><th> Function</th><th> Purpose</th><th> Use Case</th><th> Prevents SQLi?</th><th> Prevents XSS?</th></tr></thead><tbody><tr><td> <code>addslashes()</code></td><td> Adds backslashes</td><td> Legacy/unsafe SQL escaping</td><td> ? No</td><td> ? No</td></tr><tr><td> <code>htmlspecialchars()</code></td><td> Escape HTML characters</td><td> Outputting data in HTML</td><td> ? No</td><td> ? Yes</td></tr><tr><td> <code>mysqli_real_escape_string()</code></td><td> Escape SQL special chars (MySQL)</td><td> Escaping strings in SQL queries</td><td> ? Partially</td><td> ? No</td></tr></tbody></table><hr /><h3 id=&quot;Best-Practices-What-You-Should-Actually-Do&quot;> Best Practices (What You Should Actually Do)</h3><p> Instead of relying on manual escaping:</p><ol><li><p> ? <strong>Use Prepared Statements (MySQLi or PDO):</strong><br /> This is the gold standard for preventing SQL injection.</p><pre class='brush:php;toolbar:false;'> $stmt = $pdo-&gt;prepare(&quot;INSERT INTO users (name) VALUES (?)&quot;);
$stmt-&gt;execute([$name]);</pre><p> Prepared statements separate SQL logic from data— <strong>no escaping needed</strong> .</p></li><li><p> ? <strong>Use <code>htmlspecialchars()</code> When Outputting to HTML:</strong><br /> Always escape user-generated content before displaying it.</p><pre class='brush:php;toolbar:false;'> echo htmlspecialchars($userComment, ENT_QUOTES, &amp;#39;UTF-8&amp;#39;);</pre><li><p> ? <strong>Don't use <code>addslashes()</code> for SQL.</strong><br> It's broken by design for this purpose.</p></li>
<li><p> ?? <strong>Only use <code>mysqli_real_escape_string()</code> if you absolutely must build dynamic queries</strong> —but even then, prefer prepared statements.</p></li>
<hr>
<h3 id=&quot;Summary&quot;> Summary</h3>
<ul>
<li> <code>addslashes()</code> → Obsolete and unsafe. Avoid.</li>
<li> <code>htmlspecialchars()</code> → For HTML output. Stops XSS.</li>
<li> <code>mysqli_real_escape_string()</code> → For MySQL queries, better than <code>addslashes()</code> , but still second-best to prepared statements.</li>
</ul>
<p> <strong>The real answer?</strong><br> Stop escaping manually. Use <strong>prepared statements</strong> for SQL and <code>htmlspecialchars()</code> for HTML output. That's how modern PHP apps stay secure.</p>
<p> Basically:<br> ? SQL? → <strong>Prepared statements</strong><br> ? HTML? → <strong><code>htmlspecialchars()</code></strong><br> ? Never use <code>addslashes()</code> for security.</p>
以上是比較分析:'addslashes()`vs.htmlspecialchars()的詳細(xì)內(nèi)容。更多資訊請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章!