↵ Saltos de Linea y Codificacion
Convierte saltos de línea (LF / CRLF / CR), BOM, codificación de caracteres (UTF-8 / Shift-JIS / EUC-JP), indentación (tabulaciones ↔ espacios), espacios al final de línea y líneas en blanco duplicadas de una sola vez.
🔒 Sobre la privacidad
- ・Toda la conversion ocurre en tu navegador
- ・El contenido nunca se envia al servidor
- ・Sin registros, sin historial, sin base de datos
📂 Arrastra un archivo o haz clic (opcional)
Resultado
📖 Dónde se suele tropezar
Convierte de una vez los finales de línea (LF, CRLF, CR), el BOM, la codificación, la sangría y los espacios finales. Todo se ejecuta en el navegador. Los finales de línea son invisibles, así que el problema no llega cuando quieres convertirlos sino cuando no has notado que están mezclados: un diff de Git que abarca todas las líneas, un script de shell que no arranca, PHP lanzando un error inexplicable. Detrás de todo eso suele estar esto.
| Caso | Qué ocurre | Qué hacer |
|---|---|---|
| El diff de Git abarca el archivo entero | Si cambiaste una línea y aparecen todas como modificadas, casi seguro que cambiaron los finales de línea. La causa es que cada persona tiene un core.autocrlf distinto: el valor por defecto en Windows (true) convierte a CRLF al descargar y de vuelta a LF al confirmar, mientras que el de macOS y Linux (false) no hace nada. En un equipo mixto los finales se invierten en cada guardado y la revisión se vuelve imposible. Que tu editor conserve los finales del archivo que abrió o escriba siempre LF también cambia el resultado. |
Pon un .gitattributes en el repositorio con * text=auto eol=lf: a diferencia de un ajuste personal, vive en el repositorio, así que la misma regla se aplica a todos. core.autocrlf es por entorno y no sirve para alinear a un equipo. Los archivos que sí necesitan CRLF, como los batch de Windows, llevan su propia línea: *.bat text eol=crlf. Si la mezcla ya está ahí, ejecuta git add --renormalize . una vez para poner todos los archivos en línea con la regla: genera un commit enorme, así que mantenlo separado de otros cambios y fusiónalo sin revisión línea a línea. |
| Un BOM impide que algo funcione | Un BOM (marca de orden de bytes) son tres bytes invisibles al principio del archivo. En UTF-8 es innecesario, pero el Bloc de notas de Windows y otros lo añaden por defecto. El daño clásico: un BOM antes de <?php hace que esos tres bytes se emitan primero y provoca un error headers already sent; un BOM antes de #!/bin/bash impide que se reconozca el shebang y el script no se ejecuta; la mayoría de los analizadores de JSON dan error de sintaxis con él. En todos los casos la causa son tres bytes que no puedes ver, así que releer el archivo no lo revela por muchas veces que lo hagas. |
No uses BOM con UTF-8. UTF-8 no tiene ambigüedad de orden de bytes, así que el propósito original del BOM —indicar ese orden— no aplica. La única excepción es un CSV que se vaya a abrir en Excel de Windows: sin BOM, Excel en un entorno japonés lo lee como Shift-JIS y lo destroza. Ese caso único es la razón para añadirlo. Detectarlo es rápido: o bien file informa de UTF-8 Unicode (with BOM) text, o head -c 3 file | xxd devuelve efbb bf. Cuando te encuentres un archivo que inexplicablemente no funciona, mira sus tres primeros bytes antes de cuestionar su contenido: se descarta en segundos. |
| Mezclar tabuladores y espacios da error de sintaxis | Los lenguajes tratan la sangría de formas completamente distintas. Python 3 rechaza explícitamente mezclar tabuladores y espacios y lanza TabError: en pantalla son idénticos, así que una mezcla introducida al copiar y pegar es el caso más difícil de detectar. YAML no admite tabuladores en absoluto y falla siempre si sangras con uno. A la inversa, una línea de receta de Makefile debe empezar por tabulador, y usar espacios da missing separator. Parecer idénticos mientras significan cosas distintas provoca accidentes en todas las direcciones. |
Pon un .editorconfig en el repositorio y decide por extensión: la mayoría de editores lo respetan sin configuración adicional, así que la misma regla llega a todos. El valor práctico por defecto es tabuladores para Makefile y Go, espacios para el resto; en Go no hay debate porque el formateador oficial usa tabuladores. Basta con indent_style = tab bajo [Makefile] y [*.go], y indent_style = space en lo demás. Convierte en bloque los archivos ya mezclados con esta herramienta, pero deja la conversión en su propio commit, aparte de cualquier cambio funcional. Activar mostrar espacios en el editor evita que la mezcla llegue a producirse. |
Eliminar los espacios finales tiene exactamente una excepción: en Markdown, dos espacios al final de línea significan un salto. Elimínalos en bloque y los saltos que pretendías desaparecen y los párrafos se juntan. Si trabajas con Markdown, evita esa opción o revisa el renderizado después, aunque separar párrafos con líneas en blanco en lugar de fiarlo a espacios finales es más seguro de entrada. Segundo: una conversión de codificación no es reversible. Convertir UTF-8 a Shift-JIS pierde todo carácter que Shift-JIS no tenga: emoji, algunos numerales encerrados, números romanos y caracteres que parecen idénticos pero ocupan otro punto de código. Se convierten en un carácter de reemplazo o desaparecen. Guarda siempre el original con otro nombre antes de convertir: el archivo convertido no se puede deshacer. Todo en esta página se ejecuta en tu navegador, así que nada de lo que pegues se transmite.
📖 Cómo usar
-
1
Ingresa texto o archivoPega o arrastra archivo.
-
2
Elige opcionesElige todos los ajustes a la vez.
-
3
Convierte y copia o guardaCopia o descarga el resultado.
❓ Preguntas frecuentes
¿Por que falla Shift-JIS a veces?
¿Que es BOM? ¿Debo agregarlo?
¿Se sube el archivo?
🔗 Herramientas relacionadas
🐛 ¿Encontró un problema con esta herramienta?
Gratis, sin registro. Incluso solo los pasos para reproducir ayudan. Los informes van directamente al operador y se usan para corregir.
¡Gracias por tu reporte!
Tu reporte llegó al operador y se usará para mejorar.