1

m'a donné un morceau de texte représentant HTML par exemple:Décodage une combinaison de fenêtres-1252 et cité HTML imprimable

<html>\r\n<head>\r\n<meta http-equiv=3D\"Content-Type\" content=3D\"text/html; charset=3DWindows-1=\r\n252\">\r\n<style type=3D\"text/css\" style=3D\"display:none;\"><!-- P {margin-top:0;margi=\r\nn-bottom:0;} --></style>\r\n</head>\r\n<body dir=3D\"ltr\">This should be a pound sign: =A3 and this should be a long dash: =96 \r\n</body>\r\n</html>\r\n 

de la balise HTML <meta> je peux voir que doit coder le morceau de HTML Windows-1252. J'utilise node.js pour analyser cette partie de texte avec cheerio. Cependant, le décoder avec https://github.com/mathiasbynens/windows-1252 n'aide pas: windows1252.decode(myString); rend la même chaîne d'entrée.

La raison pour laquelle je pense est que cette chaîne d'entrée est déjà codée dans le charset de la norme, mais il en fait représente un morceau codé windows-1252 de HTML (si cela fait sens?).

Vérification ces chiffres HEX étranges PREPEND par = Je peux voir les codes valides windows-1252 par exemple:

  • ce =\r\n et ce \r\n devrait représenter en quelque sorte un retour chariot dans le monde Windows,
  • =3D: HEX 3D est DEC 61 qui est un signe égal: =,
  • =96: HEX 96 est DEC 150 qui est un 'en tableau de bord' signe: (une sorte de "long symbole moins"),
  • =A3: HEX A3 ryt 163 qui est un signe dièse: £

Je n'ai pas le contrôle dans la génération de ce morceau de code HTML, mais je suis censé analyser et nettoyer redonnant £ (au lieu de =A3), etc.

maintenant, je sais que je pouvais garder un sur la carte mémoire avec les conversions, mais j'étais se demandant s'il existe déjà une solution programmatique qui couvre l'ensemble du jeu de caractères windows-1252?

Cf. cela pour toute la table de conversion: https://www.w3schools.com/charsets/ref_html_ansi.asp

Edit:

Le code HTML d'entrée provient d'une session IMAP, il semble qu'il y ait un 7bit/8bit « cité d'encodage imprimable » en cours en amont que je ne peux pas contrôler (cf https://en.wikipedia.org/wiki/Quoted-printable). En attendant, j'ai pris conscience de cet encodage supplémentaire et j'ai essayé cette bibliothèque quoted-printable (voir https://github.com/mathiasbynens/quoted-printable) sans la moindre chance.

Ce qui suit est un VCM (selon la demande):

var cheerio = require('cheerio'); 
var windows1252 = require('windows-1252'); 
var quotedPrintable = require('quoted-printable'); 

const inputString = '<html>\r\n<head>\r\n<meta http-equiv=3D\"Content-Type\" content=3D\"text/html; charset=3DWindows-1=\r\n252\">\r\n<style type=3D\"text/css\" style=3D\"display:none;\"><!-- P {margin-top:0;margi=\r\nn-bottom:0;} --></style>\r\n</head>\r\n<body dir=3D\"ltr\">This should be a pound sign: =A3 and this should be a long dash: =96 \r\n</body>\r\n</html>\r\n' 
const $ = cheerio.load(inputString, {decodeEntities: true}); 
const bodyContent = $('html body').text().trim(); 
const decodedBodyContent = windows1252.decode(bodyContent); 

console.log(`The input string: "${bodyContent}"`); 
console.log(`The output string: "${decodedBodyContent}"`); 

if (bodyContent === decodedBodyContent) { 
    console.log('The windows1252 output seems the same of as the input'); 
} 

const decodedQp = quotedPrintable.decode(bodyContent) 
console.log(`The decoded QP string: "${decodedQp}"`); 

Le script précédent est produit la sortie suivante:

The input string: "This should be a pound sign: =A3 and this should be a long dash: =96" 
The output string: "This should be a pound sign: =A3 and this should be a long dash: =96" 
The windows1252 output seems the same of as the input 
The decoded QP string: "This should be a pound sign: £ and this should be a long dash: " 

Sur ma ligne de commande je ne peux pas voir le tiret long et Je ne suis pas sûr comment je pourrais décoder correctement tous ces caractères codés =<something>?

+0

ressemble vous êtes à peu près pas de chance ici. – awd

+1

Je pense que vous devez fournir un [mcve] plus complet. Comment le texte arrive-t-il d'où qu'il soit dans votre programme en premier lieu? – Quentin

Répondre

0

Il semble que le message reçu via le protocole IMAP est fourni avec une combinaison de 2 différents encodages:

  • la chaîne réelle est codé selon le codage « cité imprimable » (https://en.wikipedia.org/wiki/Quoted-printable) parce que je pense qu'il ya un problème avec les 7 bits/cartographie 8bit lors du transport de ces informations via le canal de IMAP (une connexion de socket TCP)
  • la représentation de logique de contenu (un corps de courrier électronique) qui est HTML avec une balise <meta> avec un Windows 1252 charset

Il existe également un "problème" avec ces blocs HTML qui contiennent beaucoup de retours chariot dans la syntaxe Windows (\r\n). J'ai dû pré-traiter la chaîne pour faire face à cela, dans mon cas: supprimer ces retours chariot.

L'exemple VGM suivant doit montrer le processus de nettoyage et de validation du contenu de chaîne représentant un corps e-mail:

var quotedPrintable = require('quoted-printable'); 
var windows1252 = require('windows-1252'); 

const inputStr = 'This should be a pound sign: =A3 \r\nand this should be a long dash: =96\r\n'; 
console.log(`The original string: "${inputStr}"`); 

// 1. clean the "Windows carriage returns" (\r\n) 
const cleandStr = inputStr.replace(/\r\n/g, ''); 
console.log(`The string without carriage returns: "${cleandStr}"`); 

// 2. decode using the "quoted printable protocol" 
const decodedQp = quotedPrintable.decode(cleandStr) 
console.log(`The decoded QP string: "${decodedQp}"`); 

// 3. decode using the "windows-1252" 
const windows1252DecodedQp = windows1252.decode(decodedQp); 
console.log(`The windows1252 decoded QP string: "${windows1252DecodedQp}"`); 

Ce qui donne cette sortie:

The original string: "This should be a pound sign: =A3 
and this should be a long dash: =96 
" 
The string without carriage returns: "This should be a pound sign: =A3 and this should be a long dash: =96" 
The decoded QP string: "This should be a pound sign: £ and this should be a long dash: " 
The windows1252 decoded QP string: "This should be a pound sign: £ and this should be a long dash: –" 

Notez que le « long caractère tiret "qui est rendu différemment avant/après la phase de décodage Windows-1252. Afaik, cela n'avait rien à voir avec le codage/décodage UTF-8. J'ai été capable de comprendre l'ordre de décodage de la procédure à partir de: https://github.com/mathiasbynens/quoted-printable/issues/5

Une chose dont je ne suis pas sûr, c'est si le système d'exploitation sur lequel je lance ce code a un impact sur les jeux de caractères/encodages de fichiers ou de flux de chaînes.

Les npm paquets que j'ai utilisés sont: