Estoy tratando de entender cómo decodificar un archivo que Spotify deja en mi sistema.
El archivo en cuestión se llama context_player_state_restore y se encuentra en /Users/<myuser>/Library/Application Support/Spotify/PersistentCache/ , por lo que obviamente la expectativa es que su estructura (y ahora la codificación probable) puede cambiar sin previo aviso.
La aplicación Spotify actualiza ese archivo a intervalos de tiempo regulares con la canción que se está reproduciendo actualmente, el contexto actual (por ejemplo, la lista de reproducción que se está reproduciendo actualmente) y otras cosas útiles como el historial de las pistas reproducidas.
Quiero analizar la información en ese archivo para una aplicación que estoy creando. (Puedo usar la API de Spotify para algunos de estos datos, pero el archivo local contiene más información útil, es inmediato (sin retrasos en las llamadas a la API) y puedo reaccionar ante cualquier cambio en él).
Hasta hace poco, ese archivo era un archivo JSON UTF-8 y podía analizarse con JSON.parse(data) .
Recientemente, sin embargo, Spotify ha cambiado esa codificación JSON/UTF-8.
Actualmente, abrir ese archivo con vscode (con codificación UTF-8) devuelve algo de texto legible, lo que indica que parte de la estructura JSON se ha mantenido, pero también muestra una gran cantidad de texto ilegible: los extraños signos de interrogación �� y varios UTF caracteres que no pertenecen, por ejemplo, Ω .
En resumen, me gustaría entender:
Enlace esencial al volcado de archivos visto por vscode
Descarga de archivo de Google Drive
Enlace esencial al hexdump del archivo (obtenido con hexdump -C context_player_state_restore > context_player_state_restore.hexdump )
Con respecto a su pregunta
qué codificación está usando Spotify ahora para este archivo
Creo que es la codificación utilizada por Google Protocol Buffers . Esa página da el ejemplo de la cadena "testing" codificada como 12 07 [74 65 73 74 69 6e 67] , y este patrón "0x12 seguido de la longitud de la cadena seguido de la codificación UTF-8 de la cadena" aparece en su context_player_state_restore expediente.
Si conoce el archivo .proto correspondiente, puede decodificar context_player_state_restore con el paquete protobufjs .
"Quiero analizar la información en ese archivo para una aplicación que estoy creando...
¿Es posible decodificar el archivo a JSON (o un formato similar) para que pueda analizarse fácilmente?
El formato parece bastante fácil de aplicar ingeniería inversa. Simplemente use su editor hexadecimal para notar patrones.
Por ejemplo, la mayoría de las entradas parecen seguir este formato:
[Length in 1 byte] --> [Content (by Length)] --> [END/Delimiter is sometimes byte 0x12]
Mirando los bytes proporcionados...
(1) Bytes iniciales...
Los primeros 17 bytes son 31 36 35 39 33 36 33 38 33 36 31 35 33 23 08 0F 12
El TAMAÑO aquí está en realidad en el byte final: 0x0F , que es 15 .
Sospecho que el byte final (hacia) : 0x23 (que es # ) es en sí mismo un delimitador para marcar algún punto final.
Al seleccionar todos los bytes desde el inicio del archivo hasta este delimitador # , obtenemos 31 36 35 39 33 36 33 38 33 36 31 35 33
Lo que hace 1659363836153 , que en sí mismo es una marca de tiempo UNIX :
GMT: Mon Aug 01 2022 14:23:56 GMT+0000 ¿Quizás el archivo se actualizó 5 minutos antes de que su pregunta se publicara aquí? es decir : asked Aug 1 at 14:29 .
Después de la marca de tiempo de UNIX, sigue el byte delimitador 0x23 , seguido de un 0x08 desconocido , seguido de un byte de TAMAÑO de 0x0F . (2) Comienza el análisis... La siguiente fila (posición de bytes 16 en adelante) tiene el patrón ya descrito de:
[Length in 1 byte] --> [Content (by Length)] --> [END/Delimiter is byte 0x12]
Las entradas comienzan con 0x0A o 0x12 (donde 0x12 generalmente significa entrada de texto como "falso" o similar).
(3) Estructura de archivos
El archivo parece tener datos en este orden:
Luego, en la ubicación UTF-8: spotify.player.proto.GlobalNode
Sin embargo, GlobalNode viene después de la "configuración del jugador" mencionada anteriormente, que tiene esta configuración de ejemplo (no todos los elementos incluidos):
Donde spotify es una clave y el player sería una subentrada (hijo) en un JSON.
spotify -> player -> proto -> PlayQueueNode audio -> episode -> speed -> automix video -> -> subtitles_cc -> subtitles player -> banned -> tracks -> context_tracks -> albums -> artistsEs posible que Spotify simplemente haya cambiado las codificaciones, o que estén ofuscando los datos intencionalmente. Intentaría leer como un archivo ISO-8859-1, ya que los he visto confundidos con UTF-8 en la naturaleza con cierta frecuencia. Si eso no funciona, intente leer los bytes del encabezado y los bytes de la lista de materiales (si está presente) con un editor hexadecimal y vea si puede deducir la codificación de esa manera. Este es un buen editor hexadecimal para VSCode.
Los primeros bytes de un archivo generalmente indican su codificación. Hay tablas útiles aquí y aquí . Sin embargo, incluso leyendo el encabezado , nunca puede estar seguro de qué codificación está usando realmente un archivo .
Por ejemplo, un archivo con los primeros tres bytes 0xEF,0xBB,0xBF es probablemente un archivo codificado en UTF-8. Sin embargo, podría ser un archivo ISO-8859-1 que comienza con los caracteres  . O podría ser un tipo de archivo completamente diferente.
Los primeros bytes también pueden incluir marcas de orden de bytes (BOM) .