J'utilise le Zemanta API, qui accepte jusqu'à 8 Ko de texte par appel. J'explète le texte à envoyer à Zemanta à partir de pages Web à l'aide de JavaScript, alors je recherche une fonction qui tronquera mon texte à exactement 8 kb.
Zemanta devrait faire cette troncature par elle-même (c'est-à-dire si vous l'envoyez une plus grande chaîne), mais j'ai besoin de navette sur ce texte autour d'un peu avant de faire appel à l'API, donc je souhaite garder la charge utile aussi petite que possible. .
Est-il prudent de supposer que 8 Ko de texte sont de 8192 caractères et de tronquer en conséquence? (1 octet par caractère; 1 024 caractères par ko; 8 kb = 8.192 octets / caractères) ou, est-ce inexact ou seulement véritable donné certaines circonstances?
Y a-t-il un moyen plus élégant de tronquer une chaîne en fonction de sa taille de fichier actuelle?
4 Réponses :
Non, il n'est pas sûr de supposer que 8 Ko de texte est de 8192 caractères, car dans certains codages de caractères, chaque personnage prend Plusieurs octets .
Si vous lisez les données des fichiers, vous ne pouvez pas simplement saisir les fichiers? Ou lisez-le dans des morceaux de 8kb?
Merci, Dominic - Je rassemble ce texte à partir d'un document à l'aide de la méthode de JavaScript .innertext () (plutôt qu'un fichier .txt ou quelque chose), donc je ne suis pas sûr qu'il y a un moyen de spécifier "Donnez-moi 8 Ko de données «- C'est idéalement ce que je cherche, cependant.
Comme Dominic dit, le codage de caractères est le problème - cependant si vous pouvez vraiment vous assurez que vous ne traiterez que 8 bits caractères (improbables mais possibles) ou assumer des caractères 16 bits et Limitez-vous à la moitié de l'espace disponible, c'est-à-dire 4096 caractères que vous pourriez essayer cela.
C'est une mauvaise idée de compter sur JS pour cela, car elle peut être trivialement modifiée ou ignorée et que vous avez des complications de caractères d'évacuation et de codage pour traiter par exemple. Mieux vaut utiliser JS comme filtre de première chance et utiliser le langage côté serveur que vous avez disponible (qui ouvrira également la compression).
Merci, Annakata - On dirait que les fonctions de Bobince travailleront dans mon cas. Zemanta devrait effectivement couper du texte sur la limite de 8 kb, alors je suis moins préoccupé par ce qui finit par arriver à leur API (en dehors de la conservation de la bande passante, bien sûr), car les gains de performance maximaux dans ce cas se limiteront à la limitation de au moins environ 8 Ko du côté du client.
Si vous utilisez un codage unique sur octet, oui, 8192 caractères = 8192 octets. Si vous utilisez UTF-16, 8192 caractères (*) = 4096 octets.
(en réalité 8192 points de code, qui est une chose légèrement différente face aux substituts de substitution, mais ne vous inquiétons pas pour que JavaScript ne soit pas .) P>
Si vous utilisez UTF-8, vous pouvez utiliser un truc rapide pour implémenter un encodeur / décodeur UTF-8 dans JS avec un code minimal: P>
function truncateByBytesUTF8(chars, n) {
var bytes= toBytesUTF8(chars).substring(0, n);
while (true) {
try {
return fromBytesUTF8(bytes);
} catch(e) {};
bytes= bytes.substring(0, bytes.length-1);
}
}
C'est exactement ce que je cherchais - fonctionne comme un charme! Merci, Bobince. Juste une note pour la postérité - je suis un peu dense, donc cela m'a fallu quelques minutes pour comprendre que les variables "Unicodecharacters" et "UTF8Bytes" dans vos fonctions sont juste à l'intention des sceptions de l'explication et devraient réellement faire correspondre les arguments au travail ( C'est-à-dire que les deux doivent être remplacées par "S" dans les deux fonctions plus courtes). Merci encore!
OMS! Les périls de la coupe et de la pâte, là-bas. Ta pour la prise!
Vous pouvez faire quelque chose comme celui-ci puisque Unescape est partiellement obsolète
Vous voudrez peut-être vérifier si le texte que vous avez géré concerne certains codages, par exemple. UTF-8, ASCII, etc.? Si vous êtes certain que le texte ne contient que des caractères monopy-octet, la troncature sera plus simple. Vous échangerez une certaine flexibilité. Quant à savoir si Zemanta traite 8 Ko comme 8192 octets ou 8 000 octets, pourquoi ne vous testez-vous pas vous-même?
Merci, o.k.w. Je pense que Dominic a raison que ce texte (probable UTF-8) prend potentiellement plusieurs octets par caractère, de sorte que la mesure de la base de caractère ne sera pas possible.