Conversor de mayúsculas

Una sola división de palabras, diez formas de escritura

Cambiar las mayúsculas de un texto parece lo más sencillo que puede hacer un programa, y es el origen de un número sorprendente de errores reales. Parte de la razón es que «mayúsculas y minúsculas» son en realidad dos problemas distintos bajo un mismo nombre. Pasar un texto a UPPERCASE o a lowercase es una correspondencia carácter por carácter definida por Unicode. Pasarlo a camelCase o a snake_case es otra cosa: primero hay que decidir dónde están las palabras y solo después recomponer y unir. Esta herramienta hace las dos cosas, muestra todos los resultados a la vez y, sobre todo, indica cuáles de esas respuestas dependen de un ajuste de idioma.

Las seis formas de programación salen todas de la misma división de palabras, así que nunca pueden contradecirse entre sí. Estos son sus límites:

• Una minúscula seguida de una mayúscula inicia una palabra nueva, que es lo que convierte fooBar en foo y Bar.
• Una secuencia de mayúsculas termina donde empieza la palabra siguiente, es decir, en la última mayúscula antes de una minúscula. XMLHttpRequest da XML, Http y Request; IOError da IO y Error.
• Un dígito seguido de una mayúscula inicia una palabra nueva, así que html5Parser da html5 y Parser.
• Todo lo que no sea letra, dígito o marca combinante separa palabras: espacios, guiones bajos, guiones, puntos y signos de puntuación.

Por lo demás, los dígitos siguen pegados a la palabra que los precede, y por eso utf8 y address2 pasan enteros. Es una divergencia deliberada respecto de lodash, cuyo divisor trata cada secuencia de dígitos como una palabra propia y convierte utf8 en utf_8: técnicamente coherente, pero no lo que quiso decir nadie al nombrar una variable.

La división está escrita con propiedades de Unicode y no con una clase de caracteres ASCII, así que no se limita al inglés. Un identificador en cirílico se divide en sus límites de mayúsculas igual que uno latino. Una escritura que no distingue mayúsculas — hebreo, árabe, chino, japonés, coreano — no tiene esos límites que encontrar, de modo que sus palabras se dividen solo por separadores, y esa es la respuesta correcta, no una limitación.

Siglas: dos respuestas correctas

Una vez que XMLHttpRequest se ha dividido en XML, Http y Request, recomponerlo como PascalCase plantea una pregunta sin una única respuesta correcta. Si se recompone cada palabra sale XmlHttpRequest, que es lo que produce lodash y lo que pide la guía de estilo de Google para Java: tratar la sigla como una palabra normal para que los límites sigan visibles en nombres como ParseXmlDocument. Si se conserva la secuencia de mayúsculas sale XMLHttpRequest, que es el nombre real de la API del navegador y la convención que siguen gran parte del DOM y buena parte de ‎.NET.

Ambas se usan en bases de código reales, así que la herramienta ofrece las dos y recompone por defecto. La opción solo afecta a camelCase y PascalCase: las demás formas recomponen la palabra entera de todos modos, así que XMLHttpRequest da xml_http_request y XML_HTTP_REQUEST en cualquier caso.

Un detalle está fijado y no se elige: la primera palabra de un nombre en camelCase siempre pasa entera a minúsculas, incluso si es una sigla. Conservarla daría PascalCase, y conservarla a medias daría xMLHttpRequest, una forma que ninguna guía de estilo recomienda y con la que tropieza cualquier lector. Por eso XMLHttpRequest da xmlHttpRequest con la opción activada o no, mientras que parseXMLDocument conserva su sigla intermedia cuando así se pide.

La i turca y por qué el idioma es una elección

JavaScript tiene dos métodos para pasar a mayúsculas, y la diferencia entre ellos ha tumbado sistemas en producción. El método toUpperCase aplica la correspondencia de Unicode independiente del idioma: la letra i pasa a I. El método toLocaleUpperCase aplica las reglas de un idioma concreto, y en turco y azerí la mayúscula de i es İ, la mayúscula con punto, porque esos alfabetos tienen además una ı sin punto cuya mayúscula es I. Pase a mayúsculas la entrada de un usuario turco con su propio idioma, compárela con una palabra clave de protocolo y la comparación fallará por un carácter casi idéntico.

Es el error de internacionalización más común en el tratamiento de cadenas y resulta invisible hasta que le ocurre a uno. Por eso esta herramienta nunca supone nada. Su valor por defecto es la correspondencia independiente del idioma, que es la que necesitan los identificadores, los tokens de protocolo, las cabeceras HTTP y las claves de una base de datos. Elegir un idioma cambia a sus reglas, y siempre que esa elección modifica un resultado, la herramienta muestra al lado la respuesta independiente del idioma, para que se vea exactamente qué ha hecho el idioma.

'i'.toUpperCase()             // 'I'
'i'.toLocaleUpperCase('tr')   // 'İ'  dotted capital
'I'.toLocaleLowerCase('tr')   // 'ı'  dotless lowercase
'ISTANBUL'.toLocaleLowerCase('tr')  // 'ıstanbul'

Otros tres idiomas cambian la respuesta, y la herramienta los ofrece todos. El lituano conserva el punto sobre la i al pasar a minúscula una mayúscula que lleva otro acento, de modo que Ì da una i seguida de un punto combinante y un acento grave combinante, y no la única ì precompuesta. El griego elimina el tonos al pasar a mayúsculas, así que άνθρωπος da ΑΝΘΡΩΠΟΣ y no ΆΝΘΡΩΠΟΣ, porque el griego no escribe el acento sobre las mayúsculas. El azerí comparte con el turco la i con punto y sin él.

Dos casos famosos no son reglas de idioma, y conviene saber cuál es cuál. La ß alemana pasa a SS en todos los idiomas, porque es una regla SpecialCasing de Unicode y no una regla alemana, que es también la razón de que la correspondencia no sea reversible: SS vuelve a ss. Y una sigma griega al final de palabra pasa a la forma final ς y no a σ, en todas partes: eso es una condición contextual sobre la posición del carácter, no un ajuste de idioma. Ambos se ven en esta herramienta sin elegir ningún idioma.

Aquí Title case y Sentence case son mecánicos

Title Case en esta herramienta pone en mayúscula la primera letra de cada palabra y en minúscula el resto. Sentence case pone en mayúscula la primera letra del texto y la de cada frase posterior, entendiendo que una frase termina en punto, exclamación, interrogación o puntos suspensivos seguidos de un espacio. Las dos pasan primero la entrada a minúsculas, que es lo que las hace útiles con un texto que llegó A GRITOS.

Son reglas deliberadamente mecánicas, y vale la pena explicar la alternativa. Las guías de estilo inglesas definen el título por qué palabras cortas quedan en minúscula, y discrepan entre sí sobre la lista, sobre si se capitaliza la palabra que sigue a dos puntos y sobre las preposiciones de cuatro letras o más. Aplicar una de ellas aquí sería enviar convenciones periodísticas estadounidenses a lectores que escriben en hebreo, japonés o turco, donde el concepto no se traslada en absoluto. Capitalizar cada palabra es previsible, explicable en cualquier idioma y fácil de ajustar a mano después.

La condición del espacio en Sentence case es lo que impide que 3.5 metres se convierta en 3.5 Metres, ya que allí el punto va seguido de un dígito. No resuelve las abreviaturas: e.g. this sigue iniciando una frase falsa, porque saber que «e.g.» no es un final de frase exige una lista de abreviaturas de ese idioma. Un apóstrofo dentro de una palabra tampoco inicia otra, así que it's se capitaliza una vez y da It's y no It'S.

Ordenar: orden alfabético u orden de bytes

Las utilidades de líneas recortan, eliminan duplicados, ordenan, invierten y numeran, y el orden plantea la cuestión del idioma por segunda vez. El orden alfabético es una propiedad de un idioma, no de Unicode. El alemán coloca ä junto a a: a, ä, z. El sueco la trata como una letra distinta al final del alfabeto: a, z, ä. Ambos son correctos en su país, y la herramienta usa el idioma que se haya elegido arriba en la página.

La otra opción es el orden por punto de código, que es lo que se quiere cuando la respuesta debe coincidir con otra cosa. Comparar por punto de código es el orden de bytes en UTF-8, así que reproduce exactamente lo que producen LC_ALL=C sort, git y la comparación de cadenas por defecto de la mayoría de los lenguajes: todas las mayúsculas antes que todas las minúsculas, de modo que B va antes que a. Elíjalo cuando compare con la salida de una herramienta; elija la ordenación por idioma cuando la lista la vaya a leer una persona.

El orden numérico natural — item2 antes que item10 y no después — es una función de la ordenación por idioma, así que solo está disponible con la regla alfabética. El orden de bytes no tiene el concepto de número dentro de una cadena, ni lo tiene la ordenación que imita, de modo que ofrecer ambos juntos prometería algo que la salida no podría cumplir.

Las operaciones se ejecutan en un orden fijo, y ese orden importa. El recorte ocurre antes de eliminar duplicados, así que dos líneas que solo se diferenciaban en un espacio final se reconocen como la misma. La ordenación ocurre antes de la inversión, así que invertir siempre significa «invierte lo que estoy viendo». Se informa tanto del número de líneas vacías como del de duplicados eliminados, porque un recuento silencioso es la forma de no darse cuenta de que la lista no era lo que se creía.

Dónde se ejecuta

Todo ocurre en su navegador. Las correspondencias de mayúsculas provienen de la propia implementación de Unicode del motor de JavaScript y la ordenación de Intl.Collator, así que las respuestas coinciden con el entorno de ejecución que realmente procesará sus cadenas y no con una tabla que alguien copió hace años. Nada de lo que pegue se sube, se guarda ni se registra, lo que hace segura la herramienta con nombres, líneas de registro y cualquier otra cosa que prefiera no enviar a un servidor solo para cambiar sus mayúsculas.