/*----------------------------------------------------------------------*/ Este estandar se hace necesario si no se quiere corromper la informacion en un mundo cada vez mas multicultural y multidireccional. Si tu tienes un servidor que lee con un set de caracteres y le llega informacion con otro formato, pues cagado la hemos si no puede hacer la conversion. Por ejemplo, si te llega un mail escrito en tailandes y lo lees con un programa que solo reconoce griego, patapam!, no lo entendera ni un tailandes ni un griego [ni un frances ni una cubana]. Por eso la gran mayoria de internacionales informaticas ya han adoptado el Unicode, y todos los sistemas operativos modernos ya lo soportan. ¿Todos? Todos no, todavia resisten frente al invasor los irreductibles Windows9x. Afortunadamente hay aplicaciones como las de Office-97 o Internet Explorer que soportan Unicode aunque sea en Windows9x. Un ejercicio interesante es ver un archivo Unicode. Escribamos la letra arabe 'teh' en un documento .doc de Word (es una letra que parece una sonrisa con dos puntitos encima como si fueran ojos). Puedes copiarlo de una pagina .htm y pegarlo en el .doc, o puedes insertarlo directamente en el .doc desde la opcion 'Insertar -> Simbolo'. Guardemoslo como 'texto unicode'. Lo siguiente es observarlo con un visor hexadecimal (p.ej. hiew): FF FE 2A 06 0D 00 0A 00 Vemos que no aparece el valor 'CA'x del ANSI 1256, sino 8 bytes. ¿Por que? . FFFE hace referencia al sentido en que hay que leer los pares de bytes. Es el llamado BOM [Byte Order Mark]. Resulta util en los archivos para los que no se sabe si son little endian [el byte mas significativo de los almacenados en memoria es el ultimo] o big endian [es el primero]. FFFE expresa little endian, y FEFF expresa big endian, ambos para Unicode de 16 bits. . 2A06 es el caracter arabigo 'teh'. Algo que he leido frecuentemente es que en Unicode, uno de los 2 bytes es nulo; recuerda que esto solo es cierto si estamos ante caracteres Unicode latinos. A tener en cuenta que la letra 'teh' tambien es el valor '95FE'x. . 0D 00 es retorno de carro. . 0A 00 es algo asi como fin de linea. Entonces, ¿el Unicode es de 2 bytes? Es lo que dicen la mayoria de los articulos sobre Unicode. Pero el consorcio Unicode indica que hay de 8, 16 y 32 bits, mas que de Unicode, de UTF [ref.5]. P.ej.: '61'x = 'a' [UTF-8 (y UTF-7)] '0061'x = 'a' [UTF-16] '00000061'x = 'a' [UTF-32] ¿UTF? Si, UCS Transformation Format. ¿UCS? Si, Universal Character Set o ISO 10646. ¿ISO? Si, International Organization of Standardization. ¿IOS? Pozzi. El UTF evita el uso de codigos Unicode reservados. Es por ello que aunque la letra arabe 'teh' sea en Unicode el valor '062A'x, en UTF-8 acaba siendo 'D8AA'x: 11xxxxxx 10xxxxxx --> mascara UTF-8 [consulta ref.5] 011000 101010 --> valor binario del codigo Unicode de 'teh' (062A) ----------------- + 11011000 10101010 --> valor binario del valor UTF de 'teh' D8 AA --> valor hexadecimal del valor UTF de 'teh' * * * El estandar Unicode aporta una serie de algoritmos interesantes: - de ordenacion [UCA o Unicode Collation Algorithm], o sea, lo que ocurre cuando haces un ORDER BY de SQL. ¿Como se ordena alfabeticamente las letras chinas o arabes? ¿Y si hay registros en chino y en espa=ol a la vez? - de compresion [SCSU o Standard Compression Scheme for Unicode]: todo un mundo el de las compresiones. - de bidireccionalidad [BIDI]: mi favorito. 06.Algoritmo BIDI ----------------- La escritura arabe y la hebrea tienen un comportamiento comun [toda una metafora :| ] y es que se escriben de derecha a izquierda. Para permitirlo, existe el algoritmo BIDI, que produce un fascinante comportamiento en los textos en edicion para esas escrituras. Observa tu mismo como funciona. Primero escojamos un programa que permita editar en Unicode. Por ejemplo, la edit control de busqueda del Google desde IE 5.5 o MF 0.9. Pega una sola letra arabe en la celda de edicion. Se tendria que pegar sin problemas: en arabe. Ademas el cursor parpadeante tiene que haber quedado a la izquierda de la letra. Es curioso. Pega mas veces la misma letra, unas veces con espacios entre medio y otras sin ellos. ¡No siempre se pega lo mismo! El algoritmo es lo suficientemente listo como para aplicar la siguiente norma linguistica referente a las ligaturas de letras arabes: Una letra arabe puede escribirse en cuatro formas diferentes, segun se escriba aislada, como letra final de una palabra, entre otras 2 letras, o como letra inicial de una palabra. Si tienes nociones de arabe esto tambien te habra resultado fascinante. Ahora escribe letras latinas, numeros o simbolos aritmeticos. El cursor se situa en una posicion u otra y el sentido de escritura es de dcha. a izqda. o de izqda. a dcha., todo ello segun lo que vas escribiendo [contextual]. Esto es util para escribir en la misma frase palabras arabes y latinas, o escribir numeros y simbolos mientras escribes en arabe [aunque el arabe se escriba al reves que el espa=ol, el numero 1234 no es el 4321, sigue siendo el 1234]. Tambien el comportamiento de la seleccion de texto o del avance del cursor esta alterado. No se vosotros, pero yo lo encuentro fantastico!! Ved el codigo en ref.5. Hay alternativas al BIDI de Unicode(TM), como el FriBidi, el PGB [no, no es el Partido de la Gente del Bar, es el Pretty Good Bidi Algorithm] y el JavaBidi de IBM. 07.Sets en navegadores ---------------------- Ahora que tenemos algunas nociones sobre los sets, veamos como pueden ser representados en los navegadores de Internet. A nadie le habra pasado inadvertido el gigantesco menu de codificaciones que suelen ofrecer los navegadores de Internet: 18 en Netscape Comunicator 4.5, 30 en Internet Explorer 5.5 y 79 en Mozilla Firefox 0.9. Desde el vietnamita hasta el turco pasando por el hebreo y el chino simplificado... Los .htm a los que estamos acostumbrados suelen tener el meta tag referente al charset, de forma que el navegador seleccionara ese alfabeto. Los mas comunes por aca son: Pero estos impiden mostrar la mayoria de caracteres no latinos. P.ej. la letra arabe 'teh' Unicode aparecera como un interrogante. En el html esa letra arabiga se puede escribir de 3 formas para mostrarse con el aspecto esperado: - directamente si lo permite el editor de html. - mediante NCR's: P.ej. '
ت
'. Ese numero es el valor Unicode (062A) expresado en forma decimal. - mediante la codificacion UTF-8 directamente. P.ej. 'ت
' (xD8AA). , y siempre que el charset haga referencia al UTF [ref.6]: Tambien se puede codificar en Java [\u062A] o en Javascript [%u062A]. Como observacion, en una TextArea de una applet java (JDK 1.1.8, estoy anticuado, lo se) no hay ni ligatura de letras arabes ni bidireccionalidad. Ademas, las edit control (como las de contrase=a) se comportan de forma independiente al meta tag charset. Asi pues, IE 5.5 o MF 0.9 admiten caracteres arabes en la edit control aunque el charset no sea el UTF-8. Y otros como NC 4.5 no lo admiten en ningun caso (y aparecen interrogantes en vez de letras no latinas). 08.Passwords y Unicode ---------------------- Veamos ahora como la codificacion Unicode repercute en la seguridad de nuestras passwords, para bien y para mal. Generalmente cuando escribimos una password en Windows esta queda ocultada bajo asteriscos. P.ej. gracias al input type="password" de javascript, o al estilo ES_PASSWORD de un edit control de la API Win32, o a la clase TextField (AWT) de Java. Si la password esta asteriscada, el desasteriscador que la desasterisque buen desasteriscador sera. El primero que he encontrado por Internet es el Asterisk Key [AK]. Los desasteriscadores suelen basarse en quitar el flag ES_PASSWORD, por ejemplo lanzando lo siguiente contra todas las ventanas 'hijas' de la clase 'edit': SendMessage(GetDesktopWindow(),EM_SETPASSWORDCHAR,0,0); , o leer lo que haya en ellas con GetWindowText [ref.22]. La ayuda de AK dice que 'Multilingual passwords are supported'. ¿Seguro? Por ejemplo, vayamos a la pagina de correo de Yahoo y escribamos en el campo de contrase=a letras y numeros. Si tienes abierta la pagina web, el AK es capaz de detectarlo y de devolverte la password ocultada bajo asteriscos sin problemas. Ahora pongamos de password caracteres que lleven acentos o la e=e. El AK sigue sacando la password facilmente. Ahora pon de password letras arabes (con copiar y pegar); observa que se dan signos del algoritmo BIDI. Pero... prrrtz!!! El AK devuelve interrogantes, uno por cada caracter no ASCII. Si pegamos las mismas letras arabes en la edit control de usuario, la ausencia de asteriscos nos dejara ver dichas letras arabes. Por tanto, supongo que hay que entender 'multilingual' referido a que el AK soporta lenguas romanicas, germanicas, euskera y poquito mas. El AK tambien devuelve los interrogantes en el caso de pegar caracteres arabes en la casilla de password del Norton Antivirus, del Winzip 7.0 y en la de Project de Word ['Herramientas -> Macro -> Editor de Visual Basic -> Herramientas -> Propiedades de Project -> Proteccion']. Pero en estos casos hay un detalle importante: no se dan signos de bidireccionalidad cuando se pegan caracteres arabes. ¿Realmente estamos pegando letras arabes? Si corremos el recuperador de passwords de Winzip Zip Password 5.0, este nos recupera interrogantes. Entonces, ¿la funcion de copiar y pegar no funciono correctamente porque la edit control de Winzip no soportaba Unicode, y pusimos interrogantes como password creyendo que se pegarian letras arabes? Es posible. De hecho, seguro que las passwords de muchos miles de personas que utilizan lenguas no latinas son simples interrogantes :O, por falta de soporte al Unicode de los programas y por los asteriscos. Pero no es tan sencillo, ya que podria haber sido el propio Zip Password el que no soportara el Unicode. De hecho, eso ocurre con algunos recuperadores de passwords de Word y Excel. Veamos algunos ejemplos: 08.1.Passwords en Word ---------------------- Me refiero a Word v8.0. Puedo introducir una password a traves del copiar y pegar de letras o palabras, incluso escritas en arabe. En nuestro caso, una sencillita como la letra 'teh' [U+062A]. ¿Donde? En 'Herramientas -> Opciones -> Guardar -> Contrase=as'. Aceptar. Pide confirmacion, pues se la meto de nuevo, sin vaselina. Aceptar. Parece que le ha gustado. Observa que al introducir esa contrase=a se dan signos del algoritmo BIDI, con lo que podemos estar seguros de haber metido letras arabes. Y ahora a por algunos recuperadores [demos], por orden alfabetico [alfabeto latino, claro]: 1) AOXPPR 2.42 de ElcomSoft Me permite a=adir caracteres en hexa en la celda 'Custom Charset'. Si no a=ado expresamente '2A06', la contrase=a en hexa, no la encuentra. Si la a=ado, tarda pocos milisegundos en recuperarla. Excelente. 2) Guaranteed Word 97/2000 Decryptor v.1.3 beta de PSW-soft. Una demo en modo consola que solo permite crackear passwords 'nyxo'. No, no es un tecnicismo, es la password a crackear, con lo que no podemos hacer la prueba. Su ayuda asegura que tolera todo tipo de sets de caracteres. 3) Word Key Demo 6.3 de Passware La edit control de los caracteres a utilizar en el ataque por fuerza bruta permite el 'paste' de caracteres arabes copiados de otro sitio, y la password la saca en muy poco tiempo. Excelente. 4) WordPassword DEMO v5.0 de LastBit Software He probado todas las opciones de la demo y no se hacer que me recupere la contrase=a. Dispone de una opcion para seleccionar el set de caracteres [code page], como el 1256 Arabic, lo cual sugiere que si que la puede recuperar, pero no lo he conseguido. Sin calificar. 5) Word Password Recovery v1.0g de Intelore software No saca la password y no tiene pinta de que la pueda sacar. Admite como mucho los caracteres del ASCII extendido. Suspendido. 6) Word Recovery 2003 demo de Password Service Esta demo exige que la password empiece por 'zz'. Asi que en vez de la letra 'teh', pondremos 'zz[teh]'. Los sets de caracteres no admiten mas que el ASCII y poco mas. Suspendido. 08.2.Passwords en Excel ----------------------- Hablamos de Excel97. Para introducir una password podemos ir a la opcion 'Herramientas -> Proteger'. Le enchufamos de password el mismo caracter arabe de antes: la letra 'teh'. Confirmamos y parece que chuta. No obstante, advierte que 'la contrase=a contiene caracteres acentuados o ciertos signos de puntuacion que no se transferiran correctamente a Microsoft Excel para Macintosh'. Pues vale. Para los .xls, Lastbit Software tiene a ExcelPassword DEMO v5.0. Esta version advierte que para sacar ese tipo de passwords he de comprar la version entera. Identica advertencia de Excel Key Demo 6.3, que almenos admite caracteres en arabe en la edit control de 'Symbol set -> Custom', lo cual sugiere que es capaz de recuperarla. AOXPPR 2.42 de ElcomSoft me devuelve BL9. Eso son 3 caracteres, y yo puse solamente uno. El caso es que sirve tanto si metes el caracter 'teh' como si metes 'BL9'. En dos palabras: noacabo dentenderlo. Veamoslo en hexa y a camara lenta: 'BL9' ('424C39'x) = 'teh' ('2A06'x) Otros ejemplos: '123' = '123'; 'a' = 'a'; '[alfa]' = 'a'; 'aa' = 'aa'; '[alfa]' + 'a' = 'Aq'; 'a' + '[alfa]' = 'Aq'... absurdo!!!? ¿Alguien podria explicar que algoritmo se utiliza? 08.3.Conclusiones sobre passwords --------------------------------- Inicialmente pensaba que seria posible pegar caracteres arabes o chinos en una edit control de contrase=a para asi ser irrecuperable por las actuales herramientas de crackeo. O incluso poner una password en Times New Roman 14 y que fuera diferente de la misma pero en Arial 12. Esto ultimo hoy por hoy es algo descabellado viendo como funcionan los sets de caracteres, las fuentes y las edit controls. Pero escribirla con Unicode puede ser util. Una password Unicode es mas dificil de sacar que una password ASCII, porque las combinaciones con las que podemos hacer passwords son muchas mas (y el tiempo en reventarla, mayor). Ademas, palabras como las arabes no aparecen en los diccionarios tipicos de crackeo. Y los keyloggers de poco serviran si no tienen en cuenta el teclado que estamos utilizando. Ademas, los caracteres atipicos son dificiles de comunicar, lo cual es una ventaja frente a la Ingenieria social. Podriamos a=adirlo a la tipica checklist para passwords, recuerdo: utilizar simbolos y no solo letras, alternar mayusculas y minusculas, evitar que coincida con palabras reales o con conceptos que se relacionen con nuestro entorno, cambiarla cada poco tiempo... Pero solo si lo soporta el programa que nos pide la password. Si el programa no lo soporta, podemos estar escribiendo interrogantes como password sin darnos cuenta, y eso lo saca hasta el pato Donald. Igualmente, ya hay recuperadores que han previsto el Unicode. Una curiosidad mas, si googleais 'passwords en arabe' apareceran multitud de paginas porno. ¿Alguien lo entiende? 09.Portapapeles --------------- En todos los ejemplos hemos utilizado el copiar y pegar de letras arabes, que es una opcion valida siempre que origen y destino soporten Unicode. Supongo que se puede escribir directamente en arabe si se instalan y se activan los locales y drivers correspondientes en la maquina [National Language Support API y MultiLingual API] [ref.7]. Ahora comentare un par de comportamientos extra=os que he encontrado con la API de copiar y pegar, simplemente por el hecho de comentarlos. 1) Parece ser que la conversion automatica de CF_UNICODETEXT -> CF_TEXT de la API, segun la ref.3 no esta contemplada en mi Windows98: Clipboard Format Conversion Format Platform Support ---------------- ----------------- ---------------------- CF_OEMTEXT CF_TEXT Windows NT, Windows 95 CF_OEMTEXT CF_UNICODETEXT Windows NT CF_TEXT CF_OEMTEXT Windows NT, Windows 95 CF_TEXT CF_UNICODETEXT Windows NT CF_UNICODETEXT CF_OEMTEXT Windows NT CF_UNICODETEXT CF_TEXT Windows NT x? Sin embargo, puedo copiar y pegar 'letras' Unicode en los programas de Office-97, IE, o en WordPad. Eso es porque son programas Unicode con acceso directo a todos los caracteres en todos los sets soportados en una fuente. Si copio el caracter Unicode 'teh' de un .htm, y lo pego en el WordPad, muestra la letra 'teh' correctamente. Lo extra=o es que si miro con un visor hexadecimal ese mismo .txt, veo que hay '3F'x, o sea, un interrogante. Pero no veo un interrogante, yo estoy viendo una 'teh'!! Al cerrar WordPad y volver a abrirlo, aparece el interrogante que detectaba el visor hexadecimal. ¿Alguien sabe como la GDI me llega a mostrar lo que no hay? 2) Si copio una simple letra (arabe o no) de un .doc y lo pego en el FrontPage Express v2, aparecera algo como esto: {\rtf1\ansi\ansicpg1252\uc1 \deff0\deflang1033\deflangfe3082{\fonttbl{\f0\ froman\fcharset0\fprq2{\*\panose 02020603050405020304}Times New Roman;}{\f 2\fmodern\fcharset0\fprq1{\*\panose 02070309020205020404}Courier New;} {\f 16\froman\fcharset238\fprq2 Times New Roman CE;}{\f17\froman\fcharset204\f prq2 Times New Roman Cyr;}{\f19\froman\fcharset161\fprq2 Times New Roman G reek;}{\f20\froman\fcharset162\fprq2 Times New Roman Tur;} {\f21\froman\fc harset186\fprq2 Times New Roman Baltic;}{\f28\fmodern\fcharset238\fprq1 Co urier New CE;}{\f29\fmodern\fcharset204\fprq1 Courier New Cyr;}{\f31\fmode rn\fcharset161\fprq1 Courier New Greek;}{\f32\fmodern\fcharset162\fprq1 Co urier New Tur;} {\f33\fmodern\fcharset186\fprq1 Courier New Baltic;}}{\col ortbl;\red0\green0\blue0;\red0\green0\blue255;\red0\green255\blue255;\red0 \green255\blue0;\red255\green0\blue255;\red255\green0\blue0;\red255\green2 55\blue0;\red255\green255\blue255; \red0\green0\blue128;\red0\green128\blu e128;\red0\green128\blue0;\red128\green0\blue128;\red128\green0\blue0;\red 128\green128\blue0;\red128\green128\blue128;\red192\green192\blue192;}{\st ylesheet{\nowidctlpar\widctlpar\adjustright \f2\fs18\lang1027\cgrid \snext 0 Normal;}{\*\cs10 \additive Default Paragraph Font;}}\margl1701\margr1701 \margt1417\margb1417 \deftab708\widowctrl\ftnbj\aenddoc\hyphhotz425\formsh ade\pgbrdrhead\pgbrdrfoot \fet0\sectd \linex0\headery709\footery709\colsx7 09\endnhere\sectdefaultcl {\*\pnseclvl1\pnucrm\pnstart1\pnindent720\pnhang {\pntxta .}}{\*\pnseclvl2\pnucltr\pnstart1\pnindent720\pnhang{\pntxta .}}{ \*\pnseclvl3\pndec\pnstart1\pnindent720\pnhang{\pntxta .}}{\*\pnseclvl4\pn lcltr\pnstart1\pnindent720\pnhang{\pntxta )}}{\*\pnseclvl5 \pndec\pnstart1 \pnindent720\pnhang{\pntxtb (}{\pntxta )}}{\*\pnseclvl6\pnlcltr\pnstart1\p nindent720\pnhang{\pntxtb (}{\pntxta )}}{\*\pnseclvl7\pnlcrm\pnstart1\pnin dent720\pnhang{\pntxtb (}{\pntxta )}}{\*\pnseclvl8\pnlcltr\pnstart1\pninde nt720\pnhang {\pntxtb (}{\pntxta )}}{\*\pnseclvl9\pnlcrm\pnstart1\pnindent 720\pnhang{\pntxtb (}{\pntxta )}}\pard\plain \nowidctlpar\widctlpar\adjust right \f2\fs18\lang1027\cgrid {\lang1034 \u1578\'3f}} Se trata de otro cruce de cables de las funciones de 'copiar y pegar'. No aparece en FPE v4. Esas lineas son texto con codificacion RTF. [Ref.18:] El RTF [Rich Text Format] es un metodo de codificacion de textos y graficos para ser transferidos entre Windows, MS-DOS y Macintosh. Admite los sets de caracteres ANSI, OEM 850 y 437 [es el OEM tipico de los USA], y Apple Macintosh, y como no, Unicode. Posee un monton de controles que me recuerda un lenguaje de tags, como el html, y entre ellos... si, ke pesao, hay controles de bidireccionalidad. Si creais un archivo de texto y lo guardais como 'texto RTF', y despues lo observais con un visor hexadecimal, vereis que es muy parecido a las lineas de antes. En concreto, el '\u1578' que aparece en la ultima linea es nuestra querida letra teh (U+062A). 10.Compilando Unicode en Windows -------------------------------- Hemos visto que hay aplicaciones que soportan Unicode y otras que no. Tambien parece haber compiladores que lo contemplan y otros que no. Yo normalmente compilo C con el lcc-Win32, y no he encontrado ninguna referencia para poder compilar un programa Unicode. Tampoco el djgpp parece soportarlo. Aunque las librerias graficas Allegro [ref.14] si que tratan muy bien los diferentes sets, Unicode incluido, incluso si se compila con el djgpp. Un ejemplo es el exunicod.c que trae en su bateria de ejemplos. Tambien distinguen Unicode las includes del viejo Borland C++ Compiler 5.5, pero hace siglos que no lo utilizo, y ya no se ni como funciona... Uno de mis preferidos, el Dev-C++ v4.0 [Mingw32] si que lo contempla en sus propias librerias, y es el que he utilizado. Por ejemplo, si observamos su include tchar.h, veremos que hay definiciones por duplicado, unas para Unicode y otras para no-Unicode [ANSI]: /* Non-unicode (standard) functions [las de toda la vida] */ #define _tprintf printf #define _tcscpy strcpy #define _tcslen strlen /* Unicode functions */ #define _tprintf wprintf #define _tcsncpy wcsncpy #define _tcslen wcslen Ademas casi todas las funciones estan definidas por duplicado, teniendo una de ellas una 'W' final ['W' de wide char, o sea, Unicode]; por ejemplo las tipicas Boxes de alerta pueden codificarse de 2 formas: int WINAPI MessageBoxA(HWND,LPCSTR,LPCSTR,UINT); //para ANSI int WINAPI MessageBoxW(HWND,LPCWSTR,LPCWSTR,UINT); //para Unicode He podido compilar un programa Win32 Unicode con el Dev-C++ en Windows98. Para ello, hay que incluir al principio las siguientes definiciones: #define UNICODE //para que compile como Unicode #define _UNICODE //para que pueda acceder a tchar.h como Unicode #include