It seems to be a problem with the website, and the intended rendering should be using the usual degrees, minutes and seconds symbols:
″. As noted by other users, different browsers and PDF readers behave differently.
If you look at the website's header, you can see that it explicitly claims that the page is UTF-8:
$ curl -v 'https://www.legislation.gov.au/Details/F2012L01081' 2>&1 | grep Content-Type
< Content-Type: text/html; charset=utf-8
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />[…]
but instead of using the proper Unicode characters for minute and second, the website uses those characters you see and attempts to change their font to a "Symbol" font:
<p class=TableText>25°55<span style='font-family:Symbol'>¢</span>50.8665<span style='font-family:Symbol'>²</span>S</p>
The font picked by your browser does not render those symbols as
″. As noted by other users, different tools have different support for this. In my case both Firefox and Chrome render the characters improperly. I do not have that font on my system. Other users report that Chrome rendered it as expected. My PDF reader both properly renders the font as expected and its search tool seem to be aware of the font because searching for
′ finds the expected characters, while other users report that they need to search for
The "Symbol" font seems to be a legacy from the pre-Unicode area, as Wikipedia notes:
Full legacy support of the Symbol font is provided by major modern web browsers like Internet Explorer and Google Chrome. That support involves a specific handling of Adobe's special encoding, which is not properly implemented in at least some versions of other browsers, including Opera, Safari and Firefox.
As can also be seen on Wikipedia, this font maps the
″ characters to the value 0xA2 and 0xB2 respectively.
In UTF-8 (that the page claims to be using), those values are continuation characters and should never appear on their own. Web browsers are usually very lenient when it comes to such errors and will try to correct them somehow.
In this case it seems your browser falls back to ISO/IEC 8859 (another common encoding with partial compatibility with UTF-8) of which some parts map the values 0xA2 and 0xB2 to
°, but not
¢in those PDFs. Seems to be a technical problem of the tool used to generate them.