Господа может быть у кого нибудь может быть завалялась СИ-шная функция по парсировки длинных урлов с/без параметрами (типа: http://user:password@linux.org.ru:80/add.jsp), без применения регулярных вырожений.
> libpcre - не является стандартной библиотекой, ну и скорость.
1. что понимается под "стандартной библиотекой"?
2. какая скорость необходима или устраивает?
afaik, libpcre работает под всеми unixami, m$ windows & macos
http://www.ietf.org/rfc/rfc2396.txt
Berners-Lee, et. al. Standards Track [Page 28]
RFC 2396 URI Generic Syntax August 1998
B. Parsing a URI Reference with a Regular Expression
As described in Section 4.3, the generic URI syntax is not sufficient
to disambiguate the components of some forms of URI. Since the
"greedy algorithm" described in that section is identical to the
disambiguation method used by POSIX regular expressions, it is
natural and commonplace to use a regular expression for parsing the
potential four components and fragment identifier of a URI reference.
The following line is the regular expression for breaking-down a URI
reference into its components.
^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
12 3 4 5 6 7 8 9
The numbers in the second line above are only to assist readability;
they indicate the reference points for each subexpression (i.e., each
paired parenthesis). We refer to the value matched for subexpression
<n> as $<n>. For example, matching the above expression to
http://www.ics.uci.edu/pub/ietf/uri/#Related
results in the following subexpression matches:
$1 = http:
$2 = http
$3 = //www.ics.uci.edu
$4 = www.ics.uci.edu
$5 = /pub/ietf/uri/
$6 = <undefined>
$7 = <undefined>
$8 = #Related
$9 = Related
where <undefined> indicates that the component is not present, as is
the case for the query component in the above example. Therefore, we
can determine the value of the four components and fragment as
scheme = $2
authority = $4
path = $5
query = $7
fragment = $9
and, going in the opposite direction, we can recreate a URI reference
from its components using the algorithm in step 7 of Section 5.2.
> libpcre - не является стандартной библиотекой, ну и скорость.
лично мной написанный перловый парсер логов апача для очень-очень большого проекта обрабатывает ~30млн строк за 2 часа на 2xXeon; причем там, помимо регекспа раз так в 10 более сложного, чем разбор урла, еще и пара экранов кода "если это запрос такого-то типа, то...".
Пример из RFC обрабатывается на 1000MHz Via C3 со скоростью 119047.62 штук в секунду.