HTML to Excel



  • Recently, I have been working on a part of a reporting module for our management website. This website was is written in ASP.NET 1.1 and includes some pre-written code to export data to Microsoft Excel. Basically all I have to do is write a query and it does the rest.

    Except that it doesn't really export to Excel. Instead it simply outputs a HTML page with a giant <table> in it with a "application/vnd.ms-excel" content type.

    Amazingly this actually works, sort of. It causes Excel to use a different set of toolbars and create a bunch of extra files on save, oh and occasionally something goes wrong and it causes a mangled version our system's login page to appear in Excel, but it works, mostly.

    I wonder what else lies waiting to be discovered in this application...
     



  • Actually this is a good way that I have used and read to create an Excel sheet over the web... no WTF here. This way no file is actually created on the server. If the output for HTML was in XML instead it does allow for more formatting options. And if the user saves the web page as a file on their machine and opens it, it will appear as a normal excel sheet.

     



  • I've seen the same in a webproject I occasionally maintain. Perhaps there is some CodeProject article or so that reommends this approach...



  • I actually do this quite a bit. Its a lot easier just to fill a datagrid on an empty asp.net page and set the excel content type then it is to open up an excel file to fill it.

    Its much faster and theres no need to create temp excel files on the server. 


  • Considered Harmful

    You can send directly to the current response output stream, no temporary files required.  The work to output proper CSV is negligible.  This is just lazy.



  • @joe.edwards@imaginuity.com said:

    You can send directly to the current response output stream, no temporary files required.  The work to output proper CSV is negligible.  This is just lazy.

    Assuming you can find delimiter characters that aren't valid parts of the spreadsheet's data. If some of the fields contain plain test then CSV could be a real pain to sort out...



  • @joe.edwards@imaginuity.com said:

    You can send directly to the current response output stream, no temporary files required.  The work to output proper CSV is negligible.  This is just lazy.

    Exporting CSV is even lazier. CSV is not a standard and subject to localization. For example, French versions of Excel expect a semicolon separator in a CSV file instead of a comma which tends to mess up comma separated CSV input. HTML tables and Excel both support data with multi-span rows and columns; alignment and formating; images etc. all of which is converted reasonably well when feeding HTML into Excel.
     



  • Where I work we used to do this - It's not a great way to export data, but in our case we had to export more than just raw data and had no Excel application on our web server (nor would it be installed). As far as I know, doing it in XML is not much of an option because of backwards compatibility (to '97 and 2000 without SPs). What I'm trying to say here is the same as the others: there are worse things, and this is no WTF.
     



  • @JvdL said:

    CSV is not a standard

    Fixed that for you.

     

    For example, French versions of Excel expect a semicolon separator in a CSV file instead of a comma which tends to mess up comma separated CSV input.

    It's broken. This should come as no surprise to anybody who has used Excel.



  • @asuffield said:

    @JvdL said:

    CSV is not a standard

    Fixed that for you.

     

    For example, French versions of Excel expect a semicolon separator in a CSV file instead of a comma which tends to mess up comma separated CSV input.

    It's broken. This should come as no surprise to anybody who has used Excel.

    If you bother to read the RFC, it states explicitely and multiple times that it does not define a standard. It also lists about four other conflicting specifications - none of which are standard either. That an RFC from 2005 documents something that has existed for decades ignoring the way it is being used proves the incompetence of standard committees more than anything else.

    The fact that French Excel (and probably other localizations) uses semi colons in CSV was not invented by Excel or Microsoft but continued on existing practice (having to do with the fact many locales use commas as decimal separators)

    Those who can, do.
    Those who can't, teach.
    Those who can't teach, teach computer science
    Those who can't teach computer science, write RFC's

     



  • @asuffield said:

    It's broken. This should come as no surprise to anybody who has used Excel.

    AFAIK the French version of OpenOffice does the same. 



  • This method is useful if your using a datagrid. could havea quick export to excel button on the page.  Its  quite useful for quick anddirty excel porting.

    Another method would be to use the xmldom object.  Create an excel document format it the way you like and save it as xml.  Then you can open it up in a text editor and make an xml stylesheet out of it.  Then you use the xmldom object to transform the xml and stylesheet together.  This gives you much greater flexibility.  This is how I usually do it. 

    The third approach is rather insane and that would be basically hard code most SpreadsheetML into your app as strings. then programmatically generate the rest.  I see no need for this.  I did this as experimentation when trying to learn the quirks of spreadsheetML.  However I would never use it for development.

     SpreadsheetML is the most god-awful thing to try and debug.  you open up the file in excel and it gives you the name of a temp file which contains an excessivly vague description of the error, often along the lines of "Something Happened". Avoid method 3 its bad practice IMHO. 



  • @JvdL said:

    Those who can, do.
    Those who can't, teach.
    Those who can't teach, teach computer science
    Those who can't teach computer science, write RFC's


    Those who can do
    Those who can't teach
    Those who can't teach teach computer science
    Those who can't teach computer science write RFC's

     



  • @JvdL said:

    If you bother to read the RFC, it states explicitely and multiple times that it does not define a standard.

    Actually, it says that it does not define an "Internet Standard". This is a specific procedure that the IETF uses to urinate upon certain RFCs, marking them as supposedly being soggier than the others. All it is saying is that this document remains reasonably dry.

     

    The lesson here is that the word "standard" is a curious perversion that doesn't really mean anything. You can usually replace every occurrence of the word "standard" with "purple" without significantly altering the meaning of whatever text you modified.

     

    The fact that French Excel (and probably other localizations) uses semi colons in CSV was not invented by Excel or Microsoft but continued on existing practice (having to do with the fact many locales use commas as decimal separators)

    Yes, which is no excuse or even a remotely good reason for doing it. It's broken.



  • @mallard said:

    Except that it doesn't really export to Excel. Instead it simply outputs a HTML page with a giant <table> in it with a "application/vnd.ms-excel" content type.

    I've done that several years ago, and discovered one major problem: In Austria, the decimal separator is "," instead of "."

    At one customer's site, while all installations of Excel seemed identical, some of them required a "," as the decimal separator, while others required a "."  - I've never been able to figure out why they behave differently. To make it worse, using the wrong separator caused Excel to silently ignore it...



  • @asuffield said:


    Yes, which is no excuse or even a remotely good reason for doing it. It's broken.

    Which has been precisely my point. CSV is broken. Don't use it. 



  • @JvdL said:

    @asuffield said:


    Yes, which is no excuse or even a remotely good reason for doing it. It's broken.

    Which has been precisely my point. CSV is broken. Don't use it. 

     
    Use XML

    <?xml version="1.0" encoding="utf-8"?>
    <?mso-application progid="Excel.Sheet"?>
    <Workbook xmlns="urn:schemas-microsoft-com:office:spreadsheet" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:html="http://www.w3.org/TR/REC-html40">
    <Styles><Style ss:ID="Header"><Font ss:Bold="1" /></Style></Styles>
    <Worksheet ss:Name="Worksheetname">
        <Table>
            <Row>
                <Cell ss:StyleID="Header"><Data ss:Type="String">Headercell 1</Data></Cell>
                <Cell ss:StyleID="Header"><Data ss:Type="String">Headercell 2</Data></Cell>
                <Cell ss:StyleID="Header"><Data ss:Type="String">Headercell 3</Data></Cell>
                <Cell ss:StyleID="Header"><Data ss:Type="String">Headercell 4</Data></Cell>
            </Row>
            <Row>
                <Cell><Data ss:Type="String">Text in cell 1</Data></Cell>
                <Cell><Data ss:Type="String">Text in cell 2</Data></Cell>
                <Cell><Data ss:Type="String">Text in cell 3</Data></Cell>
                <Cell><Data ss:Type="String">Text in cell 4</Data></Cell>
            </Row>
        </Table>
    </Worksheet>
    </Workbook>

     



  • @JvdL said:

    @asuffield said:


    Yes, which is no excuse or even a remotely good reason for doing it. It's broken.

    Which has been precisely my point. CSV Excel is broken. Don't use it. 

    Fixed that one for you, too. 



  • @asuffield said:

    @JvdL said:

    @asuffield said:


    Yes, which is no excuse or even a remotely good reason for doing it. It's broken.

    Which has been precisely my point. CSV Excel is broken. Don't use it. 


    Fixed Misinterpreted that one for you, too.

    Why I'm so concerned about CSV while not being French is because of a project at a French company where I was contracted to make a demand forecasting system. Part of the deal was to make the data available to Business Objects, a major OLAP platform and WTF factory. Apparently, the BO consultant (or BO itself) was only able to import this data thru CSV and wasn't able to do incremental updates. The BO server still spends three or four hours every night to repopulate itself from a 5GB CSV file.

    Anyways, when I happily provided a CommaSV export procedure, I was tarred and feathered by the company IT, by BO, and the external project manager. How could I pretend to be worth my IT salt without knowing that EVERY program in the ENTIRE world is, has been, and will always be using semi-colons in CSV files! They held this belief with the same assuredness as you and Mr. Shafranovich (author of the soggy RFC)  believe that it's commas all the way. The fact that Mr. Shafranovich's company SolidMatrix went out of business in 2004; that he has only sat on task force committees ever since, and that he is urinated upon by his own committee members, probably has to with his complete disregard of how things work in practice.


     



  • I wonder how the French justify the "C" in CSV.

    If you are going to use "CSV", then you've got to use all three letters



  • @misguided said:

    @JvdL said:

    Those who can, do.
    Those who can't, teach.
    Those who can't teach, teach computer science
    Those who can't teach computer science, write RFC's


    Those who can do
    Those who can't teach
    Those who can't teach teach computer science
    Those who can't teach computer science write RFC's

     

    Those who cando
    Those who can't, teach
    Those who can't teach
    teach computer science
    Those who can't teach computer science, write RFC's


  • @durnurd said:

    I wonder how the French justify the "C" in CSV.

    If you are going to use "CSV", then you've got to use all three letters

    Why would a Frenchman see any relationship between "C" and "Virgule"? More likely they'll relate it to "Caractère". There is no recorded history of who first used the acronym CSV in the 1950s or what it stood for at the time.

     



  • @Random832 said:

    @misguided said:
    @JvdL said:

    Those who can, do.
    Those who can't, teach.
    Those who can't teach, teach computer science
    Those who can't teach computer science, write RFC's


    Those who can do
    Those who can't teach
    Those who can't teach teach computer science
    Those who can't teach computer science write RFC's

     

    Those who cando
    Those who can't, teach
    Those who can't teach
    teach computer science
    Those who can't teach computer science, write RFC's

     

    1: can? goto 5
    2: can teach? goto 6
    3: can teach CS? goto 7
    4: goto 8
    5: do
    6: teach
    7: treach CS
    8: write RFC
    9: die



  • @dhromed said:

    1: can? goto 5
    2: can teach? goto 6
    3: can teach CS? goto 7
    4: goto 8
    5: do
    6: teach
    7: treach CS
    8: write RFC
    9: die

    Wow. Anyone caught in this Dantesque road to hell will end up writing an RFC and die.



  • @JvdL said:

    @dhromed said:

    1: can? goto 5
    2: can teach? goto 6
    3: can teach CS? goto 7
    4: goto 8
    5: do
    6: teach
    7: treach CS
    8: write RFC
    9: die

    Wow. Anyone caught in this Dantesque road to hell will end up writing an RFC and die.

    whoops

    PATCH PATCH PATCH 

    1: can? goto 5
    2: can teach? goto 6
    3: can teach CS? goto 7
    4: goto 8
    5: do goto 9
    6: teach goto 9
    7: treach CS goto 9
    8: write RFC
    9: die

    There.
    Fixed.



  • It still says "treach". Time for another patch!



  • Second the suggestion to use Excel XML. It's annoyingly verbose, but I haven't had many problems with it. It's slightly cleaner than HTML, and seems better supported by Excel itself. Also (huge plus in my case) you don't need Office installed on the server if you just generate it by hand.

     CSV is a total clusterfuck. The further away from it you stay, the better.



  • @Thief^ said:

    It still says "treach". Time for another patch!

    Wait for the service pack. 


  • Considered Harmful

    [Edit:  You win, text editor.]



  • @ammoQ said:

    I've done that several years ago, and discovered one major problem: In Austria, the decimal separator is "," instead of "."

    At one customer's site, while all installations of Excel seemed identical, some of them required a "," as the decimal separator, while others required a "."  - I've never been able to figure out why they behave differently. To make it worse, using the wrong separator caused Excel to silently ignore it...

    Well, I can help here, ammoQ. :-)

    The behavior is different because the OS is configured differently. Office apps (and other reasonably well behaved Windows apps) get their current settings for things like date separator, date format, decimal separator, list separator, etc. from Windows itself. The values are set using the Control Panel applet labeled (on American English Windows XP Professional) as "Regional and Language Options". I'd suspect that some of the users at your customer's site had chosen the comma as the decimal separator and others the period using this applet.



  • @JvdL said:

    Why would a Frenchman see any relationship between "C" and "Virgule"? More likely they'll relate it to "Caractère". There is no recorded history of who first used the acronym CSV in the 1950s or what it stood for at the time.

    I'm not sure when it was first used, but my understanding is that CSV has always meant "Comma Separated Values". SDF format is "System Delimited Format", IIRC, and would be more appropriate for the French semicolon separator.

    And maybe it wasn't "Caractère", but "colon, semi"? <g>



  • @Devi said:

    @joe.edwards@imaginuity.com said:

    You can send directly to the current response output stream, no temporary files required.  The work to output proper CSV is negligible.  This is just lazy.

    Assuming you can find delimiter characters that aren't valid parts of the spreadsheet's data. If some of the fields contain plain test then CSV could be a real pain to sort out...

    Allow me to introduce you to the concept of "quotation marks", can be conveniently used to work round this exact issue.

    Despite all the hate being dished out in this thread, there's nothing wrong with CSV if you specify what style you're using. It's far less bloated than HTML or the hideous clusterfuck that is Office Broken XML, and also has the advantage that far more people can read and write it.



  • @Iago said:

    Allow me to introduce you to the concept of "quotation marks", can be conveniently used to work round this exact issue. Despite all the hate being dished out in this thread, there's nothing wrong with CSV if you specify what style you're using. It's far less bloated than HTML or the hideous clusterfuck that is Office Broken XML, and also has the advantage that far more people can read and write it.

    From your friendly, neighbourhood RFC [url]http://tools.ietf.org/html/rfc4180[/url]:

       5.  Each field may or may not be enclosed in double quotes (however
    some programs, such as Microsoft Excel, do not use double quotes
    at all). If fields are not enclosed with double quotes, then
    double quotes may not appear inside the fields.

     So what if you need quotes in your data set? Imagine the version of Excel you have accepts quotes properly and even accepts the escape characters defined elsewhere in the RFC (I think that's what they are anyways, I've never really read one of these before) How do you know that the other versions of Excel will support it? The RFC says itself that it's not even sure if Excel supports quotes properly. Plus, iirc, when you import CSV data into Excel you have to go through a sequence of dialogue boxes explaining to Excel how to import the data. Fine if you're a coder, probably a bit of a pain of you're a secretary. The HTML alternative has a clearly defined and reliable set of escape sequences to define troublesome data, and can be imported by Excel without having to answer 20 questions first. I'm not saying that CSV is a bad format per se, all I'm saying is that it's limited in it's use and it's lack of standardization makes it a pain to work with.



  • @Iago said:

    It's far less bloated than HTML or the hideous clusterfuck that is Office Broken XML, and also has the advantage that far more people can read and write it.

    Allow me to introduce you to the concept of "Browsers", they allow people to read HTML documents, whose formatting, in this case, might just be a little more user friendly than a 200k text file sitting round in Notepad ;)
     



  • Excel writes out double quotes if the value contains double quotes, a comma, or a newline (double quotes present in the data are doubled up within a double-quoted string, as with VB, or as single quotes are in SQL.)

    It also understands all these cases.
     



  • @Random832 said:

    Excel writes out double quotes if the value contains double quotes, a comma, or a newline (double quotes present in the data are doubled up within a double-quoted string, as with VB, or as single quotes are in SQL.)

    It also understands all these cases.
     

    Edit limit expired

    Much of the "20 questions" is specifying the type of each column
    (numeric, string, date, what date format), which CSV (and HTML for that
    matter) doesn't even have a concept of. And I don't get asked them for
    a .csv file; only if opening a file with .txt (in which case,
    incidentally, excel does not understand quoting for newlines). The
    "text file wizard" is also intended for tab-delimited and fixed-column
    space-tabulated files, so having to answer a few questions is expected.



  • @Random832 said:

    Things that prove me wrong 

    Fair enough, it's been quite a while since I've done that sort of coding. It doesn't really surprise me that Excel has sorted its act out by now. I was just feeling a little patronized and decided to respond with foaming at the mouth Nerd Rage :)
     



  • @slipperhero said:

    @JvdL said:

    @asuffield said:


    Yes, which is no excuse or even a remotely good reason for doing it. It's broken.

    Which has been precisely my point. CSV is broken. Don't use it. 

     
    Use XML

    <?xml version="1.0" encoding="utf-8"?>
    <?mso-application progid="Excel.Sheet"?>
    <Workbook xmlns="urn:schemas-microsoft-com:office:spreadsheet" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:html="http://www.w3.org/TR/REC-html40">
    <Styles><Style ss:ID="Header"><Font ss:Bold="1" /></Style></Styles>
    <Worksheet ss:Name="Worksheetname">
        <Table>
            <Row>
                <Cell ss:StyleID="Header"><Data ss:Type="String">Headercell 1</Data></Cell>
                <Cell ss:StyleID="Header"><Data ss:Type="String">Headercell 2</Data></Cell>
                <Cell ss:StyleID="Header"><Data ss:Type="String">Headercell 3</Data></Cell>
                <Cell ss:StyleID="Header"><Data ss:Type="String">Headercell 4</Data></Cell>
            </Row>
            <Row>
                <Cell><Data ss:Type="String">Text in cell 1</Data></Cell>
                <Cell><Data ss:Type="String">Text in cell 2</Data></Cell>
                <Cell><Data ss:Type="String">Text in cell 3</Data></Cell>
                <Cell><Data ss:Type="String">Text in cell 4</Data></Cell>
            </Row>
        </Table>
    </Worksheet>
    </Workbook>

     

    And that is why I just cannot stand XML - that's 1137 characters to encode 104 characters of actual content (I don't know how to convert "this is in a cell" into characters so I'm just counting the header and cell text as 'actual content'); the metadata should be able to be contained in far fewer characters.  The information efficiency of XML is just tragically bad, and the repetition of information just makes me cry.

     There has got to be a better way (and why the heck does XML have to be "human readable" anyway?)
     

    And yes, I'm kind of an idealist when it comes to pure computer stuff. I can't stand the "we'll just have better storage and bandwidth in the future so it doesn't matter" mentality...


  • @too_many_usernames said:

    @slipperhero said:
    @JvdL said:

    @asuffield said:


    Yes, which is no excuse or even a remotely good reason for doing it. It's broken.

    Which has been precisely my point. CSV is broken. Don't use it. 

     
    Use XML

    <?xml version="1.0" encoding="utf-8"?>
    <?mso-application progid="Excel.Sheet"?>
    <Workbook xmlns="urn:schemas-microsoft-com:office:spreadsheet" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:html="http://www.w3.org/TR/REC-html40">
    <Styles><Style ss:ID="Header"><Font ss:Bold="1" /></Style></Styles>
    <Worksheet ss:Name="Worksheetname">
        <Table>
            <Row>
                <Cell ss:StyleID="Header"><Data ss:Type="String">Headercell 1</Data></Cell>
                <Cell ss:StyleID="Header"><Data ss:Type="String">Headercell 2</Data></Cell>
                <Cell ss:StyleID="Header"><Data ss:Type="String">Headercell 3</Data></Cell>
                <Cell ss:StyleID="Header"><Data ss:Type="String">Headercell 4</Data></Cell>
            </Row>
            <Row>
                <Cell><Data ss:Type="String">Text in cell 1</Data></Cell>
                <Cell><Data ss:Type="String">Text in cell 2</Data></Cell>
                <Cell><Data ss:Type="String">Text in cell 3</Data></Cell>
                <Cell><Data ss:Type="String">Text in cell 4</Data></Cell>
            </Row>
        </Table>
    </Worksheet>
    </Workbook>

     

    And that is why I just cannot stand XML - that's 1137 characters to encode 104 characters of actual content (I don't know how to convert "this is in a cell" into characters so I'm just counting the header and cell text as 'actual content'); the metadata should be able to be contained in far fewer characters.  The information efficiency of XML is just tragically bad, and the repetition of information just makes me cry.

     There has got to be a better way (and why the heck does XML have to be "human readable" anyway?)

    And yes, I'm kind of an idealist when it comes to pure computer stuff. I can't stand the "we'll just have better storage and bandwidth in the future so it doesn't matter" mentality...

    There are pros and cons to ML, but your argument is not valid. This example contains more than just raw data: font style, worksheet name, header and data type information to be precise.

    If users want a spreadsheet, we give them a spreadsheet - it is not ours to question why. Throwing raw data at them is just a poor excuse for laziness.



  • Regarding JvdL's response to my rant about the verbosity of XML:

    I didn't mean to discount the value (and actual useful content) in the notion of metadata - for instance, font, location information, and the like. My criticism is in the terrible way XML represents this: Very large strings of bandwidth and time-consuming-to-process tags, just so that humans can read the format. That's really the only thing I don't like about XML.

     
    Well, that, and the fact that XML still doesn't contain within itself instructions about how to interpret the data. I can receive documents all day long with <recipe>xxxx</recipe> blocks, but if I don't know what that means what good is having the data?  If I already have to know what to do with a <recipe> data object, I already have to have agreed on a data format, in which case I could have used a special binary format in the first place.

    About the only thing I really like about XML is that it ostensibly has libraries for transforming generic tree data into transmissible data files so you don't have to roll your own code to do that. I just wish it did it in a binary format rather than some ASCII format....but as long as XML is used appropriately I don't have a problem with it.

    But how many applications actually use it properly? Well, this website gives a good indication of that number I think.

     



  • @too_many_usernames said:

    And that is why I just cannot stand XML - that's 1137 characters to encode 104 characters of actual content

    XML is verbose, but can easily and efficiently be compressed.  



  • @too_many_usernames said:

    I didn't mean to discount the value (and actual useful content) in the notion of metadata - for instance, font, location information, and the like. My criticism is in the terrible way XML represents this: Very large strings of bandwidth and time-consuming-to-process tags, just so that humans can read the format. That's really the only thing I don't like about XML.

     
    Well, that, and the fact that XML still doesn't contain within itself instructions about how to interpret the data. I can receive documents all day long with <recipe>xxxx</recipe> blocks, but if I don't know what that means what good is having the data?  If I already have to know what to do with a <recipe> data object, I already have to have agreed on a data format, in which case I could have used a special binary format in the first place.

    More precisely, XML manages to strike the point in the balance where it contains the maximum amount of relevant data possible without actually containing enough data to be useful. It is probably the worst possible result that can be achieved without including irrelevant data. At the same time, it manages to be extremely difficult for both humans and computers to read correctly, and also be very easy for both humans and computers to read incorrectly.

    You just can't create something like that by chance. It takes a great deal of time and effort and a pathological hatred of the entire world.



  • I've seen a ton of these debates about CSV and commas vs. semicolons, and I never understood what's wrong with using tabs as delimiters - Excel understands them just fine...



  • @too_many_usernames said:

    Well, that, and the fact that XML still doesn't contain within itself instructions about how to interpret the data. I can receive documents all day long with <recipe>xxxx</recipe> blocks, but if I don't know what that means what good is having the data?  If I already have to know what to do with a <recipe> data object, I already have to have agreed on a data format, in which case I could have used a special binary format in the first place.

    And how does that make XML any different from any other means of data transport/storage? Getting a recipe database in a SQL Server .mdf  instead doesn't solve the "if I don't know what that means what good is having the data" question. And if you already have to know what to do with the "recipe database", you also have to have previously agreed on the data format.

    XML is great when it's used properly. For example, where I work we're totally autonomous when it comes to our computer stuff. All of our applications are written in-house for Windows. Our data is stored on a Netware server (don't ask <g>). However, we have to interract (mostly fiscally-related stuff) with our  corporate headquarters, which runs everything on Solaris.

    I had the need to transfer information to get checks generated. We chose XML as the transfer bundle because a) .XSD allows really good validation abilities; b) easy-to-use libraries are available for both platforms for building/parsing XML documents; and c) because debugging between the disparate OS's was so easy - "Hey. We need to extend both the Address1 and Address2 elements from 35 to 40 characters.", or "Ok. The problem is that the response file you generated is missing the VOID element.".

    It's like the inevitable responses when someone bashes someone else's programming language of choice (eg., "VB sucks" or "Java is crap"). Each of those statements is totally wrong, always. The languages may not be my language of choice, but neither is "bad"; either people use them who shouldn't be using anything because of their lack of skill, or they were used for something where they were the wrong choice for the task. This applies to XML as well. It's a great way to transfer and/or store data under the proper circumstances, and a terrible way under the wrong ones.
     



  • @ender said:

    I've seen a ton of these debates about CSV and commas vs. semicolons, and I never understood what's wrong with using tabs as delimiters - Excel understands them just fine...

    Is there a standard file extension for tab-delimited files? Regardless, it's my favourite also, since it's rather rare to see tabs inserted into data. It's a bit like the custom icon files for folders in Mac OS 9 and earlier -- they were called "Icon\r" to make sure that no-one ever accidentally uses the name in a Save dialog. Mac OS pre-X is adorable for its permission of any character in filenames except ":" -- you're allowed NULLs in filenames if you so wish. I do think that a colon is, visually, an abominable choice of path separator since it doesn't offer visual separation of the items.

    The other oddity is the EIKON GUI for EPOC. You don't tab through dialog controls, but instead use up and down arrow. Pressing tab has other uses, such as ticking a tickbox and expanding a pop-up menu. If you press tab in a text box ... you get a tab character. D'oh.

    But yes, I prefer tab-delimited data, since it's easier to output "\t" than worry about putting quotes around strings.


Log in to reply