Sobre la base de la especificación, aquí hay algo de código en Java que está probado y funciona:
public static String escape(String s){
if (s == null) return s;
int len = s.length();
StringBuilder sb = new StringBuilder(len);
for (int i = 0; i < len; i++){
char c = s.charAt(i);
if (c >= 0x20 && c < 0x80){
if (c == '\\' || c == '{' || c == '}'){
sb.append('\\');
}
sb.append(c);
}
else if (c < 0x20 || (c >= 0x80 && c <= 0xFF)){
sb.append("\'");
sb.append(Integer.toHexString(c));
}else{
sb.append("\\u");
sb.append((short)c);
sb.append("??");//two bytes ignored
}
}
return sb.toString();
}
Lo importante es que necesita agregar 2 caracteres (cerca del carácter Unicode o simplemente usar? En su lugar) después de descifrar el código. porque el Unicode ocupa 2 bytes.
También la especificación dice que debe usar un valor negativo si el código es mayor que 32767, pero en mi prueba, está bien si no usa un valor negativo.
Aquí está la especificación:
\ uN Esta palabra clave representa un solo carácter Unicode que no tiene representación ANSI equivalente basado en la página actual de códigos ANSI. N representa el valor del carácter Unicode expresado como un número decimal. Esta palabra clave es seguida inmediatamente por caracteres equivalentes en representación ANSI. De esta forma, los lectores antiguos ignorarán la palabra clave \ uN y elegirán la representación ANSI correctamente. Cuando se encuentra esta palabra clave, el lector debe ignorar los siguientes N caracteres, donde N corresponde al último valor de \ ucN encontrado.
Al igual que con todas las palabras clave RTF, puede estar presente un espacio de terminación de palabra clave (antes de los caracteres ANSI) que no se cuenta en los caracteres para omitir. Aunque es probable que esto no ocurra (o se recomiende), una palabra clave \ bin, su argumento y los datos binarios que siguen se consideran un solo carácter para saltarse los objetivos. Si se encuentra un carácter delimitador de alcance RTF (es decir, un corsé de apertura o cierre) mientras se escanean datos que se pueden omitir, se considera que los datos que se pueden omitir finalizan antes que el delimitador. Esto hace posible que un lector realice una recuperación de error rudimentaria. Para incluir un delimitador RTF en datos que se pueden omitir, se debe representar utilizando el símbolo de control apropiado (es decir, escapado con una barra diagonal inversa) como en texto sin formato. Cualquier palabra o símbolo de control RTF se considera un solo carácter a los efectos de contar los caracteres que se pueden omitir.
Un escritor RTF, cuando encuentra un carácter Unicode sin el correspondiente carácter ANSI, debe dar como resultado \ uN seguido de la mejor representación ANSI que pueda gestionar. Además, si el carácter Unicode se traduce en una secuencia de caracteres ANSI con un recuento de bytes que difiere del Conteo de bytes de caracteres Unicode actual, debe emitir la palabra clave \ ucN antes de la palabra clave \ uN para notificar al lector del cambio.
Las palabras de control RTF generalmente aceptan números de 16 bits con signo como argumentos. Por esta razón, los valores Unicode mayores que 32767 deben expresarse como número negativo
hmmmm, punto muy interesante.Si eso es cierto, entonces, probablemente haya un error en alguna parte de mi lógica ... y la respuesta de Ian Kemp tiene mucho más sentido ... Seguiré buscando en Google – Emir
¡Gracias, por ejemplo, funciona! – Emir