Christian F.

You could always use the "num_rows" property/function of the SQL library you're using. For MySQLI it's mysqli_result::$num_rows and for PDO it's PDOStatement::rowCount. Unfortuantely PDO doesn't guarantee it's available for all RDBM systems, but it should be available for MySQL.

As you've correctly determined, you don't need to use a regular expression for this. However, try with using this instead of the stristr call: if (strpos ($line, "window.open") !== false)) {

If you want to match an exact string, then use "==". Regular expressions are for allowing permutations of strings, or in other words: Non-exact matches.

I think that you should find the PHP manual a very good resource for your questions, especially the function reference section. As far as not needing to learn about "arrays and sorting and other things": That is exactly what you need to learn about, especially basic variable types such as arrays. Saying that you don't need to learn about them is like saying that you don't need to learn about grammar or syntax, but that you still want to learn a foreign language. If you're daunted by the code, and cannot see the relationships between it, it is (most likely) because you're too unfamiliar with the syntax and vocabulary. The only solution to that, is to read more up on it, get to know it even better. Once you've learned it well enough, reading code will be like reading a second natural language. More or less, anyway.

I'm afraid that this doesn't make any sense. What are you trying do do, which makes you think you need to do this? Is this an attempt at a bit field? Remember, the more details you give surrounding your code and problem, the more accurate and efficient help you'll get. Most of the time you might even get a better way to solve the problem on, than the one you're currently trying to employ. I suspect this will be one of those cases.

We'll need a "bit" more information than that, as you should be aware of by know... Post the code you're using, give us some examples of the strings you're using, and the different results you get. Most likely there's either some whitespace messing you up, or some differences in the (pre-)encryption process.

Most likely, yes. To get it to send out e-mails you'll need either a mail server running on your computer, or PHP configured to use an external server. Neither are default.

You'll need a web server with PHP installed, and access the page via it. PHP is a server-side scripting language, which means that it needs to be run on the server, before any content is sent to the client. Browsers does not understand PHP code, only HTML, CSS and JS. Which is why it's only showing you the code, as if the file was a pure text file (which it is, as far as the browser is concerned). For Windows you can download WAMP, which will install everything you need in one go. After you've done that, just move the files to the document root of the web server (htdocs), and then open the page via "localhost" in the browser.

str_replace

Due to the type autocasting rules, I'm afraid neither would work. php > var_dump (false >= 0); bool(true)The proper test would read like this. As you'll have to check for type as well, and not just equality: if (strpos ($value, '"') !== false || strpos ($value, "'") !== false) { return true; }

A bit busy here, so I'll make it quick: I'm fairly certain that the main problem is register_globals. Or rather, the fact that they were turned off in PHP 5 due to the security risk it presents. Make sure that all of your code uses the $_POST superglobal, when trying to access data which has been posted via a form.

If the database contains erroneous characters, then you've used the wrong charset when inserting the data in the first place. In which case the characters are irrevocably corrupted, and the only thing that can fix that is a (semi-)manual search & replace. You'll need to find out which byte sequence matches what character, and then run the search & replace on all fields, for each of those characters. Of course, you'll want to make sure that all fields and tables in the DB uses UTF-8 prior to this. So the easiest way to fix this, is to export the data, fix the tables, then search & replace each characters, and finally import the fixed SQL script. Make sure you've added a "USE NAMES utf8" statement at the top of it though, so that your data isn't corrupted again.

You don't even need a recursive function, one loop is all that's needed. Still, why is an excellent question. m0751n[7b]: This is as basic loop as you can get, and you're being more than just lazy. We're here to help those who put an effort in by themselves, but get stuck for some reason. Not to do our jobs, or yours, for free. If you want people to provide you with completed code, then the Freelance section is the correct place to post it. That said, freelancers generally expect to get paid for their time and service.

Could you please post all of the code that has to deal with the RegExp? I'm afraid I don't quite see what the connection between the RegeExp + the sample data and the array you posted is, and thus any attempt at helping would be just me guessing. Your expressions isn't quite correct either, as it seems you've added a random quantifier and a literal string inside a character block. This, and the little you've shown of the code, tells me that there might be some other sub-optimal choices made in the codebase. Something which we could help you iron out, if we had the whole block. Not to mention, I would really like to re-iterate my previous advice: You do not need to use regular expressions for this, as you're matching against complete strings. Thus you should not use regular expressions, seeing as they're both more complex and more wasteful than straight up string matches (via strpos).

You're fetching ISO-formatted text from the DB, as evidenced by this line: mysql_set_charset('ISO-8859-13',$dbc);Yet, before adding the content to the excel document, you're converting them from UTF-8 to ISO-8859-13: $out = mb_convert_encoding($str, "ISO-8859-13", "UTF-8");I reckon you can see why that is a problem. Either your data is saved as UTF-8 in the database, and you'll need to correct the MySQL charset; Or your data is saved as ISO-8859-13, and you don't need any converting. Why you're converting the text from ISO-8859-13 to ASCII later, I have no idea. Suffice to say it's completely useless, and can even cause problems with displaying some of the special diacritics used by your language. Preferably there shouldn't be any need for any converting of charsets what-so-ever, since Excel supports UTF-8 just fine.

Nothing to deny, my sammies are good!

Same goes for shell_exec, btw.

You're welcome, glad we could help.

Yes, "cd" does not change the working dir of PHP, but the "instance" of the shell that gets invoked using "exec". And each execution is a separate instance. Also, any particular reason why you're trying to use shell commands instead of the built-in PHP commands like glob?

If you know you posted it in the wrong section, please ask a mod/guru to move it to the correct location. Do not make another thread with the same content. That's just wasting everyone's time. Copy thread: http://forums.phpfreaks.com/topic/276843-need-help-possible-variable-issue

You have any pictures of what it is that you want to do? Also, check the mail headers for any mails that you have that displays this behaviour. Might be something specific to your mailing client, after all.

Just had a second look at your code, and I see that you're not setting the (correct) charset anywhere. You'll also have to tell the MySQL connection to use UTF-8, otherwise you'll have problems there too. As for how to "adapt to [your] code" I'm not even sure what you're looking to adapt even. As previously mentioned, you do not need to convert anything, so the code in your second block is unnecessary. PS: You should also be looking to change to MySQLI or PDO, as the old mysql library is outdated and deprecated.

If you change the charset information in the first code block, it should work. As you're not converting between charsets at all, but still declare it as ISO-8859-13, it explains why those non-ASCII characters comes up corrupted.

For this you really should be looking at JOINs. Running queries inside loops is really inefficient, as you've noticed, and it wastes time like nothing else. This is also what relational databases do best, retrieve data from related tables via a JOIN statement. Quick example: SELECT m.`cat_id`, m.`name`, s.`cat_id`, s.`name` FROM cats AS m LEFT JOIN cats AS s ON s.`parent_id` = m.`cat_id`

Magic quotes was intended to be a safeguard against SQL injections, it failed miserably and became a source of data corruption instead. It is strongly recommended to turn them off, as soon as possible. Chances are very high that this is what's causing your inability to use find a proper RegExp that validates a string with a single quote. (As the magic_quotes adds a backslash as a part of the content of the string.) The only proper protections against SQL injections is proper escaping of the output, but only just before adding the content to the output string that you're sending to the third party system. Do not overwrite the original values, as that will (most likely) cause the same data corruption problems as magical_quotes. Prepared Statements is the most recommended method for this, as it utilizes the database engine to do the proper escaping manually.