Monday, January 19th, 2009
Parse User Agent: Harder than you thought?
Category: Browsers
Steve Souders likes to look at user agents in the morning. For his UA Profiler he has to parse the user agents coming in to put the results in the correct bucket.
He assumed that there would be libraries that did this well, but wasn’t able to find anything reliable. In his post he talks about how he decided to build a web service to do this himself, available as Parse User Agent.
When you go to it you see results like above, and note the difference between its results and those from User Agent String.com.
Steve on the new tool:
You can paste any User-Agent string and see how my code classifies it. I also show the results from UserAgentString.com for comparison. The next steps, if there’s interest and I can find the time, would be to make this available as a web service and make the code available, too. What do people think?
- Do other people share this need for better User Agent parsing?
- Do you know of something good that’s out there that I missed?
- Do you see gaps or mistakes in UA Profiler’s parsing?
For now, I’ll keep classifying user agents as I finish the last drops of my (first) coffee in the morning.
Related Content:
Awesome!
would be more usefull if it was javascript based instead php
I have a perl script I wrote for myself that’s seen various levels of maintenance over the years [more before google analytics] and will agree that there are many, many special cases that make accurate UA parsing difficult. Kudos to Steve on this project.
@V1: I know this is ajaxian and all, but what would the benefit of parsing UAs with javascript be? Even if you /were/ wanting to do something like fork JS code I can’t see wanting to wait for a 3rd party service call before loading the rest of your scripts.
more like as hard as i thought. ua parsing was never easy. only a complete newbie would think so. i’d love to see one central authority on user agent data, maybe sponsored by the major search engines or something.
Do people still write new code that depends on parsing User Agent strings? I thought we got away from that years ago…
@shawn: The point here isn’t to special case code. In this situation, I’m analyzing the performance traits of different browsers and displaying the results. As Dion mentions, I needed a way to bucket the results according to the browser used in the test.
@souders: That much makes sense, so long as you take it with a grain of salt. Opera did make things rather fuzzy for several releases, but it should remain fairly accurate to a certain degree. I aimed my comment more toward the most common scripting-type uses of User Agent parsing, as (I think) hinted at by comments above. Even jQuery just started doing feature detection rather than browser detection (according to v1.3 release docs, anyway…I don’t follow any framework that closely).
Whoa, why would I ever want to know the useragent? If you’ve resorted to that, I think you’ve done something wrong not the browser.
For an amusing read related to this, see History of the browser User-Agent String.
There are many good, useful reasons for parsing this information – statistics purposes, etc. Given it’s a Souders project, I’m sure he’s up to something useful (eg. UA Profiler.)
My mistake, I missed the context of the article. I suppose knowing the useragent would be valuable for error or bug reports, buts that’s pretty much it.
How can I use object detection to detect Firefox 3.1′s cross-domain XMLHttpRequest object?
@Jordan1 — [disclaimer: shameless plug, not really answering your question]
.
why worry about detecting one browser’s specific XHR capable of cross-domain? Do you really have a segmented audience so much that you can justify different code (or different functionality all together) to have this cross-domain XHR only if FF3.1 (or IE8) supports it?
.
Instead, you could use flXHR http://flxhr.flensed.com/ and have cross-domain XHR on all (flash enabled) browsers (which is alot of them!). And because it’s identical in API to native XHR (pre FF3.1/IE8), it’ll work as a drop-in replacement with any existing code or frameworks.
@Schill: The History of the browser User-Agent String article is a classic. Hilarious.
@RyanMorr: “If you’ve resorted to that, I think you’ve done something wrong not the browser.”
(I know, you corrected your comment, but I want to run with it)
From a front-end, javascript enabled world, I’ve used UA parsing to allow certain code to be executed in specific cases – not a matter of “oh gee, my CSS is screwed in Browser X so I’ll just use JS…” but more of a “how can I make IE6 render all PNGs correctly without a second style sheet? How can I use CSS rules for browsers that support them, and not force them to use images for rounded corners, that IE/Opera should?”
It’s about other browsers lack of features that make JS necessary with browser detection.