Los caracteres que has publicado son los que obtienes si tomas el texto que aparece al final de este post, lo codificas como UTF-8 y luego (por error) lo decodificas como UTF-16BE.
En última instancia, Safari está decodificando los datos de forma incorrecta (debería decodificarse como UTF-8, pero se está decodificando como UTF-16BE). Esto puede ocurrir por varias razones:
- El servidor dijo incorrectamente Safari para decodificar como UTF-16BE (por ejemplo, a través de un
charset en el parámetro Content-Type cabecera de la respuesta HTTP del servidor).
- El servidor ha antepuesto incorrectamente un UTF-16BE LISTA DE MATERIALES antes de los datos UTF-8.
-
Safari está configurado por defecto en UTF-16BE.
Sin embargo, no estoy seguro de cómo se lograría esto realmente. La única entrada UTF en la lista de codificación manual † es "Unicode (UTF-8)", lo que parece excluir la posibilidad de forzar UTF-16BE (a diferencia de TextEdit donde en realidad se puede seleccionar UTF-16BE, si se personaliza su lista de codificaciones).
-
Safari autodetectado la codificación de forma incorrecta.
Su problema particular parece ser un servidor (o proxy) ‡ ) ya que dices que sólo ocurre de forma intermitente.
La pestaña Red de Safari El Inspector de la Web puede mostrarle las cabeceras de respuesta del servidor (para confirmar o negar un error charset ), pero probablemente sería molesto tener que acordarse siempre de abrirlo/activarlo para cada pestaña que se abra (para capturar la información debe estar ya activo antes de que se cargue la página de interés, lo que puede ser difícil de predecir si su problema es intermitente).
Una captura de paquetes podría identificar una lista de materiales errónea (y/o una charset ), pero estas herramientas son mucho menos convenientes (también suelen ser inútiles para las solicitudes cifradas (HTTPS)). Si sabe que el problema se produce con bastante frecuencia, podría enviar muchas peticiones a través de rizo y tratar de identificar las listas de materiales erróneas/ charset s mirando los datos que puede reportar (cabeceras de respuesta del servidor y los bytes de contenido en bruto).
† Puedes elegir manualmente una codificación (en Safari 5.1) a través del submenú Codificación del texto del menú Ver.
‡ Dicho apoderado podría ser un "transparente" proxy que de otro modo no sospecharía.
<!-- LOCALIZERS: Each localizable piece of the page is marked with a comment -->
<HTML>
<!-- LOCALIZERS: If in a right-to-left locale, add dir="rtl" to the HTML element. -->
<HEAD>
<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. -->
<STYLE>
BODY {font-family:'Helvetica Neue';}
</STYLE>
<!-- LOCALIZERS: The next line contains the page title that appears in the window's title bar -->
<TITLE>Не вдалося відкрити сторінку</TITLE>
</HEAD>
<BODY>
<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>
<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>
</div>
</div>
</BODY>
</HTML>
La traducción de Google sugiere que el cirílico <title> El texto parece ser ucraniano para "No se pudo abrir la página".
Los comentarios indicaban que este texto sólo empezó a aparecer tras una actualización de software de Apple. La actualización exacta fue probablemente la 10.7.3 actualización que añadió la localización para varios idiomas, incluido el ucraniano.
No tengo un sistema 10.7, pero el contenido anterior (aparte del ucraniano <title> ) es en gran medida idéntico al contenido de los archivos de 10.6 ( Safari 5.1.3) con nombres como /Applications/Safari.app/Contents/Resources/*.lproj/StandardErrorPage.html todos estos archivos (en 10.6 Safari 5.1.3) están codificados en UTF-16LE con una lista de materiales (UTF-16LE). Esto apunta fuertemente a la segunda razón posible que he descrito: el "servidor" (en realidad sólo un archivo local) está suministrando contenido con una lista de materiales incorrecta.
Si puede identificar el archivo utilizado para su localización particular, probablemente pueda "arreglarlo". Como conjetura, el archivo ucraniano es probablemente algo como …/ua.lproj/StandardErrorPage.html .
Nota: La modificación de este archivo puede romper Safari "firma de código". En la versión 10.6, la versión inglesa de este archivo aparece en el …/Safari.app/Contents/_CodeSignature/CodeResources como "opcional", por lo que podría estar bien (no lo he probado). Si intentas editar/reemplazar el archivo, haz primero una copia de seguridad. Para estar seguro, puedes hacer una copia de todo el Safari.app carpeta.
Puede utilizar un editor hexadecimal (por ejemplo HexFiend ) para ajustar los bytes iniciales de la lista de materiales. Si se trata de un archivo que comienza con (hex) FE FF (UTF-16BE BOM) y va seguido de datos codificados en UTF-8 (es decir, los siguientes bytes son para <!-- LOCALIZERS: sin NUL (hex 00 ) entre los caracteres), entonces probablemente pueda eliminar los dos primeros bytes ( Safari debería ser capaz de autodetectar el contenido como UTF-8). Como alternativa, puede reemplazar la secuencia de dos bytes que encabeza el texto FE FF con la secuencia de tres bytes EF BB BF (es decir, la codificación UTF-8 de U+FEFF).
Puede practicar con una copia del archivo si quiere probar el resultado antes de sustituir el archivo que Safari utiliza realmente. Sólo tienes que copiar el archivo en tu escritorio (o donde sea), editar hexagonalmente esa copia, y luego abrirlo con Safari . Después de hacer las modificaciones correctas (y de recargar la página) debería ver el título ucraniano en la barra de título y varias líneas de %@ en la propia página (en lugar de la antigua página de caracteres chinos/coreanos/etc.).
Esperemos que Apple arregle todo esto en algún nuevo Safari /Actualización del león.
