Ask Different is a question and answer site for power users of Apple hardware and software. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Occasionally my Safari hangs on loading a page, and after some time shows this text:


Maybe someone knows what that text is? Or how to solve a problem at all?

I'll be very grateful for reply.

P.S. Also when some page hangs while loading and I hit refresh, it usually loads instantly. So it's now a problem with an internet connection.

share|improve this question
Which URLs are causing this problem? How often does it happen? – bneely Feb 9 '12 at 7:56
@bneely it's no URL dependent, just happens from time to time with different URLs (for sure more often with those sites that auto refresh). And it happens in different places, event at work where I have a broadband internet, so it's not about internet problems. Also when some page hangs while loading and I hit refresh, it usually loads instantly. – Uko Feb 9 '12 at 9:41
I have no idea why it would happen, but I think it may not actually be Chinese but what can occur when utf-8 text is read as if it were utf-16 – Tom Gewecke Feb 9 '12 at 13:11
BTW I tried translating it at from Chinese to English, and it appeared as gibberish. Tom's theory is a good one. – bneely Feb 9 '12 at 20:13
@TomGewecke how can I change the encoding of that stuff? Because if I just change encoding of a webpage in Safari, it reloads the whole page, so the original content is loaded. – Uko Feb 10 '12 at 10:13
up vote 3 down vote accepted

The characters you posted are what you get if you take the text at the bottom of this post, encode it as UTF-8, and then (mistakenly) decode it as UTF-16BE.

Ultimately, Safari is decoding the data incorrectly (it should be decoded as UTF-8, but it is being decoded as UTF-16BE). It might do this for any one of several reasons:

  • The server incorrectly told Safari to decode as UTF-16BE (e.g. via a charset parameter in the Content-Type header of the server’s HTTP response).
  • The server incorrectly prepended a UTF-16BE BOM before the UTF-8 data.
  • Safari is configured to default to UTF-16BE.
    I am not sure how this would be actually be accomplished though. The only UTF entry in the manual encoding list is “Unicode (UTF-8)”, which would seem to preclude forcing UTF-16BE (unlike TextEdit where you can actually select UTF-16BE, if you customize its list of encodings).
  • Safari auto-detected the encoding incorrectly.

Your particular problem seems likely to be a server (or proxy) problem since you say that it is only happening intermittently.

The Network tab of Safari’s Web Inspector can show you the server response headers (to confirm or deny an erroneous charset parameter), but it would be probably be annoying to always have to remember to open/enable it for each tab you open (to capture the information it must already be active before when the page of interest is loaded—which may be difficult to predict if your problem is intermittent).

A packet capture could identify an erroneous BOM (and/or an erroneous charset), but such tools are much less convenient (also usually useless for encrypted (HTTPS) requests). If you know that the problem occurs fairly often, you might be able to send many requests through curl and try to identify erroneous BOMs/charsets by looking at the data it can report (server response headers and the raw content bytes).

You can manually choose an encoding (in Safari 5.1) via the View menu’s Text Encoding submenu.
Such a proxy might be a “transparent” proxy that you might not otherwise suspect.

<!-- LOCALIZERS: Each localizable piece of the page is marked with a comment -->

<!-- LOCALIZERS: If in a right-to-left locale, add dir="rtl" to the HTML element. -->
    <LINK rel=stylesheet type="text/css" href="page-load-errors.css">
    <!-- LOCALIZERS: You might want to change the font family. You can also add styles to override sizes, etc. -->
        BODY {font-family:'Helvetica Neue';}

    <!-- LOCALIZERS: The next line contains the page title that appears in the window's title bar -->
    <TITLE>Не вдалося відкрити сторінку</TITLE>

<div class="error-container">
<div class="icon" alt="Safari Icon"></div>
<div class="text-container">
<!-- main title here, repeated 3 times -->
<P class="error-title error-text-engraving">%@ <A id="help-button"></a></P>
<P class="error-title error-text">%@ <A id="help-button"></a></P>
<P class="error-title error-text-inner-shadow">%@ <A id="help-button" class="%@" HREF='open-help-anchor:%@'></a></P>
<div class="text-container">
<!-- error message here, repeated 3 times -->
<P class="error-message error-text-engraving">%@</P>
<P class="error-message error-text">%@</P>
<P class="error-message error-text-inner-shadow">%@</P>


Google translation suggests that the Cyrillic <title> text seems to be Ukrainian for “Could not open page”.

The comments indicated that this text only started showing up after a software update from Apple. The exact update was probably the 10.7.3 update which added localization for several languages, including Ukrainian.

I do not have a 10.7 system, but the above content (apart from the Ukrainian <title> text) is largely identical to the content of files from 10.6 (Safari 5.1.3) with names like /Applications/*.lproj/StandardErrorPage.html; all these files (on 10.6 Safari 5.1.3) are UTF-16LE encoded with a leading (UTF-16LE) BOM. This points strongly to the second possible reason I described: the “server” (actually just a local file) is supplying content with an incorrect BOM.

If you can identify the file used for your particular localization, you can probably “fix” it. As a guess, the Ukrainian file is probably something like …/ua.lproj/StandardErrorPage.html.

Note: Modifying this file might break Safari’s “code signature”. On 10.6, the English version of this file is listed in the …/ file as “optional”, so it might be okay (I have not tried it). If you do try editing/replacing the file, make a backup first! To be safe, you could make a copy of the whole folder.

You can use a hex editor (e.g. HexFiend) to adjust the leading BOM bytes. If you are actually dealing with a file that starts with (hex) FE FF (UTF-16BE BOM) and is followed by UTF-8 encoded data (i.e. the following bytes are for <!-- LOCALIZERS: without NUL (hex 00) bytes between the characters), then you can probably just delete the first two bytes (Safari should then be able to auto-detect the content as UTF-8). Alternatively you could replace the leading, two-byte sequence FE FF with the three-byte sequence EF BB BF (i.e. the UTF-8 encoding of U+FEFF).

You can practice on a copy of the file if you want to try out the result before replacing the file that Safari actually uses. Just copy the file to your desktop (or wherever), hex edit that copy, then open it with Safari. After making the correct modifications (and reloading the page) you should see the Ukrainian title in the title bar and several lines of %@ in the page itself (instead of the old page of Chinese/Korean/etc. characters).

Hopefully, Apple will fix all this in some new Safari/Lion update.

share|improve this answer
It seams that the problem is in Ukrainian localization. It started when Apple introduced Ukrainian localization in one of it's updates and I've switched to it. So the whole "chinese" thing was "Cannot open the page" – Uko Apr 25 '12 at 10:11
The same problem has been reported elsewhere for the Romanian localization. It appears that Apple's Safari error pages for some localizations have bugs that causes this misreading as utf-16 encoding. – Tom Gewecke Apr 25 '12 at 13:04
Major props for the detective work, Chris! – user9290 Apr 25 '12 at 17:16

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.