C / html->pain text

sscanf()

Вы имеете в виду подобные функции:

void hexdump(char *inp, char* outp, int flag){
	char *i_ptr = inp, *o_ptr = outp;
	unsigned char ch;
	strcpy(outp, "");
	while(*i_ptr){
		ch = *i_ptr++;
		//if(ch == ' ') ch = '_';
		if(ch == '/' && flag){ *o_ptr++ = '/';}
		else
		if(ch > 31 ){
			sprintf(o_ptr, "%%%x", ch);
			o_ptr += 3;
		}
	}
	*o_ptr = 0;
}

void unhexdump(char *inp){
	char tmp[512], *o_ptr = inp, *tok;
	unsigned char ch;
	int a;
	strncpy(tmp, inp, 512);
	tok = strtok(tmp, "%");
	do{
		sscanf(tok, "%x", &a);
		if(a > 31){
			ch = a;
			*o_ptr++ = ch;
		}
	}while(tok = strtok(NULL, "%"));
	*o_ptr = 0;
}

Причем здесь Unicode? Это обыкновенный URL-encoding.

Что-то мне подсказывает что это класический случай и такого должно быть валом.

правильно подсказывает.

тыц, например.

Спасибо большое. Я сначала хотел как Eddy_Em написать. Но наверное лучше использовать стандартное решение через libsoup.

У меня то же самое, но «свелосипежено» :)

> pain text
Это то, что меня заманило в этот тред.
По теме, зачем наСИловать себя, когда есть куча вменяемых ЯП под эту задачу?

> По теме, зачем наСИловать себя, когда есть куча вменяемых ЯП под эту задачу?

Для того что-бы сконвертить буфер надо вызывать внешний «вменяемый ЯП»? Я как-то об этом не подумал.. :)

Вариант Eddy_Em, возможно даже лучше, потому что не тащит лишних зависимостей. libsoup удобно использовать в комплексе работы с HTTP, если требуется только url-encode/decode, то тащить в зависимостях libsoup неудобно :)

> Для того что-бы сконвертить буфер надо вызывать внешний «вменяемый ЯП»? Я как-то об этом не подумал.. :)
И правильно сделал, что не подумал. Надо было изначально использовать ЯП под задачу, под которую Си, похоже, не очень подходит.

Надо было изначально использовать ЯП под задачу, под которую Си, похоже, не очень подходит.

Не надо тут троллить. С очень даже удобен для работы с html. Достаточно один раз написать свою собственную библиотечку с набором нужных функций и дальше писать в простом стиле. Или же можно пользоваться чужими библиотеками (хоть тем же «супом»).

> Достаточно один раз написать свою собственную библиотечку с набором нужных функций и ...
... еще несколько (десятков) лет находить в ней ошибки переполнения буффера и прочее.

>Это обыкновенный URL-encoding.

Но текст там в UTF-8 :)

Посмотри еще в сторону tidy.

>char tmp[512]

А если не влезет?

> [code=c]char tmp[512]; strncpy(tmp, inp, 512); [/code]

Eddy_Em, вы же сами в соседнем треде говорили:

А вот поэтому я обычно стараюсь в strncpy передавать цифирку на 1 меньше, чем реальный объем буфера.

Невнимательный вы однако. Читайте man strncpy, а еще лучше вообще забудьте про существование strncpy.

>Читайте man strncpy, а еще лучше вообще забудьте про существование strncpy.

А что лучше?

Си не удобен.

Си вообще для чего-то уровнем выше системного программирования КАТЕГОРИЧЕСКИ не подходит. И пока некоторые будут фанатично(хотя, скорее, идиотично) использовать низкоуровневые языки, типа Си, для прикладных программ, софт на «свободных ОС» так и будет говном.

Вот выдержка из статьи умной статьи: http://sds.podval.org/tool.html

Почитай и подумай.

... The result was that people started writing everything in this language, Emacs-Lisp, including a full-fledged news-reader, a WWW browser, a computer algebra system and a spreadsheet. The problem is that Emacs (the implementation, not the Emacs-Lisp language!) is heavily tilted towards editing operations, and not particularly good with general-purpose computations. ...

C gives yet another good example, similar to Emacs-Lisp. Essentially, it is a very good assembly-like language, designed for UNIX kernel and utilities development - so we can call it «UNIX extension language», like Emacs-Lisp is the Emacs extension language. But eventually C was used to write large programs (word processors, computer algebra systems, computer-aided design systems, etc). C is a totally inappropriate language for large projects: it lacks all the aspects of a high-level language, which means that the programmer has to design a work-around for all of them. C++ is a slight improvement in some areas, but only a slight, and at a great cost of enormous complexity. Java is better, but it is still strongly lacking in functionality.

И только великий Ц# спасёт нас?

Спасет СL или аналог, в идеале.

C# от Java, Dephi и C++ недалеко ушел.

Умники желающие переписать nginx или апача на своих языках пожалуйста код в студию. Ваши статьи тут никому нах не нужны. Только работающий код пожалуйста. Иначе разговаривать не имеет смысла.

Если бы умники, написавшие апач и nginx(или какой-нибудь IIS), написали бы их сразу на более-менее высокоуровневых языках, веб не был бы таким говном, каким сейчас является.

Ваши статьи тут никому нах не нужны. Только работающий код пожалуйста. Иначе разговаривать не имеет смысла.

Это ты к чему вообще ляпнул?
Что ты читать по-английски не умеешь, это понятно. Что ты неумный луддит - тоже.
Но зачем это показывать прилюдно?

Мда, вот же любят анонимусы поумничать...

Невнимательный вы однако. Читайте man strncpy, а еще лучше вообще забудьте про существование strncpy.

А чем прикажете строки копировать? Или динамически выделять strdup'ом?

Все правильно написал. Подписываюсь под каждым словом.

Еще один лиспотролль?

Покажи мне, в каком месте поста Анонимуса написано про Лисп.

В каком месте nginx и apache прикладной софт? Прикладной софт - это гном, это сраный Эмпати с его Телепатией, это еще куча программ, которые какое-то неумные люди написали на С, усложнив жизнь себе и другим.

здесь

Вот из за таких как ты, приходится правила ЛОРа нарушать...

Это другой пост.

А в том было про Emacs-Lisp.

А еще там было про c++, но ты обратил внимание именно на LISP.

То что анонимус клоун я согласен, из-за таких не любят лисп. А вот про C он правильно написал - его место в системном программировании, а не в написании всяких гимпов и гномов.

Ан нет, оказывается ты - вендотролль! :)

Это про ЛОР было, если че.

С++ нужен только там, где его имеет смысл использовать. А когда человек от незнания начинает городить всякие «хеллоуворлды» на плюсах, вместо того, чтобы использовать более подходящий язык, это смешно!

Да, я не использую плюсы, т.к. у меня еще не было ни одной задачи, где пригодились бы их плюсы, извиняюсь за тавтологию. Ни в одной моей задаче нет необходимости выделять объекты или заниматься всякими наследованиями. Шаблоны мне тоже не нужны - я не пишу библиотеки широкого профиля. А для CGI С является одним из обычных языков, наряду с пыхпыхом, питоном да перлом.

Еще смешнее выглядит объектная система на С.

А т.к. у меня нет объектов, то ничего смешного там нет :)

> Ни в одной моей задаче нет необходимости выделять объекты или

заниматься всякими наследованиями. Шаблоны мне тоже не нужны

Ну да, египтяне вон какие пирамиды без разных тракторов и подъёмных кранов делали и ничего! А расскажи им про какой экскаватор - так небось бы ещё и в богохульстве обвинили.

> А чем прикажете строки копировать?

Стандартная библиотека ничего хорошего не может предложить, поэтому нужно либо использовать безопасную альтернативу предоставляемую компилятором (если такая есть) либо написать свою альтернативу.

Боюсь, своя альтернатива будет еще дырявее. Поэтому лучше уж буду пользоваться тем, что есть. В критических случаях можно делать так:

char *buf = (char*) calloc(BUFSIZ, 1);
... // данные -> char *str
strncpy(buf, str, BUFSIZ);
buf[BUFSIZ] = 0;
...

А точно «buf[BUFSIZ]», а не «buf[BUFSIZ - 1]»?

:) опять очепятку, приводящую к неминуемому переполнению буфера, сделал...

В общем, думаю, так будет безопаснее:

char* hexdump(char *inp, int flag){
   int sz = strlen(inp) * 3 + 1;
   char *outp = (char*) calloc(sz, 1);
   unsigned char ch;
   while(*inp){
      ch = *inp++;
      if(ch == '/' && flag){ *outp++ = '/';}
      else
      if(ch > 31 ){
         snprintf(outp, 3, "%%%x", ch);
         o_ptr += 3;
      }
   }
   return outp;
}

char* unhexdump(char *inp){
   char *tmp, *outp, *tok;
   unsigned char ch;
   int a = strlen(inp) + 1;
   outp = (char*) calloc(a);
   tmp = strdup(inp);
   tok = strtok(tmp, "%");
   do{
      sscanf(tok, "%x", &a);
      if(a > 31){
         ch = a;
         *outp++ = ch;
      }
   }while(tok = strtok(NULL, "%"));
   return outp;
}

char* unhexdump(char *inp){
char *tmp, *outp, *tok;
unsigned char ch;
int a = strlen(inp) + 1;
outp = (char*) calloc(a);
tmp = strdup(inp);
tok = strtok(tmp, «%»);
do{
sscanf(tok, «%x», &a);
if(a > 31){
ch = a;
*outp++ = ch;
}
}while(tok = strtok(NULL, «%»));
return outp;
}


1. outp = (char*) calloc(a, 1);
2. }while(tok == strtok(NULL, «%»));

Но все равно не работет по нормальному. Нули одни в выходном буфере.

зато вроде бы вероятность переполнения буфера сведена к нулю...

А вот утечка памяти точно есть. =]

Но все равно не работет по нормальному. Нули одни в выходном буфере.

Си такой Си.
Нули там потому, что

// ...
*outp++ = ch;
// ...
return outp; // показывает на конец строки

Виноват не си, а люди которые делают ошибки.

И от языка это никак не зависит.

> Виноват не си, а люди которые делают ошибки.
Согласен

И от языка это никак не зависит.

Не согласен.