Autoit.ES

Hola

Estoy haciendo un servidor, al que se conecten los usuarios vía telnet, con el cliente telnet que quieran.

Siguiendo lo que os preguntaba en este hilo:

http://www.emesn.com/autoitforum/viewto ... nsi#p11382

Quiero controlar el diseño del texto que el servidor le envía al cliente, para poder poner colores, tabulaciones, controlar la paginación, etc.

He capturado lo que envían algunos servidores a los que uno se conecta vía telnet (como aún frecuento alguno, se me ocurrió así a voz de pronto un mud cualquiera) y vi, que enviaban el texto en carácteres ascii, algunos en decimal y otros en hexadecimal, con algún código raro por medio. Como por ejemplo al principio de cada línea algo como:
No se para qué enviarán eso... La cuestión, es, que evidentemente, el cliente telnet que sea (el de Windows mismo) lo interpreta y muestra correctamente. Imprime en pantalla los carácteres imprimibles, y los que no lo sean los procesa...

Pero, al intentar hacer yo lo mismo pues como que es un desastre.

Si envío algo como:
es exactamente lo que se ve en el cliente. Da lo mismo que lo mande en decimal que en hexadecimal...

Pero, curiosamente, si lo envío así:
el cliente lo muestra correctamente, y si son carácteres no imprimibles los procesa bien.

Ahora bien, si envío:
también se ve correctamente en el cliente. Pero, si enviara:
se vería en el cliente "09 Hola mundo".

Pasa lo mismo con las secuencias ansi, no hay forma de que las interprete un cliente telnet.

Si por ejemplo enviara:
que limpia la pantalla, en el cliente telnet se vería ".[2J". Y no limpia la pantalla. Y así con cualquier secuencia ansi.

He leído Googleando (entre la muy poca info que he visto sobre esto, porque en todas las páginas sale lo mismo) que debe ser una negociación telnet que debería hacer el servidor con el cliente, para emular un terminal que soportara todo esto. No es que lo haya leído directamente, pero lo he deducido :).
Parece que la conexión básica en telnet es en modo nvt, pero debe ser que el nvt no soporta ansi ni nada de esto, y hay que emular algo como vt100 o vt52, que no he visto como negociar el uso de ninguna de las dos, ni de ningún otro terminal de estos que soporte ansi ni lo que pretendo hacer.

La idea es, poder enviar cadenas al cliente, como por ejemplo:
y que el cliente lo interprete bien, porque no creo que sea plan de enviar carácter por carácter ¿no? :).

Almenos, creo que los servidores que he sniffeado lo hacen así, quizá esté equivocado; pero lo que se ve en el programa con el que capturo el tráfico entre el servidor y el cliente son carácteres separados por espacios, no por saltos de línea.

A ver si alguien tiene idea de esto y sabe decirme como he de hacerlo, porque llevo ya días dándole vueltas y no hay manera :P.

Salu2!

Pero si es "para cualquier cliente" entonces mejor no formateas el texto, porque el que tiene que entender ese formato es el cliente...

Pero bueno, supongo que la cosa es chequear qué capacidades tiene el cliente, supongo que habrá un protocolo para eso. Para las secuencias ANSI si el cliente no las acepta las sacará tal cual, pues son básicamente combinaciones de caracteres imprimibles. Si las entiende sí saldrán bien... si mandas bien el ASCII 27, que no es imprimible.

Para los otros códigos que dices, igual pasa lo mismo que con el 27, hay que mandar el carácter/código que corresponde, y no su representación.
Vaya, si hay que enviar el carácter 5, no vale con mandar los caracteres "0" y "5", eso obviamente hará que se imprima un "05" en el cliente. Léete lo que te dije en ese post que has enlazado, para enviar el carácter de código 5 hay que enviar CHR(5).
Prueba eso o si se puede mandas cadenas binarias con sólo los códigos (es decir, para la "A" se enviaría un 65 decimal), pero lo más fácil creo que será mandar los caracteres correspondientes.

Y claro, lo ideal sería estudiarse los protocolos del vt100 o vt52 o el que uses, ahí estará todo explicado...

Bueno; la cosa es, según lo he entendido yo por lo que he leído, que telnet emula una terminal. Según entiendo, esa terminal es para que un servidor disponga de unas capacidades concretas en el cliente, ya que antes cada ordenador y cada sistema operativo era un mundo.
Entonces, supuestamente, con esa terminal emulada, todas las máquinas tenían las mismas capacidades, aún siendo distintas.

La cosa es, que sólo no funciona con el servidor que estoy haciendo yo, con el resto de servidores que me conecte y haga lo que sea, va todo bien: colores, paginación, etc.

Pero Chr() es para sacar el carácter que corresponde a un código Ascii ¿no?. Entonces, da lo mismo mandar Chr(65) que "a". Eso funciona. El problema es enviar 07&" a", porque toma 07 como parte de la cadena, no como un carácter no imprimible... En parte tiene su lógica, claro, pero entonces no se como hacerlo?.

Por cierto, que he descubierto, que lo que decía que recibía de "00000000", "00000010" ... , en realidad no se envía entre el cliente y el servidor. No se que será, pero sale en el programa que captura el tráfico entre cliente y servidor cuando hay una negociación... Entonces es cuando salen cosas raras, que ni envía el server, y el cliente... no se si manda. Quizá eso me haya liado un poco a la hora de pensar que debía enviarse eso también...

Salu2!

He estado mirando el código fuente de un servidor, con el que los colores ansi funcionan bien en el mismo cliente que con mi servidor no lo hace.

Es este:

http://www.smaug.org

Aprovechando que puedo compilarlo, probarlo, modificarlo, pues me ha ido muy bien (en teoría), porque es un monstruo de código :). Y ni mucho menos tengo un nivel de C como para entender un código tan complejo.
Pero, así por encima veo que efectivamente debe hacer negociaciones telnet, como me suponía que tendría que hacer yo, aunque no se muy bien cuando las hace.

He visto cosas curiosas. Por ejemplo, en el archivo comm.c, hay unas constantes:
Efectivamente, son códigos de negociación telnet. Algunos he visto que los use almenos una vez en ese mismo archivo, otros aún no he visto que los use.

Lo curioso de esas constantes, es la forma de definir el valor.
En vez de poner 0xFB por ejemplo, pone \xFB. Debe ser lo mismo ¿no?. Pero no lo tengo muy claro, porque la "\" en C es el carácter de escape...
Así, que, a quien sepa mucho de C: ¿Es lo mismo 0xFB que \xFB?.
Si no lo es ¿como se haría en autoit el equivalente de \xFB?.

Más abajo, está esto:
Y luego, leyendo y leyendo, veo algo así:
"write_to_buffer" se supone que es la función que envía datos al cliente. No es que la haya visto como funciona porque no la he encontrado, pero por descarte leyendo el código... :).

La cosa es.
¿como enviará write_to_buffer() "go_ahead_str", elemento a elemento, o todo junto como un string?.
Desde luego, por más vueltas que le he dado, como un string no va, mientras que carácter a carácter, el cliente se ha quedao como colgao y no envía nada al servidor :O.

Eso en cuanto a la sesión telnet, que seguro que hay un montón más de cosas raras por ahí, que no entendería, pero aún no he visto nada con respecto a eso.

Respecto al color, pues resulta que no es tan sencillo, según el código de este soft. Envía las secuencias ansi como pone en la página que me pasó Ximorro, y como pone en otras muchas que he visto (vaya, no hay otra forma de hacerlas) :). Pero, en este programa no las envían así tal cual.
Por ejemplo, hay una función que se llama "make_color_sequence" que por supuesto no entiendo ni papa del código. Pero vaya, que tiene un montón más de código relacionado con el color, de hecho tiene hasta todo un módulo "colorize.c". Así, que no se por qué, pero no parece sser tan fácil hacer que un texto se vea con un color :).

Salu2!

Pero Chr() es para sacar el carácter que corresponde a un código Ascii ¿no?. Entonces, da lo mismo mandar Chr(65) que "a". Eso funciona. El problema es enviar 07&" a", porque toma 07 como parte de la cadena, no como un carácter no imprimible... En parte tiene su lógica, claro, pero entonces no se como hacerlo?.

¡Pues eso, si ya te lo estoy diciendo! Como tú mismo dices es lo mismo enviar "A" (la mayúscula, no la minúscula), que Chr(65) pues esto último significa "el carácter cuyo código ASCII es el 65", que en este caso es la "A".
¿Entonces cómo enviar el carácter cuyo código ASCII es 07?, pues Chr(7), ya está. Como no es un carácter imprimible no puedes poner algo entre comillas pero la función siempre puedes usarla.
De la misma manera el escape, código 27, pues se manda Chr(27).
Si tienes números en hexadecimal y no quieres pasarlos a decimal pues los mandas directamente usando el formato 0xNN, por ejemplo es lo mismo enviar Chr(0x20) que Chr(32) que " " (un espacio).

Respecto al programa en C, sí, por ejemplo '\xF9' es casi el equivalente en C del 0xF9 de AutoIt. Como bien dices en C esa barra es la de escape, y concretamente \x sirve para dar un número hexadecimal. Las comas simples en C sirven para definir caracteres, no cadenas, así que ese es "el carácter cuyo ASCII es F9".
Así que en AutoIt el equivalente no es directamente 0xF9, que es un número, sino "el carácter cuyo ASCII es F9", que como decía antes en AutoIT se pone como Chr(0xF9), que es lo mismo que Chr(249).

No sé cómo funcionará lo del buffer, supongo que usa un buffer para no hacer una mala gestión de la red mandando carácter a carácter, supongo que irá acumulando y cuando tenga algo de texto lo enviará todo junto. Y por supuesto siguiendo el protocolo, seguramente habrá comandos de control además de los datos de usuario (lo de los colores es sólo un ejemplo, pero habrá cosas para controlar la comunicación).

Lo de make_color_sequence tiene pinta que será simplemente que forma la secuencia de color, la secuencia ANSI con escape para el color, como veíamos en otro post.

Eso me suponía, que esa función no debía hacer gran cosa con los colores, aunque sí que veo en partes del código que además de esa función o en ella misma (ahora no tengo el código delante para verlo exactamente) hace cosas a nivel de bit. Por lo menos, llama una función que se llama x_bit() o algo así, a la que ni idea de lo que le pasará, ni si es nativa de C.

En teoría todo esto no debería tener mayor complicación, pero no funciona. Además, el programa que usaba para capturar el tráfico entre el servidor y el cliente como que no ayuda mucho, porque he visto que no da la información tal cual se transmite. Por ejemplo, separa los carácteres por espacios, y algunas veces los muestra en hexadecimal, y otras parece que en decimal. Además, añade secuencias que no se envían, como ya dije. "00000000" por ejemplo. Así, que no puedo saber exactamente como envía el programa que comentaba en C que he mirado, para poder hacerlo igual. Vaya, que creo que con ese programa me he liado más que otra cosa... :).
En cualquier caso, no funciona de ninguna forma. Lo normal creo que sería que:
fuera interpretado por el cliente, pero no es así.
Tampoco funciona:
Y la última forma que se me ocurre de enviarlo:
Pues tampoco.
Así, que algo raro hay :).
Y ¿el protocolo?. Pues no es que ayude mucho. Porque el protocolo telnet sí que he visto como funciona, pero lo de vt52, vt100 etc, lo menciona muy por encima. Tan por encima, que sólo dice que pueden negociarse el uso de esas terminales, pero ni como ni nada. Además, leyendo no se donde, me pareció entender que vt100 por ejemplo, es otro protocolo distinto del telnet, del que no he encontrado nada.

Pero vaya, no veo que el servidor que puse arriba (smaug) haga ninguna negociación ni nada parecido. De hecho, no sale ni siquiera los carácteres en decimal o hexadecimal, salen normal, en lo que capturo entre él y el cliente.

Total, que no se dónde más mirar ni que más probar, porque no hay mucho más que probar...

Salu2!

¿Cómo estás enviando 1B[0;1;33m?

Como el 1B estés enviando un "1" y una "B" te mato.
Eso ya sabes que es el escape, cuyo ASCII es 0x1B, o 27 en decimal. Ya sabes cómo se envía "el carácter cuyo código ASCII es 27" y si no es que has leído mi anterior comentario demasiado por encima

Te equivocas con lo de los protocolos, es importantísimo entenderlos y programarlos si quieres hacer un servidor o un cliente. Por lo pronto supongo que en el protocolo habrá una comunicación previa para conocer las capacidades del cliente, y si entiende ANSI el servidor sí tendrá sentido que envíe esas secuencias de colores, y si no pues no.
Otra posibilidad es que el servidor siempre envíe esas secuencias, y el protocolo establezca que es el cliente el que debe ignorarlas si le llegan pero no puede poner coloritos. En cualquier caso esas cosas las establece el protocolo.
Y las habrá más importantes, como por ejemplo cómo se realiza la conexión. El telnet no sé cómo funciona internamente pero por ejemplo en FTP te puedo decir que se establecen dos conexiones, una de control donde van los comandos, códigos de errores, etc, y otra línea por la que van sólo los datos.

En telnet habrá estándares similares establecidos, si dices que has visto cómo funciona el protocolo telnet no sé dónde está el problema, en realidad creo que es lo único que te hace falta porque estás haciendo un servidor, el que tiene que mostrar los datos es el cliente, con lo que la emulación de terminal (vt100, etc.) estará el en cliente, a menos que también tenga que haber una parte en el servidor, hombre, sí tendrás que enviar las secuencias ANSI, pero si ya estás enviando comandos telnet eso debería ser ya fácil.
En cualquier caso una cosa es el telnet y otra el terminal (que puede usarse para mostrar los datos que vienen del servidor telnet o para otras cosas).
¿El telnet ya lo tienes hecho?

Ximorro escribió:Te equivocas con lo de los protocolos, es importantísimo entenderlos y programarlos si quieres hacer un servidor o un cliente. Por lo pronto supongo que en el protocolo habrá una comunicación previa para conocer las capacidades del cliente, y si entiende ANSI el servidor sí tendrá sentido que envíe esas secuencias de colores, y si no pues no.Otra posibilidad es que el servidor siempre envíe esas secuencias, y el protocolo establezca que es el cliente el que debe ignorarlas si le llegan pero no puede poner coloritos. En cualquier caso esas cosas las establece el protocolo.Y las habrá más importantes, como por ejemplo cómo se realiza la conexión. El telnet no sé cómo funciona internamente pero por ejemplo en FTP te puedo decir que se establecen dos conexiones, una de control donde van los comandos, códigos de errores, etc, y otra línea por la que van sólo los datos.

Totalmente de acuerdo con Ximorro. Antes de hacer un cliente o servidor que funcione con un protocolo determinado, hay que meterse de lleno en su protocolo. Que significa esto? Que tienes que mirar sus documentos rfc.
Yo hace años, en vb6, hice un pequeño cliente de irc (chat). Por supuesto me tuve que mirar a fondo su protocolo y su rfc.
Es como dice Ximorro, el servidor me preguntaba muchos datos antes de conectarme, y por supuesto, estas preguntas tenían sus respuestas. Si no ponías una respuesta bien, no se llegaba a realizar la conexión. Por eso tuve que mirar muchos códigos y el rfc. Y eso solo era para poder conectarme. No te quiero ni contar todos los comandos que tenía que enviar para hacer las funciones!! .

He buscado en la página de rfcs traducidos (donde hace años leí yo el del irc) y tienes la especificación del protocolo telnet traducido, entre otros documentos relacionados con telnet. Leetelos con atención:
http://www.rfc-es.org/rfc/rfc0854-es.txt

Os dejo todos los protocolos y documentos relacionados traducidos, ya que pueden ser muy interesantes en algún momento:

http://www.rfc-es.org/descargas.php

Por cierto Jonny, mira la lista anterior que hay más documentos sobre telnet, además del protocolo principal. Ejemplo: Transmisión binaria en Telnet.

Saludos y lee .

Hola.

Ximorro dijo:
¿Cómo estás enviando 1B[0;1;33m?

Como el 1B estés enviando un "1" y una "B" te mato.

:)

me refería, a que había probado todas esas formas, antes de tu post. De hecho, había probado con 1B, 27, 0x1B...

Ximorro dijo:
Ya sabes cómo se envía "el carácter cuyo código ASCII es 27" y si no es que has leído mi anterior comentario demasiado por encima

NO hombre, lo he leído con toda la atención posible :).

Ximorro dijo:
Respecto al programa en C, sí, por ejemplo '\xF9' es casi el equivalente en C del 0xF9 de AutoIt. Como bien dices en C esa barra es la de escape, y concretamente \x sirve para dar un número hexadecimal.

Eso no lo sabía. Entonces, en C los números hexadecimales no se escriben como 0xnn?. Lo de la "\x" lo he visto en algún otro código de C que he bajado para intentar ver como hacían esto mismo de los colores. Pero no sabía que fuera así.

Ximorro dijo:
Así que en AutoIt el equivalente no es directamente 0xF9, que es un número, sino "el carácter cuyo ASCII es F9", que como decía antes en AutoIT se pone como Chr(0xF9), que es lo mismo que Chr(249).

No lo he probado aún así como dices, con Chr(). Pero entonces, es normal que:
no funcionara.
Espero que:
sí funcione, porque creo que es a eso a lo que te referías ¿no?.

Hombre, claro que me he mirado el protocolo telnet, y varias veces. Ya se que es importante conocer el protocolo que se va a usar en una comunicación, pero es que en el protocolo telnet (justo la web que he mirado ha sido la que dice Chepito:

http://www.rfc-es.org/rfc/rfc0854-es.txt)

Pero ahí no veo nada que diga como negociar el uso de una terminal vt52/100 ni nada de eso.

De todas formas, el link que pone Chefito, con todos los protocolos sí que es muy interesante, y voy a mirarlo, quizá ahí encuentre algo que me de la solución...
Acias :)

Salu2!

¡impresionante! :O

¡Por fin, ahora sí! :).

Aciass Ximorro, efectivamente:
muestra en el cliente "hola mundo" en amarillo.

Editado:

Además, parece que enviando así los carácteres, con Chr() ya puedo mandar bien datos en forma de string. Ahora, el cliente procesa correctamente una cadena con códigos ascii imprimibles y "no imprimibles", a diferencia de antes, que si los mezclaba aparecía todo como una cadena.
Ahora sí, implementar el protocolo es mucho más fácil :).

Salu2!

¿Al fin me has hecho caso? ¿por qué no lo has hecho antes? Ya te lo dije en el otro post del ANSI, y en éste post te lo he dicho en TODOS los comentarios desde el primero, míralo...

¿Pero entonces el protocolo telnet lo tienes programado? ¿Sólo mandando caracteres imprimibles funciona? Cuesta creerlo...
No estaría mal que nos enseñaras algo de código. Un servidor telnet no es moco de pavo y será interesante verlo.

Creo que no tienes que preocuparte de la terminal, tú estás haciendo el servidor. Si te sale el texto en amarillo en el cliente es que esa terminal ya está entendiendo ANSI, como ves tú no tienes que hacer nada. Bueno, quiero decir que tienes que enviar las secuencias de escape, pero no programar el terminal para que las entienda.
Si quieres enviar comandos específicos a terminales de vt100 etc, pues sí vendrá bien que te mires los protocolos, que no salen en el telnet porque lógicamente no tienen que ver con eso. Los protocolos para las terminales estarán en otro RFC (seguro que hay estándares para eso también), un terminal puede servir para mostrar datos de un telnet, de un ftp o lo que escribe el usuario por consola, no está vinculado inseparablemente al telnet.

¡Gracias Chefito por la traducción del los RFC!, yo siempre lo había visto en inglés, aunque de eso hace muchos años, igual entonces no estaba traducido.

Ximorro es una máquina . Yo también me imaginaba que tenía razón en lo que decía.

No se si has solucionado el tema del envío de cadenas string. Si no es así te comento esto por si por casualidad vale:

Se me olvidó comentaros que cuando programé el cliente irc, creo recordar que siempre que mandaba cadenas de texto (o sea, siempre ), tenía que acabar estas cadenas con un retorno de carro más un salto de línea. Si no hacía esto, el servidor me ignoraba. Mira a ver si tu problema de envíos de cadenas es por esto. Prueba a acabar las cadenas con un retorno de carro (@cr o chr(13)), con un salto de línea (@lf o chr(10)), o con ambos (@crlf o chr(13) & chr(10)). Creo que la buena es con un retorno de carro más un salto de línea.
Prueba con las macros de autoit (debería ir bien). Si por casualidad no van, inténtalo con los caracteres directamente (chr).

Piensa que te estoy hablando del envío de información de otro protocolo, pero puede que sirva, ya que parece algo general.

Saludos.

Puedes mirar todas las posibilidades, o mirar el protocolo a ver qué dice
A lo mejor no hay que enviar los retornos como datos, sino un código por un puerto de control que indique fin de línea. No, no creo que se haga así, es simplemente para indicar que podría haber otras posibilidaes. ¿Probar todo a ver cuál funciona? es una locura, es mejor leerlo en la especificación.

Si al final es que lo fácil es seguir el estándar, de verdad, es mucho más difícil averiguar qué hay que hacer a base de esnifar la red.
Por ejemplo efectivamente en FTP, que lo conozco más, al igual que en IRC (eso no lo sabía, es por lo que dice Chefito) el retorno de carro en modo texto es necesariamente CRLF (con transferencia en modo binario no hay que tocar los retornos, se envía todo directamente).
Y eso es independiente de las máquinas en las que estás, si el servidor FTP es Unix tendrá los retornos con LF en su disco duro, pero para enviar por FTP DEBE enviar CRLF. De la misma manera si el receptor está en un Mac (hasta MacOS9 creo, ahora usan el sistema Unix), el cliente tendrá que transformar esos CRLF en CR.

Esto no se hace para fastidiar, sino para establecer un marco común y que todo el mundo se entienda. Si haces un cliente o un servidor FTP sabes que las nuevas líneas te llegan SIEMPRE como CRLF, si tienes que convertir a tu sistema pues es más faena, pero lo bueno es poder comunicarse con sistemas diferentes sin tener que estar haciendo conversiones desde el sistema del otro, sino desde una plataforma común, establecida por el protocolo de comunicación.

En telnet seguro que hay normas similares establecidas, hay que estudiarse el protocolo y seguirlo a rajatabla, si no fallará la comunicación con la otra parte.

---
Y mira que he dicho veces lo del CHR, que no hay que enviar la representación texto del carácter, sino el propio carácter, pero ha costado que lo probara, cno lo fácil que era...
Ay Jonny, Jonny...

Porque no te entendía, Chr() es para sacar el carácter al que pertenece un código ASCII, pero yo lo asociaba con carácteres imprimibles, no se me ocurrió que el carácter de escape fuera chr(0x1B), cuando en todas partes veía 1B, 27, "escape". :).
Pero en ninguna web de las que he visto, he visto que pusieran \x1B, como en el código C que acabé mirando.

Sí, ya, es lo mismo que chr(0x1B), pero ya te digo que no asociaba yo esta función con carácteres "no imprimibles". De hecho, no había visto nunca el carácter que devuelve Chr() :).

No tengo nada más, que lo básico de un servidor, que en AutoIt no tiene ninguna dificultad. Recibir conexiones y un TcpSend() de prueba, con el que veía lo que enviaba el servidor.
He perdido un montón de días con el rollo este...

Sí, sólo enviando cadenas funciona, hasta ahora. Ya te digo que pasando los carácteres que voy a enviar por Chr() puedo enviar carácteres imprimibles y "no imprimibles" mezclados, que todo funciona correctamente.
Ya dije, que había leído que vt100, era otro protocolo distinto del telnet. No se si me hará falta, de momento lo que necesitaba hacer parece funcionar sin más, pero efectivamente el protocolo telnet tiene su miga. Pero hasta donde he leído (incluida la web que pasó Chepito) sólo parece ser algo complicado si quieres negociar cosas con el cliente :).
Parece ser, que si no te metes a negociar tipos de terminal ni nada de eso, la conexión se queda en modo nvt (básico) por así decirlo.

Entonces, cabe la posibilidad de que algún cliente no soporte ciertas características (como el color ansi) si no negocias un tipo de terminal que lo soporte (yo en el de Windows veo que funciona sin negociar ningún tipo de terminal), pero se que hay muchos que seguro que no lo soportan.
La solución entonces, es,o aprenderse los protocolos vt100 y demás, o hacer una opción en el servidor para que sea configurable. Así, el cliente puede configurar "color=si" o "color=no".

No pretendía programar nada en el cliente, sólo controlar un poco la interfaz con algún color, negrita, y siacaso ajustar la paginación, que por cierto he visto que eso sí se ha de negociar con el cliente. Pero todavía no he llegado a eso :P.

Salu2!

Porque no te entendía, Chr() es para sacar el carácter al que pertenece un código ASCII, pero yo lo asociaba con carácteres imprimibles, no se me ocurrió que el carácter de escape fuera chr(0x1B), cuando en todas partes veía 1B, 27, "escape". :).

Pero si lo dije expresamente, además muchas veces, que con los caracteres no imprimibles tenías que tomarlo a partir de su ASCII con Chr...
Iba a ponerte algún ejemplo pero es que tendría que copiar por ejemplo entero el primer comentario mío de este post. Léetelo otra vez y verás. Y eso mismo lo he dicho varias veces después, y antes también en el post del ANSI, que lo llamaste precisamente "códigos no imprimibles ansi", o sea, que tratábamos el tema de los no imprimibles, y ya te expliqué allí cómo tomarlos con CHR y también con SEND, para enviarlo por eventos de teclado...

En las webs no tienen que poner '\x1B' porque eso es C, pero te dirán que es Escape es el ASCII 27 en decimal o 1B en hexadecimal, y tú ya lo pondrás como tenga que ser en el lenguaje en que programes.

No estaría mal ver el código, es curioso que sin seguir el protocolo los clientes ya se conecten a tu servidor. El protocolo básico debe ser muy simple si sin hacer mucho ya se entienden.

como puedo sacar el rfc?

KarlaSn escribió:como puedo sacar el rfc?

Si lo que necesitas es decodificar un código de barra RFC tienes que buscas alguna librería o UDF. Si lo quieres mas fácil probablemente puedas usar algún programa por linea de comandos.


Saludos