INFORMACIÓN: Diferencias de la función entre ASC y AscB/AscW y Chr y ChrB y ChrW

Seleccione idioma Seleccione idioma
Id. de artículo: 145745 - Ver los productos a los que se aplica este artículo
Expandir todo | Contraer todo

Resumen

Para años, BASIC los programadores han estado usando el ASC y Chr las funciones de acceso y manipular el ASCII juego de caracteres. Con la llegada de aceptación de Unicode en sistemas convencionales y aplicaciones, ha desarrollado la necesidad de versiones mejoradas de las funciones Asc y Chr. Para satisfacer esta demanda, Microsoft Visual Basic (4.0 y posterior) para Windows incluye ChrB y AscB y las funciones AscW y ChrW.

Más información

Unicode es un estándar diseñado para reemplazar el estándar ANSI para codificar caracteres en un formulario numérico. Dado que el estándar ANSI sólo utiliza un solo byte para representar cada carácter, está limitado a un máximo de 256 caracteres distintos. Aunque esto es suficiente para las necesidades de una audiencia habla inglés, recae corta cuando se considera el mercado mundial de software. Con el estándar Unicode, cada carácter está representado por dos bytes, para que el carácter Unicode completo establece incluye 65.536 posibles ubicaciones.

Son totalmente Unicode basado Microsoft Windows NT, Microsoft Windows 2000 y Microsoft OLE 2.0 y Visual Basic (4.0 y superior) representa todas las cadenas internamente en formato Unicode. Las funciones AscW y ChrW permiten el acceso a los completa gama de caracteres Unicode. Estas funciones funcionan de la misma manera como las funciones Asc y Chr originales salvo que aceptan argumentos de 0 a 65.535 en lugar de simplemente desde 0 a 255. Muchos objetos de Visual Basic (como la ventana de depuración y la etiqueta y el cuadro de texto) devuelven un "?" cuando estos objetos no saben cómo mostrar un carácter Unicode.

Dado que todas las cadenas son ahora representa internamente en formato Unicode, no es tan sencillo como utiliza para representar datos binarios en una cadena. Mediante la función Chr para asignar datos a una cadena no da como resultado el mismo comportamiento que antes. Por ejemplo:
   stringvar = Chr(65)
				

resultados en una cadena larga dos bytes, donde bytes 1 tiene un valor de 65 y bytes 2 tiene un valor de 0 (que es la representación Unicode de la letra "A"). Asegúrese de tener en cuenta que convertir de ANSI a Unicode no siempre suponen sólo agregar un segundo byte con un valor de cero como ocurre en este caso. Por ejemplo, la mayoría de los códigos de carácter ANSI en el intervalo 130 159 tienen valores Unicode completamente diferentes. Intente ejecutar una 'Debug.Print AscW(Chr(130))' y un valor de 8218 se muestra.

Actualmente, Microsoft Windows requiere un poco procesador endian, lo que significa que en una entidad bytes varios el primer byte es menos significativo y importancia aumenta en bytes sucesivos. Esto explica por qué el carácter Unicode "A" se representa internamente como las siguientes:
   -------------------
   |   65   |    0   |
   -------------------
     byte 0     byte 1
				

Las funciones AscB y ChrB pueden utilizarse para replicar lo que solía realizarse mediante las funciones Asc y Chr, ya que estas funciones permiten la manipulación de las cantidades de un solo byte. Si desea que una cadena de cuatro bytes que tiene los valores binarios de 65, 66, 67 y 68 consecutivamente, a continuación, mediante la función Chr no funcionará. En su lugar, debe utilizar la función ChrB. Por ejemplo:
   stringvar = ChrB(65) & ChrB(66) & ChrB(67) & ChrB(68)
				

Como alternativa, puede utilizar la capacidad para crear matrices del tipo de datos byte nuevo y manipular los datos binarios de ese modo.

Enumerados es una explicación de los resultados de algunos usos de estas funciones con más claridad esta información simples.

Imprimir Asc(Chr(255))--> "255"

No hay nada nuevo aquí, excepto en que la función Chr es devolver un carácter Unicode que ocupa dos bytes en lugar de un carácter ANSI de un byte.

Imprimir Asc(ChrB(255))--> 5 - llamada de procedimiento no válido.

Este uso devuelve un error porque la función Asc espera siempre al menos un parámetro de dos bytes y la función ChrB sólo devuelve un solo byte.

Imprimir Asc(Chr(256))--> 5 - llamada de procedimiento no válido.

Aunque la función Chr devuelve un carácter Unicode de dos bytes, tarda sólo números entre 0 y 255 para su argumento (tenga en cuenta que en un sistema DBCS habilitado, ASC y Chr controlar caracteres de dos bytes DBCS, convertir ellos a Unicode). Mediante la función ChrW permite el acceso a las ubicaciones de caracteres Unicode completo 65.536.

Imprimir AscW(ChrW(256))--> "256"

Ésta es la nueva versión de la primera instrucción en esta sección. La función ChrW toma un valor de 0 a 65.536 y devuelve ese carácter (en sistemas de 32 bits). La función AscW interpreta este carácter como un carácter Unicode de dos bytes y devuelve el valor correcto de Unicode para ese carácter.

Imprimir Asc(ChrW(256))--> "65"
Imprimir Asc(ChrW(5000))--> "63"

Lo que sucede aquí es que la función ChrW se evalúa primero. ChrW(256) es el carácter "A", por lo que reduce la función a Asc("A") y el número de Unicode y (ANSI) para "A" es 65. Ya que Visual Basic no sabe cómo mostrar el carácter representado por Chr(5000) sólo muestra un "?", y como se esperaba, valor para el Unicode y ANSI "?" es 63.

Imprimir AscB(Chr(65))--> "65"
Imprimir AscB(ChrW(256))--> "0"
Imprimir AscB(ChrW(257))--> "1"
Imprimir AscB(ChrW(555))--> "43"
Imprimir AscB(ChrW(65535))--> "255"

Todas estas devuelven valores pueden deber a la descripción de cada carácter se representa internamente (consulte la referencia de little-endian anterior) y por el hecho de que la función AscB busque sólo en el primer byte del carácter que recibe. Visualmente parece el diagrama siguiente:
             -------------------
   Chr(65)   |   65   |    0   |
             -------------------
   Chr(256)  |    0   |    1   |
            -------------------
   Chr(257)  |    1   |    1   |
             -------------------
   Chr(555)  |   43   |    1   |
             -------------------
   Chr(65535)|   255  |  255   |
             -------------------
               byte 0    byte 1
				

La función AscB sólo devuelve todo lo que el primer byte del carácter es.

--> ChrB(65) impresión ""

Visual Basic se imprime nada para esta llamada a la función CarB porque la función ChrB sólo devuelve una cadena de un byte. Cadenas de un byte así significan nada a Visual Basic porque no constituyen un carácter Unicode válido (o serie de caracteres).

Impresión ChrB(65) & ChrB(0)--> "A"

En este caso, nos son concatenar dos cadenas de un byte en una sola cadena de dos bytes. Dado que el modelo de bits resultante es el mismo que el modelo de bits de Unicode "A", es lo que se imprime en Visual Basic.

Propiedades

Id. de artículo: 145745 - Última revisión: miércoles, 07 de mayo de 2003 - Versión: 2.0
La información de este artículo se refiere a:
  • Microsoft Visual Basic 5.0 Learning Edition
  • Microsoft Visual Basic 6.0 Edición de aprendizaje
  • Microsoft Visual Basic 5.0 Professional Edition
  • Microsoft Visual Basic 6.0 Professional Edition
  • Microsoft Visual Basic 5.0 Enterprise Edition
  • Microsoft Visual Basic Enterprise Edition for Windows 6.0
  • Microsoft Visual Basic 4.0 Standard Edition
  • Microsoft Visual Basic 4.0 Professional Edition
  • Microsoft Visual Basic 4.0 Professional Edition
  • Microsoft Visual Basic 4.0 16-bit Enterprise Edition
  • Microsoft Visual Basic 4.0 32-Bit Enterprise Edition
Palabras clave: 
kbmt kbinfo KB145745 KbMtes
Traducción automática
IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.
Haga clic aquí para ver el artículo original (en inglés): 145745

Enviar comentarios

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com