phdphd Posted November 12, 2013 Share Posted November 12, 2013 Hi All, I would like to share a strange experience with you and get your opinion about it. The issue is that a php file is not processed as expected, apparently due to the html code line <meta charset="utf-8" />, hence the presence of my post in the HTML section of the Forum. My config is PHP 5.3.25/Mysql 5.6.11. I am trying to adjust my website so that it is fully utf-8 aware. I am presently adjusting all my php files for that purpose. Basically, I have an index.php file with links to different processes the user can start. Every process involves a series of forms and is made up of one file (called process-to-do.php) and a series of php files that the process-to-do.php file calls one after the other via include file instructions (every included file contains a form). All works great. In Notepad++ (with default encoding previously set to utf-8 ) in order to make every php file utf-8 aware, and to avoid retyping all the code, I sequentially created a new php file, saved it with the same name as the legacy non-utf-8 file, and pasted a basic html5 code structure in it. Then I pasted the legacy pieces of code and made utf-8 adjustments where appropriate. FYI the basic html5 code structure I insert is <!DOCTYPE html> <html lang="fr"> <head> <meta charset="utf-8" /> <title>Titre</title> <link rel="stylesheet" href="style.css"> </head> <body> </body> </html> This process worked great until a certain file was called for inclusion. What happens visually is that this file is not displayed and that the index.php file is displayed instead. In other words the user is redirected back to the starting point where they choose what to do, without the ability to validate the form in the called file and to go to the next step. At first sight it seems that the called file is just ignored. But actually it is not. I noticed that the php contents of the file is successfully processed (there is some php that sends some data to a database and that job is done). I first thought that some php code was corrupted and causing the issue. I deleted the php code and I reexecuted the process. Again, the file would not display and the user would be redirected back to the starting point (index.php file). This indicated that php code was not causing the issue. OK. So I thought the form html code itself was corrupted. I deleted it and I reexecuted the process with only the basic html5 code structure in the file. Again, the file would not appear and the user would be redirected back to the starting point (index.php file). This indicated that the form html code was not causing the issue. OK. So I thought "let's do it the other way by keeping only the form html code, without html5 code structure". I reexecuted the process and that time, the file displayed, though with incorrect accent formatting due to the absence of the html utf-8 formatting. To go further I decided to add just the head section to the file to see if I could recover the utf-8 formatting. Failure again : the file would not appear and the user would be redirected back to the starting point. So I added the doctype and the html tags, without the head section. That time, the file displays again, though with incorrect accent formatting due to the absence of the html utf-8 formatting. Then I added the head section without the <meta charset="utf-8" /> line to get a 99,999% confirmation that this single line was causing the issue. As expected, the file displayed again, though with incorrect accent formatting due to the absence of the html utf-8 formatting. I made a final test -BTW congratulations to all of you who reached that point in my post - by inserting the header('Content-type: text/html; charset=utf-8'); php piece of code at the beginning of the included php file, and then the file was correcty processed and displayed. My questions are (a) why can a mere <meta charset="utf-8" /> line apparently cause such an issue, and (b) why in this included php file and not in the previous ones in the sequence ? Thanks! Quote Link to comment Share on other sites More sharing options...
AbraCadaver Posted November 12, 2013 Share Posted November 12, 2013 (edited) That was a long post with surprisingly little information. Error reporting on? What errors? Just a shot in the dark, are you using sessions and are you saving the BOM in your files? Notepad++: Settings > Preferences > New Document > UTF-8 without BOM, Apply to opened ANSI files? The BOM will cause issues, especially with sessions. Edited November 12, 2013 by AbraCadaver Quote Link to comment Share on other sites More sharing options...
phdphd Posted November 12, 2013 Author Share Posted November 12, 2013 (edited) Thanks for your answer. Yes, I use sessions. Files are saved without BOM. No errors reported. (To be more precise there is a warning reported about the use of the php date function in the file, but as I wrote in my post, the issue also occurs when the file contains no php code). BTW I see no "Apply to opened ANSI files" equivalent option in my Notepad++ French version. However "ANSI as UTF-8" appears at the bottom right of Notepad++ status bar. Edit : I misread your Notepad++ sequence. Yes, the "UTF-8 without BOM, Apply to opened ANSI files" option is selected. Edited November 12, 2013 by phdphd Quote Link to comment Share on other sites More sharing options...
AbraCadaver Posted November 12, 2013 Share Posted November 12, 2013 (edited) Well, we'll hope that somebody with more charset knowledge than me reads this, as that is the extent of my knowledge there. Edited November 12, 2013 by AbraCadaver Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.