¿Cómo determino la codificación de archivos en OS X?

Estoy tratando de ingresar algunos caracteres UTF-8 en un archivo LaTeX en TextMate (que dice que su codificación predeterminada es UTF-8), pero LaTeX no parece entenderlos.

La ejecución cat my_file.texmuestra los caracteres correctamente en la Terminal. La ejecución ls -almuestra algo que nunca había visto antes: una "@" en la lista de archivos:

-rw-r--r--@  1 me      users      2021 Feb 11 18:05 my_file.tex

(Y sí, lo estoy usando \usepackage[utf8]{inputenc}en LaTeX).

Lo he encontrado iconv, pero eso no parece ser capaz de decirme cuál es la codificación: solo se convertirá una vez que lo descubra.

Los @medios de que el archivo tiene archivo extendido atributos asociados con él. Puedes consultarlos usando la getxattr()función.

No hay una forma definitiva de detectar la codificación de un archivo. Lea esta respuesta, explica por qué.

Hay una herramienta de línea de comandos, enca , que intenta adivinar la codificación. Quizás quieras revisarlo.

El uso de la -Iopción (que es una i mayúscula) en el comando de archivo parece mostrar la codificación del archivo.

file -I {filename}

En Mac OS X, el comando file -I(mayúscula i) le dará el juego de caracteres adecuado siempre que el archivo que está probando contenga caracteres fuera del rango ASCII básico.

Por ejemplo, si vas a Terminal y usas vi para crear un archivo, por ejemplo. vi test.txt luego inserte algunos caracteres e incluya un carácter acentuado (intente ALT-e seguido de e) luego guarde el archivo.

Escriben file -I text.txty deberías obtener un resultado como este:

test.txt: text/plain; charset=utf-8

vim -c 'execute "silent !echo " . &fileencoding | q' {filename}

alias en algún lugar de mi configuración bash como

alias vic="vim -c 'execute \"silent !echo \" . &fileencoding | q'"

así que solo escribo

vic {filename}

En mi vanilla OSX Yosemite, produce resultados más precisos que "archivo -I":

$ file -I pdfs/udocument0.pdf
pdfs/udocument0.pdf: application/pdf; charset=binary
$ vic pdfs/udocument0.pdf
latin1
$
$ file -I pdfs/t0.pdf
pdfs/t0.pdf: application/pdf; charset=us-ascii
$ vic pdfs/t0.pdf
utf-8

También puede convertir de un tipo de archivo a otro con el siguiente comando:

iconv -f original_charset -t new_charset originalfile > newfile

p.ej

iconv -f utf-16le -t utf-8 file1.txt > file2.txt

Solo usa:

file -I <filename>

Eso es.

Usar el filecomando con la --mime-encodingopción (p file --mime-encoding some_file.txt. Ej. ) En lugar de la opción -I funciona en OS X y tiene el beneficio adicional de omitir el tipo mime, "text / plain", que probablemente no le interese.

El clásico LaTeX de 8 bits está muy restringido en los caracteres UTF8 que puede usar; depende en gran medida de la codificación de la fuente que esté utilizando y de los glifos que esa fuente tenga disponibles.

Como no da un ejemplo específico, es difícil saber exactamente dónde está el problema: si está intentando usar un glifo que su fuente no tiene o si no está usando la codificación de fuente correcta en el primer sitio.

Aquí hay un ejemplo mínimo que muestra cómo se pueden usar algunos caracteres UTF8 en un documento LaTeX:

\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage{lmodern}
\usepackage[utf8]{inputenc}
\begin{document}
‘Héllø—thêrè.’
\end{document}

Es posible que tenga más suerte con la codificación [utf8x], pero tenga en cuenta que ya no es compatible y tiene algunas idiosincrasias en comparación con [utf8] (por lo que recuerdo; ha pasado un tiempo desde que lo vi). Pero si funciona, eso es todo lo que importa para ti.

El signo @ significa que el archivo tiene atributos extendidos . xattr filemuestra qué atributos tiene, también xattr -l filemuestra los valores de los atributos (que a veces pueden ser grandes; intente, por ejemplo, xattr /System/Library/Fonts/HelveLTMMver una fuente antigua que exista en la bifurcación de recursos).

Escribir file myfile.texen un terminal a veces puede indicarle la codificación y el tipo de archivo utilizando una serie de algoritmos y números mágicos. Es bastante útil, pero no confíe en que proporcione información concreta o confiable.

Un Localizable.stringsarchivo (que se encuentra en aplicaciones localizadas de Mac OS X) generalmente se informa como un archivo fuente UTF-16 C.

Synalyze It! permite comparar texto o bytes en todas las codificaciones que ofrece la biblioteca ICU . Al usar esa función, generalmente ve de inmediato qué página de códigos tiene sentido para sus datos.

Puede intentar cargar el archivo en una ventana de Firefox y luego ir a Ver - Codificación de caracteres. Debe haber una marca de verificación junto al tipo de codificación del archivo.

¿Qué LaTeX estás usando? Cuando estaba usando teTeX, tuve que descargar manualmente el paquete Unicode y agregar esto a mis archivos .tex:

% UTF-8 stuff
\usepackage[notipa]{ucs}
\usepackage[utf8x]{inputenc}
\usepackage[T1]{fontenc}

Ahora, me cambié a XeTeX desde el paquete TeXlive 2008 ( aquí ), es aún más simple:

% UTF-8 stuff
\usepackage{fontspec}
\usepackage{xunicode}

En cuanto a la detección de la codificación de un archivo, puedes jugar file(1)(pero es bastante limitado) pero, como dijo alguien más, es difícil.

Una forma de fuerza bruta para verificar la codificación podría ser simplemente verificar el archivo en un editor hexadecimal o similar. (o escriba un programa para verificar) Mire los datos binarios en el archivo. El formato UTF-8 es bastante fácil de reconocer. Todos los caracteres ASCII son bytes individuales con valores inferiores a 128 (0x80) Las secuencias multibyte siguen el patrón que se muestra en el artículo wiki.

Si puede encontrar una manera más simple de obtener un programa para verificar la codificación por usted, obviamente es un acceso directo, pero si todo lo demás falla, esto sería el truco.

Implementé el script bash a continuación, funciona para mí.

Primero intenta iconvdesde la codificación devuelta por file --mime-encodingto utf-8.

Si eso falla, pasa por todas las codificaciones y muestra la diferencia entre el archivo original y el codificado nuevamente. Se salta las codificaciones que producen una gran salida de diferencia ("grande" según lo definido por la MAX_DIFF_LINESvariable o el segundo argumento de entrada), ya que es muy probable que la codificación sea incorrecta.

Si suceden "cosas malas" como resultado del uso de este script, no me culpe. Hay una rm -fallí, así que habrá monstruos. Traté de evitar efectos adversos al usarlo en archivos con un sufijo aleatorio, pero no estoy haciendo ninguna promesa.

Probado en Darwin 15.6.0.

#!/bin/bash

if [[ $# -lt 1 ]]
then
  echo "ERROR: need one input argument: file of which the enconding is to be detected."
  exit 3
fi

if [ ! -e "$1" ]
then
  echo "ERROR: cannot find file '$1'"
  exit 3
fi

if [[ $# -ge 2 ]]
then
  MAX_DIFF_LINES=$2
else
  MAX_DIFF_LINES=10
fi


#try the easy way
ENCOD=$(file --mime-encoding $1 | awk '{print $2}')
#check if this enconding is valid
iconv -f $ENCOD -t utf-8 $1 &> /dev/null
if [ $? -eq 0 ]
then
  echo $ENCOD
  exit 0
fi

#hard way, need the user to visually check the difference between the original and re-encoded files
for i in $(iconv -l | awk '{print $1}')
do
  SINK=$1.$i.$RANDOM
  iconv -f $i -t utf-8 $1 2> /dev/null > $SINK
  if [ $? -eq 0 ]
  then
    DIFF=$(diff $1 $SINK)
    if [ ! -z "$DIFF" ] && [ $(echo "$DIFF" | wc -l) -le $MAX_DIFF_LINES ]
    then
      echo "===== $i ====="
      echo "$DIFF"
      echo "Does that make sense [N/y]"
      read $ANSWER
      if [ "$ANSWER" == "y" ] || [ "$ANSWER" == "Y" ]
      then
        echo $i
        exit 0
      fi
    fi
  fi
  #clean up re-encoded file
  rm -f $SINK
done

echo "None of the encondings worked. You're stuck."
exit 3