Escribe "this app can break" en un bloc de notas y guardalo con cualquier nombre y cualquier extensión. Ahora prueba a abrirlo. Vivir para ver (en Windows 2000/XP).
A mi si me funciona, abro notepad, copiopego salvo como "loquesea.txt" y al abrir salen caracteres extraños (cajas a falta de caracteres chinos instalados).
Por lo visto es un error de la api a la hora de detectar la encodificacion de tipo UTF-16 (pedancia +5).
¿No será algo exclusivo de Windows XP? Lo digo porque yo tengo Windows 98, entonces la noticia es errónea, debería especificar para que sistema operativo (concreto) es ¿no?
Entonces yo pondría otra descripción en el envío, mira que lo he hecho todo ilusionado para nada ... como consuelo me queda poder hacerlo por la mañana, si me acuerdo ...
"Increible", lo que se dice "increible"... Si guardáis un texto en una codificación y tratáis de interpretarlo con otra es normal que "se vea mal".
En el ejemplo del meneo escribes caracteres de 8 bits y luego los interpretas como de 16. Eso petaría igual en cualquier sitio, no solo en windows. En linux estoy harto de verlo y eso que ahí unicode significa utf-8, que es compatible con ascii.
Lo malo es que el notepad no tiene una opción de cambiar la codificación sobre la marcha. Si te pasa una cosa de estas tienes que abrir otra vez el archivo y elegir ahí la codificación o usar un editor de verdad.
no se yo si será un error, puede que tenga sentido. Usando el traductor de google http://google.com/translate
桴獩愠灰挠湡戠敲歡
de chino a ingles es
After 獩 indignant grey harassment 湡 personal sounded Fun
que pasandolo a español es
Después de la diversión sonada personal del 湡 gris indignado del hostigamiento del 獩
Despues de dos traducciones mas o menos literales parece que podría tener algun sentido, así que puede que si sea un huvo de pascua y no un error
#20 a mi con el resto de cadenas no me sale nada raro
EDITO: Me acabo de dar cuenta de que al volver a poner la primera cadena, guardarlo como un archivo nuevo y abrirlo, ya sale bien, así que puede que las otras cadenas si funcionen
Lo he probado y solo funciona si lo copias tal como esta o lo escribes tal como esta, pero si le das enter o retorno de carro o le adicionas un espacio al final de "this app can break "
no funciona el truco
Donde 74 es 't' y etc, etc. Luego, al abrirlo Notepad se hace un pequeño lío (demasiado poco texto y demasiado regular para autodetectar) y lo interpreta como si hubiera texto UTF-16LE, agrupando los bytes asi:
6874 7369 6120 7070 6320 6e61 6220 6572 6b61
Y ya está resuelto el misterio, porque 0x6874 es 桴, 0x7369 獩... Y podéis seguir descifrando (o crear más ejemplos) mirando los códigos aquí:
En el meneo explican por donde van los tiros pero si alguien quiere leer más, hace tiempo Joel escribió un artículo muy bueno sobre la problemática de las codificaciones:
para los que se esten matando haciendolo en win 98 o en otro y no le sale, en el articulo muy bien sale en que sistema operativo : "Vivir para ver (en Windows 2000/XP)."
A mi esto me pasaba con php. Al escribir en el fichero 2 o 3 veces hola mundo. efectivamente poniendo "hola mundohola mundohola mundo" también pasa. y yo que pensaba que era fallo mio
#32 Con edit tienes el problema inverso: un texto de caracteres anchos de 16 bits con o sin BOM te lo va a interpretar como ascii con el código de página que esté usando la consola de Windows porque no entiende otra cosa.
El mismo mensaje guardado como unicode y visto en edit sería dos caracteres raros (el BOM) seguido de: "t h i s a p p c a n b r e a k", donde los espacios extras no son espacios sino el caracter no imprimible 0x00.
En realidad la consola de Windows (y edit en consecuencia) tiene soporte para unicode pero no está activado por defecto por el tema de la compatibilidad. El problema de notepad --que no es una aplicación sino un ejemplo del Visual Studio-- es que por defecto escribe en un formato y por defecto tiende a leer en otro.
Pues yo no utilizo Notepad y también me sale el mismo error. Así que una de dos, o es un fallo del propio Windows o el otro programa utiliza el mismo método para detectar la codificación.
#37 la función para adivinar la codificación (si no hay BOM ni nada) que usa notepad es la windows que si no es capaz de decidir, opta por devolver la codificación por defecto de windows que es UTF-16LE. Por un lado notepad guarda ascii si no le decimos nada y por otro windows supone que cualquier texto que no sepa que es es unicode.
#38 file hace algo tan tonto como contar el número de caracteres imprimibles según el rango de los juegos de caracteres usuales. Ese archivo pr, si estás usando una consola UTF-8, es en realidad un archivo UTF-8 pero file no ha sido capaz de adivinarlo.
Comentarios
¿Cualquier nombre y cualquier extensión o solo cualquier nombre y como txt?
Curioso..
juas , pos vaya...
#1 escribe eeso y guardalo como archivo de texto y vuelve a abrirlo
¿Un huevo de pascua o un grito desesperado de advertencia de un programador de microsoft?
Lo guardo como texto, lo abro y veo lo mismo que cuando lo había escrito antes de guardarlo, no sucede nada extraño
#5 sin las comillas, a ver si es por esos. Salen cosas raras
A mi si me funciona, abro notepad, copiopego salvo como "loquesea.txt" y al abrir salen caracteres extraños (cajas a falta de caracteres chinos instalados).
Por lo visto es un error de la api a la hora de detectar la encodificacion de tipo UTF-16 (pedancia +5).
He probado de las dos formas.
¿No será algo exclusivo de Windows XP? Lo digo porque yo tengo Windows 98, entonces la noticia es errónea, debería especificar para que sistema operativo (concreto) es ¿no?
Curioso (tengo Windows XP)
桴獩愠灰挠湡戠敲歡, veo caracteres chinos, curioso.
Va a ser... WindowsXP Only! ;-P
#8 En Windows 2000 SP4... Liam, será cosa de los Win NT y con 98 no funciona. Ni idea
correcto, con win2k...
Entonces yo pondría otra descripción en el envío, mira que lo he hecho todo ilusionado para nada ... como consuelo me queda poder hacerlo por la mañana, si me acuerdo ...
He cambiado la descripción con lo de XP.
¿Y nadie sabe chino para traducirnos lo que pone? Podría ser interesante.
Según pone aquí http://www.wincustomize.com/articles.aspx?SID=1&AID=117870&c=1 son caracteres aleatorios o sin sentido en chino.
Para el que no lo vea: http://i7.photobucket.com/albums/y258/KarnEvil60/Graphic_5_22_20065_04_18PM.jpg
Curioso cuanto menos
Déjenme que pruebe:
sudo apt-get install notepad...
...
E: No se puede encontrar el paquete notepad
Oh, wait...
桴獩愠灰挠湡戠敲歡
No puedo evitar ponerlo, y si escribes
"this cat can split" o
"xxxx xxx xxx xxxxx" o
"abcd efg hij klmno"
te salen cosas raras también
"Increible", lo que se dice "increible"... Si guardáis un texto en una codificación y tratáis de interpretarlo con otra es normal que "se vea mal".
En el ejemplo del meneo escribes caracteres de 8 bits y luego los interpretas como de 16. Eso petaría igual en cualquier sitio, no solo en windows. En linux estoy harto de verlo y eso que ahí unicode significa utf-8, que es compatible con ascii.
Lo malo es que el notepad no tiene una opción de cambiar la codificación sobre la marcha. Si te pasa una cosa de estas tienes que abrir otra vez el archivo y elegir ahí la codificación o usar un editor de verdad.
no se yo si será un error, puede que tenga sentido. Usando el traductor de google http://google.com/translate
桴獩愠灰挠湡戠敲歡
de chino a ingles es
After 獩 indignant grey harassment 湡 personal sounded Fun
que pasandolo a español es
Después de la diversión sonada personal del 湡 gris indignado del hostigamiento del 獩
Despues de dos traducciones mas o menos literales parece que podría tener algun sentido, así que puede que si sea un huvo de pascua y no un error
#20 a mi con el resto de cadenas no me sale nada raro
EDITO: Me acabo de dar cuenta de que al volver a poner la primera cadena, guardarlo como un archivo nuevo y abrirlo, ya sale bien, así que puede que las otras cadenas si funcionen
Lo he probado y solo funciona si lo copias tal como esta o lo escribes tal como esta, pero si le das enter o retorno de carro o le adicionas un espacio al final de "this app can break "
no funciona el truco
#22 A ver, no te comas la cabeza que no hay mensaje oculto.
Notepad, que tiene ANSI como código por defecto, escribe esto en el archivo (en hex)
74 68 69 73 20 61 70 70 20 63 61 6e 20 62 72 65 61 6b
Donde 74 es 't' y etc, etc. Luego, al abrirlo Notepad se hace un pequeño lío (demasiado poco texto y demasiado regular para autodetectar) y lo interpreta como si hubiera texto UTF-16LE, agrupando los bytes asi:
6874 7369 6120 7070 6320 6e61 6220 6572 6b61
Y ya está resuelto el misterio, porque 0x6874 es 桴, 0x7369 獩... Y podéis seguir descifrando (o crear más ejemplos) mirando los códigos aquí:
http://www.isthisthingon.org/unicode/
Para ver la frase original de nuevo en el notepad sólo tienes que marcar en el cuadro de "Abrir..." que lo haga como ansi en vez de unicode.
Me quito el sombrero, #24
#25: Usas Red Hat?
#26, El sombrero no solo es rojo
http://www.stallman.org/articles/yellow-hat.html
#25 naaa, si es una chorrada
En el meneo explican por donde van los tiros pero si alguien quiere leer más, hace tiempo Joel escribió un artículo muy bueno sobre la problemática de las codificaciones:
http://www.joelonsoftware.com/articles/Unicode.html
pues a mi me sale poniendo "linux sucks", muy curioso lo que se puede encontrar de microsoft en contra de el OS del pingüino...
ami me sale poniendo "nose con que comer" jkajkajka.
para los que se esten matando haciendolo en win 98 o en otro y no le sale, en el articulo muy bien sale en que sistema operativo : "Vivir para ver (en Windows 2000/XP)."
#24 lo ha dejado bien claro
A mí con W2000PRO me salen cuadraditos, pero al abrirlo con EDIT desde línea de comandos veo el texto correctamente.
Lo que nos lleva a deducir que el NotePad de Windows, muestra lo que quiere el programador, y no siempre lo que debe mostrar...
Otro ejemplo de código malicioso en aplicaciones de M$... menos mal que hay otros visores de txt y editores que no sean preciosa kakita
#7:
(pedantería +5, gramática -5)
sin acritud
A mi esto me pasaba con php. Al escribir en el fichero 2 o 3 veces hola mundo. efectivamente poniendo "hola mundohola mundohola mundo" también pasa. y yo que pensaba que era fallo mio
#32 Con edit tienes el problema inverso: un texto de caracteres anchos de 16 bits con o sin BOM te lo va a interpretar como ascii con el código de página que esté usando la consola de Windows porque no entiende otra cosa.
El mismo mensaje guardado como unicode y visto en edit sería dos caracteres raros (el BOM) seguido de: "t h i s a p p c a n b r e a k", donde los espacios extras no son espacios sino el caracter no imprimible 0x00.
En realidad la consola de Windows (y edit en consecuencia) tiene soporte para unicode pero no está activado por defecto por el tema de la compatibilidad. El problema de notepad --que no es una aplicación sino un ejemplo del Visual Studio-- es que por defecto escribe en un formato y por defecto tiende a leer en otro.
Pues yo no utilizo Notepad y también me sale el mismo error. Así que una de dos, o es un fallo del propio Windows o el otro programa utiliza el mismo método para detectar la codificación.
Por si alguien quiere probarlo, es este: http://www.flos-freeware.ch/notepad2.html
$ echo this app can break > pr
$ file pr
pr: ASCII text
$ cat pr
this app can break
$ echo 桴獩愠灰挠湡戠敲歡 > pr2
$ file pr2
pr2: UTF-8 Unicode text
$ cat pr2
桴獩愠灰挠湡戠敲歡
Muahaha, chúpate esa, MS!!
#37 la función para adivinar la codificación (si no hay BOM ni nada) que usa notepad es la windows que si no es capaz de decidir, opta por devolver la codificación por defecto de windows que es UTF-16LE. Por un lado notepad guarda ascii si no le decimos nada y por otro windows supone que cualquier texto que no sepa que es es unicode.
#38 file hace algo tan tonto como contar el número de caracteres imprimibles según el rango de los juegos de caracteres usuales. Ese archivo pr, si estás usando una consola UTF-8, es en realidad un archivo UTF-8 pero file no ha sido capaz de adivinarlo.