¿Cómo se puede convertir un documento con escapes ANSI a un formato más portátil? Me gustaría enviar un documento de este tipo, pero el receptor no tiene terminal ANSI. -- Thomas Hafner — Comentario anterior sin firmar añadido por 192.94.73.35 ( discusión ) 14:00, 21 octubre 2003 (UTC) [ responder ]
Estoy seguro de que hay muchas herramientas en la web; conozco un complemento para FAR (Administrador de archivos y archivos); puede ver los archivos .ANS y traducirlos al formato HTML.
Además, también hay códigos para las teclas de la terminal (F1-F12, Re Pág/Av Pág, etc.). ¿Alguien tiene una lista de esos códigos?
-- Vladimir Panteleev — Comentario anterior sin firmar añadido por 217.26.150.114 (discusión) 00:18, 26 de julio de 2004 (UTC) [ responder ]
F1 ^[OP F2 ^[OQ F3 ^[OR F4 ^[OS F5 ^[[15~ F6 ^[[17~ (Esto no es un error tipográfico) F7 ^[[18~ F8 ^[[19~ F9 ^[[20~ F10 ^[[21~ F11 ^[[23~ (Esto no es un error tipográfico) F12 ^[[24~
(No tan estandarizado) Terminal F13-F15.app: F13 ^[[25~ F14 ^[[26~ F15 ^[[28~
iTerm2.app: F13 ^[[1;2P F14 ^[[1;2Q F15 ^[[1;2R
F13 ^[[1;2P F14 ^[[1;2Q F15 ^[[1;2R -- George Orwellophile — Comentario anterior sin firmar añadido por 111.223.237.154 (discusión) 09:03 8 may 2013 (UTC) [ responder ]
Esto tiene un sesgo hacia DOS; además, sería bueno incluir una referencia a la documentación de ansi.sys (para el material específico de DOS), si existe alguna -- Random832 ( t c ) 08:29, 4 de febrero de 2007 (UTC) [ responder ]
- De acuerdo. El artículo carece de una visión más amplia: los terminales de texto sólo se mencionan brevemente e incluso el VT100 se omite por completo, aunque ha tenido mucha influencia en las implementaciones de ANSI X3.64. Un poco de historia no vendría mal, especialmente porque la combinación de facto de estándares ha evolucionado con el tiempo. -- Viznut 12:58, 4 de febrero de 2007 (UTC) [ responder ]
El artículo sobre los códigos de control C0 y C1 dice que los códigos de control C1 se definen en la norma ISO 6429. La norma ISO 6429 redirige a este artículo, Código de escape ANSI . Pero en este artículo no se tratan los códigos de control C1. ¿Tiene realmente algo que ver el código C1 con los códigos de escape ANSI? -- Abdull 08:03, 8 de junio de 2007 (UTC) [ responder ]
- Respuesta para mí mismo. Según la quinta edición oficial de ECMA-048, la cuarta edición de ECMA-048 se adoptó como segunda edición de ISO 6429. La quinta edición de ECMA-048 se adoptó como tercera edición de ISO/IEC 6429. La quinta edición de ECMA-048 define tanto los llamados códigos de escape ANSI como el conjunto C0 (página 22 del PDF) y el conjunto C1 (páginas 22 y 23 del PDF). Por cierto, CSI puede ser el verdadero carácter CSI del conjunto C1 o una secuencia segura de 7 bits del carácter ESC más [ (corchete, ASCII 0x5B). -- Abdull 10:09, 8 de junio de 2007 (UTC) [ responder ]
Este artículo sólo cubre los códigos de visualización. ANSI X3.64 cubría cualquier dispositivo de salida, pero era bastante abierto en cuanto a su implementación. Muchas empresas de impresoras utilizaron variaciones de ANSI a lo largo de los años: Digital, Texas Instruments, Printronix, Tally, GENICOM y más. -- — Gadget850 (Ed) talk - 21:44, 8 de diciembre de 2007 (UTC) [ responder ]
- Quizás, con las fuentes adecuadas. Los únicos controles de impresora que recuerdo bien son los PCL, que no son ANSI Tedickey ( discusión ) 22:21 8 dic 2007 (UTC) [ responder ]
¿Tiene algún mérito vincularse al Protocolo de extensión de Mud (MPX) dado que utiliza un CSI con un único argumento Ps y un carácter final de z para un servidor de juego de mazmorras multiusuario (MUD) para controlar qué etiquetas similares a HTML posteriores son interpretadas por el cliente MUD? Especialmente porque algunas de esas etiquetas se utilizan para controlar la visualización de la información. Aunque el creador fue Zuggsoft, el autor de los clientes MUD zMUD y cMUD , ahora está presente, aunque no de forma robusta (ha habido algunas ambigüedades tanto en el protocolo como en cómo el creador lo interpretó e implementó en sus propios proyectos) en varios MUD y otros clientes. -- SlySven ( discusión ) 01:29, 29 de marzo de 2015 (UTC) (actualmente desarrollador del cliente MUD FOSS Mudlet) [ responder ]
- El protocolo Mud eXtension Protocol (MPX) lleva a una página de desambiguación. Quizás te referías a la redirección a MXP (informática) , que a su vez lleva a http://www.zuggsoft.com/zmud/mxp.htm, que parece contener parte de la información que mencionaste, pero "una cantidad de MUD" necesita una fuente confiable (de terceros, por supuesto) TEDickey ( discusión ) 01:39, 29 de marzo de 2015 (UTC) [ responder ]
En cuanto a la nota a pie de página sobre el color marrón, valdría la pena proporcionar un enlace al artículo Adaptador de gráficos de color .
En ese artículo se menciona que el color marrón era un caso especial en el hardware. IBM agregó circuitos a los primeros monitores CGA para obligarlos a que el color fuera naranja/marrón/óxido, en lugar de un amarillo oscuro desagradable. El artículo de CGA explica más sobre esto.
No todos los primeros clones de PC hicieron el mismo truco de monitor CGA que hizo IBM. Por lo tanto, evidentemente hay mucha variación en la industria sobre cuál debería ser ese color.
He editado el artículo para incluir este enlace, a menos que haya una buena razón para no hacerlo. No pude encontrar evidencia sólida de que los códigos de color ANSI estuvieran vinculados al diseño del hardware IBM CGA, pero seguro que parecen similares. Es obvio que los 16 colores ANSI disponibles tienen una correspondencia 1:1 con los colores IBM CGA disponibles, pero aparecen en un orden ligeramente diferente. Si se puede encontrar una prueba de que los colores ANSI se basaban en colores CGA, o viceversa, agréguela al artículo.
-- Kreline ( discusión ) 21:37 11 ago 2008 (UTC) [ responder ]
- Gracias por la referencia. Sabía que el amarillo tenue era en realidad naranja/marrón, pero no sabía por qué ni de dónde provenía. Davygrvy ( discusión ) 08:37 27 ene 2009 (UTC) [ responder ]
Este artículo no debería estar dentro de esa categoría. Por favor, consulte el artículo principal sobre Técnica de interfaz de usuario para obtener una aclaración. Dragice ( discusión ) 19:09, 5 de septiembre de 2008 (UTC) [ responder ]
- Por supuesto que no estoy de acuerdo. Estás afirmando que los códigos de escape ANSI no se utilizan (por ejemplo) para representar efectos visuales para interfaces de usuario. Tedickey ( discusión ) 19:54 5 sep 2008 (UTC) [ responder ]
Lo siento, pero esto todavía no se ajusta a la definición de técnica de interfaz de usuario . Los códigos de escape ANSI no son técnicas de interfaz de usuario al menos por dos razones: 1) solo involucran la salida 2) están a nivel del sistema: el usuario no los ve. Tómese un tiempo para leer el artículo. Dragice ( discusión ) 23:10 5 septiembre 2008 (UTC) [ responder ]
- Leí el artículo (que es vago y está orientado hacia un punto de vista). Compárelo con Interfaz de usuario . También noto la inconsistencia entre sus comentarios y la inclusión de la tecla Modificadora , Desplazamiento y Menú circular . Tedickey ( discusión ) 23:27 5 sep 2008 (UTC) [ responder ]
He examinado el artículo con más atención y admito que escribir directamente códigos de escape ANSI en una terminal para limpiar la pantalla o mover el cursor puede considerarse una técnica de interacción. Pero, ¿es realmente así como la gente utiliza los códigos de escape ANSI? ¿O es más bien un formato de archivo para texto atribuido? No queda claro en el artículo. Este artículo es extremadamente técnico y me temo que la mayor parte de su contenido actual es irrelevante para la interacción entre humanos y computadoras. Si está dispuesto a hacer algo al respecto, me encantaría ver los códigos de escape ANSI incluidos como una técnica de interfaz de usuario. Sin embargo, tenga en cuenta que en caso de que los códigos de escape ANSI no estén destinados a usarse en modo interactivo , no tendría sentido incluirlos en esa categoría. No más que HTML y otros lenguajes. Dragice ( discusión ) 20:35, 13 de septiembre de 2008 (UTC) [ responder ]
- En general, la mayoría de las personas interesadas en los códigos ANSI los utilizan como cadenas literales en su línea de comandos (shell) (o usos similares). Esto es así a pesar de las interfaces de nivel superior, por ejemplo, tput para sistemas UNIX. Aquí hay información técnica porque eso es lo que cubre el tema. Dada la composición actual de la categoría, es más interactivo que el resaltado de sintaxis Tedickey ( discusión ) 20:47, 13 de septiembre de 2008 (UTC) [ responder ]
Los comentarios sobre la "corrección" están fuera de lugar: "código" es aplicable, pero más genérico. Tedickey ( discusión ) 00:49 2 ene 2009 (UTC) [ responder ]
El título de este artículo debería ser "Secuencias de escape ANSI" (con una desambiguación que indique que es "código de escape ANSI"). Solo hay un código de escape ANSI; lo que se describe en esta página es una secuencia de códigos ANSI, no el único punto de código ANSI (0x1C) para el código que normalmente se conoce como "ESC".
Sin embargo, no sé cómo editar la página para corregir el título. Tripodics ( discusión ) 13:41 28 jul 2018 (UTC) [ responder ]
¿No debería Franktur ser Fraktur? Wikipedia parece haber elegido la segunda opción para otros artículos.
208.252.219.2 (discusión) 22:54 3 mar 2010 (UTC) [ responder ]
- Sí, la ECMA-48 está de acuerdo en que debería ser Fraktur Tedickey ( discusión ) 00:15 4 mar 2010 (UTC) [ responder ]
El estándar no ofrece una definición para SGR 38/48. Una mejor manera de expresarlo podría ser mediante una nota al pie que indique que algunos terminales de uso común que comienzan con xterm interpretan esto como una selección de una paleta de colores, por ejemplo, 88 o 256 colores. Tal como está, la entrada de la tabla es incorrecta, ya que se refiere a las definiciones del estándar en lugar de a una interpretación particular TEDickey ( discusión ) 09:50, 30 de noviembre de 2010 (UTC) [ responder ]
- Parece que estas secuencias se basaron en un estándar mal interpretado. [1] [2] 74.85.42.110 ( discusión ) 03:56 29 dic 2010 (UTC) [ responder ]
- Se refiere a esto (que en sí mismo es parcialmente inexacto, por ejemplo, afirmar que cierta información está en ECMA-48):
+Una nota sobre la conformidad++Estos códigos ESC rompen la "asociatividad" de SGR, pero después de algún tiempo+El resultado de la investigación es que aquí el propio estándar se rompe.++Los mejores códigos debido a ECMA-48 probablemente serían, por ejemplo:+38:2:<r>:<g>:<b>, es decir, consistentemente dos puntos en lugar de punto y coma.+Pero aparentemente, esto se define de manera diferente en ISO-8613 (que es+incluido en este lugar en ECMA-48), en realidad rompiendo ECMA-48.++No podemos evitarlo e implementamos los códigos como se indica arriba, que+es una decisión equilibrada.
- Una alternativa sería anotarlo como se ha hecho para 90-109 poniendo el texto '(no en el estándar)' en la sección de notas. De cualquier manera, incluso si no está en el estándar, es muy común ya que prácticamente todos los emuladores de terminal compatibles con xterm lo admiten.Ferroin (discusión) 15:39 27 feb 2012 (UTC) [ responder ]
Hay una discusión que puede encontrar en una de las listas de correo de KDE que menciona el hecho de que el estándar que se aplicaría en esa área no estaba disponible libremente (cuesta quizás $200 USD obtener una copia), y el hecho de que no se use ampliamente es discutible TEDickey ( discusión ) 13:35, 29 de diciembre de 2010 (UTC) [ responder ]
¿Por qué es esto dudoso? Dice exactamente cómo funciona. Aquí hay una prueba. (Sí, no es xterm-256color, es iTerm2, que sigue las mismas reglas).
En mi humilde opinión, SGR 38/48 tiene poco que ver con xterm, aunque (como se mencionó anteriormente en la discusión) xterm ha realizado una implementación no conforme de estas secuencias. El estándar CCITT T.416, al que se refiere Ecma-48 en relación con el uso previsto de SGR 38/48, define el uso adecuado de las secuencias. Además, los dos puntos utilizados en T.416 causan problemas en Ecma-48, posiblemente rompiendo el estándar, pero, de todos modos, ¿no debería el artículo mencionar la definición de T.416 y el hecho de que está rota y simplemente omitir la mención de la implementación de xterm? — Comentario anterior sin firmar agregado por 81.233.4.136 (discusión) 21:20, 3 de diciembre de 2011 (UTC) [ responder ]
- Bueno, actualmente lo más cercano a ser el mismo caso en esa tabla son las dos últimas líneas que tratan sobre aixterm. Esos códigos no están en ECMA-48 TEDickey ( discusión ) 22:07 3 dic 2011 (UTC) [ responder ]
- La tienda ISO todavía pide unos 200 dólares por una copia, pero Google encuentra una copia de CCITT T.416 (de 1993) aquí, lo que simplifica la discusión. TEDickey ( discusión ) 00:53 6 dic 2011 (UTC) [ responder ]
- Ese enlace parece estar roto, pero encontré uno que funciona aquí, en "Acceso: elementos disponibles libremente": http://www.itu.int/rec/T-REC-T.416-199303-I/en — Comentario anterior sin firmar agregado por 80.192.180.160 (discusión) 03:15, 25 de junio de 2013 (UTC)[ responder ]
Lo siento, pero el artículo es un poco caótico. Hace tiempo que aprendí los códigos ANSI, pero me lleva casi 30 minutos descubrir cómo establecer un determinado color a partir de la información del artículo. Adivinen cuánto tiempo le llevaría a una persona totalmente desinformada... -- 89.13.133.69 (discusión) 00:56 26 mar 2011 (UTC) [ responder ]
La fuente mencionada es inexacta en más de una parte: el color es una de las primeras tres secciones con errores que saltan a la vista (las fuentes tienen texto faltante, lo que la hace inútil, mientras que define-key no corresponde a ningún modelo de vt100). Hay errores dispersos en los atributos de visualización ("oculto" no es vt100), borrado, el comentario sobre el movimiento del cursor, así como algún contenido cuestionable en la impresión). Conozco esta fuente desde hace "un tiempo". Cuando la encontré por primera vez, aparentemente era obra de "Robert M. Free", que puede encontrar en otros lugares, con su aviso de derechos de autor de 1996. Esta copia no tiene los derechos de autor. Por mucho tiempo que la conozco (digamos diez años), no he encontrado ninguna utilidad para el contenido. (El autor no es muy conocido y no se ha tomado el tiempo de antagonizarme, aunque hay un informe de error divertido en el que otra persona se lo tomó en serio...). vt100.net contiene información veraz, al igual que el sitio web de Shuford, que recientemente dejó de funcionar. TEDickey ( discusión ) 20:44 16 ago 2011 (UTC) [ responder ]
Por ejemplo, esta copia TEDickey ( discusión ) 20:52 16 ago 2011 (UTC) [ responder ]
- Parece que esta referencia es inútil. Estoy de acuerdo en que muestra secuencias que el VT100 no hacía (no podía cambiar de color). Sería bueno encontrar una referencia real que simplemente diga "El VT100 se fabricó por primera vez en 1978 y admitía secuencias de escape ANSI". Lo mismo para el H19. Spitzak ( discusión ) 21:44, 16 de agosto de 2011 (UTC) [ responder ]
- http://vt100.net/vt_history TEDickey ( discusión )
Incorrecto. En Linux (cuando la tecla Bloq Mayús está desactivada) Alt+A envía "27 97", que es una secuencia de dos caracteres, pero el segundo carácter no está en el rango 64..95. Cuando la tecla Bloq Mayús está activada, envía "27 65". — Comentario anterior sin firmar añadido por 188.233.8.82 (discusión) 23:20, 17 de septiembre de 2011 (UTC) [ responder ]
- Sin embargo, estás hablando de una secuencia enviada por el teclado, lo cual no es de interés aquí. El contenido relevante sería el descrito en la página de manual console_codes TEDickey ( discusión ) 23:30, 17 de septiembre de 2011 (UTC) [ responder ]
El ejemplo y la presentación que se dan son específicos de Linux y probablemente no agreguen mucho valor a este tema. Por cierto, el ejemplo de script está resaltado de manera inconsistente. TEDickey ( discusión ) 20:58, 27 de octubre de 2011 (UTC) [ responder ]
Vine aquí intentando interpretar los códigos que me entregó un dispositivo obsoleto. Hace décadas sabía de memoria qué eran ESC-H, ESC-F o ESC-J; ahora pensé que lo buscaría. Resulta que el artículo simplemente me dice que existe ESC-* (y que hay un cierto rango de contenidos válidos de "*"), pero no hay ninguna lista o tabla que me diga cuáles son esos códigos. Qué tontería. — Comentario anterior sin firmar añadido por 137.78.180.35 (discusión) 01:02, 29 de octubre de 2011 (UTC) [ responder ]
Respecto a la edición que he hecho el 29 de octubre de 2011 a las 19:12 (UTC), TEDickey la revirtió porque parece ser incorrecta y carece de verificación en una fuente publicada y fiable. La edición fue: `También hay un CSI de un solo carácter (155/0x9B/0233)' -> `También hay un código de terminación de un solo carácter (155/0x9B/0233)'. La referencia es en.wikipedia.org/wiki/Talk:ANSI_escape_code/xterm -> Referencias -> 2.ª referencia == http://invisible-island.net/xterm/xterm.faq.html. Citando http://invisible-island.net/xterm/xterm.faq.html#how2_title `El terminador "\007" es un área problemática. Xterm históricamente usa este carácter, aunque no es ANSI. El carácter "correcto" debería ser un terminador de cadena "\233" o "\033\\", que es el equivalente de 7 bits. El xterm moderno reconoce cualquiera de los dos (el "\007" o el terminador de cadena); se espera el primero de ellos. — Comentario anterior sin firmar añadido por 85.64.29.102 ( discusión ) 20:32, 29 de octubre de 2011 (UTC) [ responder ]
- Según ECMA-48, CSI significa "introductor de secuencia de control". La mayoría de las secuencias que se analizan en este tema comienzan con CSI. No tiene ningún significado fuera de ese contexto. "Terminador de cadena" es algo diferente. Se utiliza para finalizar ciertas secuencias. TEDickey ( discusión ) 20:48 29 oct 2011 (UTC) [ responder ]
El vt100 tuvo imitadores, pero las fuentes citadas no abordan este tema, ya que no mencionan la relación TEDickey ( discusión ) 21:09 4 nov 2011 (UTC) [ responder ]
Originalmente edité ls-color=always para que fuera ls --color=always, pero lo deshice en retrospectiva. Sé que 'ls --color=always' es la sintaxis correcta para gnu ls, pero sentí que debería comentarlo ya que se especificó como estilo Unix. ¿Debería cambiarse esto? Siento que gnu ls es más común si la sintaxis es realmente diferente. — Comentario anterior sin firmar agregado por 128.255.162.247 (discusión) 01:08, 20 de diciembre de 2011 (UTC) [ responder ]
- El espacio es ciertamente necesario. Creo que cualquier alternativa a GNU va a utilizar un modificador de una letra, pero no encuentro ninguna indicación de cuál puede ser. El "siempre" no es necesario. Revertiré el texto. Spitzak ( discusión ) 05:49 21 dic 2011 (UTC) [ responder ]
- FreeBSD ls implementa -G, que es usado por GNU ls para un propósito diferente. Mac OS X usa el mismo código (aunque su página de manual sugiere que es de una versión anterior a FreeBSD, que originó esta opción). ("-G" no se menciona en el estándar, según recuerdo. El ls estándar no menciona el color). Una diferencia principal entre las dos implementaciones es que GNU ls no usa ni termcap ni terminfo, y hace suposiciones sobre el comportamiento del color que lo limitan a un subconjunto de lo que haría una aplicación termcap/terminfo, mientras que FreeBSD ls usa termcap. TEDickey ( discusión ) 09:57, 21 de diciembre de 2011 (UTC) [ responder ]
Los controles C1 están definidos por ECMA-35, que no sabe nada sobre UTF-8. La declaración en cuestión implica que existe un comportamiento estándar (sin fuentes) y que existen terminales (plural) que siguen este estándar (o convención), también sin fuentes. Como es habitual, a falta de una fuente, se debe eliminar toda la declaración TEDickey ( discusión ) 01:10 21 jun 2012 (UTC) [ responder ]
- Los controles C1 forman parte del estándar Unicode. En particular, CSI (Control Sequence Introducer) se define como el carácter U+009B. Por lo tanto, el artículo es totalmente correcto. 93.97.16.78 ( discusión ) 23:01 14 jul 2012 (UTC) [ responder ]
Véase más arriba: el estándar Unicode define los puntos de código, pero no define el comportamiento de las secuencias de control como se describe en este tema. TEDickey ( discusión ) 23:45, 14 de julio de 2012 (UTC) [ responder ]
- Yo también tenía la misma pregunta. Preguntaré en el foro de Unicode sobre este tema, pero por ahora sólo puedo decir que Unicode define la codificación (UTF‑8, UTF‑16 y UTF‑32) que se aplica a la transmisión, y nada en los estándares Unicode (que he leído en gran parte) dice que los puntos de código de control no se deben codificar de la misma manera que otros puntos de código. Por el contrario, establece explícitamente que si un flujo utiliza una forma de codificación Unicode, entonces todo el flujo debe codificarse en esa forma, de lo contrario, todo el flujo no es válido. Según tengo entendido, se trata de dos capas diferentes, y se puede comparar esto con TCP/IP y HTTP: TCP/IP es para la transmisión y HTTP es lo que se transmite a través de TCP/IP, y los encabezados y datos HTTP están sujetos a la transmisión a través de TCP/IP, no sólo los datos o sólo los encabezados. De todos modos, preguntaré en el foro de Unicode y volveré aquí tan pronto como obtenga una respuesta autorizada. -- Hibou57 ( discusión ) 06:05 12 abr 2013 (UTC) [ responder ]
- Esa es la mitad de la pregunta. La otra mitad se refiere a los terminales no especificados que se supone que codifican C1 como UTF-8. TEDickey ( discusión ) 08:17, 12 de abril de 2013 (UTC) [ responder ]
- Realicé una prueba en kterm y maneja la codificación UTF-8 de CSI como el inicio del escape. Un código CSI sin procesar se maneja como un error e imprime un cuadro de error. También probé xterm y la codificación UTF-8 de CSI se ignoró como si fuera un carácter de control desconocido, mientras que un CSI sin procesar se convirtió en un carácter '@' que utilizó para todos los errores de codificación. Sería interesante probar otros emuladores de terminal, pero parece que el CSI debe estar codificado en UTF-8.
- Aunque los bytes CSI sin procesar pueden ser interpretados por una terminal y no pueden ser confundidos con UTF-8 (ya que son un código para bytes de continuación), seguirá habiendo problemas al almacenarlos en cadenas que se envían para ser impresas. Los bytes sin procesar funcionarían, pero en muchos casos la cadena pasa a través de un sistema o es producida por él, lo que hace imposible producir el CSI sin procesar. Spitzak ( discusión ) 00:51 13 abr 2013 (UTC) [ responder ]
- Parece que estás confundido en algún aspecto sobre xterm (es una de esas características sobre las que la gente comenta ocasionalmente; consulta http://osdir.com/ml/internationalization.linux/1999-09/msg00070.html y http://www.mail-archive.com/[email protected]/msg00210.html por ejemplo). En cuanto a kterm, no recuerdo que sepa sobre UTF-8; es una terminal ISO-2022 (a menos que confundas el nombre con konsole, tal vez). TEDickey ( discusión ) 02:04 13 abr 2013 (UTC) [ responder ]
- Esos documentos parecen coincidir exactamente con la forma en que veo que funciona xterm. Tienes razón, me refería a konsole, no a kterm. He probado algunas terminales más y no he encontrado ninguna que interprete un CSI sin formato (por "CSI sin formato" me refiero a un solo byte con el valor 0x9b). Solo he encontrado dos que interpretan un CSI codificado en UTF-8 (es decir, los dos bytes 0xc2,0x9b): konsole y la consola Linux. Por lo tanto, la conclusión es que el texto que dice que un CSI ocupa dos bytes en UTF-8 es correcto, en mi humilde opinión. Spitzak ( discusión ) 18:39, 13 de abril de 2013 (UTC) [ responder ]
- Acabo de probar esa declaración usando konsole 2.4.5 (no respeta la traducción de CSI a UTF-8). La consola Linux se comportó como sugieres, pero sus controles C1 no funcionan, como se señaló hace bastante tiempo en una discusión sobre vttest. De todos modos, se necesita un WP:RS ; no creo que puedas producir uno. TEDickey ( discusión ) 19:36, 13 de abril de 2013 (UTC) [ responder ]
- Corrección menor: la consola Linux simplemente ignoró el CSI traducido en mi verificación rápida; en realidad, no lo interpretó. TEDickey ( discusión ) 19:38, 13 de abril de 2013 (UTC) [ responder ]
¿Alguien puede explicar un poco más la opción 'Fraktur'? A juzgar por el artículo al que se vincula, selecciona una fuente gótica, pero aún no he visto fuentes góticas en ningún terminal o emulador a partir de 1980. Gracias. Stepho talk 05:43, 14 de mayo de 2013 (UTC) [ responder ]
ECMA-48 (quinta edición, junio de 1991) dice "Fraktur (gótico)" pero no ofrece ninguna explicación. TEDickey ( discusión ) 08:29 14 may 2013 (UTC) [ responder ]
- Suspiro :( Pero gracias por la respuesta de todos modos. Stepho talk 11:07, 14 de mayo de 2013 (UTC) [ responder ]
Al menos en Linux aquí parece que el orden no importa; el software de terminal (por ejemplo xterm) seleccionará lo que es razonable para una secuencia ANSI. Por ejemplo, printf "\033[0 7;35m " y printf "\033[0 35;7m " producirán el mismo resultado al menos aquí. Aunque no necesariamente en todas partes, supongo. -andy 77.191.221.163 (discusión) 13:17 19 ago 2013 (UTC) [ responder ]
- Esto se debe a que 7 (inverso) y 35 (texto magenta) son atributos no relacionados. printf "\033[0 35;36m " (seleccionar texto magenta, luego texto cian) se vería bastante diferente a printf "\033[0 36;35m " (seleccionar texto cian, luego texto magenta). Stepho talk 13:31 19 ago 2013 (UTC) [ responder ]
A lo largo de los años, varias impresoras han utilizado la emulación ANSI. Si bien existen diferencias obvias entre una terminal de video y una impresora, existen comandos diferentes y comandos similares se implementan de manera diferente.
- Manual del programador de la serie 5000 (PDF) . GENICOM. GEK-00031B.
Consulte la página 16 para GENICOM ANSI, la página 155 para DEC LGplus y la página 195 para las emulaciones DEC PPL3. -- Gadget850 talk 12:58, 21 de agosto de 2013 (UTC) [ responder ]
Ninguno de los enlaces proporcionados para el comentario sobre los colores de 24 bits en Konsole es relevante para la afirmación que ellos nominalmente respaldan. TEDickey ( discusión ) 13:04 7 sep 2013 (UTC) [ responder ]
Esos enlaces son un desorden, ya que ANSI.SYS implementa una fracción muy pequeña de ANSI para empezar TEDickey ( discusión ) 20:29, 15 de septiembre de 2013 (UTC) [ responder ]
Al observar la fuente sugerida, ninguno de los códigos parece ser específico de DEC: no hay fuentes de información específicas de DEC citadas en la página. Tal vez el proponente de la fuente pueda señalar las características que tienen una fuente confiable (los comentarios en una wiki no cumplen ese criterio); de lo contrario, el comentario sobre DEC se puede eliminar. Una fuente confiable, por supuesto, sería WP:Verifiable . La mayoría de los controles son específicos de Amiga o de alguna fuente no identificada; una pequeña fracción es "ANSI". TEDickey ( discusión ) 19:18, 10 de julio de 2014 (UTC) [ responder ]
La documentación del desarrollador en http://www.mirc.com/colors.html deja claro que el programa depende de emuladores de terminal para representar los colores reales. A falta de una fuente fiable (no hay comentarios anónimos de segunda mano), no hay motivo para añadirlo a este tema TEDickey ( discusión ) 09:24, 23 de diciembre de 2014 (UTC) [ responder ]
- Obviamente leíste mal el documento. El programa no depende de emuladores de terminal para representar colores reales en mIRC. Le explica al usuario de mIRC que otros emuladores de terminal verán colores ligeramente diferentes a los que ven ahora, que diferentes terminales usan colores diferentes. La naturaleza misma de mi edición. 75.173.74.69 ( discusión ) 14:23, 23 de diciembre de 2014 (UTC) [ responder ]
Estoy de acuerdo con @75.173.74.69: en este sentido: mIRC es un programa GUI de Windows. No utiliza un emulador de terminal para poner texto en la pantalla; reproduce su propio texto. Creo que lo que se advierte es que cuando se utiliza mIRC y se envían cadenas de texto que incluyen la secuencia de codificación de colores de mIRC (ctrl-K, etc.) a canales o usuarios de IRC, los usuarios de IRC que utilizan un programa de IRC en modo texto en un emulador de terminal pueden ver otros colores. (O ninguno en absoluto. No me queda claro si la secuencia ctrl-K es algo estándar de IRC o simplemente una propiedad de mIRC y PIRCH).
Bueno, eso está bien. Pero, @75.173.74.69: , con respecto a tu sugerencia extraordinariamente poco civilizada , lo intenté. Siguiendo tu sugerencia, creé una cadena que contiene $chr(27) seguido de [1,31mDerp! .
alias ctest { %lacadena = $chr(27) $+ [1;31m¡Mierda! eco %lacadena}Al ejecutar este alias veo
←[1;31m¡Qué tontería!
en la ventana de mensajes. Por cierto, esto es con mIRC 7.38, la última versión publicada. La flecha izquierda es, por supuesto, el gráfico asociado con el carácter número 27 (decimal) en la página de códigos 437, que es lo que utiliza mIRC. Por lo tanto, el chr(27) se está manejando como se desea. Pero mIRC claramente no está interpretando la cadena como una secuencia de escape ANSI, aunque esté correctamente formateada.
Además, no hay ninguna mención de secuencias de escape ANSI en la ayuda de mIRC, excepto por el identificador $ansi2mirc, que existe para que puedas convertir texto que fue creado para usar secuencias de escape ANSI en algo que mIRC mostrará. Verás, este identificador existe porque mIRC no interpreta secuencias de escape ANSI en sus visualizaciones: si obtienes texto que incluye dichas secuencias, debes ejecutarlo a través de $ansi2mirc antes de que mIRC lo muestre como las secuencias ANSI previstas.
¿Qué me estoy perdiendo? ¿Hay alguna manera de configurar las ventanas de mensajes, canales, etc. de mIRC para que interpreten secuencias de escape ANSI en lugar de simplemente mostrar ESC como una flecha hacia la izquierda? (¿Y hay alguna fuente confiable que documente esta capacidad? Los experimentos propios con "mirc.exe" no cuentan; eso es WP:OR .)
De lo contrario, mi edición (es decir, la eliminación de su adición a la tabla) y su fundamento se mantienen: la visualización de texto de mIRC no interpreta las secuencias de escape ANSI... que son el tema de este artículo... por lo que los códigos de color de mIRC no pertenecen aquí.
El documento al que hace referencia Tedicky lo confirma. No se menciona la secuencia SGR ANSI ni ninguna otra secuencia de escape ANSI, solo el conocido código Ctrl+K de mIRC: "Los códigos de color en mIRC se insertan utilizando la combinación de teclas Control+K. El carácter de control real insertado en el texto es el carácter ASCII 3, que se ve como ^C o C inversa en la mayoría de los clientes UNIX. La sintaxis del atributo de color en el texto tiene el formato ^CN[,M]". Esto claramente no describe nada que se parezca a una secuencia de escape ANSI. Jeh ( discusión ) 19:51 23 dic 2014 (UTC) [ responder ]
- Mi comentario inicial se basó en la afirmación del editor de IP de que la aplicación utiliza secuencias ANSI. No se menciona ninguna en la página que proporciona el proveedor para el programa (a menos que demuestren una mayor participación y la ajusten para ayudar). Si se observa más de cerca, se da a entender que el programa es una aplicación nativa de Windows; no hay ningún emulador de terminal involucrado. Eso significa que se limita a proporcionar cierta representación de IRC. Los RFC relevantes no mencionan el color:
- http://www.mirc.com/rfc1459.html
- https://tools.ietf.org/html/rfc2812
Lo que descubrí al leer es que no existe un estándar para los colores de IRC, sino más bien una convención. La página citada ofrece una descripción informal de la misma. Ninguno de los ejemplos tiene relación con las secuencias de escape ANSI, al igual que los escapes interpretados por un "echo -e". A continuación se incluyen algunos otros enlaces que tratan sobre los colores utilizados con los clientes de IRC:
- http://en.wikichip.org/wiki/Talk:ANSI_escape_code/irc/colors
- http://irssi.org/documentation/formats
- https://wiki.ietfng.org/pub/IRCIE/Encoding
- http://www.ircbeginner.com/ircinfo/colors.html
Tal vez lo que estamos viendo aquí es alguna edición promocional para una nueva versión de mIRC, que aún no está disponible. Ver que la página del proveedor cambió inmediatamente después de que comenzó la disputa hace que esa parezca la explicación más probable TEDickey ( discusión ) 00:27, 24 de diciembre de 2014 (UTC) [ responder ]
- Tedikey, ¿qué cambio se ha hecho en qué sitio web? No soy el vendedor ni estoy relacionado con el software de ninguna manera. Publiqué esto, sin embargo, veo que no se han realizado cambios según mi sugerencia. ¿Dónde estás buscando?
- forums.mirc.com/ubbthreads.php/topics/249923/Color_index_RGB_values_documen#Post249923 75.173.74.69 ( discusión ) 02:04 24 dic 2014 (UTC) [ responder ]
- Es un producto comercial. No voy a verificar algo de esa naturaleza sin una fuente confiable , de libre acceso y de terceros . Encuentra una si quieres discutir el tema. TEDickey ( discusión ) 01:46 24 dic 2014 (UTC) [ responder ]
- mIRC recibe colores ANSI y colores mIRC, utilizando la misma tabla de colores que proporcioné en el artículo. Pruebe enviándose la cadena ANSI a usted mismo a través de /msg. Las RFC no mencionan ANSI porque es una capa diferente de protocolo; al igual que la RFC de Telnet no menciona ANSI.
- https://tools.ietf.org/html/rfc854
- http://www.mirc.com/register.html (una licencia de usuario único cuesta $20). Una reseña publicada en Wikipedia no es un WP:RS , una reseña del producto que yo publicaría en otro lugar te sería útil de cualquier manera. TEDickey ( discusión ) 01:54 24 dic 2014 (UTC) [ responder ]
- No entiendo a qué te refieres. mIRC existe desde 1995. ¿Estás sugiriendo que cualquier software que no sea FOSS no puede tener estándares significativos o impacto para los usuarios y otros sistemas en el mundo real? ¿Qué pasa con BeOS? ¿O Microsoft Windows? Estamos hablando de un software de 20 años de antigüedad que ha contribuido y se ha adherido a los mismos estándares para el curso... así que WP:RS ha quedado satisfecho. ~ 75.173.74.69 ( discusión ) 02:31, 24 de diciembre de 2014 (UTC) [ responder ]
- @75.173.74.69: : Pero tu "RS" aún no respalda tu afirmación. He probado mIRC como describiste y publiqué los resultados arriba. mIRC no interpreta la secuencia SGR ANSI. Simplemente representa el carácter ESC como el carácter número 27 de la página de códigos 437 (una flecha que apunta hacia la izquierda) y luego pasa el resto de la "secuencia de escape" a la ventana de salida como texto, y no hay cambio de color. Por lo tanto, cualquier afirmación de que mIRC implementa códigos de escape ANSI para el cambio de color va a necesitar mucho más que tus afirmaciones.
- Por cierto, no puedes simplemente "enviarte la cadena ANSI a ti mismo mediante /msg" en mIRC porque mIRC cerrará la ventana en la que estás escribiendo en el momento en que presiones el carácter Escape. Tu sugerencia de intentarlo implica claramente para mí que, a pesar de tu fanfarronería, nunca lo has intentado en realidad. La secuencia de control de mIRC para cambiar colores no es en absoluto una secuencia de escape ANSI. Es Ctrl-K seguido del código de color de primer plano, opcionalmente seguido de una coma y el código de color de fondo, y luego otro Ctrl-K.
- La secuencia ctrl-K de mIRC tampoco utiliza los mismos números de color que la tabla ANSI. En la secuencia de mIRC, 0 es blanco, 1 es negro, 2 es azul, 3 es verde... y hay 16 números de color, no sólo 8. Por lo tanto, no veo ninguna base para su afirmación de que "mIRC recibe colores ANSI y colores mIRC, utilizando la misma tabla de colores que proporcioné en el artículo" . Los códigos de color de mIRC no utilizan la misma tabla de colores, y mIRC no interpreta secuencias SGR ANSI en absoluto (independientemente de la tabla de colores).
- SI dos personas estuvieran ejecutando clientes IRC en modo carácter (no mIRC) en programas o ventanas de emuladores de terminal, y SI esos programas o ventanas implementaran la secuencia ANSI SGR con soporte para los colores estándar, y SI los clientes IRC pasaran el carácter ESCape de un extremo al otro... entonces sí, un usuario podría escribir una secuencia SGR y el otro vería el cambio de interpretación. Pero eso no es "IRC que soporta la secuencia ANSI SGR", son simplemente clientes IRC que pasan caracteres tipeados de un extremo al otro. La interpretación de los códigos de color sería una función del emulador de terminal en cada extremo del enlace, no de los programas cliente IRC. Por lo tanto, en la tabla de este artículo, no incluiríamos los programas cliente IRC, pero podríamos incluir los emuladores de terminal si su implementación de ANSI SGR fuera lo suficientemente notable.
- No veo ninguna línea argumental clara en su última respuesta. El software libre y de código abierto no tiene nada que ver con nada más que con la libre disponibilidad del software para probarlo. Microsoft Windows ya no incluye un emulador de terminal, pero su ventana de modo de caracteres no implementa secuencias de escape ANSI, por si eso sirve de algo. Hasta ahora sólo tenemos su afirmación de que cualquier implementación de IRC realmente implementa secuencias de escape de control de terminal ANSI en cualquier forma (en lugar de simplemente pasarlas de un extremo a otro). Tampoco veo ninguna relevancia en el hecho de que mIRC haya existido durante 20 años (al igual que la ventana de modo de caracteres de MS Windows, después de todo).
- Mi postura es la misma: dado que este artículo trata sobre secuencias de escape ANSI y mIRC no implementa secuencias de escape ANSI, no corresponde mencionar aquí mIRC (excepto quizás en la lista de programas que no las implementan). ("Windows XP CMD" tampoco debería estar en la tabla).
- Ahora bien, si tuviéramos un artículo titulado algo como "Representación de colores con nombres estándar en varios programas orientados a texto", entonces seguramente podríamos mencionar mIRC allí. Pero no aquí. Jeh ( discusión ) 07:02 24 dic 2014 (UTC) [ responder ]
- Yo dejaría la palabra "estándar" fuera del título sugerido, ya que no hay estándares como tales que se relacionen con el IRC con colores (ninguno que yo haya podido encontrar, en cualquier caso). La mejor manera de hacerlo es centrarse en fuentes confiables en forma de revisiones no anónimas de terceros sobre el tema. TEDickey ( discusión ) 09:11 24 dic 2014 (UTC) [ responder ]
- Tipo:
//msg $me $chr(27) $+ [1;31m¡Tonterías!
Lo siento por la metodología extraña, pero quiero asegurarme de que obtengas una buena copia a través de aquí y resultados absolutamente repetibles y confiables. Sí, mIRC siempre ha renderizado o emulado secuencias de control ANSI. Sigues mencionando también la propia versión Ctrl+K de codificación de color de mIRC; no sé por qué. Está permitido admitir más de una codificación, ¿verdad? También se admite UTF-8. No volvamos a mencionar Ctrl+K y hablemos de ANSI, porque se siguen distrayendo. 75.173.74.69 ( discusión ) 09:15, 24 de diciembre de 2014 (UTC) [ responder ]
- Hasta el momento no has aportado ninguna información útil. TEDickey ( discusión ) 09:18 24 dic 2014 (UTC) [ responder ]
- Proporcioné la información útil en la página del artículo. La comparación de colores es útil porque la gente realmente busca estas comparaciones para comprender cómo los diversos entornos de terminales reciben los colores cuando deciden cómo escribir su propio software o antes de transmitir esos colores. De hecho, el autor de al menos un cliente IRC de Android buscó esta información en un canal de ayuda de mIRC e hizo referencia a este artículo en su investigación sobre compatibilidad con colores. Es la razón por la que lo puse aquí. Dices que no he proporcionado ninguna información útil; yo digo que no has proporcionado un entorno congruente con la información útil. 75.173.74.69 ( discusión ) 09:22, 24 de diciembre de 2014 (UTC) [ responder ]
- ¿A qué te refieres con "Varios entornos de terminal"? mIRC no es un programa emulador de terminal. Esa es otra razón por la que no pertenece a la tabla.
- Además, "es útil" no es suficiente para incluirlo en Wikipedia. Tanto las guías prácticas como los manuales son útiles, pero Wikipedia no debería contener ninguno de estos tipos de información (véase WP:NOTHOWTO , WP:NOTMANUAL ). Incluso ignorando estos, ¿cuántas personas necesitan implementar clientes IRC?
- La prueba con //msg funcionó, pero no creo que demuestre lo que crees que demuestra. Creo que mIRC está usando su función $ansitomirc en tu entrada , de modo que el material que va al servidor (y luego regresa al usuario receptor) se ha convertido a la convención Ctrl-C de IRC. Como demostré anteriormente, mIRC no muestra correctamente la secuencia de escape ANSI SGR en el texto entrante . Simplemente muestra ESC como un "carácter gracioso" (como lo hace con la mayoría de los otros caracteres del 0 al 31). Jeh ( discusión ) 12:04, 24 de diciembre de 2014 (UTC) [ responder ]
- mIRC es un emulador de terminal por exactamente esta razón, emula ANSI. Dices que no representa correctamente las secuencias de escape ANSI SGR en el texto entrante ; pero estás equivocado. Representa secuencias de escape ANSI SGR en el texto entrante, pero no en el texto saliente, lo cual es intencional, para permitir que el usuario vea los "caracteres graciosos" que está escribiendo (lo que puede cambiar en el futuro; no es incapaz, aparentemente no es deseado). Dices que mIRC convierte ANSI a su propio tipo de códigos ^c cuando un usuario ingresa ANSI; esto también es incorrecto. Cuando envías una secuencia de escape ANSI, se envía al servidor intacta y otros usuarios ven el mismo ANSI SGR que escribiste. Cuando otro usuario envía una secuencia ANSI, mIRC la ve y la emula también en color. Lo único que hace con ^c es que cuando intentas copiar texto en color a tu portapapeles, lo convierte en $ansitomirc desde tu búfer de chat. Si quieres observar lo que sucede bajo el capó, escribe: //debug -p @debug 75.173.74.69 ( discusión ) 22:17 24 dic 2014 (UTC) [ responder ]
- "mIRC es un emulador de terminal precisamente por esta razón: emula ANSI". Incorrecto. Un emulador de terminal es un programa que emula un terminal interactivo como un VT100. Un programa de este tipo presenta una pantalla que actúa como el terminal emulado y envía y recibe caracteres a través de un puerto serie, una conexión TELNET o similar en el otro extremo. Si mIRC fuera un "emulador de terminal", entonces habría comandos mIRC para abrir COM1 y escribir comandos AT en mi módem, o para comunicarse por TELNET con un servidor apropiado. El hecho de que un emulador de terminal implemente ANSI o no es irrelevante para determinar si es realmente un emulador de terminal; había docenas, si no cientos, de modelos de terminales que tenían sus propias secuencias de control no ANSI y muchos de ellos son emulados por programas emuladores de terminal.
- "Dice que no muestra correctamente las secuencias de escape ANSI SGR en el texto entrante , pero se equivoca. Muestra sin duda las secuencias de escape ANSI SGR en el texto entrante". ¿Entonces por qué no lo hizo en mi prueba con echo? Claramente, el ESC estaba allí en el texto entrante, pero mIRC simplemente lo mostró como el carácter 27 de la página de códigos 437 (que es como sé que estaba allí...) Sigue ignorando este punto.
- Veo lo que estás viendo con la salida /debug, pero no creo que sea definitivo ni se correlacione con tus afirmaciones sobre el texto entrante o saliente. El nombre de la función $ansitomirc te indica que ansi no es la representación "verdadera" o "interna" de mIRC.
- Yo apoyaría la eliminación de esta tabla y su inclusión en un artículo de "todas las tablas", "Tabla de representaciones de color por software" o algo similar. Entonces no habría posibilidad de incluir mIRC, o el símbolo del sistema de Windows, para el caso. Tal como está, no creo que la tabla tenga mucho que ver con los "códigos de escape ANSI", sino más bien con las propiedades de varios programas. Jeh ( discusión ) 22:49 24 dic 2014 (UTC) [ responder ]
- ¿Estarías de acuerdo en que IRC se lleva a cabo a través de una conexión TELNET y, de hecho, la mayoría de los clientes de IRC (Irssi, XChat, Weechat, etc.) se ejecutan desde la terminal a través de un emulador de terminal? mIRC es una solución de Windows para esto, que incluye el cliente de IRC en su propio emulador de terminal básico. A través de complementos de script simples, mIRC también puede conectarse a TELNET (23) estándar y mazmorras multiusuario MUD/MUSH/MOO sin ningún código sofisticado. 75.173.74.69 ( discusión ) 23:23, 24 de diciembre de 2014 (UTC) [ responder ]
- "¿IRC se realiza a través de una conexión TELNET"? Absolutamente no. No veo cómo alguien familiarizado con los dos puede considerar tal idea. Del artículo de Telnet : "Telnet todavía se utiliza a veces para depurar servicios de red como SMTP, IRC, HTTP, FTP o servidores POP3, para enviar comandos a un servidor y examinar las respuestas, pero de todos estos protocolos sólo FTP utiliza realmente el formato de datos Telnet". Parece que estás afirmando que un cliente IRC se conecta a un servidor Telnet. Eso es ridículo.
- Ahora bien, alguien podría conectarse a un sistema remoto mediante telnet y ejecutar un cliente IRC en modo texto en el sistema remoto... pero eso no es "IRC que se lleva a cabo a través de una conexión TELNET". El protocolo IRC en ese caso no viaja entre el sistema remoto y la máquina del usuario. Jeh ( discusión ) 00:19 25 dic 2014 (UTC) [ responder ]
¿Vale la pena mencionar que el MacOS "clásico" no era compatible con ANSI y que los autores de terminales debían crear sus propios códigos? Y si vale la pena mencionarlo, ¿qué tal si mencionamos el uso de códigos VT52 en lugar de ANSI por parte de Atari ST? Si hay usuarios de GEMDOS, ¿también estaba basado en VT52? Maury Markowitz ( discusión ) 22:05 16 ene 2015 (UTC) [ responder ]
- No lo creo. Los artículos deberían tratar sobre sus temas. El tema aquí son los códigos de escape ANSI, no todas las cosas que parecen terminales y que no los implementaron. (Estoy a punto de eliminar la ventana del símbolo del sistema de Windows NT de la tabla de colores, sobre esa base).
- Discusión: Sin embargo, tal vez sería razonable, dada la cronología, señalar que algunos microcomputadores destacados de la época no implementaron códigos de escape ANSI a pesar de que se habían establecido en la industria de terminales de hardware años antes.
- Recuerde que los códigos de escape ANSI (y todos los códigos específicos del fabricante y modelo que los precedieron son importantes en una terminal, o un programa emulador de terminal real que realiza comunicaciones en serie con un sistema remoto), es que lo que le envía datos no tiene nada que hacer más que enviarle caracteres "en banda". Su emulador de terminal muestra algunos de ellos tal como están y otros los interpreta como comandos; metadatos, por así decirlo.
- Pero una ventana de modo carácter implementada por un sistema operativo no necesariamente tiene esa restricción. El sistema operativo es libre de proporcionar API que permitan a los programas hacer todo lo que permiten los códigos ANSI y más, sin que el programador tenga que crear secuencias de escape ANSI e incluirlas en lo que sea que esté poniendo. Para mí, esta es una diferencia clave. El hecho de que una ventana de modo carácter implemente uno o unos pocos códigos de escape ANSI no la convierte en un emulador de terminal, y el hecho de que no implemente la mayoría o ninguno de los códigos de escape ANSI no es particularmente notable.
- Jeh ( discusión ) 22:26 16 enero 2015 (UTC) [ responder ]
- Estoy de acuerdo con tus ideas. A ver qué opinas de las modificaciones. Maury Markowitz ( discusión ) 15:28 17 ene 2015 (UTC) [ responder ]
Algunos podrían visitar esta página sólo para ver cómo pueden filtrar esos códigos de un flujo de caracteres. ¿Cuántos caracteres hay que omitir? ¿Hay una etiqueta de "fin"? Todo ese tipo de información es -si es que hay alguna- difícil de encontrar en el artículo. 79.220.111.150 (discusión) 01:03 18 feb 2015 (UTC) [ responder ]
Sin una redacción específica en ECMA-48 (que no se citó), esta área se aborda en una de las pantallas de vttest: ningún terminal que no acepte controles integrados en una secuencia CSI es compatible con VT100. Tal vez los lectores prefieran hablar de algún otro tipo de terminal, en cuyo caso también se necesita una cita adecuada. TEDickey ( discusión ) 23:55, 20 de julio de 2015 (UTC) [ responder ]
- Estoy de acuerdo con que esa sección debería ser citada o eliminada. Por cierto, ¿"aceptar" significa ejecutar los controles o simplemente seguir tratándolos como cualquier otro personaje en una secuencia de CSI? PsyMar ( discusión ) 17:33 31 jul 2015 (UTC) [ responder ]
En mi comentario hice referencia a una pantalla en vttest que se ve así:
Prueba de caracteres de control del cursor dentro de secuencias ESC.A continuación deben aparecer cuatro líneas idénticas:ABCDEFGHABCDEFGHABCDEFGHABCDEFGHPresione <RETURN>
En forma legible, los caracteres enviados "dentro de las secuencias ESC" son retroceso y retorno de carro:
\E[1;1HTest de caracteres de control del cursor dentro de secuencias ESC.\r\r\nA continuación deben aparecer cuatro líneas idénticas:\r\r\n\r\r\nA BCDEFGHI\r\r\n / A\E[2\bCB\E[2\bCC\E[2\bCD\E[2\bCE\E[2\bCF\E[2\bCG\E[2\bCH\E[2\bCI\E[2\bC\r\r\n / A\E[\r2CB\E[\r4CC\E[\r6CD\E[\r8CE\E[\r10CF\E[\r12CG\E[\r14CH\E[\r16CI\r\r\norte\E[20lA\E[1^KAB\E[1^KAC\E[1^KAD\E[1^KAE\E[1^KAF\E[1^KAG\E[1^KAH\E[1^KAI\E[1^KA\r\r\n\r\r\nPulse <RETORNO>\E[2J
ECMA-48 es bastante explícito en cuanto a que los controles C0 y C1 no utilizan patrones de bits que podrían ser parte de secuencias CSI. Al leer ECMA-48, no veo ninguna discusión sobre secuencias ilegales (si, por ejemplo, la presencia de un byte C0 en medio de una secuencia CSI rompería la interpretación de la secuencia CSI). Dada la larga duración de la función vttest (desde mediados de los años 80) que confirma que el VT100 ejecuta estos controles C0, parece que los diseñadores del VT100 interpretaron los estándares como si permitieran que cualquiera de las categorías de controles enumeradas en la sección 5.1 de ECMA-48 se interpretaran simultáneamente. (Recuerdo que quizás alguna implementación maneja mal esta prueba, pero eso es irrelevante para este tema). TEDickey ( discusión ) 00:33, 2 de agosto de 2015 (UTC) [ responder ]
- Puedes descargar un VT100 "real" desde un repositorio en Github. Es un emulador 8080 y algo de código personalizado suficiente para ejecutar una ROM VT100 real. Sin embargo, muestra que un VT100 real falla algunas de las pruebas más recientes en vttest. 2001:470:1F09:10D6:5E26:AFF:FE7D:2F72 (discusión) 22:52 12 dic 2015 (UTC) [ responder ]
No entiendo por qué el plomo tendría una "excepción notable" en lugar de un "ejemplo notable" en el encabezamiento. Imagínense si el artículo de WP sobre metales terminara el encabezamiento con "Un no metal notable es el oxígeno". KazDragon (discusión) 13:47 9 nov 2015 (UTC) [ responder ]
- El único dispositivo o software de uso común en la actualidad que acepta un flujo de texto como entrada para mostrarlo al usuario como una salida desplazable con el texto más reciente al final que no interpreta ANSI es la consola de Windows. Esta excepción es "notable" porque es lo suficientemente importante como para desalentar el uso de estas secuencias, especialmente en la salida estándar del software. Spitzak ( discusión ) 23:46 10 nov 2015 (UTC) [ responder ]
La conversión de 0-5 a 0-255 se realiza con esta expresión:
nr = nr ? nr * 40 + 55 : 0;
NO este
número = número * 51;
Eso hace que los colores del XTerm sean bastante más brillantes. 2001:470:1F09:10D6:5E26:AFF:FE7D:2F72 (discusión) 22:01 12 dic 2015 (UTC) [ responder ]
- ¿Qué pasa con los terminales que no son XTerm? ¿Como VT241? ¿O VT340? ¿O la consola de Windows? ¿O PuTTY? ¿Alguno de los estándares cubre esto? ECMA-48 dice que hay que mirar T.416, pero T.416 solo dice que es "el índice en la tabla de colores dado por el atributo "tabla de colores de contenido" que se aplica al objeto con el que está asociado el contenido". Lo cual es realmente útil. 82.13.91.100 (discusión) 23:45, 22 de marzo de 2020 (UTC) [ responder ]
Este artículo ni siquiera explica qué es "CSI". Simplemente utiliza directamente el acrónimo, sin establecer ningún contexto previo. El artículo entero parece una hoja de referencia para geeks, en lugar de un artículo general que explique los conceptos.
Además, probablemente se debería evitar el término "código ANSI" sin más aclaraciones. Existen muchos estándares especificados por ANSI que también son algún tipo de "código". El contexto que puede estar implícito en algunos foros técnicos no necesariamente lo está para el público general de Wikipedia.
- WP:SOFIXIT . Jeh ( discusión ) 23:12 22 jun 2016 (UTC) [ responder ]
- ¿Y por favor firmad los mensajes de vuestra página de discusión? Jeh ( discusión ) 23:14 22 jun 2016 (UTC) [ responder ]
Hola compañeros wikipedistas,
Acabo de modificar 2 enlaces externos en el código de escape ANSI . Tómese un momento para revisar mi edición. Si tiene alguna pregunta o necesita que el bot ignore los enlaces o la página en su totalidad, visite esta sencilla sección de preguntas frecuentes para obtener información adicional. Hice los siguientes cambios:
- Se agregó el archivo https://web.archive.org/web/20120113230301/http://www.pestingers.net/Computer_history/Computers_79.htm a http://www.pestingers.net/Computer_history/Computers_79.htm
- Se agregó el archivo https://web.archive.org/web/20060206022229/http://enterprise.aacc.cc.md.us/~rhs/ansi.html a http://vt100.net/docs/
Cuando haya terminado de revisar mis cambios, puede seguir las instrucciones de la plantilla a continuación para solucionar cualquier problema con las URL.
Este mensaje fue publicado antes de febrero de 2018. Después de febrero de 2018 , las secciones de la página de discusión "Enlaces externos modificados" ya no son generadas ni monitoreadas por InternetArchiveBot . No se requiere ninguna acción especial con respecto a estos avisos de la página de discusión, aparte de la verificación regular utilizando las instrucciones de la herramienta de archivo que se encuentran a continuación. Los editores tienen permiso para eliminar estas secciones de la página de discusión "Enlaces externos modificados" si desean despejar las páginas de discusión, pero consulte la RfC antes de realizar eliminaciones sistemáticas masivas. Este mensaje se actualiza dinámicamente a través de la plantilla (última actualización: 5 de junio de 2024) .{{source check}}
- Si ha descubierto URL que el bot consideró erróneamente como muertas, puede informarlas con esta herramienta.
- Si encuentra un error con algún archivo o con las URL en sí, puede solucionarlo con esta herramienta.
Saludos.— InternetArchiveBot ( Reportar error ) 03:17 24 jun 2017 (UTC) [ responder ]
Esta página es más que inútil. La mitad de los códigos de escape que aparecen aquí ni siquiera están definidos por ANSI X3.64 o ECMA-48. Todo el artículo es un vertedero de pura basura.
- Pero sería útil saber cuáles no están en el estándar. ¿Nos lo puedes decir? -- Wtshymanski ( discusión ) 01:32 27 oct 2017 (UTC) [ responder ]
"Tenga en cuenta también que muchas implementaciones que reconocen ':' como separador olvidan erróneamente el parámetro identificador del espacio de color y, por lo tanto, cambian la posición de los restantes".
No veo cómo la primera parte de la oración apoya a la segunda; además, ¿qué implementaciones manifiestan este comportamiento?
Recuerde que a cualquier parámetro numérico omitido se le debe asignar el valor 0 (cero), por lo que una secuencia que comience con un código 38 o 48 puede omitir legítimamente los valores cero finales. En retrospectiva, esto hace que sea un poco más fácil ver por qué se usa ':' para separar los valores, ya que entonces es posible decodificar de manera inequívoca algo como:
- \033[3;38:2:255;48:4:0:0:0:255;9m
- // Edición posterior: lo anterior es un error, debería haber sido:
- \033[3;38::2:255;48::4:0:0:0:255;9m SlySven ( charla ) 11:54, 27 de octubre de 2019 (UTC) [ respuesta ]
como cursiva, tachado, rojo sobre fondo negro. También me pregunto cómo XTerm decodificaría tales secuencias si los dos puntos fueran puntos y coma, o ¿es que ninguno de los elementos de parámetro se puede omitir en ese caso? ¿Así es como se hace, señor Tedickey? ¡Lo reconozco como el gurú de referencia en esta área temática! 8-) SlySven ( discusión ) 02:12, 21 de febrero de 2018 (UTC) [ responder ]
- El error es que los programas simplemente reutilizaron su código de punto y coma para los dos puntos, lo que hace que el primer número sea el rojo, no el ID del espacio de color. Como usted señala, los argumentos finales se pueden eliminar, por lo que no hay forma de determinar qué disposición pretendía el programa. Spitzak ( discusión ) 06:06, 21 de febrero de 2018 (UTC) [ responder ]
- El comportamiento de xterm está documentado en XTerm Control Sequences (los comentarios de la página de discusión, por cierto, no son una fuente confiable ) TEDickey ( discusión ) 10:12 21 feb 2018 (UTC) [ responder ]
Creo que he sido uno de los que erróneamente olvidó el identificador del espacio de color y desplazó las posiciones de los parámetros restantes, para citar la sección (página 41) del documento UIT-T Rec. T. 416 (03/93):
- Una subcadena de parámetros para los valores 38 o 48 puede dividirse mediante uno o más separadores (03/10) en elementos de parámetros, denominados Pe. El formato de dicha subcadena de parámetros se indica como:
- Pe: P...
- Cada elemento de parámetro consta de cero, uno o más bits de combinaciones de 03/00 a 03/09, que representan los dígitos del 0 al 9. Un elemento de parámetro vacío representa un valor predeterminado para este elemento de parámetro. No es necesario incluir elementos de parámetro vacíos al final de la subcadena de parámetros.
- El primer elemento de parámetro indica una elección entre:
- 0 implementación definida (solo aplicable para el color de primer plano del personaje)
- 1 transparente;
- 2 colores directos en el espacio RGB;
- 3 colores directos en el espacio CMY;
- 4 colores directos en el espacio CMYK;
- 5 colores indexados.
- Si el primer parámetro tiene el valor 0 o 1, no hay elementos de parámetro adicionales.
- Si el primer elemento de parámetro tiene el valor 5, entonces hay un segundo elemento de parámetro que especifica el índice en la tabla de colores dada por el atributo “tabla de colores de contenido” que se aplica al objeto con el que está asociado el contenido.
- Si el primer elemento de parámetro tiene el valor 2, 3 o 4, el segundo elemento de parámetro especifica un identificador de espacio de color que hace referencia a una definición de espacio de color en el perfil del documento.
- Si el primer elemento de parámetro tiene el valor 2, los elementos de parámetro 3, 4 y 5 son tres números enteros para los componentes de color rojo, verde y azul. El parámetro 6 no tiene ningún significado.
- Si el primer parámetro tiene el valor 3, los elementos de parámetro 3, 4 y 5 y tres números enteros para los componentes de color cian, magenta y amarillo. El parámetro 6 no tiene ningún significado.
- Si el primer parámetro tiene el valor 4, los elementos de parámetro 3, 4, 5 y 6 son cuatro números enteros para los componentes de color cian, magenta, amarillo y negro.
- Si el primer elemento de parámetro tiene el valor 2, 3 o 4, el elemento de parámetro 7 puede usarse para especificar un valor de tolerancia (un entero) y el elemento de parámetro 8 puede usarse para especificar un espacio de color asociado con la tolerancia (0 para CIELUV, 1 para CIELAB).
- NOTA 3 – El componente “identificación del espacio de color” hará referencia a la descripción del espacio de color aplicable en el perfil del documento, que puede contener datos de escala de color que describen la escala y el desplazamiento que se aplicarán a los componentes de color especificados en el contenido del carácter. Puede ser necesario un uso adecuado de la escala y los desplazamientos para asignar todos los valores de color requeridos al espacio de codificación de números enteros proporcionado. Esto puede ser particularmente importante si el contenido concatenado requiere la inserción de dichas secuencias SGR mediante el proceso de diseño de contenido.
A primera vista, es fácil malinterpretar lo anterior (ahora sé que lo hice, en particular la línea que puse en negrita), e incluso con la NOTA 3, no sé más sobre lo que significa ese parámetro... SlySven ( discusión ) 19:47, 4 de octubre de 2018 (UTC) [ responder ]
"Los atributos de visualización permanecen vigentes hasta la próxima aparición de SGR".
Esta redacción sugiere que los atributos de visualización se borran en la siguiente aparición de SGR. Por ejemplo, considere los atributos de visualización independientes italic y underline . ¿La secuencia CSI 3 m XXX CSI 4 m YYY muestra YYY tanto en italic como con subrayado? Si cada SGR restablece todos los atributos de visualización, entonces los códigos como CSI 24 (subrayado desactivado) son innecesarios. El artículo debería aclarar que los atributos individuales continúan hasta que se borren explícitamente mediante otro SGR.
Hice una edición en este sentido.
Jim Fehrle (discusión) 00:06 27 mar 2018 (UTC) [ responder ]
- Eso significa que el efecto permanece vigente hasta que un comando posterior relacionado con esa característica llegue para cambiarla, por lo que en el ejemplo que das, "YYY" estará en cursiva y subrayado. Una ocurrencia de SGRm , que es equivalente a SGR0m, restablecerá esas y todas las demás características, por lo que podría haber sido un error tipográfico en esa oración citada. SlySven ( discusión ) —Comentario anterior sin fecha agregado a las 00:52, 1 may 2018 (UTC)[ responder ]
La sección "Soporte de plataforma" afirma que
El uso generalizado de ANSI por parte de tablones de anuncios y servicios en línea condujo a un soporte de plataforma casi universal a mediados de la década de 1980, primero por parte de terminales de video y luego por emuladores de terminal (como muchos programas de comunicación para IBM PC, ZTerm en el Mac OS "clásico" , y xterm , GNOME Terminal , Konsole y otros en sistemas X11 , y MacOS Terminal ).
Tal vez los emuladores de terminal de DOS/Windows y Mac clásicos admitían secuencias de escape ANSI para poder admitir tablones de anuncios y servicios en línea, pero ¿es esa la razón por la que los emuladores de terminal para UN*X los admitían, o se debía más bien a la popularidad de los VT100 como terminales para sistemas UN*X de la era anterior a las estaciones de trabajo? Dudo que los autores del programa de terminal de SunWindows/SunView y xterm estuvieran principalmente preocupados por el uso de estaciones de trabajo UN*X para acceder a BBS y otros servicios en línea, y realmente dudo que a los autores de los emuladores de terminal de GNOME y KDE les importara mucho eso, dada la época en que se escribieron. Tal vez a los desarrolladores del emulador de terminal NeXTSTEP les importara, de modo que el programa Terminal de macOS, un descendiente de ese emulador, heredó el soporte de código ANSI del programa NeXTSTEP, pero soy escéptico incluso al respecto. Guy Harris ( discusión ) 03:59, 11 de abril de 2018 (UTC) [ responder ]
- Estoy de acuerdo con tu evaluación. Los de X11 se escribieron para mostrar la salida de programas locales diseñados para mostrarse en VT100. El problema es que la gente sigue mezclando todos los emuladores de terminal para Linux en listas de programas que se escribieron para PC hogareñas en ese momento. Spitzak ( discusión ) 18:20, 11 de abril de 2018 (UTC) [ responder ]
- Entonces, tal vez deberíamos limitar la sección "Compatibilidad con plataformas" a describir qué compatibilidad con plataformas existe en varias plataformas, y no molestarnos con ninguna información histórica o especulación sobre por qué varios emuladores de terminal admitían códigos de escape ANSI. Entonces tendríamos solo subsecciones, además de la subsección DOS/Windows que ya tenemos:
- una subsección para sistemas tipo Unix, que menciona tanto los emuladores basados en X11 como los de macOS, así como las consolas de sistema para varios sistemas operativos;
- una subsección para el Mac OS clásico (que podría decir que la plataforma en sí no tenía soporte, a menos que Apple enviara algún tipo de emulador de terminal, y el único soporte estaba en aplicaciones particulares como ZTerm);
- una sección para AmigaOS;
- y mencionar la falta de soporte en el Atari ST en alguna parte.
- La parte sobre BBS y otros servicios en línea ya se mencionó en la sección Historial; tal vez lo que aún no esté allí debería trasladarse desde "Soporte de plataforma". Guy Harris ( discusión ) 19:33 11 abr 2018 (UTC) [ responder ]
- Hasta donde sé, los BBS fueron importantes para mantener el soporte de estos sistemas en los PC, debido al pésimo soporte de los fabricantes de computadoras que producían una señal de video directamente (no solo la IBM PC, sino también Apple y la mayoría de las máquinas CP/M con video incorporado). Estoy de acuerdo en que todo lo que sucedió debería trasladarse a la sección Historial.
- No estoy seguro de si realmente necesitamos listas gigantes. Prácticamente *todas* las emulaciones de terminal y terminales de video RS232 fabricadas desde aproximadamente 1980 las admitían. Las excepciones notables son los sistemas de PC autónomos, incluidos el IBM PC y el emulador de terminal que Microsoft proporcionó con Windows. Spitzak ( discusión ) 01:04 12 abr 2018 (UTC) [ responder ]
- Vale, he trabajado un poco en la sección "Soporte de la plataforma" y he copiado algunas cosas en Historial; ¿cómo está el estado actual de esas secciones? Guy Harris ( discusión ) 01:36 12 abr 2018 (UTC) [ responder ]
- LGTM Spitzak ( discusión ) 17:50 12 abr 2018 (UTC) [ responder ]
El artículo afirma que
Los sistemas operativos tipo Unix casi siempre podían asumir que estaban usando una terminal o un emulador que admitía estas secuencias.
Según el artículo vi :
El código original de vi fue escrito por Bill Joy en 1976, como modo visual para un editor de líneas llamado ex que Joy había escrito con Chuck Haley. [1] La versión ex 1.1 de Bill Joy se publicó como parte de la primera versión de Unix de Berkeley Software Distribution (BSD) en marzo de 1978.
Según el artículo VT100 :
El VT100 es un terminal de vídeo , presentado en agosto de 1978 por Digital Equipment Corporation (DEC). Fue uno de los primeros terminales en admitir códigos de escape ANSI para el control del cursor y otras tareas, y agregó una serie de códigos extendidos para funciones especiales como el control de las luces de estado del teclado. Esto llevó a una rápida adopción del estándar ANSI, que se convirtió en el estándar de facto para los emuladores de terminales .
Y según este artículo:
El primer terminal de vídeo popular que admitió estas secuencias fue el Digital VT100 , presentado en 1978. [2]
Marzo de 1978 es anterior a agosto de 1978, por lo que parecería que los programas que utilizan secuencias de control del cursor para implementar un editor de pantalla completa son anteriores a "la primera terminal de video popular que soporta las secuencias de escape [ANSI]".
Es posible que haya habido un momento en el que las terminales ANSI fueran lo suficientemente dominantes como para que los programas no necesitaran usar termcap o terminfo, o bibliotecas como curses/ncurses que usaban termcap o terminfo, y pudieran simplemente usar secuencias de escape ANSI directamente, pero sospecho que ese momento llegó significativamente después del momento en el que UN*Xes tenía una cantidad significativa de programas que usaban secuencias de escape de posicionamiento del cursor. Guy Harris ( discusión ) 19:06 3 jul 2018 (UTC) [ responder ]
- Seguro, eso debió haber sido en los años 90, cuando las estaciones de trabajo gráficas (con emuladores de terminal) eran más comunes que las terminales de video de hardware. TEDickey ( discusión ) 20:45 3 jul 2018 (UTC) [ responder ]
- Y eso fue probablemente mucho más tarde que el momento en el que los UN*X tenían una cantidad significativa de programas que usaban secuencias de escape para posicionar el cursor, por lo que "los sistemas operativos tipo Unix casi siempre podían asumir que estaban usando una terminal o un emulador que admitía estas secuencias" es ahistórico, y el primer párrafo del código de escape ANSI#sistemas tipo Unix necesita ser reescrito para reflejar la historia. Guy Harris ( discusión ) 20:55 3 jul 2018 (UTC) [ responder ]
- Hacia 1984, todos los terminales utilizados por cualquier máquina Unix moderna interpretaban secuencias de escape ANSI. Esto provocó que muchos programas ignoraran termcap/curses, por ejemplo, los ejemplos de indicaciones de este artículo. El Unix más popular es Linux (o tal vez OS/X), que es posterior a este. Spitzak ( discusión ) 22:04, 3 de julio de 2018 (UTC) [ responder ]
Referencias
- ^ "Entrevista con Bill Joy". Archivado desde el original el 10 de febrero de 2012. Consultado el 3 de junio de 2017 .
- ^ Williams, Paul (2006). "Terminales de vídeo digitales". VT100.net . Consultado el 17 de agosto de 2011 .
- Eso no se acerca a ser un hecho, sino que simplemente repite tu opinión. De entrada, están los Wyse50 y Wyse60, que se utilizaron mucho después de "1984". TEDickey ( discusión ) 01:22 4 jul 2018 (UTC) [ responder ]
Un commit anterior eliminó de la tabla SGR la mención de que el bold off no tenía un amplio soporte; parece haber causado un error con curl en MacOS (https://github.com/curl/curl/issues/2736) y encuentro que con Xfce#Xfce_Terminal (que es un "terminal debian" y por lo tanto refuta el mensaje de commit allí al menos en parte) veo un doble subrayado, xterm un subrayado, que parece indicar que no tiene un amplio soporte .
Un archivo fuente de la venerable biblioteca ncurses menciona 21 como código de doble subrayado en un comentario, así que lo agregué de nuevo: el ECMA-48 al que hace referencia el comentario indica "doblemente subrayado" para 21. No estoy seguro de que haya consenso sobre el "negrita no muy usado" o incluso sobre el "doble subrayado no muy usado", así que dejé algunos ejemplos. ¿Alguna idea? – ASiplas ( discusión ) 21:17, 7 de septiembre de 2018 (UTC) [ responder ]
- Acabo de volver a comprobar en xfce-terminal: ｢printf 'a\e[1mb\e[21mc\e[0m\n'｣ muestra b pero ni a ni c en negrita, c sin subrayado de ningún tipo. Han pasado años desde que verifiqué la cobertura de códigos ANSI entre terminales, pero xterm es el único con ese comportamiento que conozco. Todo lo demás hace que \e[2 X m deshabilite de manera consistente lo que \e[ X m habilita (para X en 1..9). - KiloByte ( discusión ) 21:40, 7 de septiembre de 2018 (UTC) [ responder ]
- Entonces, ¿en qué documento, si es que hay alguno, se especifica que SGR 21 significa "negrita" en lugar de "doble subrayado"? La cuarta edición de ECMA-48 (diciembre de 1986) y la quinta edición (junio de 1991) dicen que significa "doble subrayado". Guy Harris ( discusión ) 22:00 7 septiembre 2018 (UTC) [ responder ]
- Hmm, bueno, tal vez el comportamiento dependa de algo más que el uso de una determinada terminal (por ejemplo, xfce-term). Lo veo en xfce4-terminal 0.8.7.4 (tanto 'b' como 'c' en negrita, y 'c ' doble subrayado). Con tanta variación, ¿quizás sea más seguro dejar ambos? La falta de uniformidad causó problemas para aquellas personas en curl (error vinculado arriba) y tal vez buscaron aquí como referencia y asumieron que siempre desactivarían el modo negrita. Llegué aquí después de encontrar mi terminal en modo de doble subrayado después de ejecutar curl; alguien que usa MacOS presentó un error después de dejar activado el modo negrita (ver enlace arriba). – ASiplas ( discusión ) 22:33, 7 de septiembre de 2018 (UTC) [ responder ]
abc
- La página del manual "console_codes" de Linux dice
21 establece la intensidad normal (ECMA-48 dice "doblemente subrayado")
- El comentario sobre ncurses es engañoso: la biblioteca no conoce ningún código SGR en particular. Se trata de la base de datos (y un comentario basado en ECMA-48, si elige leer el texto). Asimismo, mencionar PuTTY es engañoso: permite el doble subrayado como un subrayado normal (de la misma manera, sería útil leer el código fuente). El comentario anterior sobre xterm también parece ser incorrecto (la documentación es un buen punto de partida) TEDickey ( discusión ) 22:28, 7 de septiembre de 2018 (UTC) [ responder ]
- Gracias por el comentario corregido – ASiplas ( discusión ) 22:33 7 septiembre 2018 (UTC) [ responder ]
- La norma ECMA-48 (que tontamente pensé que no sería gratuita y por eso ni siquiera la busqué) establece en §8.3.117 en la página 61 (PDF de reimpresión de 1998) de manera inequívoca que SGR 21 indica "doblemente subrayado", por lo que yo votaría, como mínimo, por que se mantengan ambos o que se mantenga el "doble subrayado". Voy a agregar una referencia a la norma ECMA. – ASiplas ( discusión ) 22:43, 7 de septiembre de 2018 (UTC) [ responder ]
- He investigado un poco sobre esto: resulta que ni una sola terminal histórica cuyos manuales he consultado (vt100, vt220, vt520, ...) tenía esa funcionalidad. Parece que este era un elemento de la lista de deseos en la documentación de xterm (¡y xterm ni siquiera lo implementa hasta el día de hoy!), que se copió. En cambio, todas las terminales restantes tenían 2X deshabilitando lo que 0X habilita (al igual que 3X es consistente con 4X, 9X con 10X, etc.). Solo en vte0.51.2 esto cambió, alguien también envió un parche para el kernel. Como se trata de una regresión que rompe los programas existentes, simplemente presenté un informe de error en vte. La versión ofensiva está presente en Debian unstable pero no en Debian stretch. - KiloByte ( discusión ) 00:02, 8 de septiembre de 2018 (UTC) [ responder ]
- El parche n.° 305 de xterm en 2014 implementó SGR 21. Quizás tengas una versión anterior a esa TEDickey ( discusión ) 00:16 8 sep 2018 (UTC) [ responder ]
- Entiende el código pero lo muestra como un único subrayado, incluso con el zoom máximo admitido (a partir de xterm=335-1). El nuevo vte se duplica. - KiloByte ( discusión ) 13:15, 9 de septiembre de 2018 (UTC) [ responder ]
- El programa dibuja dos líneas y así está documentado. Ten en cuenta que Wikipedia no es una fuente de información fiable TEDickey ( discusión ) 14:30 9 sep 2018 (UTC) [ responder ]
- Entonces, a partir del 22 de marzo de 2020, ¿qué emuladores de terminal, si los hay, tratan a SGR 21 como "negrita desactivada" en lugar de "doble subrayado activado" (o como una operación nula porque no implementan el doble subrayado) en la versión más reciente? Guy Harris ( discusión ) 05:02 23 mar 2020 (UTC) [ responder ]
- La documentación de Linux todavía decía eso hasta hace poco, y menciona una actualización aquí (aunque se modificó silenciosamente hace un par de años) y, como sabemos, una fuente confiable prevalece sobre otras consideraciones. La fuente principal de esto se modificó en el ínterin TEDickey ( discusión ) 08:15, 23 de marzo de 2020 (UTC) [ responder ]
- "¿Sigue xterm en lugar de sentido común y coherencia, siendo el único comando 1..9 donde N+20 no deshace lo que N hizo"? ¿Alguien podría indicarle a esa persona que consulte ECMA-48, quinta edición, y que vaya a la página 61, para que sepa que 1) sigue el estándar ECMA, por inconsistente y sin sentido común que pueda pensar, y 2) N+20, para algunos valores de N, deshace múltiples variantes de lo que N hace, por ejemplo, SGR 22 deshace tanto SGR 1 (negrita) como SGR 2 (débil).
- Sin embargo, SGR 21 puede agregar doble subrayado (si es compatible) a los modos existentes o reemplazar los modos existentes con doble subrayado, según la configuración del "MODO DE COMBINACIÓN DE REPRESENTACIÓN GRÁFICA". Supongo que si 1) no se admite el doble subrayado y se "implementa" sin subrayar realmente y 2) la terminal o el emulador están en modo REEMPLAZO en lugar de modo ACUMULATIVO, SGR 21 podría hacer que el texto se muestre de la misma manera que lo haría SGR 0, y un efecto de eso sería desactivar la negrita. Pero eso no se debe a que el código SGR para negrita es 1 y, por lo tanto, 20+1 significa "desactivar negrita". Guy Harris ( discusión ) 21:34, 23 de marzo de 2020 (UTC) [ responder ]
- xterm 351, GNOME Terminal 3.34.1 con VTE 0.58.1 y konsole 19.12.1 en Fedora 31 (versión de KDE para konsole) y Terminal versión 2.10 (433) en macOS 10.15.3, todos parecen soportar solo el MODO DE COMBINACIÓN DE REPRESENTACIÓN GRÁFICA ACUMULATIVA, por lo que SGR 1 seguido de SGR 21 produce texto en negrita con doble subrayado (GNOME Terminal), texto en negrita con un solo subrayado (xterm y konsole) o texto en negrita (Terminal), y SGR 1 seguido de SGR 4 produce texto en negrita con un solo subrayado en todos ellos. (A menos que <ESC> 21 l = RM 21 no restablezca el MODO DE COMBINACIÓN DE REPRESENTACIÓN GRÁFICA a REEMPLAZO). Guy Harris ( discusión ) 22:11 23 mar 2020 (UTC) [ responder ]
- No está claro a quién te diriges. En cualquier caso, los comentarios de la página de discusión no son una fuente confiable , y lo que se necesita es una fuente confiable. TEDickey ( discusión ) 22:33 23 mar 2020 (UTC) [ responder ]
- "No está claro a quién te diriges". 1) La persona que hizo este commit y 2) aquellos curiosos sobre el comportamiento de SGR 21 en emuladores de terminal populares. "En cualquier caso, los comentarios de la página de discusión no son una fuente confiable , y lo que se necesita es una fuente confiable". Por lo tanto, eso presumiblemente significaría 1) una tabla de los emuladores de terminal más comunes (y terminales si aún nos importan) de una fuente confiable y 2) documentación para esos emuladores de terminal (y terminales) que indique que no implementan SGR 21 como "negrita". Guy Harris ( discusión ) 22:53, 23 de marzo de 2020 (UTC) [ responder ]
- Sí... No sé dónde encontrarás eso (aparte de alguien que pueda sentirse inspirado por esta página para construir una tabla, que generalmente termina siendo menos que útil) TEDickey ( discusión ) 23:15, 23 de marzo de 2020 (UTC) [ responder ]
En la sección "Secuencias de escape" puede encontrar "Las secuencias tienen diferentes longitudes. Todas las secuencias comienzan con ESC (27 / hex 0x1B / octal 033), seguido de un segundo byte en el rango 0x40–0x5F (ASCII @A–Z[\]^_).[16]:5.3.a
En primer lugar, ESC + seguido de byte no tiene longitudes diferentes. En segundo lugar, no es una secuencia ESC válida.
Vea la suya ref 16 (ECMA-48):
4.2.48 Byte intermedio
a) En una secuencia de escape, combinación de bits que puede ocurrir entre la función de control ESCAPE ( ESC ) y el Byte Final.
b) En una secuencia de control, una combinación de bits que puede ocurrir entre la función de control INTRODUCTOR DE SECUENCIA DE CONTROL (CSI) y el Byte Final, o entre un Byte de Parámetro y el Byte Final.
La secuencia ESC se define en ECMA-35:
4.17 Byte intermedio
Una combinación de bits que puede ocurrir entre la del carácter de control ESCAPE y el byte final en una secuencia de escape.
13.1. ... El primer byte de una secuencia de escape será la combinación de bits que representa el carácter ESCAPE y el último se conocerá como Byte Final. Una secuencia de escape también puede contener uno o más bytes conocidos como Bytes intermedios .
...
Sugiero agregar
luego por cualquier número de "bytes intermedios" en el rango 0x20–0x2F (espacio ASCII y !"#$%&'()*+,-./),
a la definición de ESC, como está ahora en la definición de CSI.
31.179.146.6 (discusión) 11:24, 11 de octubre de 2018 (UTC): rysson (Robert Kalinowski) [ respuesta ]
- 31.179.146.6 (discusión · contribs ), siéntete libre de hacer esta actualización. II | ( t - c ) 11:40 26 nov 2018 (UTC) [ responder ]
Por lo general, los programadores utilizan los escapes ANSI, por lo que no creo que muchas personas que NO sean programadores visiten esta página con frecuencia. Por lo tanto, creo que se debería eliminar la advertencia de "demasiado técnico", ya que la audiencia de esta página debería estar formada principalmente por programadores que puedan entender este tema. Nathan0kulzer (discusión) 13:16 26 ago 2019 (UTC) [ responder ]
- A menos que quien lo haya puesto ahí pueda indicar claramente qué tipo de cosas son "demasiado técnicas" y qué audiencia cree que es apropiada como "mínimamente técnicamente consciente", yo diría "déjenlo". Si la idea es "intentar explicárselo a alguien que no sabe qué es un 'bit'", entonces el objetivo no es "escribirlo para que esa persona pueda leer el artículo y entenderlo sin tener que, por ejemplo, hacer clic en el enlace a bit y leerlo para entender qué es un 'bit'", el objetivo es "agregar suficientes enlaces para que el lector pueda aprender lo suficiente para entenderlo". Guy Harris ( discusión ) 18:54 26 ago 2019 (UTC) [ responder ]
- Como nadie se opuso, eliminé la etiqueta. En mi opinión, la introducción y la sección "Historia" están en el nivel adecuado para los no expertos, mientras que las otras secciones son naturalmente de naturaleza más técnica. -- Rublov ( discusión ) 00:57 29 oct 2020 (UTC) [ responder ]
Algunas secciones de este artículo tratan sobre la arquitectura de documentos abiertos . Si bien el contenido es interesante, realmente creo que pertenece a ese artículo en lugar de a este. El hecho es que ODA es básicamente un estándar fallido: nunca recibió una adopción generalizada en el mercado. Es interesante saber que partes de él implicaban la definición de secuencias de escape de estilo ECMA-48, pero en realidad los detalles de eso, si pertenecen a algún lugar de Wikipedia, pertenecen al artículo de ODA, no a este: nunca se pretendió que los emuladores de terminal admitieran directamente ODA; el documento ODA se cargaría mediante un procesador de texto que podría usar secuencias de escape ECMA-48 para la visualización si fuera un editor de texto sin GUI, y que convertiría las secuencias de escape ODA en instrucciones de lenguaje de impresora para imprimir (el lenguaje de impresora podría haber estado basado en ECMA-48, podría haber sido algo completamente diferente como PostScript en su lugar). SJK ( discusión ) 14:17, 4 de abril de 2020 (UTC) [ responder ]
- "Some" significa "dos oraciones cortas más una lista de "ver también" al final", y si hay terminales o emuladores de terminal que aceptan secuencias de escape derivadas de ODA, esa parte es relevante aquí. Guy Harris ( discusión ) 19:13 4 abr 2020 (UTC) [ responder ]
- Bueno, ¿qué terminales o emuladores de terminal admiten secuencias de escape específicas de ODA? Muchos emuladores de terminal admiten SGR 38 y 48, que pueden derivarse de ODA, pero las versiones implementadas realmente en los emuladores de terminal están muy simplificadas a partir de la especificación ODA y no son compatibles con ella (aunque estén inspiradas en ella de alguna manera). No creo que ningún emulador de terminal haya intentado implementar el resto de las numerosas secuencias de escape de ODA (y por qué deberían hacerlo, es una especificación de formato de archivo para documentos de procesamiento de texto, no una especificación para un terminal de texto). El artículo actualmente dice cosas como "ofrece una versión alternativa que parece tener menos soporte". ¿Alguien la admite? ¿Por qué un emulador de terminal admitiría un elemento aleatorio extraído de una especificación para un formato de archivo de procesamiento de texto? O de manera similar, la afirmación "tenga en cuenta que muchas implementaciones que reconocen ':' como separador olvidan erróneamente el parámetro identificador del espacio de color y, por lo tanto, cambian la posición de los restantes"; ningún emulador de terminal está intentando implementar T.416, ni debería hacerlo. ¿Por qué un emulador de terminal debería implementar un estándar que ha fracasado en gran medida para un formato de archivo de procesamiento de textos? SJK ( discusión ) 20:06, 4 de abril de 2020 (UTC) [ responder ]
- En ninguna parte del artículo (o yo) se habla de implementar el estándar T.416 completo, por lo que el estándar completo es una pista falsa.
- Cuando el artículo menciona ODA, sólo habla de 1) las secuencias de escape de color de 8 bits, donde T.416 utiliza dos puntos en lugar de un punto y coma como separador, y 2) las secuencias de escape de color de 24 bits, donde T.416 vuelve a utilizar dos puntos como separador y tiene algunos parámetros adicionales. Un terminal puede implementar eso sin implementar todo el estándar. (Tenga en cuenta, por cierto, que ECMA-48, 5.ª edición, dice que los códigos SGR 38 y 48 están reservados para configurar los colores de primer plano y de fondo, respectivamente, "como se especifica en ISO 8613-6 [Recomendación T.416 del CCITT]", lo que podría haber inspirado a algunos desarrolladores de terminales o emuladores a usarlos para ese propósito).
- En este punto, lo correcto es probablemente pedir citas sobre 1) "una versión alternativa que parece tener menos soporte", 2) "Tenga en cuenta que esto utiliza el carácter ':', que de otro modo estaría reservado, para separar las subopciones, lo que puede haber sido una fuente de confusión para las implementaciones del mundo real", y 3) "Tenga en cuenta también que muchas implementaciones que reconocen ':' como separador olvidan erróneamente el parámetro identificador del espacio de color y, por lo tanto, cambian la posición de los restantes". Si nadie puede encontrar una cita para terminales o emuladores que utilicen los dos puntos o implementen los parámetros adicionales, eliminamos lo que no tiene citas; de lo contrario, dejamos lo de T.416 allí únicamente para indicar por qué los terminales o emuladores en cuestión admitían los dos puntos como separadores. Guy Harris ( discusión ) 20:28, 4 de abril de 2020 (UTC) [ responder ]
- Creo que el problema es que la forma en que está redactado no deja claro el hecho de que los emuladores de terminal no están intentando implementar ODA en absoluto, sino que solo se inspiran en una pequeña característica de una de las especificaciones de ODA. Creo que si lo redactamos de tal manera que quede claro, no tendría ningún problema en hacer referencia a ODA. SJK ( discusión ) 22:43, 11 de abril de 2020 (UTC) [ responder ]
- La prueba con la terminal de Gnome muestra que acepta las sintaxis "\033[38;5;Nm" y ""\033[38;2;R;G;Bm". También acepta exactamente lo mismo con dos puntos en lugar de punto y coma. No le gusta que haya una mezcla de punto y coma y dos puntos. Y no le gusta el número de "espacio de color" ni ningún otro número agregado al principio o al final de la sintaxis rgb, incluso si se usan dos puntos. Spitzak ( discusión ) 21:01, 4 de abril de 2020 (UTC) [ responder ]
PU2_(ANSI) es una redirección a este artículo, pero no se menciona. -- Itu ( discusión ) 05:34, 26 de mayo de 2020 (UTC) [ responder ]
- Tal vez, en algún momento, este artículo habló sobre PU1 y PU2, pero actualmente no lo hace, por lo que PU1 (ANSI) y PU2 (ANSI) no deberían redirigir a este artículo. Los cambié a ambos para que redirijan a los códigos de control C0 y C1#Códigos de control C1 para uso general en su lugar, ya que esa sección al menos menciona los códigos de uso privado. Guy Harris ( discusión ) 05:56, 26 de mayo de 2020 (UTC) [ responder ]
Está (a menudo) bien utilizar una fuente primaria para afirmar que algo existe, pero utilizar una fuente primaria para afirmar que algo se hizo por primera vez en un lugar determinado no es una buena práctica TEDickey ( discusión ) 23:25, 4 de junio de 2020 (UTC) [ responder ]
- A estas personas se les ocurrió la idea de tener esta extensión. Cuando se trata de partes que un estándar no cubre, no es suficiente simplemente indicar qué hace algo, sino también indicar quién lo usa. -- Artoria 2e5 🌉 09:43, 5 de junio de 2020 (UTC) [ responder ]
- Claro, quité la palabra "primero", porque iba más allá de los hechos y era promocional. TEDickey ( discusión ) 22:41 5 jun 2020 (UTC) [ responder ]
- El listado de Github que se agregó parece caer en esta misma discusión. Es el mismo autor, con contribuciones menores de algunos otros (que, por ejemplo, usan Wikipedia como fuente de información). TEDickey ( discusión ) 08:03, 20 de octubre de 2023 (UTC) [ responder ]
La fuente dada no respalda la afirmación. Para ello, tendría que (a) señalar que se hizo por primera vez en SCO (¿Xenix?) con un año de introducción, o (b) una fuente de terceros con conocimiento que haga esta afirmación. Por ejemplo, no era una característica nueva en 1997 cuando se agregó a xterm, ni tampoco era nueva cuando se incorporó a la consola Linux unos años antes de eso. Por lo tanto, un manual de 2003 que menciona la característica no respalda el término "invención" TEDickey ( discusión ) 13:39, 13 de junio de 2020 (UTC) [ responder ]
Sugiero agregar ESC[?3h y ESC[?3l que realizan este cambio. pietro 151.29.37.171 (discusión) 11:57 8 dic 2020 (UTC) [ responder ]
Estimados autores
La oración "Por ejemplo, <esc>[4;2~ es Shift-End, <esc>[20~ es la tecla de función 9, <esc>[5C es Ctrl-Right" ha sido marcada como dudosa. Sin embargo, dado que las tablas que se encuentran debajo de esa oración son correctas, creo que los ejemplos son válidos:
Ejemplo 1: <esc>[4;2~: Esto coincide con el patrón general "<esc> '[' (<num>) (';'<num>) '~'" con la explicación "secuencia de código de tecla, <num> por defecto es 1" dada anteriormente. Como se explica en el texto "Si el carácter de terminación es '~', el primer número debe estar presente y es un número de código de tecla, el segundo número es un valor de modificador opcional". Por lo tanto, "4" es el código de tecla, que según la tabla "vt sequences" es "<esc>[4~ - Fin" y ";2" es el modificador. El modificador "... por defecto es 1, y después de restar 1 es un mapa de bits de las teclas modificadoras que se presionan: Meta-Ctrl-Alt-Shift". Por lo tanto, 2-1=1 y en el mapa de bits "Meta-Ctrl-Alt-Shift" esto selecciona "Shift"
Ejemplo 2: <esc>[20~ Esto es F9 según la tabla "secuencias vt": "<esc>[20~ - F9"
Ejemplo 3: <esc>[5C En el párrafo anterior a los ejemplos se explica "Si el carácter final es una letra, la letra es el valor del código de tecla y el número opcional es el valor del modificador". Por lo tanto, "C" es la letra final y el significado de la letra del código de tecla "C" es "<esc>[C - Derecha" según la tabla "secuencias xterm". Y del modificador 5 hay que restar 1 para obtener el valor del mapa de bits de las teclas modificadoras. Por lo tanto, 5-1=4 y 4 selecciona "Ctrl" en "Meta-Ctrl-Alt-Shift".
Así que creo que los ejemplos son correctos (aunque me llevó un tiempo entenderlos).
Entonces, ¿por qué tienes dudas? 89.206.112.15 ( discusión ) 09:44 22 mar 2021 (UTC) [ responder ]
La información sobre "Windows Terminal" es incorrecta. Dice "Windows Terminal, introducido en 2019, admite las secuencias de forma predeterminada. Microsoft ha dejado obsoleto el subsistema y las API de la consola de Windows clásica y tiene la intención de reemplazarlos con Windows Terminal en el futuro". Me resulta muy difícil creer que el subsistema y las API de la consola de Windows alguna vez queden obsoletos, por lo que leí la referencia con mucha atención y no pude encontrar ninguna referencia a la declaración. Había un enlace en la página de referencia https://docs.microsoft.com/en-us/windows/console/classic-vs-VT que aborda las inquietudes sobre el subsistema y las API de la consola de Windows clásica. En la sección "Planificación futura y pseudoconsola" de esta página, dice lo siguiente:
No hay planes para eliminar las API de la consola de Windows de la plataforma.
Por el contrario, el host de la consola de Windows ha proporcionado la tecnología de pseudoconsola para traducir las llamadas de aplicaciones de línea de comandos de Windows existentes en secuencias de terminal virtual y reenviarlas a otro entorno de alojamiento de forma remota o entre plataformas.
- La impresión que se desprende de la referencia es que cuando los usuarios ejecutan "Comando" o "Powershell", la ventana de terminal será Windows Terminal y los programas que se ejecuten en ella podrán asumir que las secuencias ANSI funcionan. Parece sensato que la antigua API se emule en esto. La API no se está desestimando. Pero la imposibilidad de imprimir secuencias de escape *sí* se está desestimando. Spitzak ( discusión ) 01:56, 5 de agosto de 2021 (UTC) [ responder ]
3.10 contiene múltiples ocurrencias de "(sección borrador)" y utiliza bloques de código en lugar de tablas.
197.185.106.15 (discusión) 04:36 13 sep 2021 (UTC) [ responder ]
Creo que sería beneficioso agregar una columna por implementación del emulador de terminal para indicar el soporte del código SGR. Kaznovac (discusión) 15:13, 2 de enero de 2022 (UTC) [ responder ]
- Tal vez no: necesitarías una fuente confiable , y es bastante conocido que la cobertura es aleatoria (ver las preguntas frecuentes de xterm) TEDickey ( discusión ) 15:17 2 ene 2022 (UTC) [ responder ]
Creo que la sección CPM en la sección Historial se podría reducir sustancialmente. Apenas menciona los códigos ANSI y, en cambio, quiere hablar sobre terminales de hardware CPM.
Tal vez el CPM tuvo un uso sustancial en los años 80 con terminales ANSI, pero no lo sabrías al leer esa sección. — Comentario anterior sin firmar agregado por 45.48.161.1 ( discusión ) 20:51, 19 de junio de 2022 (UTC) [ responder ]
- Esa sección fue eliminada en https://en.wikipedia.org/w/index.php?title=ANSI_escape_code&diff=1186405891&oldid=1186404947 esta edición], con el comentario de edición "eliminar - 95% fuera de tema, además la frase "también lo describe como compatible con ANSI"". Guy Harris ( discusión ) 06:37 24 abr 2024 (UTC) [ responder ]
Esa oración necesita una nueva redacción (la compatibilidad con colores en terminfo es más de diez años anterior a la jerga). TEDickey ( discusión ) 18:37 5 nov 2022 (UTC) [ responder ]
¿Se definieron los colores a los que se hace referencia en los colores ANSI? ¿Se les dio un nombre? ¿Se hizo referencia a algún otro estándar ANSI, FED o MIL? 1.159.58.220 ( discusión ) 23:21 11 feb 2023 (UTC) [ responder ]
- No hay ningún "color ANSI". ANSI X3.64-1979 dice
- ISO 6429 contiene los siguientes valores de parámetros para usar con SGR (Representación gráfica seleccionada) que no están presentes en ANSI X3.64-1979.
- ...
- 30 Pantalla negra
- 31 Pantalla roja
- 32 Pantalla verde
- 33 Pantalla amarilla
- 34 Pantalla azul
- Pantalla magenta 35
- Pantalla cian 36
- 37 Pantalla blanca
- 38 (reservado para futura estandarización)
- 39 (reservado para futura estandarización)
- 40 Fondo negro
- 41 Fondo rojo
- 42 Fondo verde
- 43 Fondo amarillo
- 44 Fondo azul
- 45 Fondo magenta
- 46 Fondo cian
- 47 Fondo blanco
- Por lo tanto, son "colores ISO" y son simplemente nombres que no hacen referencia a ningún otro estándar. Guy Harris ( discusión ) 00:02 12 feb 2023 (UTC) [ responder ]
- ECMA-48 (2.ª edición) proporciona más información y parece ser el primer estándar publicado con estos códigos TEDickey ( discusión ) 01:03 12 feb 2023 (UTC) [ responder ]
- X3.64-1979 dice
ANSI X3.64-1979 y ECMA-48, Controles adicionales para dispositivos de E/S de creación de imágenes de caracteres, se desarrollaron en paralelo, con una estrecha colaboración. ISO DP 6429, Funciones de control adicionales para dispositivos de creación de imágenes de caracteres, se desarrolló como una síntesis de X3.64 y ECMA-48. Durante este proceso, se añadieron algunas funciones de control, así como parámetros selectivos adicionales. A excepción del punto 1 que aparece a continuación, X3.64 es un subconjunto de ISO 6429. Aunque las dos normas utilizan un lenguaje diferente, la intención es que el subconjunto sea técnicamente idéntico. X3.64 se sometió a votación y se envió antes de la resolución final de ISO 6429 y no incorpora el propio ISO/TC97/SC2 para completar ISO 6429. La revisión de X3.64 intentará incorporar esos elementos y supuestos de X3.64.
- siendo el "punto 1" que
- X3.64-1979 contiene un valor de parámetro para usar con SM (modo de configuración) y RM (modo de reinicio) que no está presente en ISO 6429. Es:
- 3/2 3/0 LNM Línea de avance Modo de nueva línea
- ECMA-48, 1.ª edición, marzo de 1976, no está disponible en línea en ECMA.
- La segunda edición de ECMA-48, de agosto de 1979, está disponible (en un formato claramente escaneado manualmente; quizás nadie tenía una copia de la primera edición para escanear). Tiene los colores, así como algunas opciones de selección de fuentes, incluida Fraktur (es de suponer que al menos un colaborador de habla alemana participó en la especificación :-)). No indica qué cambió entre la primera y la segunda edición. Dice:
- Tras haber publicado su Norma ECMA-35 para la ampliación del conjunto de caracteres codificados de 7 bits, el comité de codificación TC 1 de la ECMA creó un grupo de trabajo con vistas a desarrollar un conjunto de funciones de control adicionales. Este trabajo se llevó a cabo en estrecha colaboración con el comité de codificación X3L2 de ANSI. Los resultados intermedios se discutieron periódicamente en las reuniones del ISO/TC97/SC2. La primera edición de la Norma ECMA-48 se publicó en septiembre de 1976.
- En el marco del ISO/TC97/SC2, un grupo de trabajo elaboró una propuesta preliminar de la ISO basada en la ECMA-48 y en las contribuciones presentadas por los representantes de X3L2. Se redactaron varias versiones, que se presentaron al SC2 y se actualizaron de acuerdo con los comentarios recibidos. Finalmente, en su reunión de mayo de 1978, el SC2 adoptó el texto final, que se procesará como borrador de norma internacional y se publicará finalmente como ISO 6429.
- Esta segunda edición de ECMA-48 se basa en el texto de DIS 6429 y es técnicamente idéntica a él. Fue aceptada como norma ECMA por la Asamblea General de ECMA el 21 de junio de 1979.
- La 3.ª edición de la ECMA-48, de marzo de 1984, no contiene ninguna nota histórica. La 4.ª edición de la ECMA-48, de diciembre de 1986, dice:
- Paralelamente al trabajo sobre las normas ECMA-6 para el conjunto de caracteres codificados de 7 bits, ECMA-35 para las técnicas de extensión de código y ECMA-43 para las reglas y estructura de los códigos de 8 bits, TC1, el comité de codificación de ECMA, trabajó en la definición y codificación de las funciones de control que se utilizarán con las distintas normas para conjuntos de caracteres gráficos codificados producidas por ECMA, a saber, ECMA-94, ECMA-113, ECMA-114 y ECMA-118.
- La primera edición de esta norma ECMA-48 se publicó en 1976. Una segunda y una tercera edición se publicaron en 1979 y 1984, respectivamente. El texto era técnicamente idéntico al de la norma ISO 6429. Mientras tanto, el grupo de trabajo ISO/TC97/SC2/WG-6 ha llevado a cabo una revisión de esta última.
- El alcance de la norma se ha ampliado para incluir todas las posibles funciones de control necesarias para aplicaciones y códigos muy diferentes, incluidas las especificadas en ECMA-6 y las funciones de cambio de ECMA-35. Como el SC2/WG-6 es responsable en ISO de la normalización de las definiciones y la codificación de las funciones de control, se han recibido numerosas solicitudes para la inclusión de funciones de control necesarias en aplicaciones específicas. Como consecuencia de ello, la publicación de la próxima edición de la ISO 6429 se ha retrasado, aunque ahora hay un conjunto de aproximadamente 150 funciones de control estables y bien definidas.
- La cuarta edición actual de ECMA-48 contiene las definiciones y la codificación de todas las funciones de control ya acordadas por SC2/WG-6. El objetivo de esta publicación es ponerlas a disposición de la comunidad de tecnologías de la información en general para que su implementación facilite el intercambio de datos.
- y ECMA-48, 5ª edición, junio de 1991 dice:
- Como parte del trabajo sobre estándares de conjuntos de caracteres codificados, TC1, el comité de codificación de ECMA, trabajó en la definición y codificación de funciones de control que se utilizarán con los diversos estándares para conjuntos de caracteres gráficos codificados producidos por ECMA, a saber, ECMA-6, ECMA-94, ECMA-113, ECMA-114, ECMA-118, ECMA-121, ECMA-128 y ECMA-144.
- La primera edición de esta norma ECMA-48 se publicó en 1976. A ella le siguieron otras ediciones. La cuarta edición, publicada en 1986, fue adoptada por la ISO/IEC mediante el procedimiento de vía rápida como segunda edición de la ISO 6429. Constituye un repertorio de un gran número de funciones de control cuyas definiciones y representaciones codificadas están así normalizadas. Para cada aplicación, se puede realizar la selección necesaria de funciones de control a partir de este repertorio.
- Esta quinta edición de la Norma ECMA-48 contiene las funciones de control ya normalizadas en la cuarta edición y, además, nuevas funciones de control necesarias para el manejo de textos bidireccionales, es decir, textos que comprenden partes escritas con una escritura de izquierda a derecha y partes escritas con una escritura de derecha a izquierda. El Informe Técnico ECMA TR/53 proporciona más información y ejemplos de manejo de dichos textos. La inclusión de estas funciones de control especializadas ha requerido un ajuste correspondiente de las definiciones de algunas de las otras funciones de control. Además, el concepto de "dispositivo" tuvo que ser revisado.
- Esta quinta edición ha sido aportada a ISO/IEC para su adopción conforme al procedimiento acelerado como tercera edición de ISO/IEC 6429.
- En cuanto a ISO 6429, parece que la primera edición salió en 1983, la segunda edición salió en 1988 y la tercera edición, que es la edición actual, salió en 1992, por lo que ECMA-48, 2.ª edición (1979), es anterior a ISO 6429, 1.ª edición (1983), y X3.64 no tenía los colores y nunca, hasta donde yo sé, ha sido revisado, por lo que ECMA-48 fue, de hecho, el primer estándar publicado con los colores.
- La impresión que tengo de la historia dada en X3.64 y los estándares ECMA es que:
- ANSI y ECMA trabajaron juntos en sus estándares y también participaron en el estándar ISO;
- La ECMA publicó actualizaciones de la ECMA-48, incorporando varias cosas que sucedieron en el proceso ISO, con el fin de incluirlas en un estándar sin tener que esperar a que se complete el proceso ISO;
- Es posible que ANSI haya decidido "ahora está en manos de ISO, así es como participaremos" y no se haya molestado en publicar ninguna actualización.
- Entonces, tal vez los colores surgieron por primera vez en ISO y se incluyeron en ECMA-48, segunda edición, antes de que se publicara la primera edición de ISO 6429, o estaban en ECMA-48, primera edición y se incorporaron en ISO 6429 a partir de esa norma. Al no tener la primera edición de ECMA-48, no sé si tiene los colores o no. Guy Harris ( discusión ) 06:16 12 feb 2023 (UTC) [ responder ]
- LNM estaría en la página 42, pero no lo veo allí. La 3.ª edición (página 44) dice que hay que ver el apéndice E (que falta). La 4.ª edición (página 64) dice que está reservado y (páginas 84-85) marca a LNM como que debe eliminarse, aludiendo a algunas implementaciones, etc. La 5.ª edición dice que quedó obsoleto en la 4.ª edición (página 88). Está en xterm, para compatibilidad con DEC TEDickey ( discusión ) 10:29 12 feb 2023 (UTC) [ responder ]
El comentario de un editor sobre los colores versus el video inverso tiene una fuente deficiente (la fuente proporcionada no proporciona al lector ninguna información) TEDickey ( discusión ) 18:55, 26 de abril de 2023 (UTC) [ responder ]
- Creo que el texto citado en apoyo de la afirmación de "emulación inconsistente" se encuentra en la subsección Elementos de visualización de la página de destino. Lamentablemente, esa subsección no se puede vincular directamente debido a la deficiente estructura interna del HTML de esa página. – ReadOnlyAccount ( discusión ) 16:38, 29 de febrero de 2024 (UTC) [ responder ]
- Parece que estás hablando del párrafo que comienza con "Los buffers de visualización de terminales virtuales también incluyen una bandera de pantalla de "fondo claro/oscuro"", que utiliza el término solo en la oración " console-termio-realizer maneja esta bandera por sí mismo, por lo tanto, para la coherencia entre terminales realizadas y con otros realizadores", después de un par de comentarios (incluidos algunos inexactos) sobre otros programas. Esa no es una fuente confiable para el propósito previsto en este tema. TEDickey ( discusión ) 19:54, 29 de febrero de 2024 (UTC) [ responder ]
Considerando que la sección de descripción contiene alrededor de 17 subsecciones y la mayor parte del artículo cuando las conté, ¿deberían algunas subsecciones promocionarse como secciones normales?
Incluso contiene la sección de ejemplos, y normalmente no es una subsección .
También estoy pensando en eliminar la sección de descripción. Apenguinlover < discusión >() 12:34, 26 de octubre de 2024 (UTC) [ responder ]
Supongo que lo haré de todos modos Apenguinlover < discusión >() 11:29, 28 de octubre de 2024 (UTC) [ responder ]
