Tag:编码

Tag (编码)'s result:

浅析各种编码(持续更新)

1.ascii (标准): 所有编码的祖先。 二进制八位一组,只能表示128个字符 表1:ascii表(来源于百度百科) Bin(二进制) Oct(八进制) Dec(十进制) Hex(十六进制) 缩写/字符 解释 0000 0000 0 0 00 NUL(null) 空字符 0000 0001 1 1 01 SOH(start of headline) 标题开始 0000 0010 2 2 02 STX (start of text) 正文开始 0000 0011 3 3 03 ETX (end of text) 正文结束 0000 0100 4 4 04 EOT (end of transmission) 传输结束 0000 0101 5 5 05 ENQ (enquiry) 请求 0000 0110 6 6 06 ACK (acknowledge) 收到通知 0000 0111 7 7 07 BEL (bell) 响铃 0000 1000 10 8 08 BS (backspace) 退格 0000 1001 11 9 09 HT (horizontal tab) 水平制表符 0000 1010 12 10 0A LF (NL line feed, new line) 换行键 0000 1011 13 11 0B VT (vertical tab) 垂直制表符 0000 1100 14 12 0C FF (NP form feed, new page) 换页键 0000 1101 15 13 0D CR (carriage return) 回车键 0000 1110 16 14 0E SO (shift out) 不用切换 0000 1111 17 15 0F SI (shift in) 启用切换 0001 0000 20 16 10 DLE (data link escape) 数据链路转义 0001 0001 21 17 11 DC1 (device control 1) 设备控制1 0001 0010 22 18 12 DC2 (device control 2) 设备控制2 0001 0011 23 19 13 DC3 (device control 3) 设备控制3 0001 0100 24 20 14 DC4 (device control 4) 设备控制4 0001 0101 25 21 15 NAK (negative acknowledge) 拒绝接收 0001 0110 26 22 16 SYN (synchronous idle) 同步空闲 0001 0111 27 23 17 ETB (end of trans. block) 结束传输块 0001 1000 30 24 18 CAN (cancel) 取消 0001 1001 31 25 19 EM (end of medium) 媒介结束 0001 1010 32 26 1A SUB (substitute)……

PHP+MYSQL中文乱码解决历程

问题描述: 1.php输出mysql里的中文数据出现乱码。 2.mysql存储中文数据乱码。 ******************************************* 乱码问题一般就是编码不统一,只要把各部分的编码统一就ok了,但是就是各部分编码统一很烦人,写php时就遇到上述问题,记录一下解决过程,供大家参考。 这里以统一utf-8编码为例: 1.网页显示编码声明为utf-8:<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ /> 2.保存的文件用utf-8编码:另存为-utf-8-replace 3.thinkphp的配置 ‘db-charset’ => ‘utf8’ 4,数据库编码改为utf8:mysql>alter database <数据库名> character set utf8; 5.数据库表名改为utf8:mysql>alter table <表名> character set utf8; (最好在创建库和表就设为utf8,不然可能还要改字段的编码) 首先保证上述5点编码统一! mysql> show variables like ‘character_set_database’;查看数据库编码 mysql> show create table <表名>;查看数据表编码 都是utf8没问题 但是看php输出的中文数据一直是乱码,看了网上的资料才发现cmd的编码是gbk,而我的中文数据是从cmd直接insert into的(在cmd中看正常不乱码),所以还是乱码,接着我从php添加中文数据,输出乱码问题解决! 由此引发新问题,当我在cmd中查看数据库中刚刚从php添加的中文数据又乱码了,而且一个中文就变成一个?号,其余正常。 先了解下相关知识: show variables like ‘character%’;查看当前数据库的相关编码集 client    为客户端使用的字符集。 connection    为连接数据库的字符集设置类型,如果程序没有指明连接数据库使用的字符集类型则按照服务器端默认的字符集设置。 database    为数据库服务器中某个库使用的字符集设定,如果建库时没有指明,将使用服务器安装时指定的字符集设置。 results    为数据库给客户端返回时使用的字符集设定,如果没有指明,使用服务器默认的字符集。 server    为服务器安装时指定的默认字符集设定。 system    为数据库系统使用的字符集设定。 猜想可能是由于mysql用utf8存储数据,而cmd用gbk编码,所以在cmd中看就乱码了,尝试set names gbk;改变connection,results,client的编码为gbk,再次查看还是乱码(而且问号更多了……)。 现在先在my.cnf中加入: [mysql] default-character-set=utf8 [mysqld] character-set-server=utf8 把connection,result,client都先设置为utf8。 发现中文乱码更奇怪了,但是用php新增的那个中文数据倒是没乱码了,以前用cmd新增的数据就是乱码(a…)。 感觉越来越乱了。 猜测可能是php用utf8新增数据而cmd新增的数据是gbk所以乱码,尝试用php再新增一条中文数据,结果发现php输出正常,在cmd中查看也正常,所以是cmd中用gbk insert into导致乱码,在cmd中再添加一条中文数据发现中文也正常了,真是神奇。 这个中文乱码问题真的非常烦人,不过勉强解决了文章开始的两个问题,先这样吧!

常见编码方式整理(持续更新)

1. html编码 空格 < 小于号 < < > 大于号 > > & 和号 & & “ 引号 “ “ ‘ 撇号 ‘ (IE不支持) ‘ ¢ 分(cent) ¢ ¢ £ 镑(pound) £ £ ¥ 元(yen) ¥ ¥ € 欧元(euro) € € § 小节 § § © 版权(copyright) © © ® 注册商标 ® ® ™ 商标 ™ ™ × 乘号 × × ÷ 除号 ÷ ÷ ———————————————- 2. JS编码 JavascriptEncode可以采用跟HtmlEncode不同的编码方式,即使用“\”对特殊字符进行转义。也可以转换成对应的字符编码。js提供了四种字符编码的策略: 1、三个八进制数字,如果不够个数,前面补0,例如“e”编码为“\145” 2、两个十六进制数字,如果不够个数,前面补0,例如“e”编码为“\x65” 3、四个十六进制数字,如果不够个数,前面补0,例如“e”编码为“\u0065” 4、对于一些控制字符,使用特殊的C类型的转义风格(例如\n和\r) ——————————————— 3. Url编码 又叫百分号编码,是统一资源定位(URL)编码方式 如:%54%68%65%20%71%75%69%63%6b%20%62%72 ————————————— 4. Unicode编码 [Hex]: The &# [Decimal]: The \U [Hex]: \U0054\U0068\U0065 \U+ [Hex]: \U+0054\U+0068\U+0065 ———————————————————- 5. ASCII编码 ASCII编码大致可以分作三部分组成: 第一部分是:ASCII非打印控制字符 第二部分是:ASCII打印字符,也就是CTF中常用到的转换; 第三部分是:扩展ASCII打印字符 ————————————————— 6.Base64/32/16编码 ———————————————————- 7.shellcode编码 如:\x54\x68\x65\x7f\x71\x75\x69\x63\x6b\x7f\x62\x72\ ———————————————————– 8.Quoted-printable 编码 它是多用途互联网邮件扩展(MIME) 一种实现方式。有时候我们可以邮件头里面能够看到这样的编码 如:=E6=95=8F=E6=8D=B7=E7=9A=84=E6=A3=95=E8=89=B2=E7=8B=90=E7=8B=B8=E8=B7=B3=E8 ———————————————— 9.XXencode编码: XXencode将输入文本以每三个字节为单位进行编码。如果最后剩下的资料少于三个字节,不够的部份用零补齐。 它所选择的可打印字符是:+- ———————————————- 11.Escape/Unescape编码: 又叫%u编码,采用UTF-16BE模式, Escape编码/加密,就是字符对应UTF-16 16进制表示方式前面加%u。Unescape解码/解密,就是去掉”%u”后,将16进制字符还原后,由utf-16转码到自己目标字符。如:字符 “中”,UTF-16BE是:“6d93”,因此Escape是“%u6d93”。 如:%u0054%u0068%u0065 ———————————————–

(转)深入理解浏览器解析机制和XSS向量编码(附LSA对题目的解答)

本文转自 安全客:http://bobao.360.cn/learning/detail/292.html (译者注:由于某些词汇翻译成中文后很生硬,因此把相应的英文标注在其后以便理解。这篇文章讲的内容很基础,同时也很重要,希望对大家有所帮助。) 这篇文章将要深入理解HTML、URL和JavaScript的规范细则和解析器,以及在解析一段XSS脚本时他们之间有着怎样的差别。这些内容对读者的难易程度取决于读者对HTML规范和浏览器解析的知识是否充足。当然,我向您保证这篇文章比较长,因此请准备一小时或两小时来从中获益。在主题开始之前,请花费一点时间来看看下列语句并尝试回答:这些脚本能够正确执行吗? 基础部分 <a href=”%6a%61%76%61%73%63%72%69%70%74:%61%6c%65%72%74%28%31%29″></a> URL 编码 “javascript:alert(1)” <a href=”&#x6a;&#x61;&#x76;&#x61;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;:%61%6c%65%72%74%28%32%29″> HTML字符实体编码 “javascript” 和 URL 编码 “alert(2)” <a href=”javascript%3aalert(3)”></a> URL 编码 “:” <div>&#60;img src=x onerror=alert(4)&#62;</div> HTML字符实体编码 < 和 > <textarea>&#60;script&#62;alert(5)&#60;/script&#62;</textarea> HTML字符实体编码 < 和 > <textarea><script>alert(6)</script></textarea>   高级部分 <button onclick=”confirm(‘7&#39;);”>Button</button> HTML字符实体编码 ” ‘ ” (单引号) <button onclick=”confirm(‘8\u0027);”>Button</button> Unicode编码 ” ‘ ” (单引号) <script>&#97;&#108;&#101;&#114;&#116&#40;&#57;&#41;&#59</script> HTML字符实体编码 alert(9); <script>\u0061\u006c\u0065\u0072\u0074(10);</script> Unicode 编码 alert <script>\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0031\u0029</script> Unicode 编码 alert(11) <script>\u0061\u006c\u0065\u0072\u0074(\u0031\u0032)</script> Unicode 编码 alert 和 12 <script>alert(’13\u0027)</script> Unicode 编码 ” ‘ ” (单引号) <script>alert(’14\u000a’)</script> Unicode 编码换行符(0x0A) 额外赠送 <a href=”&#x6a;&#x61;&#x76;&#x61;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;&#x3a;&#x25;&#x35;&#x63;&#x25;&#x37;&#x35;&#x25;&#x33;&#x30;&#x25;&#x33;&#x30;&#x25;&#x33;&#x36;&#x25;&#x33;&#x31;&#x25;&#x35;&#x63;&#x25;&#x37;&#x35;&#x25;&#x33;&#x30;&#x25;&#x33;&#x30;&#x25;&#x33;&#x36;&#x25;&#x36;&#x33;&#x25;&#x35;&#x63;&#x25;&#x37;&#x35;&#x25;&#x33;&#x30;&#x25;&#x33;&#x30;&#x25;&#x33;&#x36;&#x25;&#x33;&#x35;&#x25;&#x35;&#x63;&#x25;&#x37;&#x35;&#x25;&#x33;&#x30;&#x25;&#x33;&#x30;&#x25;&#x33;&#x37;&#x25;&#x33;&#x32;&#x25;&#x35;&#x63;&#x25;&#x37;&#x35;&#x25;&#x33;&#x30;&#x25;&#x33;&#x30;&#x25;&#x33;&#x37;&#x25;&#x33;&#x34;&#x28;&#x31;&#x35;&#x29;”></a> 这些问题的答案在这里,测试页面在这里。如果你能答对大部分问题并且没有感觉困惑,看到这就停下吧。如果没有,那么余下的内容将能够很好的帮助你理解浏览器解析过程。 在解析一篇HTML文档时主要有三个处理过程:HTML解析,URL解析和JavaScript解析。每个解析器负责解码和解析HTML文档中它所对应的部分,其工作原理已经在相应的解析器规范中明确写明。 0x01  HTML解析 从XSS的角度来说,我们感兴趣的是HTML文档是如何被词法解析的,因为我们并不想让用户提供的数据最终被解析为一段可执行脚本的script标签。HTML词法解析细则在这里。HTML词法解析细则是一篇冗长的文档,这篇博文并不会覆盖它的所有内容。这篇博文只会覆盖有关文档解码如何结束,以及新token何时被创建这两个有趣的部分。 一个HTML解析器作为一个状态机,它从输入流中获取字符并按照转换规则转换到另一种状态。在解析过程中,任何时候它只要遇到一个'<‘符号(后面没有跟’/’符号)就会进入“标签开始状态(Tag open state)”。然后转变到“标签名状态(Tag name state)”,“前属性名状态(before attribute name state)”……最后进入“数据状态(Data state)”并释放当前标签的token。当解析器处于“数据状态(Data state)”时,它会继续解析,每当发现一个完整的标签,就会释放出一个token。 (译者注:词法解析是《编译原理》所涉及的内容,学习过编译原理的读者可以更好的理解“状态机”的工作原理)。 这里有三种情况可以容纳字符实体,“数据状态中的字符引用”,“RCDATA状态中的字符引用”和“属性值状态中的字符引用”。在这些状态中HTML字符实体将会从“&#…”形式解码,对应的解码字符会被放入数据缓冲区中。例如,在问题4中,“<”和“>”字符被编码为“&#60;”和“&#62;”。当解析器解析完“<div>”并处于“数据状态”时,这两个字符将会被解析。当解析器遇到“&”字符,它会知道这是“数据状态的字符引用”,因此会消耗一个字符引用(例如“&#60;”)并释放出对应字符的token。在这个例子中,对应字符指的是“<”和“>”。读者可能会想:这是不是意味着“<”和“>”的token将会被理解为标签的开始和结束,然后其中的脚本会被执行?答案是脚本并不会被执行。原因是解析器在解析这个字符引用后不会转换到“标签开始状态”。正因为如此,就不会建立新标签。因此,我们能够利用字符实体编码这个行为来转义用户输入的数据从而确保用户输入的数据只能被解析成“数据”。 (译者注:这里要解释几个概念) 字符实体(character entities) 字符实体是一个转义序列,它定义了一般无法在文本内容中输入的单个字符或符号。一个字符实体以一个&符号开始,后面跟着一个预定义的实体的名称,或是一个#符号以及字符的十进制数字。 HTML字符实体(HTML character entities) 在HTML中,某些字符是预留的。例如在HTML中不能使用“<”或“>”,这是因为浏览器可能误认为它们是标签的开始或结束。如果希望正确地显示预留字符,就需要在HTML中使用对应的字符实体。一个HTML字符实体描述如下: 需要注意的是,某些字符没有实体名称,但可以有实体编号。 字符引用(character references) 字符引用包括“字符值引用”和“字符实体引用”。在上述HTML例子中,'<‘对应的字符值引用为’&#60;’,对应的字符实体引用为‘&lt;’。字符实体引用也被叫做“实体引用”或“实体”。) 现在你大概会明白为什么我们要转义“<”、“>”、“’” (单引号)和“”” (双引号)字符了。但为什么我们还要转义“&”呢?大概 “&” 是无辜的,任何跟在“&”后面的内容仅会被解释为字符引用,这并不会开始或闭合一个标签。事实上,“&”字符并不会打断HTML级别的转义过程,但它可能会打断其他级别的转义过程。我们将在JavaScript解析的部分讨论这个问题。 这里要提一下RCDATA的概念。要了解什么是RCDATA,我们先要了解另一个概念。在HTML中有五类元素: 1.  空元素(Void elements),如<area>,<br>,<base>等等 2.  原始文本元素(Raw text elements),有<script>和<style> 3.  RCDATA元素(RCDATA elements),有<textarea>和<title> 4.  外部元素(Foreign elements),例如MathML命名空间或者SVG命名空间的元素 5.  基本元素(Normal elements),即除了以上4种元素以外的元素 五类元素的区别如下: 1.  空元素,不能容纳任何内容(因为它们没有闭合标签,没有内容能够放在开始标签和闭合标签中间)。 2.  原始文本元素,可以容纳文本。 3.  RCDATA元素,可以容纳文本和字符引用。 4.  外部元素,可以容纳文本、字符引用、CDATA段、其他元素和注释 5.  基本元素,可以容纳文本、字符引用、其他元素和注释 如果我们回头看HTML解析器的规则,其中有一种可以容纳字符引用的情况是“RCDATA状态中的字符引用”。这意味着在<textarea>和<title>标签中的字符引用会被HTML解析器解码。这里要再提醒一次,在解析这些字符引用的过程中不会进入“标签开始状态”。这样就可以解释问题5了。另外,对RCDATA有个特殊的情况。在浏览器解析RCDATA元素的过程中,解析器会进入“RCDATA状态”。在这个状态中,如果遇到“<”字符,它会转换到“RCDATA小于号状态”。如果“<”字符后没有紧跟着“/”和对应的标签名,解析器会转换回“RCDATA状态”。这意味着在RCDATA元素标签的内容中(例如<textarea>或<title>的内容中),唯一能够被解析器认做是标签的就是“</textarea>”或者“</title>”。当然,这要看开始标签是哪一个。因此,在“<textarea>”和“<title>”的内容中不会创建标签,就不会有脚本能够执行。这也就解释了为什么问题6中的脚本不会被执行。 我们来迅速看一下CDATA元素。任何在CDATA元素中的内容将不会触发解析器创建开始标签。闭合CDATA元素的标志是“]]>”序列。因此如果用户想逃出CDATA元素,就要用未经任何编码的“]]>”序列,不然是不会逃出CDATA元素的。 0x02  URL解析 URL解析器也是一个状态机模型,从输入流中进来的字符可以引导URL解析器转换到不同的状态。解析器的解析细则在这里。其中有很多有关安全或XSS转义的内容。 首先,URL资源类型必须是ASCII字母(U+0041-U+005A || U+0061-U+007A),不然就会进入“无类型”状态。例如,你不能对协议类型进行任何的编码操作,不然URL解析器会认为它无类型。这就是为什么问题1中的代码不能被执行。因为URL中被编码的“javascript”没有被解码,因此不会被URL解析器识别。该原则对协议后面的“:”(冒号)同样适用,即问题3也得到解答。然而,你可能会想到:为什么问题2中的脚本被执行了呢?如果你记得我们在HTML解析部分讨论的内容的话,是否还记得有一个情况叫做“属性值中的字符引用”,在这个情况中字符引用会被解码。我们将稍后讨论解析顺序,但在这里,HTML解析器解析了文档,创建了标签token,并且对href属性里的字符实体进行了解码。然后,当HTML解析器工作完成后,URL解析器开始解析href属性值里的链接。在这时,“javascript”协议已经被解码,它能够被URL解析器正确识别。然后URL解析器继续解析链接剩下的部分。由于是“javascript”协议,JavaScript解析器开始工作并执行这段代码,这就是为什么问题2中的代码能够被执行。 其次,URL编码过程使用UTF-8编码类型来编码每一个字符。如果你尝试着将URL链接做了其他编码类型的编码,URL解析器就可能不会正确识别。 0x03  JavaScript 解析 JavaScript解析过程与HTML解析过程有点不一样。JavaScript语言是一门内容无关语言。对应着有一份内容无关的语法来描述它。我们可以利用内容无关语法来解释JavaScript是如何解析的。ECMAScript-262细则在这里,语法文件在这里。 这里有一些与安全相关的事情:字符是如何被解码的?对一些字符进行转义是否有效? 开始之前,让我们来回到HTML解析过程中的“原始文本”元素。我故意将HTML中的一部分留到这个章节是因为它与JavaScript解析有关。所有的“script”块都属于“原始文本”元素。“script”块有个有趣的属性:在块中的字符引用并不会被解析和解码。如果你去看“脚本数据状态”的状态转换规则,就会发现没有任何规则能转移到字符引用状态。这意味着什么?这意味着问题9中的脚本并不会执行。所以如果攻击者尝试着将输入数据编码成字符实体并将其放在script块中,它将不会被执行。 那像“\uXXXX”(例如\u0000,\u000A)这样的字符呢,JavaScript会解析这些字符来执行吗?简单的说:视情况而定。具体的说就是要看被编码的序列到底是哪部分。首先,像\uXXXX一样的字符被称作Unicode转义序列。从上下文来看,你可以将转义序列放在3个部分:字符串中,标识符名称中和控制字符中。 字符串中:当Unicode转义序列存在于字符串中时,它只会被解释为正规字符,而不是单引号,双引号或者换行符这些能够打破字符串上下文的字符。这项内容清楚地写在ECMAScript中。因此,Unicode转义序列将永远不会破环字符串上下文,因为它们只能被解释成字符串常量。 ECMA-262 5.1版 6章 6节 “ECMAScript 与 JAVA 编程语言在对待Unicode转义序列时的行为不同。在Java程序中,如果Unicode转义序列\u000A出现在单行字符串注释中,它会被解释为行结束符(换行符),因此会导致接下来的Unicode字符不是注释的一部分。同样的,如果Unicode转义序列\u000A出现在Java程序的字符串常量中,它同样会被解释为行结束符(换行符),这在字符串常量中是不被允许的——如果需要在字符串常量中表示换行,需要用\n来代替\u000A。在ECMAScript程序中,出现在注释中的Unicode转义序列永远不会被解释,因此不会导致注释换行问题。同样地,ECMAScript程序中,在字符串常量中出现的Unicode转义序列会被当作字符串常量中的一个Unicode字符,并且不会被解释成有可能结束字符串常量的换行符或者引号。” 标识符名称中:当Unicode转义序列出现在标识符名称中时,它会被解码并解释为标识符名称的一部分,例如函数名,属性名等等。这可以用来解释问题10。如果我们深入研究JavaScript细则,可以看到如下内容:……