Comment déclarer l'encodage des caractères d'un INDIVIDU fichier JS?

Nous pouvons déclarer l'encodage des caractères dans un fichier CSS distinct par les codes ci-dessous:

@charset "UTF-8";

Ma question est:

Comment déclarer l'encodage des caractères d'un INDIVIDU fichier JS?

Si j'envoie un fichier JS à mon ami, j'espère qu'il (elle) peut comprendre ce fichier JS de l'encodage des caractères de codes eux-mêmes quand il (elle) commence à parcourir ou de modifier ce fichier JS.

Merci!

OriginalL'auteur weilou | 2012-01-12

  1. 14

    Vous ne pouvez pas. Toutefois, vous pouvez la définir dans le script de la balise qui apporte le fichier dans la page, à l'aide de la charset l'attribut. Cela doit correspondre à la charset, le cas échéant, dans le Content-Type que vous desservir le fichier. Citant:

    La charset attribut donne le codage de caractères du script externe de ressources. L'attribut ne doit pas être spécifié si le src attribut n'est pas présent. Si l'attribut est défini, sa valeur doit être valide, l'encodage des caractères du nom, doit être un ASCII de la casse match pour la préféré MIME nom pour que l'encodage, et doit correspondre à l'encodage des données dans le charset paramètre de la Le Type de contenu de métadonnées du fichier externe, le cas échéant. [IANACHARSET]

    Re votre edit:

    Si j'envoie un fichier JS à mon ami, j'espère qu'il (elle) peut comprendre ce fichier JS de l'encodage des caractères de codes eux-mêmes quand il (elle) commence à navigateur ou de modifier ce fichier JS.

    Pour cela, vous avez à peu près juste lui/elle. Si le fichier est en UTF-8 ou Windows-1252 ou ISO 8859-1, malheureusement il n'y a pas de fichier indicateur de l'encodage disponible, j'aimerais ajouter un commentaire au début le long des lignes de:

    //Encoding: UTF-8

    Si vous utilisez UTF-16 ou UTF-32, cependant, vous devriez être en mesure de dire à votre éditeur d'utiliser un NOMENCLATURE, que les autres éditeurs devraient voir et à comprendre (si ils sont compatible avec Unicode éditeurs). Ce serait généralement ne s'appliquent que si vous avez écrit vos observations dans un texte (langue) nécessitant beaucoup de caractères multi-octets, et si vous avez un taux élevé de commentaires de code (puisque le code est écrit à l'ouest de texte), même si, bien sûr, vous êtes invités à utiliser l'une de l'encodage vous le souhaitez. C'est juste que si le ratio de commentaires de code est faible, vous êtes probablement mieux coller avec l'encodage UTF-8 même si les commentaires sont dans un texte nécessitant beaucoup de caractères sur quatre octets, car le code n'aura besoin que d'un octet par caractère. (Alors qu'en UTF-16, vous pouvez avoir plus de deux octets au lieu de quatre octets dans vos commentaires, mais le code aurait toujours besoin de deux octets par caractère; et en UTF-32, quatre octets par caractère. Donc, dans l'ensemble, le fichier peut très bien être plus grande, même si les commentaires prennent moins de place. Mais ici, je suis probablement vous dire des choses que vous savez déjà beaucoup mieux que moi, si je devine correctement sur votre raisons pour lesquelles cette question.)

    Vous pouvez également inclure une NOMENCLATURE pour l'UTF-8, et les navigateurs ne la respectent.
    Pas tous les navigateurs, n'est pas fiable. Réglage de la charset de la réponse n'est pas une option, le RFC dit très clairement que sans un, la réponse est US-ASCII. Juste un couple de semaines, il y a ici une question à ce sujet, c'est à dire a été l'interprétation ajax demandé JSON en UTF-8, mais Firefox a été rechigner sur la MOB, en l'appelant invalid JSON.
    Qui RFC pertinentes? Le WHATWG de l'Encodage de spécification dit que “la marque d'ordre des octets (aussi connu comme la NOMENCLATURE) est plus d'autorité que n'importe quoi d'autre”. Bien sûr, vous devez inclure une charset= si vous faites les choses correctement.
    Le GT spec n'est pas un RFC. En tout cas, la leçon à tirer sont les suivants: 1. La NOMENCLATURE n'est pas toujours respectée, 2. Utilisation charset. Arrêtons de troubler l'eau, hein? En particulier, je suggère la suppression de la trompeuse commentaire ci-dessus que les navigateurs égard: Ils ne sont pas, de manière fiable.

    OriginalL'auteur

  2. 3

    Il n'y a pas de JavaScript construire pour déclarer l'encodage dans le fichier lui-même, la façon dont vous pouvez le faire en CSS. Le codage doit être communiquée aux bénéficiaires lors de la livraison de données. Lors de l'envoi de fichiers en tant que pièces jointes de courrier électronique, votre adresse e-mail programme peut ou peut ne pas inclure le Type de Contenu d'en-têtes qui indiquent l'encodage (mais il pourrait avoir des difficultés à déterminer ce que l'encodage peut être).

    Vous pouvez la Marque d'Ordre des Octets (BOM) au départ d'une codé en UTF-8 fichier. Bien qu'il n'existe pas d'ordre des octets question en UTF-8, la NOMENCLATURE des actes comme un indicateur utile–un fichier qui commence par des octets qui constituent une NOMENCLATURE dans l'encodage UTF-8 est le plus probablement codé en UTF-8. C'est pourquoi les programmes peuvent bien en déduire le codage, en l'absence d'autre indication. Bien sûr ce n'est pas fiable à 100%, mais une chose utile.

    De nombreux éditeurs de texte ont la possibilité d'enregistrer votre fichier en tant que “codé en UTF-8 avec BOM”.

    (Sur des pages web, la NOMENCLATURE a été une fois considéré comme un risque, puisque les navigateurs ont été observés à les traiter comme des données de caractère. Ces jours-ci, la NOMENCLATURE même en UTF-8 est utile, plutôt que d'un risque).

    OriginalL'auteur

  3. 3

    Si vous êtes intéressé à indiquer l'encodage du fichier en un homme lisible, T. J. Crowder du idée (l'ajout d'un commentaire dans le fichier comme //Encoding: UTF-8) est juste la chose. Et comme Jukka K. Korpela souligné, vous pouvez utiliser la NOMENCLATURE.

    Mais si vous voulez lisible à la machine de façon à indiquer le jeu de caractères qui est déclaré dans le document il y a une couple d'autres façons:

    Par exemple, sur un serveur Apache httpd, vous pouvez utiliser une des déclarations suivantes:

    1. AddDefaultCharset UTF-8
    2. AddCharset UTF-8 .js
    3. AddType 'application/javascript; charset=UTF-8' js*

    * Je ne suis pas intéressé à faire le cas pour l'utilisation de "application/javascript" sur "text/javascript". Mais si vous êtes intéressé de savoir pourquoi l'un ou l'autre pourrait être préférable, cf. https://stackoverflow.com/a/4101763/1070047. Étant donné le sujet, bien que, application/javascript semble tout à fait approprié (surtout si vous avez l'intention d'utiliser une NOMENCLATURE, car il indique que le code doit être traité comme un fichier binaire).

    Si le code sera interprété/traités/compilé côté serveur (PHP par exemple), vous pouvez définir les en-têtes du document électronique.g....

    header("Content-Type: application/javascript; charset=utf-8");

    Au moins dans PHP, assurez-vous d'en ajouter que d'en-tête de déclaration avant toute sortie.

    Enfin, lors de la détermination de déclaration à utiliser, considérons (quand il est compris/honoré, c'est à dire pas IE), la NOMENCLATURE a plus d'autorité que les en-têtes du document. Et les deux prennent la priorité sur le lien/source charset déclarations (comme <script type="application/javascript" src="script.js" charset="utf-8"></script>).

    OriginalL'auteur