Cambiar las mayúsculas de un texto suena a la operación más trivial que hace un ordenador. No lo es, y las formas en que sale mal han roto software real. Esta herramienta convierte entre diez convenciones a la vez, pero algunas de esas conversiones tiran información para siempre, y conviene saber cuáles.
Poner en mayúsculas es una puerta de sentido único
Casi todo el mundo supone que la conversión es reversible. No lo es. La ß alemana no tiene forma mayúscula propia, así que pasarla a mayúsculas la convierte en dos letras: straße se convierte en STRASSE. Un carácter se ha vuelto dos.
Ahora vuelve. STRASSE en minúsculas es strasse, con ss, no ß. La letra original ha desaparecido y nada puede recuperarla, porque al llegar a las minúsculas ya no queda constancia de que esas dos S fueran una ß. Hacer pasar una palabra alemana por las mayúsculas cambia su ortografía en silencio.
La ligadura fi hace lo mismo, convirtiéndose en FI. Por eso una columna de base de datos que guarda una copia en mayúsculas de un nombre para búsquedas pierde información sin avisar, y por eso comparar textos poniendo ambos lados en mayúsculas es una idea sutilmente peor de lo que parece.
La I turca, que ha tumbado sistemas en producción
El turco tiene dos letras I: una con punto y otra sin él, y son letras distintas con significados distintos. La i con punto en mayúscula es İ. La I sin punto en minúscula es ı.
Esto choca con un hábito que todo desarrollador tiene. En JavaScript, "title".toUpperCase() da TITLE. Pero "title".toLocaleUpperCase("tr") da TİTLE, con punto en la I. Si un usuario tiene configuración regional turca y tu código pone una cadena en mayúsculas para compararla con una constante, la comparación falla, y falla solo para los usuarios turcos. Lo mismo al revés: "I".toLocaleLowerCase("tr") es ı, no i.
Esto ha tumbado software real, repetidamente. La regla que lo evita es que la conversión para comparar debe ser independiente de la configuración regional, mientras que la conversión para mostrar debe seguir la del usuario. Son operaciones distintas que casualmente comparten nombre. Esta herramienta convierte para mostrar y no pretende ser una función de comparación.
Los acrónimos sobreviven en una dirección y no en la otra
Partir un identificador camelCase en palabras es más delicado de lo que parece, porque una racha de mayúsculas podría ser un acrónimo. Un corte ingenuo en cada mayúscula convierte parseHTMLDocument en parse_h_t_m_l_document, que es un disparate.
Esta herramienta lo maneja: parseHTMLDocument se convierte en parse_html_document, XMLHttpRequest en xml_http_request, getUserID en get_user_id. Busca el límite donde una racha de mayúsculas se encuentra con una mayúscula seguida de minúscula, que es donde acaba el acrónimo y empieza la palabra siguiente.
El viaje de vuelta no puede funcionar, y conviene entenderlo en vez de reportarlo como un fallo. Convierte parse_html_document de nuevo a camelCase y obtienes parseHtmlDocument, no parseHTMLDocument. La forma snake_case nunca registró que html fuera un acrónimo: esa información se destruyó a la ida, y ninguna astucia a la vuelta puede inventarla. Si estás convirtiendo identificadores en un código, convierte una vez y revisa, en vez de ir y volver y fiarte.
El Title Case no es una operación definida
Pide a dos manuales de estilo que pongan la misma frase en title case y obtendrás dos respuestas. El estilo AP capitaliza las palabras de cuatro letras o más. Chicago capitaliza todo excepto artículos, conjunciones coordinantes y preposiciones cortas, salvo que sean la primera o la última palabra. Ninguno dice "capitaliza todas las palabras".
Que es lo que hace esta herramienta, porque es la única regla que funciona sin conocer tu manual de estilo, tu idioma ni qué palabras son nombres propios. Es un valor por defecto razonable y no es title case de verdad: obtienes "The Lord Of The Rings", y Chicago te diría que es "The Lord of the Rings". Para titulares que importen, usa la salida como punto de partida y arregla las palabras pequeñas a mano.
Preguntas frecuentes
¿Se envía mi texto a un servidor?
No. Esta herramienta está marcada como "client": cada conversión se ejecuta en la pestaña de tu navegador y no se transmite nada.
¿Qué convención uso y para qué?
Sigue al lenguaje, no a tu preferencia: cada ecosistema tiene una convención y pelearse con ella hace que tu código parezca extranjero. camelCase para variables de JavaScript y Java, PascalCase para clases y componentes, snake_case para Python y columnas de base de datos, kebab-case para URLs y CSS, CONSTANT_CASE para constantes y variables de entorno. El único sitio donde pensar en vez de seguir son las URLs, donde kebab-case no es solo convención: los guiones bajos son más difíciles de ver bajo el subrayado de un enlace.
¿Por qué mi palabra alemana ha cambiado de ortografía?
Has puesto en mayúsculas una ß. Se convirtió en SS, y las minúsculas devolvieron ss en lugar de ß, porque la información se perdió en el primer paso. No es que esta herramienta sea descuidada: es lo que Unicode especifica, y toda implementación correcta hace lo mismo. Si necesitas el original, conserva el original; no lo reconstruyas desde una copia en mayúsculas.
¿Son seguras las mayúsculas para comparar dos cadenas?
No de forma fiable. Más allá del problema turco de arriba, hay caracteres cuyas formas mayúscula y minúscula no hacen el viaje completo, así que dos cadenas pueden coincidir en mayúsculas siendo genuinamente distintas, y viceversa. Para comparar, usa un plegado de caja independiente de la configuración regional: en JavaScript, localeCompare con sensitivity en "base" o "accent" suele ser lo que realmente quieres.
¿Por qué el sentence case falla con los nombres?
Porque el sentence case pone en minúsculas todo después del primer carácter, y no tiene forma de saber que París es un sitio. De "JUAN FUE A PARÍS" obtienes "Juan fue a parís". Recuperar los nombres propios requiere un diccionario y, en los casos ambiguos, un humano. Si el texto te llegó gritado en mayúsculas, el sentence case te lleva casi hasta el final y los nombres necesitan una pasada a ojo.