Hi Edward, > I hope I don't annoy you. If so, please tell me.
Not at all - you'll be the first to know! However you/I would be more comfortable if things were kept on the list - (a) others might 'jump in' and solve your problem before I find the time/inspiration, and (b) everyone with similar problems can learn from you! Please tell me if there are sentences in my messages, that you have difficulty understanding/translating - I'm quite used to working in a multi-lingual situation (but quite confident that I cannot converse with you as well as you can with me!) > >My first thought is that you have a neat system of encoding the link data > >being stored in MySQL. > > > >I assume this is preceded by some sort of 'extract' function which takes > >the link out of some HTML page? That > >being the case, and particularly if you are using a PREGI to accomplish > >the 'extraction', why don't you store > >the two components of the HTML link in two separate columns? So "<a > >href="http://www.test.com";> test </a>" could > >become "www.test.com" and "test". The disassembly step being part of the > >(presumed) existing PREGI and > >reassembly afterwards being a snap - seems easier than all those > >EREGI_REPLACEs! > > Yes, indeed, this was the first thing I thought to, but I can't store them > separately, because they are being part of an large amount of other stuff > and tags (i.e. a HTML content of a web page). Does this mean that you don't just use MySQL to store a short string, eg the "<a>href="http://www.test.com";> test </a>" you have mentioned to-date, but that this is a small portion of a chunk/whole page of HTML stored in the db/tbl? There is no reason why you cannot store both 'small bits' of the code, and the whole of the rest of a page, separately/together/alongside each other - check out how PHP templating systems work! (that process involves exactly the same functionality as you have here) > > > Here is the code for input: > > > -------------- cut----------------- > > > mysql_select_db("falrdb",$con) or die ("nu pot"); > >* > > > $chtml=eregi_replace('<',' \[st]',$chtml); > >* > > > $chtml=eregi_replace('>','\[dr] ',$chtml); > >* > > > $ins= "INSERT INTO continut (cef) VALUES > > > '$chtml')";$rezins=mysql_db_query("falrdb", $ins, $con); > >** > > > -----------------cut-------------------------- > > > > > > Here is the code for output: > > > > > > -------------------cut------------------ > > > > > > $q="select * from continut"; > > > > > > $rez=mysql_db_query("falrdb",$q); > >** > > > $zz=mysql_fetch_row($rez); > >* > > > $zz[0]=eregi_replace('\[st]','<',$zz[0]); > >* > > > $zz[0]=eregi_replace('\[dr]','>',$zz[0]); > >* > > > $zz_fsh=stripslashes($zz[0]); > >* > > > echo "$zz[0]"; > > > > > > ---------------------cut--------------------------- > > > > > >Do I observe STRIPSLASHES() but no ADDSLASHES()? > Yes. A friend, more experimented than me told the ADDSLASHES() is not > required if the magic_quotes_gpc are "on" Ok, I NEVER use such things - I like to convince myself that I am in charge, and the computer will do nothing behind my back/without my explicit instruction (yes, I'm fooling myself, but it's a 'reality' I've grown comfortable with). So I cannot comment on the effect of combining magic_quotes with a *SLASHES(). I would be tempted to remove the STRIPSLASHES() altogether and observe the debug ECHOs closely to observe any differences. Next suggestion: what happens if you turn magic_quotes off, and if necessary put a pair of *SLASHES() back in? > >Recommend the addition of a debug ECHO "<BR>chtml=$chtml~"; (or > >equivalent) at every line where I have marked *. > > > >Recommend the addition of a validation step to assure the MySQL interface > >calls where I have marked **. > > Done. The result was the same... ECHO is working fine... :) > > >The last/only ECHO statement examines the reconstituted HTML link BEFORE > >the call to STRIPSLASHES() - not the > >resultant value!? > > Damn!!! 10x. After correcting the problem, there are still links that work > and that don't work, even after printing the correct value!!! Please post a couple of examples of those that worked, and five or six of those that failed. I would also like to see a copy of the debug output (as discussed above) showing one (or more) running through these sequences of instructions in the script. > >Is cef the first field in continut? > > Is the only important field, and is the content. (the other one is the id > (auto_increment field) used for index of the table) This was not the reason I asked the question - I was keen to ensure that what was returned from the db by the SELECT/mysql_db_query() was the cef value and NOT an ID (or something else). Are you confident that the value returned is the correct field and a valid/correct value for cef? > > > I hope that it will be OK for debugging... If not, I'll send you more > > > >Don't hesitate to be 'generous' - the more you show, the better the chance > >that we'll spot something out of > >place! > > > >Once you have added the above debugging ECHOs, please run the routine and > >show what happens with a sample that > >works, and then two or three samples that don't. See re-request for this info (above) > It' above the normal!!! URL's that work and that don't. On the same page... Agreed, it is quite abnormal/unusual, but there MUST be a logical reason for it, however illogical ! To supplement my (lack of) knowledge in the server arena, perhaps you should re-state the question as an Apache?IIS request to the list. Is it possible that the server is somehow interpreting the URL as a local address instead of a remote Internet address, and causing some sort of re-direction? Only mention the URL's appearance in the db and it's eventual value in the browser, the type of browser and server you're using, and see if anyone can offer advice. > QUESTION: it is possible that the HTML code provided to contain some > characters that can not be translated by the MySQL?! Because at that time, > this is the only valid reason I can see. Unfortunately you have not provided URLs so that we can see how complex they are/what characteristics are faced. Now is the time to do so! Have you considered the applicability of htmlspecialchars()? Regards, =dn --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
