jn_meter wrote: ↑July 27th, 2020, 3:22 am
: Someone might be helped by an answer to this question, but I myself have switched to Powershell to do the job. It seems easier to use Powershell to do that job.
I found this thread
called 'Help parsing JSON objects with WebParser'. I even found a tool, created by morley from this board, to help with such parsing. However, and perhaps because I fail utterly to understand the syntax of so-called regular expressions, I am horribly stuck.
The JSON I wish to read starts like this:
Code: Select all
"longitude":<value, which is a negative number>,
I have managed, in a script and in the aforementioned tool, to read the respective values for ip
. I do so with:
Code: Select all
Yet, I cannot manage to read the longitude
. Perhaps I should add that my main confusion about regular expressions is about where they use quotation marks. Also, though: I do not understand the (?siU)
. Moreover: can't I just specify a field name and thereby pull its value, whilst not even mentioning - in my regular expression - any of the other fields? For in fact I am interested only in one field within the data.
The quotation marks presence is not a regex thing, it's a JSON thing (at least the way it is structured at weather.com). Generally, the name of the fields and their string values are enclosed between quotes, but the numerical values of the fields are not. Since the ip, country and city values are strings, they are enclosed between quotes. Latitude and longitude on the other hand, being numbers, are not. Using a regex pattern like the one suggested by mak_kawa should do the job.
Using PowerShell for this is a bit of waste of resources, in my view. Regular expressions are the way to do it when it comes to parsing (although in the case of JSON a "built-in" parser is obviously easier). They might be a bit "underpowered" by the fact that they can't count, but otherwise they are extremely powerful irrespective of the level of the user using them. What makes most users here on the forum "shy" when it comes to regex is the fact that they don't try it out for themselves. A lot of them prefer to rely on the regexes made by others and don't attempt things on themselves from scratch. So what happens is that when they see a longer regex pattern they are instantly "confused", but that's simply because they didn't build it themselves step by step. In other words, when you see a mile long regex you'd have difficulties trying to figure out what it does (I might have as well), but if you build it yourself, step by step (and then forget), it's much easier - you just have to take things (i.e. each small pattern part) one at a time.
Personally, I didn't even know regex existed before Rainmeter, but as soon as I began trying it out myself one step at a time, I quickly understood it. It's no big deal, really, but a good testing site and the willingness to try do help. I use RegExr
to build and test my patterns, as its "help section" (i.e. the RegEx Reference option from the left sidebar) is in my view unmatched in terms of simplicity and straight to the point approach, no garbage / bloat / unneeded info there: just what the pattern does and a single basic example. Unlike other help tools on other sites which present the information all at once, this one is very well structured into sections, pretty much like the Rainmeter manual is. To get an idea of how simple it is, there are just 9 sections in the RegEx Reference there, and only 2 of them are longer than what you could call "pages" in that sidebar.