2011-07-21 14 views
5
<head> 
<meta charset="ISO-8859-7"> 
</head> 

He estado trabajando con formularios y veo que la etiqueta <meta charset="ISO-8859-7"> codifica el texto que se tecleará dentro de un área de texto. Cosa que el método de codificación utilizado para almacenar el archivo no es así.¿Cómo se transmiten los caracteres sobre un formulario?

he visto que si un carácter escrito no es parte de la codificación speciefied por la etiqueta <meta charset="ISO-8859-7">, el carácter será referenced (& #D;)

que estaba suponiendo que la forma estaba enviando bytes secuencias de la codificación speciefied. Porque si escribo un carácter, sea lo que sea, será un byte que interpretará una codificación.

Por ejemplo, con el <meta charset="ISO-8859-7"> tipo i en una forma del carácter "¥"

Este carbón no es parte de la codificación pero debe enviar como un byte de la posición que representa A5, no importa si se puede representar (Esto lo hace normalmente cualquier editor).

Pero no, el formulario no lo envía como un byte, sino que el carácter es referenced.

Código:

index.php:

<?php header('Content-Type: text/html; charset=ISO-8859-7'); ?> 

<head> 
    <meta charset="ISO-8859-7"> 
</head> 
<form method="post" action="encode.php" accept-charset="ISO-8859-7"> 
    <p><textarea name="input" maxlength="10" rows="5" cols="100"></textarea></p> 
    <p><button>Submit</button></p> 
</form> 

encode.php:

<head> 
    <meta charset="ISO-8859-7"><!-- Useless, Even if is specified the ISO-8859-1 where the "¥" exist, the form sended a reference char rather an a byte to interpret.--> 
</head> 
<?php 
    $input=$_POST["input"]; 
    var_dump($input); 
?> 

Resultado de código fuente:

string(6) "&#165;" 

Nota: He probado cambiando la codificación usada para almacenar el archivo.

en el index.php: No importa lo que la codificación se utiliza para almacenar el archivo, la forma siempre enviará en consecuencia con el atributo accept-charset="" o con la etiqueta <meta charset=""> si no se especifica el accept-charset="".

Y con encode.php: La cadena nunca es codificada por el archivo. Se puede trabajar y representar, pero la codificación utilizada para almacenar el archivo no tiene nada que ver con eso.

+1

¿Por qué no utilizar UTF-8? – CuriousMind

+0

Uso UTF-8 pero me preguntaba sobre este tema. – nEAnnam

+0

¿Podría el encabezado 'Content-Type' enviar un juego de caracteres en conflicto? – cmbuckley

Respuesta

3

El problema es que el carácter escrito no es compatible con la forma de codificación.

Por lo que puedo ver, ni HTML 4 ni HTML 5 especifican qué debe hacer el navegador, si el usuario ingresa un carácter en un campo de formulario que no es compatible con la codificación del formulario.

HTML 5 qué especifican que los caracteres no admitidos deben ser sustituidos por una ? ASCII como parte de consulta de URLs¹ (y por lo tanto en los envíos de formularios GET?), Pero no puedo encontrar nada de formas POST.

Parece que todos los navegadores (o, al menos, IE, FF, Chrome, Opera) han acordado codificar caracteres no compatibles como una entidad XML. (Un mejor enfoque probablemente habría sido advertir al usuario y evitar el envío de formularios, pero eso es agua debajo del puente).

La solución es, por supuesto, usar UTF-8 hasta el final. Entonces todos los caracteres son compatibles con la codificación, y este problema no aparece.


¹ 2.6.3 Resolving URLs. HTML 5, W3C Working Draft 25 May 2011, punto 8.1:

Si el personaje en cuestión no se puede expresar en la codificación de codificación , luego sustituirlo por un solo octeto 0x3F (un signo de interrogación ASCII) [. ..]

dato curioso: lo anterior sólo se aplica a la parteconsulta (la parte después del signo de interrogación) de la IRI. El camino porción es siempre codificado utilizando UTF-8. Y el nombre de host está codificado, por supuesto, usando Punycode. La mente se confunde.

+0

¿De modo que no hay forma de que la forma acepte un elemento que no forma parte de un carácter de codificación? – nEAnnam

+0

Acerca de que HTML5 especifique que los caracteres no compatibles deben reemplazarse por ... Probablemente sea el mismo que el método POST, ¿puede consultar esa información, por favor? – nEAnnam

+0

1) Buen punto, he agregado una referencia. 2) No existe una forma bien definida para que una forma acepte caracteres que no son compatibles con la codificación del formulario. (La codificación del formulario se puede proporcionar explícitamente en la etiqueta

o derivada de la codificación del documento). –

1

¿Ha intentado también unir el juego de caracteres al elemento de forma?

<form method="post" action="encode.php" accept-charset="ISO-8859-7"> 

por ejemplo. si utiliza UTF-8, primero hay que decodificar el mensaje:

$input=utf8_decode($_POST["input"]); 

no muy seguro de si esto cubre su tema, pero yo creo que sirve de alguna manera :)

+0

Gracias pero igual que el anterior, el punto es que el formulario no se envía como un byte, incluso si uso la función 'utf8_decode()', no hay nada que decodificar. Y sobre el 'accept-charset =" ISO-8859-7 "' sigue el mismo problema. – nEAnnam

0

Las referencias charset son más de lo un navegador recibe (o acepta en su encabezado de solicitud) y no qué o cómo ingresa algo en un formulario.

creo que lo que escribe no es relevante para la definición conjunto de caracteres en su documento HTML. Lo que importa es tu lenguaje de teclado y cómo ingresas los personajes. Si tiene un idioma de teclado con un signo YEN, su navegador reconocerá el signo YEN y realizará la traducción correspondiente en una entidad o una referencia de caracteres. Querías un signo de YEN para obtener un YEN y no la representación griega de A5.

0

esto puede no ser la causa de su problema específico, pero es algo a tener en cuenta al tener problemas de codificación de caracteres: guardar los scripts PHP usando la misma codificación de caracteres. Hacer lo contrario puede causar fácilmente problemas de este tipo.

+0

Sí, es principalmente lo que hago, pero yo era bastante curioso sobre el tema. gracias hombre – nEAnnam

Cuestiones relacionadas