EBAY File Exchange Description field stuff

Joseph_Sliker

Hi;

PREAMBLE/CONTEXT
I find listing stuff on Ebay to be a royal pain. I'm sure they have a lovely elegant database underlying everything that makes perfect sense to them, but when one of us mere mortals (or our wives) has a ton of miscellaneous stuff to list, their a-la-cart item lister, TurboLister and other tools seem way over-elaborate and time consuming.

Luckily (to a point) they have the File Exchange method where you can fill up a .csv table with stuff (so long as it is oh so carefully formatted and you understand all the fine points of their system of variables and item dimensions). Then you upload the .csv and individual items either get posted correctly or you get line by line cryptic messages about the items that failed to post.

After a couple of years of on and off putzing with this, I seem to be getting the hang of it and have developed a little web app that allows us colloaboratively (from different computers whereever we are) to build up the data needed to list items pretty efficiently and export the required .CSV file.

HERE IS THE PROBLEM
The one problem I am having is with the "Description" field. In my item entry form I use a TEXTAREA control to collect this. I know that if I use specific characters in this field (like the apostrophe, quotation marks, [Enter] key line-breaks, etc. that the Ebay file exchange process will choke on that item. Is there a way, when I run my query for MySQL or php to return allowable characters instead of those no-no's from such a (MySQL TEXT)field?

Hope this is not too vague or wordy.

Res

mysql_real_escape_string and nl2br. This will add slashes for your all your quotes while the second one will convert the \n to <br/>.

CSV can be a fickle *****, not the fault of ebay.

bradgrafelman

Res;10969042 wrote:
This will add slashes for your all your quotes

Careful - that's not all it does. It will also replace line breaks with the proper escape sequence (e.g. CRLF gets changed to "\r\n" - a string of length four). In other words, after applying [man]mysql_real_escape_string/man to a string, [man]nl2br/man is guaranteed to do nothing since there won't be any line breaks in the string.

@: CSV format can easily handle line breaks, apostrophes, all sorts of things. [man]fputcsv/man, for example, properly escapes/transforms things so that they are in proper CSV format.

It sounds like you should figure out how the eBay CSV import mechanism expects such characters to be escaped/encoded rather than simply trying to mangle the data into something that hopefully won't break the import.

EDIT: Forgot to mention... since we're talking about preparing data for a CSV import/export, [man]mysql_real_escape_string/man isn't really appropriate anyway.

Res

Sorry I've been putting CSV files into tables the last weeks, brain was hardwired to want to real_escape them. You're not putting them into a database though, sorry for the misleading advice.

Joseph_Sliker

Actually, I am wondering if this is more of a MySQL query question: Is there a way to create the SELECT statement with some MySQL function that converts the contents of the text field into something that might be more .csv-processor friendly? Like maybe the cast([field] as [type]) function? I don't know anything about the values one could use in the [type] part.

bradgrafelman

Joesph Sliker wrote:
Is there a way to create the SELECT statement with some MySQL function that converts the contents of the text field into something that might be more .csv-processor friendly? Like maybe the cast([field] as [type]) function?

Not really, no. And besides, it's quite easy to make a call to [man]fputcsvman which will do all of the work for you...