Uri

The `GUri` type and related functions can be used to parse URIs into their components, and build valid URIs from individual components.

Since `GUri` only represents absolute URIs, all `GUri`s will have a URI scheme, so [method@GLib.Uri.get_scheme] will always return a non-`NULL` answer. Likewise, by definition, all URIs have a path component, so [method@GLib.Uri.get_path] will always return a non-`NULL` string (which may be empty).

If the URI string has an [‘authority’ component](https://tools.ietf.org/html/rfc3986section-3) (that is, if the scheme is followed by `://` rather than just `:`), then the `GUri` will contain a hostname, and possibly a port and ‘userinfo’. Additionally, depending on how the `GUri` was constructed/parsed (for example, using the `G_URI_FLAGS_HAS_PASSWORD` and `G_URI_FLAGS_HAS_AUTH_PARAMS` flags), the userinfo may be split out into a username, password, and additional authorization-related parameters.

Normally, the components of a `GUri` will have all `%`-encoded characters decoded. However, if you construct/parse a `GUri` with `G_URI_FLAGS_ENCODED`, then the `%`-encoding will be preserved instead in the userinfo, path, and query fields (and in the host field if also created with `G_URI_FLAGS_NON_DNS`). In particular, this is necessary if the URI may contain binary data or non-UTF-8 text, or if decoding the components might change the interpretation of the URI.

For example, with the encoded flag:

```c g_autoptr(GUri) uri = g_uri_parse ("http://host/path?query=http%3A%2F%2Fhost%2Fpath%3Fparam%3Dvalue", G_URI_FLAGS_ENCODED, &err); g_assert_cmpstr (g_uri_get_query (uri), ==, "query=http%3A%2F%2Fhost%2Fpath%3Fparam%3Dvalue"); ```

While the default `%`-decoding behaviour would give:

```c g_autoptr(GUri) uri = g_uri_parse ("http://host/path?query=http%3A%2F%2Fhost%2Fpath%3Fparam%3Dvalue", G_URI_FLAGS_NONE, &err); g_assert_cmpstr (g_uri_get_query (uri), ==, "query=http://host/path?param=value"); ```

During decoding, if an invalid UTF-8 string is encountered, parsing will fail with an error indicating the bad string location:

```c g_autoptr(GUri) uri = g_uri_parse ("http://host/path?query=http%3A%2F%2Fhost%2Fpath%3Fbad%3D%00alue", G_URI_FLAGS_NONE, &err); g_assert_error (err, G_URI_ERROR, G_URI_ERROR_BAD_QUERY); ```

You should pass `G_URI_FLAGS_ENCODED` or `G_URI_FLAGS_ENCODED_QUERY` if you need to handle that case manually. In particular, if the query string contains `=` characters that are `%`-encoded, you should let [func@GLib.Uri.parse_params] do the decoding once of the query.

`GUri` is immutable once constructed, and can safely be accessed from multiple threads. Its reference counting is atomic.

Note that the scope of `GUri` is to help manipulate URIs in various applications, following RFC 3986. In particular, it doesn't intend to cover web browser needs, and doesn’t implement the WHATWG URL standard. No APIs are provided to help prevent homograph attacks, so `GUri` is not suitable for formatting URIs for display to the user for making security-sensitive decisions.

Relative and absolute URIs

As defined in [RFC 3986](https://tools.ietf.org/html/rfc3986section-4), the hierarchical nature of URIs means that they can either be ‘relative references’ (sometimes referred to as ‘relative URIs’) or ‘URIs’ (for clarity, ‘URIs’ are referred to in this documentation as ‘absolute URIs’ — although [in constrast to RFC 3986](https://tools.ietf.org/html/rfc3986section-4.3), fragment identifiers are always allowed).

Relative references have one or more components of the URI missing. In particular, they have no scheme. Any other component, such as hostname, query, etc. may be missing, apart from a path, which has to be specified (but may be empty). The path may be relative, starting with `./` rather than `/`.

For example, a valid relative reference is `./path?query`, `/?query#fragment` or `//example.com`.

Absolute URIs have a scheme specified. Any other components of the URI which are missing are specified as explicitly unset in the URI, rather than being resolved relative to a base URI using [method@GLib.Uri.parse_relative].

For example, a valid absolute URI is `file:///home/bob` or `https://search.com?query=string`.

A `GUri` instance is always an absolute URI. A string may be an absolute URI or a relative reference; see the documentation for individual functions as to what forms they accept.

Parsing URIs

The most minimalist APIs for parsing URIs are [func@GLib.Uri.split] and [func@GLib.Uri.split_with_user]. These split a URI into its component parts, and return the parts; the difference between the two is that [func@GLib.Uri.split] treats the ‘userinfo’ component of the URI as a single element, while [func@GLib.Uri.split_with_user] can (depending on the [flags@GLib.UriFlags] you pass) treat it as containing a username, password, and authentication parameters. Alternatively, [func@GLib.Uri.split_network] can be used when you are only interested in the components that are needed to initiate a network connection to the service (scheme, host, and port).

[func@GLib.Uri.parse] is similar to [func@GLib.Uri.split], but instead of returning individual strings, it returns a `GUri` structure (and it requires that the URI be an absolute URI).

[func@GLib.Uri.resolve_relative] and [method@GLib.Uri.parse_relative] allow you to resolve a relative URI relative to a base URI. [ func@GLib.Uri.resolve_relative] takes two strings and returns a string, and [method@GLib.Uri.parse_relative] takes a `GUri` and a string and returns a `GUri`.

All of the parsing functions take a [flags@GLib.UriFlags] argument describing exactly how to parse the URI; see the documentation for that type for more details on the specific flags that you can pass. If you need to choose different flags based on the type of URI, you can use [ func@GLib.Uri.peek_scheme] on the URI string to check the scheme first, and use that to decide what flags to parse it with.

For example, you might want to use `G_URI_PARAMS_WWW_FORM` when parsing the params for a web URI, so compare the result of [ func@GLib.Uri.peek_scheme] against `http` and `https`.

Building URIs

[func@GLib.Uri.join] and [func@GLib.Uri.join_with_user] can be used to construct valid URI strings from a set of component strings. They are the inverse of [func@GLib.Uri.split] and [func@GLib.Uri.split_with_user].

Similarly, [func@GLib.Uri.build] and [func@GLib.Uri.build_with_user] can be used to construct a `GUri` from a set of component strings.

As with the parsing functions, the building functions take a [flags@GLib.UriFlags] argument. In particular, it is important to keep in mind whether the URI components you are using are already `%`-encoded. If so, you must pass the `G_URI_FLAGS_ENCODED` flag.

`file://` URIs

Note that Windows and Unix both define special rules for parsing `file://` URIs (involving non-UTF-8 character sets on Unix, and the interpretation of path separators on Windows). `GUri` does not implement these rules. Use [func@GLib.filename_from_uri] and [ func@GLib.filename_to_uri] if you want to properly convert between `file://` URIs and local filenames.

URI Equality

Note that there is no `g_uri_equal ()` function, because comparing URIs usefully requires scheme-specific knowledge that `GUri` does not have. `GUri` can help with normalization if you use the various encoded [flags@GLib.UriFlags] as well as `G_URI_FLAGS_SCHEME_NORMALIZE` however it is not comprehensive. For example, `data:,foo` and `data:;base64,Zm9v` resolve to the same thing according to the `data:` URI specification which GLib does not handle.