|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2012-06-18 21:28 UTC] patrickallaert@php.net
-Assigned To:
+Assigned To: patrickallaert
[2012-06-18 21:54 UTC] patrickallaert@php.net
[2012-06-18 21:57 UTC] patrickallaert@php.net
[2012-06-18 21:57 UTC] patrickallaert@php.net
-Status: Assigned
+Status: Closed
[2012-06-18 22:00 UTC] patrickallaert@php.net
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Fri Nov 07 11:00:01 2025 UTC |
Description: ------------ When you have code that receives data that may be perceived as broken UTF-8 and you have a full UTF-8 config for MySQL then MySQL will truncate the backtrace up to the first broken byte. Suggested fix: Since APM can not know what data it is dealing with, it should not make any assumptions either. Convert the BACKTRACE field in the MySQL schema to the BINARY character set: ALTER TABLE event MODIFY backtrace CHARACTER SET BINARY; Test script: --------------- <?php function h($str) { return htmlspecialchars($str, ENT_QUOTES, 'UTF-8'); } function stuff($bericht) { $y = h($bericht); } stuff("lalala \xE9 bork bork"); Expected result: ---------------- This backtrace: #0 htmlspecialchars("lalala ? bork bork", 3, "UTF-8") called at [test.php:5] #1 h("lalala ? bork bork") called at [test.php:11] #2 stuff("lalala ? bork bork") called at [test.php:14] Actual result: -------------- This backtrace: #0 htmlspecialchars("lalala