Background: I'm creating a hierarchical geographic directory. The geo databases I'm using has fields such that I can create a URL like this: /ISO_country/1st_admin_division/2nd_admin_division/place_name/zipcode/
ISO_country, place_name, and zipcode are guaranteed to have data. But 1st and 2nd admin division may or may not have data.
In US I have a /US/New-York/Nassau-County/Hicksville/51212/ But in South Africa I have /ZA/[blank]/[blank]/Pretoria/0030/
If I go with the (ugly) /ZA///Pretoria/0030/ is it a valid URL? What about the also ugly /ZA/-/-/Pretoria/0030/?
Do any major browsers get "smart" and try to elimi开发者_JS百科nate things like this?
Yes, both are perfectly valid URIs. See RFC 2396.
/ZA///Pretoria/0030/
/ZA/-/-/Pretoria/0030/
Do any major browsers get "smart" and try to eliminate things like this?
Not as far as I've seen. BTW, dashes (-
) are not special characters in URIs so you really don't need to concern yourself with those.
Why not work on an optional-argument model? Both of these URLs seem workable and easily parseable:
/ZA/Pretoria/0030
/US/New-York/Nassau-County/Hicksville/51212/
And, just to throw a pickle in the works:
/AU/Victoria/Melbourne/3000
If you know that you'll always have values for your first, second-last and last items, why not chomp the first one then parse your URL tokens backwards?
# rubyish pseudocode
tokens = "/AU/Victoria/Melbourne/3000".split("/")
iso_country = tokens[0]
tokens.reverse!
tokens.drop_last_item!
zipcode = tokens[0] # => 3000
place_name = tokens[1] # => Melbourne
admin_division_2 = tokens[2] # => Victoria
admin_division_1 = tokens[3] # => nil / ""
精彩评论