iis - Problema al usar unicode en las URL con cgi.PATH_INFO en ColdFusion
pathinfo (3)
Esto es lo que puedes hacer:
<cfset url.searchTerm = URLEncodedFormat("القاهر", "utf-8") >
<cfset myVar = URLDecode(url.searchTerm , "utf-8") >
Por supuesto, recomendaría que trabajas con algo como esto en ese caso:
yourtemplate.cfm? searchTerm =% C3% 98% C2% A7% C3% 99% E2% 80% 9E
Y luego se hace la reescritura de URL en IIS (si no se ha hecho ya por framework / resto de la aplicación) http://learn.iis.net/page.aspx/461/creating-rewrite-rules-for-the-url-rewrite -module / para que coincida con su patrón.
Mi sitio ColdFusion (MX7 en IIS 6) tiene una funcionalidad de búsqueda que agrega el término de búsqueda a la URL, por ejemplo, http://www.example.com/search.cfm/searchterm .
El problema al que me estoy enfrentando es que este es un sitio multilingüe, por lo que el término de búsqueda puede estar en otro idioma, por ejemplo, القاهرة conduce a una URL de búsqueda como http://www.example.com/search.cfm/القاهرة
El problema es cuando vengo a recuperar el término de búsqueda de la URL. Estoy usando cgi.PATH_INFO para recuperar la ruta de la página de búsqueda y el término de búsqueda y extraer el término de búsqueda de este, por ejemplo /search.cfm/searchterm , sin embargo, cuando se usan caracteres Unicode en la búsqueda, se convierten en signos de interrogación. /search.cfm/?????? .
Estos aparecen signos de interrogación reales, en lugar de que el navegador no pueda formatear caracteres Unicode, o que se alteren en la salida.
No puedo encontrar ninguna información sobre si ColdFusion admite unicode en la URL, o cómo puedo resolver esto y obtener la URL completa de alguna manera. ¿Alguien tiene alguna idea?
Aclamaciones,
Tom
Editar : La investigación adicional me ha llevado a creer que el problema puede estar relacionado con IIS en lugar de ColdFusion, pero mi consulta original sigue en pie.
Editar más
El resultado de GetPageContext().GetRequest().GetRequestUrl().ToString() es http://www.example.com/search.cfm/searchterm/????? por lo que parece que el problema es bastante profundo.
Puede establecer la codificación de caracteres de la URL y el alcance de FORMULARIO utilizando la función setEncoding ():
Debe hacer esto antes de acceder a cualquiera de las variables en este ámbito.
Pero la codificación predeterminada de esos ámbitos ya es UTF-8, por lo que puede no ser de ayuda. Además, esto probablemente no afecte el alcance de CGI.
¿El Servidor IIS está registrando los caracteres correctos en el registro de solicitud?
Sí, en realidad no es culpa de ColdFusion. Es un problema común.
Principalmente es culpa de la especificación CGI original, que especifica que PATH_INFO tiene que estar codificado en%, perdiendo así las secuencias de bytes %xx originales que le habrían permitido averiguar a qué caracteres verdaderos se referían.
Y es en parte culpa de IIS, porque siempre intenta leer %xx bytes enviados en la parte de la ruta como Unicode codificado en UTF-8 (a menos que la ruta no sea una secuencia de bytes UTF-8 válida, en cuyo caso aumenta el valor predeterminado de Windows página de códigos, pero no le da ninguna forma de descubrir que esto ha sucedido). Una vez hecho esto, lo pone en variables de entorno como una cadena Unicode (como envvars son Unicode en Windows).
Sin embargo, la mayoría de las herramientas basadas en bytes que usan C stdio (y supongo que esto se aplica a ColdFusion, como en Perl, Python 2, PHP, etc.) luego intentan leer las variables de entorno como bytes y las codificaciones de tiempo de ejecución de MS C el contenido Unicode vuelve a usar la página de códigos predeterminada de Windows. Por lo tanto, los caracteres que no encajan en la página de códigos predeterminada se pierden para siempre. Esto incluiría sus caracteres árabes cuando se ejecuta en una instalación de Western Windows.
Una secuencia de comandos inteligente que tiene acceso directo a la API Win32 GetEnvironmentVariableW podría llamar a eso para recuperar una variable de entorno nativo-Unicode que luego podrían codificar a UTF-8 o lo que quisieran, asumiendo que la entrada también era UTF-8 (que es lo que generalmente querrías hoy). Sin embargo, no creo que CodeFusion le otorgue este acceso, y en cualquier caso, solo funciona desde IIS6 en adelante; IIS5.x descartará cualquier carácter de página de códigos no predeterminada incluso antes de que lleguen a las variables de entorno.
De lo contrario, su mejor apuesta es la reescritura de URL. Si una capa por encima de CF puede convertir esa search.cfm/القاهرة a search.cfm/?q=القاهرة entonces no enfrentará el mismo problema, ya que la variable QUERY_STRING , a diferencia de PATH_INFO , no está especificada como% -decoded, por lo que los %xx bytes permanecen donde una herramienta en el nivel de CF puede verlos.