 |
 |
Ugh, that third step is ugly to require the user to do that. Will it work okay in MS Access if you skip that part, will Access be okay with just \n? If not, I might actually try sniffing the OS from the user-agent and converting line-endings to appropriate for that OS before delivering the file; making people do that extra step would make me sad. On 1/12/2011 10:34 AM, Doran, Michael D wrote: >> For future reference, Notepad will only recognize "\r\n", not "\r" or >> "\n" alone. Also, use Wordpad or Notepad++ instead. > That's been my experience, too. > > These are my instructions to staff for downloading a delimited text file from one of our (Unix) web servers to their PC: > > 1) Right-click and select "Save Target (or Link) As..." > 2) Save the file in desired directory > 3) Once the file is saved, open it in WordPad and re-save > 4) Optional: import the file into MS Access > > After step 3, they can also view it okay in Notepad. Opening and re-saving the file in WordPad apparently converts the Unix line-endings to the Windows line-endings. > > -- Michael > > >> -----Original Message----- >> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of >> Gabriel Farrell >> Sent: Wednesday, January 12, 2011 12:09 AM >> To: [log in to unmask] >> Subject: Re: [CODE4LIB] data export help: line breaks on tab-delimited >> download >> >> For future reference, Notepad will only recognize "\r\n", not "\r" or >> "\n" alone. Also, use Wordpad or Notepad++ instead. >> >> Further reading: >> http://social.msdn.microsoft.com/forums/en-US/vclanguage/thread/cba503b1-a0e2- >> 4a64-a970-f735c5bc1c90 >> http://www.baanboard.com/baanboard/showthread.php?t=9069 >> >> On Tue, Jan 11, 2011 at 7:57 PM, Ken Irwin<[log in to unmask]> wrote: >>> Jonathan's questions were right on target. I was opening the files in the >> standard MS Notepad editor, and it was not observing line breaks. When I went >> to go open the files in MiniTab they were just fine. (Changing the files to >> .txt and text/plain did *not* fix the problem in Notepad, and I do wonder what >> it would take to make that program happy, but in this case it doesn't much >> matter.) >>> Thanks for the help >>> Ken >>> >>> -----Original Message----- >>> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of >> Jonathan Rochkind >>> Sent: Tuesday, January 11, 2011 3:41 PM >>> To: [log in to unmask] >>> Subject: Re: [CODE4LIB] data export help: line breaks on tab-delimited >> download >>> line breaks don't appear when you view it with what software? >>> >>> Can you have your browser save it to disk after it prompts you to do so, >>> and open with a reliable text editor you know how to use and confirm if >>> \n is really still in the file or not? >>> >>> If you are viewing it in your web brower, then your web browser is >>> probably deciding to display it as HTML. The line breaks are probably >>> still there, the web browser is just displaying as HTML. Web browsers >>> aren't great places to view text. If you are viewing it after saving it >>> to disk, then your web browser probably won't know to display as text >>> unless the filename ends in ".txt". If you are viewing it without >>> saving to disk (but then why are you using >>> Content-Disposition:attachment?), then make sure you're still setting >>> the content-type appropriately; and you may need to make the filename >>> end in .txt anyway. >>> >>> The line breaks are probably still there, your web browser is just >>> rendering the file as html rather than txt, is my guess. >>> >>> On 1/11/2011 3:29 PM, Ken Irwin wrote: >>>> Hi all, >>>> >>>> I've got a dataset that I'm trying to make exportable for MiniTab, etc. >> It's tab-delimited and lines end with "\n". >>>> When I serve it up as "text/plain" and view it in my web browser, it works >> just fine and all the line breaks are in the right places. >>>> When I send the header to make it a downloadable "attachment": >>>> Content-Disposition: attachment; filename="categories.tab" >>>> Then there are no line breaks at all - it's all one line, and the line- >> breaks don't appear. >>>> I tried "\r" instead, and that didn't work either. >>>> >>>> Any idea what I might be doing wrong here? >>>> >>>> Thanks >>>> Ken >>>>