Говнокод #16561 — C# — Говнокод.ру

kegdan 19.08.2014 11:54 # +3

Что не так?
хотя да, есть Environment.NewLine

Ответить

roman-kashitsyn 19.08.2014 11:59 # +4

Без контекста не говняно.
Например, HTTP и CSV требуют именно "\r\n" в качестве разделителей строк, независимо от операционной системы.

Ответить

defecate-plusplus 19.08.2014 12:31 # 0

у csv что, есть стандарт?
rfc 4180
ахуеть...
Ответить
- roman-kashitsyn 19.08.2014 12:35 # +3
  я пиарюсь
  https://github.com/roman-kashitsyn/text-csv
  Ответить
  - defecate-plusplus 19.08.2014 13:13 # +3
    
    только тут такая беда...
    локализованный мс офис класть хотел на стандарт, для него разделитель - системный (и далеко не каждый знает, куда надо влезть, чтобы это отменить)
    так что, если ты понадобится без ёбли открывать самодельные csv в русском экселе, то это нельзя не учитывать
    
    (насколько я помню, в опен/либреофисе при открытии csv даже мастер импорта csv файла запускается, который позволяет нащёлкать опций, чтобы этот самый файл открыть)
    Ответить
    - Vasiliy 19.08.2014 13:18 # 0
      
      еще одна причина почему open source лучше.
      Ответить
      - anonimb84a2f6fd141 21.08.2014 07:12 # 0
        
        Больше пространства для пердолинга? Limux после 10 лет сдулся, сколько там уже лет непрерывных успехов? http://habrahabr.ru/post/233813/
        Ответить
    - roman-kashitsyn 19.08.2014 13:23 # +4
      
      Ты говоришь о разделителе полей или разделителе строк?
      Ни символ разделителя полей, ни символ экранирующих кавычек rfc не фиксирует, только разделитель строк. В моей либе символы COMMA и QUOTE передаются в конструктор "стрима".
      А строки в винде вроде бы всю жизнь разделялись \r\n, независимо от языка системы.
      Ответить
      - defecate-plusplus 19.08.2014 17:05 # 0
        
        системный - это как раз про ;
        где-то там в жопе экселя есть настройки, которые снимают это поведение
        но всем насрать
        и экселю насрать, потому что ; это вынужденная мера ради , дробного разделителя
        
        я, когда давно делал лабы, был вынужден смотреть заданную локаль (точка там или запятая), чтобы предугадать поведение экселя и выбрать делимитер
        стойкая неприязнь к цсв у меня уже с тех времен
        правда там были не лабы, а текстовые таблицы на десятки метров, которые надо было обрабатывать, и проще было бороться с цсв под эксель, чем с xls
        Ответить
    - Lokich 19.08.2014 13:50 # 0
      
      специально попробовал сохранить CSV
      
      аа;"б""б""б";вввCRLF ггг;ддд;"""еее"""CRLF
      
      все по RFC, экранирование только там где надо, кавычки экранированы. наговариваете вы батенька :)
      Ответить
      - bormand 19.08.2014 15:15 # +3
        
        Ага, а теперь числа сохрани. Иностранный ворд напишет через точку, а местный - через запятую. Удачного преобразования.
        Ответить
        
        roman-kashitsyn 19.08.2014 15:18 # +2
        
        а вот это уже не проблемы csv, а проблемы локалей
        Ответить
        
        anonimb84a2f6fd141 21.08.2014 07:13 # 0
        
        Я правильно понял, что импорт на системе с другой локалью нинужен?
        Ответить
        
        roman-kashitsyn 21.08.2014 09:46 # +1
        
        Нужен, разумеется. Я не говорю, что проблемы нет, я лишь утверждаю, что она в другом месте.
        
        CSV-формат служит для обмена текстовыми колонками. Их интерпретация лежит на совести тех, кто обменивается данными, и тут всплывают типичные проблемы локалей, не привязанные конкретно к CSV. Читать из потока в локали, отличной от системной - тривиальная задача. Надо просто сообщить принимающей стороне, в какой именно локали файл записан, закодировать в имени файла, например.
        Ответить
      - defecate-plusplus 19.08.2014 16:27 # +1
        
        > все по RFC
        по какому RFC разделитель у тебя точка-с-запятой?
        
        > http://tools.ietf.org/html/rfc4180
        > COMMA = %x2C
        Ответить
        
        roman-kashitsyn 19.08.2014 16:40 # 0
        
        Мдя, я слегка лопухнулся. Кстати, юникод, видимо, в TEXTDATA не помещается.
        Ответить
        
        defecate-plusplus 19.08.2014 17:00 # 0
        
        с их условиями - нет, не помещается
        так что я не зря удивился наличию этого стандарта
        ноубоди лайкс сиэсви
        Ответить
        
        Lokich 19.08.2014 17:07 # 0
        
        другие варианты?
        Ответить
        
        defecate-plusplus 19.08.2014 17:13 # 0
        
        pisat translitom "," konechno "," i sledovat standartu kakogoto mudaka "," potomu chto eto standartCRLF
        
        не рассматривать цсв как портабельный формат обмена между системами
        либо при передаче его не говорить "см. рфц", а декларировать, что и как в нем записано
        может, ты экранировать любишь через \", а не блядский паскалеораклоебанизм """"
        
        раз уж в xml/json не выходит каменный цветок
        Ответить
        
        Lokich 19.08.2014 17:24 # 0
        
        xml&json тяжелые для больших объемов, а там пох, построчное чтение, и нет OutOfMemoryException
        Ответить
        
        bormand 19.08.2014 17:40 # +4
        
        > xml&json тяжелые для больших объемов
        Скажи это ФИАС'у и openstreetmap.
        
        Зато с xml/json я могу быть уверен, что почти на любом языке я смогу написать их разбор за несколько минут, при этом мне не придется ебаться с экранированием, разделителями и вообще марать руки о парсинг.
        
        Безобразные стандарты de-facto (json, xml) лучше, чем безобразный велосипед (csv).
        Ответить
        
        Lokich 19.08.2014 17:53 # 0
        
        ну, справедливости ради, там структурированные данные, которые по другому хз как выгружать, к тому же это не такие большие объемы... ну... по идее. энивей, есть DBF.
        2.5 гиговый XML я думаю, ну может 5-6 будет весить. мне вот например нужно было грузить XML пакет, который 20+ гб весит. не сказать, чтобы я не справился, но для тех, кто этот пакет готовит, это видимо проблема. то они иерархию забудут добавить, то нужные поля, то еще чего.
        Ответить
        
        bormand 19.08.2014 17:56 # 0
        
        > то они иерархию забудут добавить, то нужные поля, то еще чего
        Можно подумать, что эта проблема как-то от формата зависит. С самопальным форматом ты только ёбли с парсингом\генерацией себе добавишь. А если структура выгрузки будет часто меняться - со своим велосипедом будет еще больше боли, чем с xml...
        Ответить
        
        Lokich 20.08.2014 14:55 # 0
        
        XSD схема документа четко описана в ТЗ, и чтобы изменить ее, нужны будут доп. работы.
        Ответить
        
        Lokich 19.08.2014 18:02 # 0
        
        кстати, вопрос не в тему, но, может в курсе. есть ли где-то геокоды для ОКАТО или ОКТАМО?
        Ответить
        
        bormand 19.08.2014 18:04 # 0
        
        Привязка адресов к геоданным? Ну я у яндекса видел подобный сервис, но там не ОКАТО, а просто адреса. А чтобы скачать и импортнуть себе в базу - не попадалось.
        Ответить
        
        Lokich 20.08.2014 14:59 # 0
        
        скорее полигон координат районов. Яндекс возвращает одну точку, по сути середины улицы.
        у них был сервис "Регионы", которые рисовали полигон субъектов федерации, и то, основанный на данных OSM, которые по creative commons распространяются.
        Ответить
        
        eth0 19.08.2014 18:08 # 0
        
        > Зато с xml/json я могу быть уверен
        Что если повезёт, и в библиотеке будет баг, кто угодно сможет подсунуть специальным образом сгенерированный™ xml, который выжрет всю память и даже немного более.
        /сарказм
        Ответить
        
        bormand 19.08.2014 18:14 # 0
        
        1) Во многих либах эту багофичу с entity бомбой уже пофиксили.
        2) Это представляет реальную угрозу только для тех сервисов, в которые xml'ку может загрузить анонимный/псевдонимный мудак.
        Ответить
        
        eth0 19.08.2014 18:29 # 0
        
        Или файл был модифицирован злоумышленником и/или был обработан невнимательным пользователем из недостоверного источника.
        Само собой, этот выпад не против xml, но против злоумышленников.
        Ответить
        
        anonimb84a2f6fd141 21.08.2014 07:14 # −1
        
        Пыхопроблемы?
        Ответить
        
        bormand 21.08.2014 07:51 # +1
        
        Да почему, эта entity-бомба много где работала, не только в пыхе. Практически везде, на самом деле, пока в большинстве либ не ограничили вложенность entity.
        Ответить
        
        bormand 19.08.2014 17:52 # 0
        
        > OutOfMemoryException
        Ну вот я вычленял из ФИАС'а улочки и домики нашего региона, без заливки в базу. XML'ки там что-то около 10-20 гиг, емнип. На компе был всего гиг памяти.
        
        Если правильно помню - вся процедура заняла всего лишь 10-15 минут. Причем прога был сляпана еще минут за 10-15 на... пыхе.
        
        Брат жив, никаких OutOfMemory. Потоковый парсинг рулит.
        Ответить
        
        Lokich 19.08.2014 17:57 # 0
        
        ну конечно, SAX'ом парсить 10-20 гигов, чтобы найти там нужную информацию...
        Ответить
        
        bormand 19.08.2014 18:00 # 0
        
        > ну конечно, SAX'ом парсить 10-20 гигов, чтобы найти там нужную информацию...
        А в чем проблема то? Надо было бы постоянно работать с этими данными - залил бы в базу. Но здесь операция разовая.
        
        Ну хорошо, предложи другой формат выгрузки, с которым я эту задачу решил бы в пределах получаса без заливки в СУБД.
        Ответить
        
        wvxvw 19.08.2014 18:04 # +1
        
        http://www.hdfgroup.org/HDF5/
        Ответить
        
        bormand 19.08.2014 18:10 # 0
        
        А есть либы под все-все-все языки? Я навскидку вижу только жабу и шарп.
        Ответить
        
        wvxvw 19.08.2014 18:18 # +1
        
        Есть еще для R - это то, что я использовал. Есть для ОКамла, есть для Лиспа, но очень низкоуровневые, просто обвязка, без какого-либо дополнительного кода. Есть для Питона. Больше не искал.
        Ответить
        
        1024-- 19.08.2014 19:33 # 0
        
        > xml&json тяжелые для больших объемов
        Если использовать от JSON только массивы, выйдет не так много.
        Выходит (3cols + 2) rows + 2 накладных расходов (не считая экранирования)
        В CSV: (cols + 1) rows - 1 (не считая кавычек и экранирования) или (3cols + 1) rows - 1, если каждая строка будет в кавычках.
        
        [["xxx","yyy","zzz"],["xxx","yyy","zzz"],["xxx","yyy","zzz"]]
        
        В реальности это будет в среднем 5..20% размера файла.
        Ответить
        
        Lokich 20.08.2014 15:08 # 0
        
        проблема в том, что CSV файл можно спокойно считывать построчно, а в случае с XML это DOM, а в случае с JSON это большой объект.
        хотя по хорошему, никто не запрещает считывать их по элементам, но там много нюансов
        Ответить
        
        bormand 20.08.2014 15:29 # 0
        
        > а в случае с XML это DOM
        А как же потоковые парсеры? Если структура линейна и умещается в ксв, то и саксом отлично будет читаться.
        
        И есть еще полу-дом парсеры, которые читают по одной ноде и возвращают ее в виде дома. Если файл состоит из миллионов мелких деревьев - удобно.
        Ответить
        
        roman-kashitsyn 20.08.2014 15:31 # +1
        
        Есть ещё техника "один json-документ в строке"
        Файл целиком перестаёт быть валидным JSON, но позволяет добиться потокового эффекта.
        Ответить
        
        Lokich 20.08.2014 15:40 # 0
        
        я уже говорил, что парсить файл можно как угодно, но при таком подходе нужно жестко оговаривать то, как будут упакованы данные, и жесткий формат.
        я не говорю, что CSV такой хороший, я говорю, что все говно, но для загрузки больших объемов данных он подходит куда лучше чем xml и json.
        Ответить
        
        bormand 21.08.2014 05:48 # 0
        
        > но при таком подходе нужно жестко оговаривать то, как будут упакованы данные, и жесткий формат
        А в CSV типа не надо писать документацию к формату?
        
        > куда лучше
        Да никуда не лучше. По скорости разницы почти не будет - парсинг это копейки по сравнению с той же вставкой в субд. Даже двоичный формат по скорости будет такой же. По объему - в zip'е вроде как че xml че csv будут одинаковы, ну или будут отличаться на копейки.
        Ответить
        
        Lokich 21.08.2014 15:05 # 0
        
        смотря что за СУБД, есть например http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlbulkcopy(v=vs.9 0).aspx. вполне себе ок результат
        http://www.adathedev.co.uk/2011/01/sqlbulkcopy-to-sql-server-in-parallel.html
        Ответить
        
        anonimb84a2f6fd141 21.08.2014 07:15 # −1
        
        Сжатие забыл.
        Ответить
        
        1024-- 21.08.2014 11:29 # 0
        
        Со сжатием так просто не прикинешь.
        Что примерно выйдет?
        Ответить
        
        roman-kashitsyn 20.08.2014 15:02 # 0
        
        > не рассматривать цсв как портабельный формат обмена между системами
        
        CSV всё ещё сложно заменить, когда частичная обработки данных осуществляется человеком. Например, если контент-менеджеры нормализуют/обрабатывают/заполняют данные в Excel или в OpenRefine.
        Ответить
- Lokich 19.08.2014 13:08 # 0
  
  конечно есть, думаешь я просто так хуесосил долбаебов, которые делали "конвертер" XLS->CSV, где вместо того, чтобы экранировать двойную кавычку они ее просто удаляли, а ; заменяли на SemocoloN, и потом его не заменяли обратно? столько сюрпризов было, когда данные из этих "CSV" пытались сопоставить с исходными данными...
  Ответить

gost 19.08.2014 18:40 # +1

readonly string SPACE = " ";
readonly string DOT = ".";
readonly string CONSTANT_STRING = "константа";
readonly string HEAD = "головного";
readonly string BRAIN = "мозга";

readonly string COMMENT = CONSTANT_STRING + SPACE + HEAD + SPACE + BRAIN + DOT;

Ответить

TauSigma 20.08.2014 16:54 # +1

internal struct Constants {
	public const String SPACE = " ";
	public const String DOT = ".";
	public const String CONSTANT_STRING = "константа";
	public const String HEAD = "головного";
	public const String BRAIN = "мозга";
	public const String COMMENT = CONSTANT_STRING + SPACE + HEAD + SPACE + BRAIN + DOT;
	//Тоже годный вариант, если необходимо ещё и рантайм вычисление:
	//public static readonly String COMMENT = CONSTANT_STRING + SPACE + HEAD + SPACE + BRAIN + DOT;
}

Ответить

guest 19.08.2014 19:41 # −5

показать все, что скрытоЯ, guest, находясь в здравом уме и твердой памяти, торжественно заявляю:

Ответить

guest 26.09.2014 08:19 # −1

Your article peeclftry shows what I needed to know, thanks!

Ответить

guest 30.09.2014 20:46 # −1

No more s***. All posts of this qulitay from now on http://bhcslpdwy.com [url=http://udefcba.com]udefcba[/url] [link=http://zvympocqh.com]zvympocqh[/link]

Ответить

Говнокод: по колено в коде.

C# / Говнокод #16561

Комментарии (54) RSS

Добавить комментарий