Comportamiento extraño del método de coincidencias de String()

Encontré un problema interesante sobre el método de concordancias de String (RegExp).Comportamiento extraño del método de coincidencias de String()

assertTrue("33CCFF".matches("[0-9A-Za-z]{6}")); 
assertTrue("CC33FF".matches("[0-9A-Za-z]{6}")); 
assertTrue("CC3355".matches("[0-9A-Za-z]{6}")); 
assertTrue("CC9955".matches("[0-9A-Za-z]{6}")); 
assertTrue("CC3366".matches("[0-9A-Za-z]{6}")); 
assertTrue("CC3965".matches("[0-9A-Za-z]{6}")); 
assertTrue("CC1961".matches("[0-9A-Za-z]{6}")); 
assertTrue("CC9999".matches("[0-9A-Za-z]{6}")); 
assertTrue("СС3966".matches("[0-9A-Za-z]{6}")); // failing 
assertTrue("СС9965".matches("[0-9A-Za-z]{6}")); // failing 
assertTrue("СС9966".matches("[0-9A-Za-z]{6}")); // failing

Las últimas 3 afirmaciones fallan inesperadamente. No pude encontrar ninguna razón por la cual este extraño comportamiento está sucediendo. ¿Tienes el mismo problema? ¿Tienes alguna idea?

Por cierto, en caso de que me pregunten, mi versión de Java es la siguiente.

java version "1.6.0_26" 
Java(TM) SE Runtime Environment (build 1.6.0_26-b03) 
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

Fuente

2011-10-05 lemiorhan

Indagué después de sus respuestas y noté que los caracteres C superiores (& # 0043) son diferentes a los caracteres C inferiores (& # 1057). Los caracteres C en las últimas 3 líneas parecen ser del alfabeto cirílico. http://webdesign.about.com/od/localization/l/blhtmlcodes-ru.htm – lemiorhan

El problema ocurre debido a la entrada del usuario. Para verificar si la entrada es alfa-decimal (incluso para Círica C), org.apache.commons.lang.StringUtils.isAlphanumeric() está devolviendo verdadero como el siguiente: assertTrue (StringUtils.isAlphanumeric ("\ u0421 \ u0421")) ; // cirílico C assertTrue (StringUtils.isAlphanumeric ("\ u00E7 \ u00E7")); // ascii C – lemiorhan

Los tres últimos No realidad inicio con un carácter ASCII "C". Comienzan con un carácter no ASCII que parece como "C". Eso no coincide con nada en el conjunto [0-9A-Za-z], por lo que el patrón falla.

(I descubrió esto al copiar y pegar el código en un editor de texto, que no maneja caracteres no ASCII terriblemente bien - "?". Que como)

Fuente

2011-10-05 16:25:28

Derecha, el código HEX del incorrecto-C-character es '0x3F' pero para todas las' C' anteriores es '0x43' – sll

@sll: No, el 3F es simplemente"? " que a menudo se usa para representar personajes que de otra manera no se pueden representar. El personaje que se muestra es * no * "?". –

¡Buena captura! Parece que mi editor reemplazó este caracter por '?' Antes de guardar – sll

su "СС3966" (I estoy cortando y pegando) están siendo marcados como no UTF-8, por lo que reg-ex no los está igualando. Cuando cambio tu texto y simplemente lo escribo, funciona como se esperaba. No estoy seguro de dónde copió estos valores, pero ese es su problema

Fuente

2011-10-05 16:29:01

Entiendo tu punto. Descubriste el problema como JonSkeet. Muchas gracias por tu respuesta. – lemiorhan

Es gracioso ... John y yo descubrimos la misma respuesta, la encontré 1 minuto antes que él ... recibe 12 votos positivos, obtengo 1 :) ¡Parece que este es un concurso de popularidad después de todo! lol. –

Por cierto, cuando pegué su partida en mi eclipse y traté de guardarla, trajo un cuadro de diálogo que decía que estoy tratando de guardar texto que no sea UTF-8. No creo que haya modificado mis configuraciones de eclipse, por lo que debería ver por qué la suya no le está dando la misma advertencia para futuros problemas como este. –

Comportamiento extraño del método de coincidencias de String()

Respuesta

Cuestiones relacionadas