Leaderboard

This is just a matter of two separate levels of escape sequence processing that you need to wrap your mind around, which can be difficult at times. When you're setting a string in PHP first you have PHP's escape sequence processing. PCRE then has it's own level of processing that is done on the value that was passed to the function. For example, if you wanted to use \0 in a replacement literally rather than have it interpreted as a back reference you have to pass the string '\\0' as your replacement. If you're defining value in your PHP source as a string then you need to escape those slashes again for PHP's sake so you have $replacement = "\\\\0" If you get the value from a file or database you don't have to worry about the PHP level of escaping, but do still need to account for the PCRE level so you need your file to contain \\0 not just \0. It's not clear to me exactly what output you're expecting in your code sample. The addslashes call effectively mitigates PHP's escaping meaning $replacement is set to the literal value "<pre>\\\\</pre>". preg_replace will then see that and process it's own escaping which means the value it's working with is effectively "<pre>\\</pre>". That means your final replaced output would be "<div><pre>\\</pre></div>" If you have "<pre>\\\\</pre>" stored in your database and are pulling that value from there then you should get the same result, just don't run it through addslashes() as you don't have to deal with the PHP level of escaping things.

Is this what you want to achieve Receipts Batch | a | b | c | d | Date | 2020-01-01 | 2020-01-02 | 2020-01-03 | 2020-01-04 | Qty | 15 | 10 | 23 | 30 | ------------------------+--------------+--------------+--------------+--------------+ Issues | | | | | | | | | | 2020-01-01 10 | 10 | | | | 10 from batch a 2020-01-02 7 | 5 | 2 | | | 5 from batch a, 2 from batch b 2020-01-03 25 | | 8 | 17 | | 8 from batch b, 17 from batch c 2020-01-04 16 | | | 6 | 10 | 6 from batch c, 10 from batch d