Monday, January 19th, 2009

Parse User Agent: Harder than you thought?

Category: Browsers

<>p>

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:

Posted by Dion Almaer at 8:30 am
14 Comments

+++--
3.2 rating from 24 votes

14 Comments »

Comments feed TrackBack URI

Awesome!

Comment by oopstudios — January 19, 2009

would be more usefull if it was javascript based instead php

Comment by V1 — January 19, 2009

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.

Comment by ChrisCasciano — January 19, 2009

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.

Comment by ilazarte — January 19, 2009

Do people still write new code that depends on parsing User Agent strings? I thought we got away from that years ago…

Comment by shawn — January 19, 2009

@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.

Comment by souders — January 19, 2009

@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).

Comment by shawn — January 19, 2009

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.

Comment by RyanMorr — January 19, 2009

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.)

Comment by Schill — January 19, 2009

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.

Comment by RyanMorr — January 19, 2009

How can I use object detection to detect Firefox 3.1′s cross-domain XMLHttpRequest object?

Comment by Jordan1 — January 20, 2009

@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.

Comment by shadedecho — January 20, 2009

@Schill: The History of the browser User-Agent String article is a classic. Hilarious.

Comment by souders — January 20, 2009

@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.

Comment by keif — January 21, 2009

Leave a comment

You must be logged in to post a comment.