一个字元有多种编码方式,编译器或直译器须知道 网页设计中的程序中的字元编码,才能正确解读程序,得知编码方式可能是使用预设字元集、程式引数、环境或全域变数设定、在网页设计的原始码中使用魔法注解(Magic comments)等。
        有些编译器会使用作业系统预设编码,让开发者以为它能会聪明地分辨原始码档案编码为何,例如Java。如果在中文Windows中,用记事本编辑纯文字档案,预设用MS950编码;在Ubuntu使用vi编辑纯文字,预设使用UTF-8;Java原始码若含中文字串,编译器在Windows中预设使用MS950解读原始码,在Ubuntu中预设使用UTF-8。
        如果在Windows因为中文字串包括了“?”,记事本要求转存为Unicode,而存档时选“Unicode big endian”编码,编译时,也没有指定-encoding告知档案编码為UTF-16,就会出错。
        有些编译器或直译器预设网页设计的原始**使用特定字元集,通常是ASCII字元集,如果使用了范围外的字元,必须明确告知编译器或直译器档案编码为何。例如,原始码档案撰写中文而编码为UTF-8时,Ruby 1.8必须指定$KCODE为'u',或在执行直译器时,指定-Ku引数,而Ruby 1.9必须在档案开头撰写# encoding: UTF-8ython 2.x必须在档案开头撰写# -*- coding: UTF-8 -*-,Python 3.x则预设使用UTF-8字元集,网页设计的原始码档案撰写时必须使用UTF-8编码,也就不用在档案开头撰写魔法注解。
        网页设计的应用程序经常处理乱码问题,最常面对的对象之一,就是JavaScript如何处理编码问题。
        现代浏览器会假设载入的.js编码与HTML网页设计编码相同。如果.js档案与网页设计编码不同,例如网页设计编码为Big5而.js档案为UTF-8时,.js档案中ASCII范围以外的字元,就会有乱码问题。