Am Sonntag, 27. März 2011, 23:32:22 schrieb Thomas Weber: > Hi, > > I'm currently facing a failing test in financial's test suite. The > problem can be seen with the following call: > > wget > "http://finance.google.com/finance/historical?q=yhoo&startdate=01-Jul-2005&; > enddate=08-Jul-2005&histperiod=daily&output=csv" > > If you redirect the output into a file and use a hexeditor for looking > at it, you get the following: > 00000000 ef bb bf 44 61 74 65 2c 4f 70 65 6e 2c 48 69 67 > |...Date,Open,Hig| > > So, Google returns some binary crap at the beginning. When loading this > .csv data into Octave, the first variable has a length of 7, whereas the > unit test expects a lenght of 4 - in other words, it's looking for > "Date", not for crappy "...Date". > > BTW, it's actually difficult to see this issue with Octave'pager or vim > -- they simply show the "Date" string, but Octave happily tells you > about the length of 7. > > So, I'm looking for a good idea here? Does anybody have any contacts at > Google whom they could ask whether these 3 characters are intentional? > > Thomas > This is no crap, it is the BOM for utf8 for text files
http://de.wikipedia.org/wiki/Byte_Order_Mark ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
