home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.forth      Forth programmers eat a lot of Bratwurst      117,927 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 117,759 of 117,927   
   Hans Bezemer to Hans Bezemer   
   Re: Back & Forth - CSV is dead, long liv   
   21 Nov 25 15:11:49   
   
   From: the.beez.speaks@gmail.com   
      
   On 21-11-2025 14:13, Hans Bezemer wrote:   
   > On 20-11-2025 23:26, Hans Bezemer wrote:   
   >> But true, it can be considered a IANA TSV - provided it doesn't double   
   >> quotes. It's late, I haven't tested this yet. But I'll report back in   
   >> the morning.   
   >   
   > I tested it. {Tab} denotes a [CHAR] 9:   
   >   
   > Brand{Tab}Model{Tab}Size   
   > HP{Tab}Series 3 Pro{Tab}"23,8"""   
   > Dell{Tab}P2425H{Tab}"23,8"""   
   > Lenovo{Tab}L15{Tab}"15,6"""   
   > Verbatim{Tab}Portable Screentouch{Tab}"15,6"""   
   > Verbatim{Tab}Portable Ultra{Tab}"17,3"""   
   > Acer{Tab}EK2510Gbi{Tab}"24,5"""   
   > Iiyama{Tab}XUB2493HS-B6{Tab}"23,8"""   
   > ASUS{Tab}ZenScreen MB166C{Tab}"15,6"""   
   > Dell{Tab}P2425{Tab}"24,1"""   
   >   
   > Since it uses not only double quotes, but also doubles the native   
   > quotes, it does *not* comply to either IANA mime type, nor RFC 4180 (LOC   
   > is a superset of IANA):   
   >   
   > Now, let's assume we use "comma" as a delimiter and save the *entire raw   
   > records* from above as single fields (AKA this thing has just ONE field   
   > - and forget about the quotes), this would have been written in TSV LOC   
   > format:   
   >   
   > Brand\tModel\tSize   
   > HP\tSeries 3 Pro\t"23,8"""   
   > Dell\tP2425H\t"23,8"""   
   > Lenovo\tL15\t"15,6"""   
   > Verbatim\tPortable Screentouch\t"15,6"""   
   > Verbatim\tPortable Ultra\t"17,3"""   
   > Acer\tEK2510Gbi\t"24,5"""   
   > Iiyama\tXUB2493HS-B6\t"23,8"""   
   > ASUS\tZenScreen MB166C\t"15,6"""   
   > Dell\tP2425\t"24,1"""   
   >   
   > Where "\t" denotes [CHAR] \ + [CHAR] t. Hence, since LOC requires *all*   
   > fields to have certain (control) characters escaped (like [CHAR] 9)   
   > there can *never* be a conflict between a delimiter and an embedded TAB   
   > in a field.   
   >   
   > If one would have done their research instead of just assuming things,   
   > they would have saved me to explain their misgivings. Or one could just   
   > have watched the video where I summarize all this, having done the   
   > research for you. ;-)   
   >   
   > Hans Bezemer   
      
   BTW, I just made my CSV writer configurable upto RFC 4180, by making the   
   delimiter configurable - and consistently writing CR+LF as EOL.   
      
   .. and of course [CHAR] 9 should be just "9". That's its ASCII code.   
   [CHAR] 9 results in ASCII code 57 - which is not a TAB. That will learn   
   me to dabble in BASIC and then go Forth. ;-)   
      
   Hans Bezemer   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca