Jump to content

phdphd

Members
  • Posts

    248
  • Joined

  • Last visited

Everything posted by phdphd

  1. Hi All, I am applying some htmlspecialchars to strings before displaying them to the user. In theory, there are 2 situations : 1/ when the user submits a form, I display the just-entered data as plain text at the top of the next form to tell the user that their entries have been taken into account. 2/ Should the user make a mistake while filling a form, the form is displayed again with form fields ("value" parameters of input tags) prefilled so that correctly-entered data does not need retyping. In both cases, I use the syntax echo htmlspecialchars($string) to display the data. To simulate both cases at the same time, I have put echo htmlspecialchars($string) both into a "value" parameter of an input tag and outside this input tag, and left some mandatory fields blank to force the form to display again. The string tested is <<<<<<"<<<<<<. From the user's point of view, the string is reproduced as is in both cases. However the html output differs : where the string is plain text, the html output is <<<<<<"<<<<<< (every character is converted except the double quote), whereas where the string is the content of the "value" parameter of the input tag, the html output is <<<<<<"<<<<<< (only the double quote is converted). I have 3 questions : 1. Since I did not use ENT_NOQUOTES, why the double quote did not get converted in the plain text situation ? (official doc : '"' (double quote) becomes '"' when ENT_NOQUOTES is not set. ). 2. Why the "less than" characters remained untouched in the input tag situation (official doc : '<' (less than) becomes '<' ). 3. Does this apparent lack of conversions bear some risks as far as the html structure of the whole page is concerned? Thanks! (PHP version : 5.3.25)
  2. 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.
  3. 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!
  4. Thanks a lot Requinix. I think the problem was that my php file was initially a non-utf-8 file that I had resaved to utf-8. I created a new php file, saved it to utf-8 format, then pasted in it some pieces of code. So for whom it may be useful, the pregmatch regex instruction that works for me is if (preg_match('#[[:alnum:]]#u', $_POST['regex'])) One can even mix chars from left-to-right and right-to-left alphabets. Thanks again, have a nice Sunday.
  5. Thanks for your reply. Unfortunately neither works when special chars are involved, like in the German string "Schönen Tag". Is there something wrong in my UTF-8 setting ? My php file is UTF-8 saved and the contents of the POST is converted to UTF-8 using htmlspecialchars($_POST['regex'], ENT_NOQUOTES, 'UTF-8');.
  6. Indeed, this is the first thought that came to my mind when I woke up this morning . So coming back to your suggestion and since the character encoding is UTF-8, what would be the right regex syntax combining [[:alnum:]] with the /u flag ? All regexes that I tried (like /#[[:alnum:]]#/u) return either false or a modifier issue. Thanks.
  7. Actually #[^[:alnum:]]# will accept "hello world öÄßáéíóúÁÉÍÓÚüÜñÑ" or just "öÄßáéíóúÁÉÍÓÚüÜñÑ" but not just "world". It seems it needs at least one "special" character (that could be a space). I think I finally found the solution by combining both regexes. The one below accepts strings like "solution", "öÄáéíóúÁÉÍÓÚ" and "a f öÄßáéíóúÁÉÍÓÚ t üÜz z z z ñÑ dsd dfd ?! hope I found the solution now :-(" "[^[:alnum:]]|[[:alnum:]]"
  8. Hi All, I am trying to set up a pregmatch that validates some data entered by the user. Since my website is intended to any European-language speaking people (including German, Swedish, Spanish, etc.), I am testing it with a string that contains characters from most of those languages. I initially thought that a simple #[[:alnum:]]# would do the job. It actually works fine for English, French and Spanish, but it still does not accept the test string. Any help welcome. Thanks !
  9. Hi All, I have a web page where I load a radio-button list of about 10000 cities. This list appears in a vertically scrolling zone. To get the list as much visually uncluttered as possible, every city name appears "alone", however under the hood every city name is associated with a radio button. Basically every city name has the following formatting : <li><input style="display:none;" type="radio" name="rb_group_name" value="[city_name]" id="[city_id]" onclick="this.form.submit()"><label style="cursor:pointer" for="[city_id]"><span class="name_format">[city_name]</span></label></li> The name_format class is associated with some css that determines the aspect of a city name according to its state (not hovered using the mouse/hovered). This page takes only a few seconds to load in FF, Chrome, Opera, and even in - though not as fast- Safari. But in IE 10, it takes up to 30 seconds for the city list to be actually scrollable, even though it is populated. I tried to reset the IE settings to their default values, and to disable add-ons, but this did not help. (I noticed that refreshing the page in IE is as fast as first loading in others browsers. However, clicking "back" button+calling the page again from localhost results in the same issue.) Thanks in advance for your help!
  10. Very interesting. I am going to investigate key caching. I think I understand why in PHPMyAdmin even the first execution is fast. Actually I think it is just an illusion, in the sense that the time that the php script takes to gather all the indexes is apparently taken by PHPMyAdmin when one selects the database (by clicking on its name) before running the query manually under the SQL tab.
  11. Hi All, Me again, sorry . First of all I'd like to thank all of you for your patience and time dedicated to my issue, I really appreciate it, even if so far we have not found the solution. On my side I keep testing. I've just noticed something strange : assuming that my query contains SQL_NO_CACHE and that I run it through the php script, the first execution will last very long (generally between 1 to 3 minutes). If I reload the php page, I noticed the execution lasts only one second. At first I thought the recordset could be cached somewhere else than in the query cache. So to clarify this I tried to make a slight change to my query : trying another partition. And against the new partition, the query ran as quick as when reloading. It is like if on the first execution the query wanted to "make acquaintance" (sort of indexing?) with all of the partitions. I would like to know your opinion on this. Thanks.
  12. Yes, this is a true representation of the query. However table1.fieldX does not represent the same data as table2.fieldX. The reason for partition is that table1 contains 4 millions records, and the partition "only" about 400k.
  13. The code I initially posted was complete and actual code. I just changed it a bit when I was asked if I was sure the recordset was the same in both cases. I was 100% sure it was, but to satisfy the request I just added a while loop with an echo line to have the results displayed in the browser and have the visual proof that the recordset returned there was the same as the one returned in phpmyadmin. Yes I use the same database username in phpmyadmin and in my php code.
  14. Here are the explain outputs, reformatted for better readability. The first two lines represent the output in phpmyadmin, as displayed by phpmyadmin. The last two lines represent the output as displayed in firefox, using a while loop in the php script with an echo line that displays the contents of each column. The only difference is that while the output from phpmyadmin displays "null" for the last field (Extra) of the second line, the output in firefox displays nothing. id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE events ref PRIMARY,fk_events_cns1,city,cn_city cn_city 334 const,const 3844 Using where; Using index; Using temporary 1 SIMPLE event_crit ref fk_event_crit_events1,crit_pert fk_event_crit_events1 4 mydb.events.event_id 21 NULL 1 SIMPLE events ref PRIMARY,fk_events_cns1,city,cn_city cn_city 334 const,const 3844 Using where; Using index; Using temporary 1 SIMPLE event_crit ref fk_event_crit_events1,crit_pert fk_event_crit_events1 4 mydb.events.event_id 21 EDIT: Oops, seems the table formatting did not work. I hope the data are still relevant anyway.
  15. the magic happening for me would be getting the results through the php script as quick as from within phpmyadmin :-(
  16. Yes I am sure the results are the same, exactly 33 records in both cases (in the php script, I use a while loop with an echo line that displays the contents of the 2 fields record by record).
  17. I confirm that with SQL_NO_CACHE and after computer rebooting+server starting, the results are returned immediately. Yes. Yes.
  18. As I said earlier to get objective results I always run the query after rebooting the computer and restarting the server, so that no previously cached data is available. I confirm that the query returns results immediately from within phpmyadmin.
  19. mysqli does not really help. I am not sure that php is the "guilty" part indeed. If I run the query in a standalone mode from within FlySpeed SQL Query, it still takes a very long time to run. So , so far, it just works as expected when executed from within PHPMyAdmin.
  20. Yes, the PHP code I posted is the complete code. Actually it is just aimed at sending the query and measuring the time elapsed for processing the query. If I just change the query line to a query that runs against a non partitioned table but equivalent in size and in number of records to be returned, the same results are returned in a couple of seconds. My feeling is that when running against the partitioned table, all partitions are parsed, instead of the mentioned partition being directly queried. In UwAmp, in PHP settings dialog box, both php_mysql.dll and php_mysqli.dll are enabled. In phpmyadmin, in "Web Server" section, mysqli is mentioned as a PHP extension. The same section also indicates "Apache/2.2.22". Also when I open http://localhost/partition_vs_non_partition/ page, "Apache/2.2.22 (Win32) PHP/5.4.15 Server at localhost Port 80" appears at the end of the page.
  21. Putting "127.0.0.1" instead of "localhost" does not help. Also with "localhost", If I run the same query through a php script against a non-partitioned similar-size table, the query is very quick. There seems to be an issue with php dealing with partitioned tables.
  22. Hi All, I am facing a situation where the exactly same query is very quick from within phpmyadmin (less than 1s) and very slow through a php script (up to 2 minutes). To obtain objective measures, in both cases, the query is executed only after restarting the computer, and turning the server on. The environment is mysql 5.6.11/php 5.4.15. This query returns just 33 records. It runs against a partitioned table and contains an inner join with another table. The php test script structure is very simple : $connexion = mysql_connect(...); mysql_select_db('db', $connexion) $time = microtime(TRUE); $sql = 'SELECT distinct `field1`, ` field2` FROM `table1` partition (p1) Inner Join table2 On table1.id=table2.id Where table2.field1 = "something" And table2.field2 = " something_else"'; $rs = mysql_query($sql, $connexion); echo '<pre>'; print_r(array('time elapsed' => microtime(TRUE) - $time)); echo '</pre>'; mysql_close($connexion); Is there something wrong on PHP's side ? Thanks !
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.