额外补充:如果大家使用Tp5 上传,文件在think/File.php.大概是374行:大多数解决办法是在下面的方法转码,但会存在问题,转码后,文件是上传成功,随后就报错:
大家都知道,不同字符编码,其在内存占用的字节数不一样。如 ASCII编码字符占用1个字节,UTF-8编码的中文字符是3字节,GBK为2个字节。
其实php输出excel倒是很简单 第一: <?php header("Content-Type: application/vnd.ms-excel; charset=gb2312"); //解
在php中iconv函数库能够完成各种字符集间的转换,是php编程中不可缺少的基础函数库;但有时候iconv对于部分数据转码会无缘无故的少一些。比如在转换字符”—”到gb2312时会出错。
今天在修改论文在线的时候,遇到了iconv这个函数。学习一下 header('Content-Type: application/vnd.ms-excel;charset=UTF-8"'); $name=iconv('utf-8', 'gb2312', $data['year'].'年,第'.$data['period'].'期通信录'); header('Content-Disposition: attachment;filename="' . $name . '.xls"'); header('Cach
在以前的学习当中,比方说有一次的写采集过程中转换字符的编码的时候老是失败,转换的结果总没有完全输出,后来经过网络查询得知是iconv有一个“-”漏洞,所以我们有必要掌握PHP的另一个字符编码函数mb_convert_encoding。
在以前的学习当中,比方说有一次的写采集过程中转换字符的编码的时候老是失败,转换的结果总没有完全输出,后来经过网络查询得知是iconv有一个“-”漏洞,所以我们有必要掌握PHP的另一个字符编码函数mb_convert_encoding。 mb_convert_encoding函数为php内部多字节字符串编码转换函数,可以在有需要的使用场合(如:解决在GB2312编码环境下使用Ajax产生的中文字乱码的问题)方便进行编码转换,以解决网页乱码的问题,使用非常方便,效率非常高,几乎支持所有编码。PHP 4 >= 4
开工了,首先祝贺大家猴年大吉!早上ytkah用dedecms发布文章提示"标题不能为空",春节这段时间基本没更新文章,回来后得赶紧补回来,可一开始就碰到这问题,以ytkah喜欢钻研的精神一定要先折腾一下怎么修改。 新的一年,我们用的云服务器有进行了升级,有些设置得调整一下。 问题根源:htmlspecialchars在php5.4默认为utf8编码,gbk编码字符串经 htmlspecialchars 转义后的中文字符串为空,也就是标题为空. 解决办法:给htmlspecialchars添加EN
1、php下载原理图 2、文件下载源码: 1 <?php 2 $file_name="umiwi.apk";//需要下载的文件 3 $file_dir = "./"; //文件目录 4 $fi
大家在使用wampserver中的mysql数据库时,插入中文会显示“??”,很多小伙伴都不知道给如何做,明明在创建数据库和表时已经设置字符为UTF-8了,可插入结果还是乱码。下面我来告诉大家一下原因。
web2.0的到来,ajax逐渐成为主流,什么是ajax,ajax的开发模式,优点,使用技术。(ajax概述,ajax使用的技术,需要注意的 问题,在PHP应用ajax技术的应用)
================================================起================================================
PHP程序设计中中文编码问题曾经困扰很多人,导致这个问题的原因其实很简单,每个国家(或区域)都规定了计算机信息交换用的字符编码集,如美国的扩展 ASCII 码, 中国的 GB2312-80,日本的 JIS 等。作为该国家/区域内信息处理的基础,字符编码集起着统一编码的重要作用。字符编码集按长度分为 SBCS(单字节字符集),DBCS(双字节字符集)两大类。早期的软件(尤其是操作系统),为了解决本地字符信息的计算机处理,出现了各种本地化版本(L10N),为了区分,引进了 LANG, Codepage 等概念。但是由于各个本地字符集代码范围重叠,相互间信息交换困难;软件各个本地化版本独立维护成本较高。因此有必要将本地化工作中的共性抽取出来,作一致处理,将特别的本地化处理内容降低到最少。这也就是所谓的国际化(118N)。各种语言信息被进一步规范为 Locale 信息。处理的底层字符集变成了几乎包含了所有字形的 Unicode。
大家好,我是架构君,一个会写代码吟诗的架构师。今天说一说php截取字符串几个实用的函数,希望能够帮助大家进步!!!
什么是多字节的字符串操作呢?其实不少的同学可能都已经使用过了,但我们还是要从最基础的问题说起。
python 中的 unicode是让人很困惑、比较难以理解的问题. 这篇文章 写的比较好,utf-8是 unicode的一种实现方式,unicode、gbk、gb2312是编码字符集.
如上面代码,str\str1\str2均为字符串类型(str),给字符串操作带来较大的复杂性。
由于客户需求,需要按照汉字的首字拼音排序,项目开发中免不了数据的排序问题,排序中又免不了对中文的处理。今天分享一下如何在mysql中对中文进行排序,介绍下thinkphp连贯操作的order底层原理
网上有很多php操作excel或其他文件的类库,也做的很完善。比如无比风骚的PHPExcel,官方网站:http://www.codeplex.com/PHPExcel ,pear的Spreadsheet_Excel_Writer类等。然而我们只是用到其中一部分功能,这就会让程序显的有些臃肿。在你调用这些类库的时候,不管你是多简单的操作,他都会消耗巨大的内存,这对我们来说是很不可取的。 比如我需要一个做php导出 excel的的程序,只需要把相关的数据导出到excel表就可以了,这么简单的操作就不需
在默认情况下,也就是未自行安装新字体或者 Office 等文字处理软件的情况下,Windows 默认提供下列字体:
个人认为,对于Web前端程序员和跟HTML和CSS打交道的人来说,jQuery是有史以来最伟大的发明。jQuery的出现使Web程序员的开发效率突飞猛进,不亚于工业革命给人类生产力带来的提升。 但问题在在于,只有前端程序员可以利用jQuery的强力,他们可以用它分析HTML,根据CCS类,HTML属性,CSS规则等各种选择器来查 询、获取、操作HTML里的任何一个元素。而作为后端(服务端)程序员来说,他们同样需要分析HTML内容,从HTML中提取符合要求的HTML片段、获 取某个符合条件的属性值等。 遇到这
注意:如果是中文,php文件环境是UTF-8,GBK不需要mb_convert_encoding操作
JSP中文乱码的产生原因及解决方案在JSP的开发过程中,经常出现中文乱码的问题,可能一直困扰着大家,现在把JSP开发中遇到的中文乱码的问题及解决办法写出来供大家参考。首先需要了解一下Java中文问题的由来: Java的内核和class文件是基于unicode的,这使Java程序具有良好的跨平台性,但也带来了一些中文乱码问题的麻烦。原因主要有两方面,Java和JSP文件本身编译时产生的乱码问题和Java程序于其他媒介交互产生的乱码问题。首先Java(包括JSP)源文件中很可能包含有中文,而Java和JSP源文
<?php function getfirstchar($s0) { $fchar = ord($s0 { 0 }); if ($fchar >= ord("A") and $fchar <=
Test:什么是宽字节注入?怎么防止sql注入? 00x1 防止数字型sql注入 说到mysql宽字节注入之前要提的是php中常见的sql防护思路。 php是弱类型的语言,而弱类型的语言在开发中很容易出现数字型的注入,所以对于这方面的防御,应该要有严格的数据类型。 比如:用is_numeric()、ctype_digit()判断字符类型。或者自定义一个check_sql函数对select union关键字进行过滤。 这类的防御比较简单,但是字符型的防注入就比较麻烦了。就是要将单引号
UNICODE,GBK,UTF-8区别 简单来说,unicode,gbk和大五码就是编码的值,而utf-8,uft-16之类就是这个值的表现形式.而前面那三种编码是一兼容的,同一个汉字,那三个码值是完全不一样的.如"汉"的uncode值与gbk就是不一样的,假设uncode为a040,gbk为b030,而uft-8码,就是把那个值表现的形式.utf-8码完全只针对uncode来组织的,如果GBK要转UTF-8必须先转uncode码,再转utf-8就OK了. 详细的就见下面转的这篇文章. 谈谈Unicode编码,简要解释UCS、UTF、BMP、BOM等名词 这是一篇程序员写给程序员的趣味读物。所谓趣味是指可以比较轻松地了解一些原来不清楚的概念,增进知识,类似于打RPG游戏的升级。整理这篇文章的动机是两个问题: 问题一: 使用Windows记事本的“另存为”,可以在GBK、Unicode、Unicode big endian和UTF-8这几种编码方式间相互转换。同样是txt文件,Windows是怎样识别编码方式的呢? 我很早前就发现Unicode、Unicode big endian和UTF-8编码的txt文件的开头会多出几个字节,分别是FF、FE(Unicode),FE、FF(Unicode big endian),EF、BB、BF(UTF-8)。但这些标记是基于什么标准呢? 问题二: 最近在网上看到一个ConvertUTF.c,实现了UTF-32、UTF-16和UTF-8这三种编码方式的相互转换。对于Unicode(UCS2)、GBK、UTF-8这些编码方式,我原来就了解。但这个程序让我有些糊涂,想不起来UTF-16和UCS2有什么关系。 查了查相关资料,总算将这些问题弄清楚了,顺带也了解了一些Unicode的细节。写成一篇文章,送给有过类似疑问的朋友。本文在写作时尽量做到通俗易懂,但要求读者知道什么是字节,什么是十六进制。 0、big endian和little endian big endian和little endian是CPU处理多字节数的不同方式。例如“汉”字的Unicode编码是6C49。那么写到文件里时,究竟是将6C写在前面,还是将49写在前面?如果将6C写在前面,就是big endian。如果将49写在前面,就是little endian。 “endian”这个词出自《格列佛游记》。小人国的内战就源于吃鸡蛋时是究竟从大头(Big-Endian)敲开还是从小头(Little-Endian)敲开,由此曾发生过六次叛乱,一个皇帝送了命,另一个丢了王位。 我们一般将endian翻译成“字节序”,将big endian和little endian称作“大尾”和“小尾”。 1、字符编码、内码,顺带介绍汉字编码 字符必须编码后才能被计算机处理。计算机使用的缺省编码方式就是计算机的内码。早期的计算机使用7位的ASCII编码,为了处理汉字,程序员设计了用于简体中文的GB2312和用于繁体中文的big5。 GB2312(1980年)一共收录了7445个字符,包括6763个汉字和682个其它符号。汉字区的内码范围高字节从B0-F7,低字节从A1-FE,占用的码位是72*94=6768。其中有5个空位是D7FA-D7FE。 GB2312支持的汉字太少。1995年的汉字扩展规范GBK1.0收录了21886个符号,它分为汉字区和图形符号区。汉字区包括21003个字符。 从ASCII、GB2312到GBK,这些编码方法是向下兼容的,即同一个字符在这些方案中总是有相同的编码,后面的标准支持更多的字符。在这些编码中,英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼,GB2312、GBK都属于双字节字符集 (DBCS)。 2000年的GB18030是取代GBK1.0的正式国家标准。该标准收录了27484个汉字,同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。从汉字字汇上说,GB18030在GB13000.1的20902个汉字的基础上增加了CJK扩展A的6582个汉字(Unicode码0x3400-0x4db5),一共收录了27484个汉字。 CJK就是中日韩的意思。Unicode为了节省码位,将中日韩三国语言中的文字统一编码。GB13000.1就是ISO/IEC 10646-1的中文版,相当于Unicode 1.1。 GB18030的编码采用单字节、双字节和4字节方案。其中单字节、双字节和GBK是完全兼容的。4字节编码的码位就是收录了CJK扩展A的6582个汉字。例如:UCS的0x3400在GB18030中的编码应该是8139EF30,UCS的0x3401在GB18030中的编码应该是8139EF31。 微软提供了GB18030的升级包,但这个升级包只是提供了一
php读取excel在网上找了n多办法,没有合适的。但是也有一定的收获,就是尽量实用类,不用odbc或者csv格式读取——因为它可以跨平台。各自的优缺点在这里都不多说了。 在这里下载phpExcelReader:http://sourceforge.net/projects/phpexcelreader/ 然后可以看到有excel文件夹(很重要)、changelog.txt、example.php、example2.php、jxlrwtest.xls和README文件 不说每个文件夹的用途了,先修改exce
参考:http://www.jianshu.com/p/ff2de81e1b83 http://www.jianshu.com/p/6199b5c26725
这篇文章将是大猫《如何搞定头疼的编码》一文的一部分,当时本来想做一个完整的有关“R与编码”的笔记,没想到后来洋洋洒洒写了六七千字,估计一时半会也完成不了,所以先选出其中有意思的一节同大家分享。
在Python2.X及Python3有时经常碰到各种中文乱码的情况,这里整理了相关各种情况汇总。
在上世纪八十年代的时候,发送Email只允许使用7bits(即每个字节的8bits,最高位固定为0,只使用后面7bits)。早期的一些电脑操作系统也是基于ASCII(每字节最高位固定为0)。我们知道1字节等于8bits,对于英语国家来说,ASCII编码已经能够满足日常邮件内容。ASCII只有128种字母或符号,采用7bits足够了。但是,对于中文来说只使用7bits是远远不够的。当时已经存在GB2312字符集,每个中文汉字可以使用2字节(16bits)表示出来,GB2312总共定义了6000多个中文汉字或标点符号,足够日常使用。比如“国家”的“国”字,在GB2312中编码为0xB9FA,二进制表示为“10111001 11111010”,占据两个字节。
现在很多IP的接口api很多我例举几个常用的出来: http://int.dpool.sina.com.cn/iplookup/iplookup.php //新浪 http://ip.ws.126.
最近项目中涉及到了解析文件内容的需求,文件中全都是中文,由于这一过程中碰到的乱码问题实在过多,所以特地花时间研究了一下中文编码。本文中先介绍一下ASCII,GB2312,GBK和GB18030编码。
完整教程下载地址:http://www.armbbs.cn/forum.php?mod=viewthread&tid=86980 第52章 STM32H7的LTDC应用之点阵字体和字符编码
Python的requests库是一个非常好用的库,这应该已经是大多写过爬虫的人的共识了。它的简洁易用给我们带来很大方便。然而,它也并不是非常完美。今天我们就说说它在处理中文编码方面的不足。
这是一篇程序员写给程序员的趣味读物。所谓趣味是指可以比较轻松地了解一些原来不清楚的概念,增进知识,类似于打RPG游戏的升级。整理这篇文章的动机是两个问题:
CKEditor是一个专门使用在网页上属于开放源代码的所见即所得文字编辑器。它志于轻量化,不需要太复杂的安装步骤即可使用。它可和PHP、JavaScript、ASP、ASP.NET、ColdFusion、Java以及ABAP等不同的编程语言相结合。
1、css实现宽度是百分比的盒子为正方形 只需要保证width的百分比值和padding-bottom的百分比值一样即可 2、手机端判断是横屏还是竖屏 function checkOrient() { if (window.orientation == 0 || window.orientation == 180){ alert
字符串在Python内部的表示是unicode编码,因此,在做编码转换时,通常需要以unicode作为中间编码,即先将其他编码的字符串解码(decode)成unicode,再从unicode编码(encode)成另一种编码。
在很多项目里,或者一些应用上,我们经常需要把一些文件导入到SAP系统里,最经常我们使用的读取数据的方法就是使用GUI_UPLOAD这个FM.在这个FM中有个CODEPAGE,是用来指定代码页的. 如果我们导的是中文的话,我们经常使用的是8400.当然还有8401,8411等等. 主要介绍一下8400/8401.因为大家最常用的是8400.看8400的介绍上说,是based on GB2312-EUC版本,WINDOWS的代码页就是CP936.8401使用的就是GB18030 2000编码.那么他们的区别在哪里呢. 1、 GB2312 GB2312(1980年)一共收录了7445个字符,包括6763个汉字和682个其它符号。汉字区的内码范围高字节从B0-F7,低字节从A1-FE,占用的码位是72*94=6768。其中有5个空位是D7FA-D7FE。 在windows中的代码页是CP936 2、 GBK GBK最初是由微软对GB2312的扩展,也就是CP936字码表 (Code Page 936)的扩展(原来的CP936和GB 2312-80一模一样),最初出现于Windows 95简体中文版中,由于Windows产品的流行和在大陆广泛被使用,中华人民共和国国家有关部门将其作为技术规范。注意GBK并非国家正式标准,只是国家技术监督局标准化司、电子工业部科技与质量监督司发布的“技术规范指导性文件”。虽然 GBK收录了所有Unicode 1.1及GB 13000.1-93之中的汉字,但是编码方式与Unicode 1.1及GB 13000.1-93不同。仅仅是GB 2312到GB 13000.1-93之间的过渡方案。GBK收录了21886个符号,它分为汉字区和图形符号区。汉字区包括21003个字符。 GBK作为对GB2312的扩展,在现在的windows系统中仍然使用代码页CP936表示,但是同样的936的代码页跟一开始的936的代码页只支持GB2312编码不同,现在的936代码页支持GBK的编码,GBK同时也向下兼容GB2312编码。 3、 GB18030 2000年的GB18030取代了GBK1.0的正式国家标准。该标准收录了27484个汉字,同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。现在的PC平台必须支持GB18030,对嵌入式产品暂不作要求。所以手机、MP3一般只支持GB2312。 GB18030在windows中的代码页是CP54936。 4、 GB13000 GB13000等同于国际标准的《通用多八位编码字符集 (UCS)》 ISO10646.1,就是等同于Unicode的标准,代码页等等的都使用UTF的一套标准。 从ASCII、GB2312、GBK到GB18030,这些编码方法是向下兼容的,即同一个字符在这些方案中总是有相同的编码,后面的标准支持更多的字符。在这些编码中,英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼,GB2312、GBK到GB18030都属于双字节字符集 (DBCS)。
英文字母再加一些其他标点字符之类的也不会超过256个,用一个字节来表示一个字符就足够了(2^8 = 256)。但其他一些文字不止这么多字符,比如中文中的汉字就多达10多万个,一个字节只能表示256个字符,肯定是不够的,因此只能使用多个字节来表示一个字符。
UNICODE,GBK,UTF-8 简单来说,unicode,gbk和大五码就是编码的值,而utf-8,uft-16之类就是这个值的表现形式.而前面那三种编码是一兼容的,同一个汉字,那三个码值是完全不一样的.如"汉"的uncode值与gbk就是不一样的,假设uncode为a040,gbk为b030,而uft-8码,就是把那个值表现的形式.utf-8码完全只针对uncode来组织的,如果GBK要转UTF-8必须先转uncode码,再转utf-8就OK了. 详细的就见下面转的这篇文章. 谈谈Unicode编码,简要解释UCS、UTF、BMP、BOM等名词 这是一篇程序员写给程序员的趣味读物。所谓趣味是指可以比较轻松地了解一些原来不清楚的概念,增进知识,类似于打RPG游戏的升级。整理这篇文章的动机是两个问题: 问题一: 使用Windows记事本的“另存为”,可以在GBK、Unicode、Unicode big endian和UTF-8这几种编码方式间相互转换。同样是txt文件,Windows是怎样识别编码方式的呢? 我很早前就发现Unicode、Unicode big endian和UTF-8编码的txt文件的开头会多出几个字节,分别是FF、FE(Unicode),FE、FF(Unicode big endian),EF、BB、BF(UTF-8)。但这些标记是基于什么标准呢? 问题二: 最近在网上看到一个ConvertUTF.c,实现了UTF-32、UTF-16和UTF-8这三种编码方式的相互转换。对于Unicode(UCS2)、GBK、UTF-8这些编码方式,我原来就了解。但这个程序让我有些糊涂,想不起来UTF-16和UCS2有什么关系。 查了查相关资料,总算将这些问题弄清楚了,顺带也了解了一些Unicode的细节。写成一篇文章,送给有过类似疑问的朋友。本文在写作时尽量做到通俗易懂,但要求读者知道什么是字节,什么是十六进制。 0、big endian和little endian big endian和little endian是CPU处理多字节数的不同方式。例如“汉”字的Unicode编码是6C49。那么写到文件里时,究竟是将6C写在前面,还是将49写在前面?如果将6C写在前面,就是big endian。如果将49写在前面,就是little endian。 “endian”这个词出自《格列佛游记》。小人国的内战就源于吃鸡蛋时是究竟从大头(Big-Endian)敲开还是从小头(Little-Endian)敲开,由此曾发生过六次叛乱,一个皇帝送了命,另一个丢了王位。 我们一般将endian翻译成“字节序”,将big endian和little endian称作“大尾”和“小尾”。 1、字符编码、内码,顺带介绍汉字编码 字符必须编码后才能被计算机处理。计算机使用的缺省编码方式就是计算机的内码。早期的计算机使用7位的ASCII编码,为了处理汉字,程序员设计了用于简体中文的GB2312和用于繁体中文的big5。 GB2312(1980年)一共收录了7445个字符,包括6763个汉字和682个其它符号。汉字区的内码范围高字节从B0-F7,低字节从A1-FE,占用的码位是72*94=6768。其中有5个空位是D7FA-D7FE。 GB2312支持的汉字太少。1995年的汉字扩展规范GBK1.0收录了21886个符号,它分为汉字区和图形符号区。汉字区包括21003个字符。 从ASCII、GB2312到GBK,这些编码方法是向下兼容的,即同一个字符在这些方案中总是有相同的编码,后面的标准支持更多的字符。在这些编码中,英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼,GB2312、GBK都属于双字节字符集 (DBCS)。 2000年的GB18030是取代GBK1.0的正式国家标准。该标准收录了27484个汉字,同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。从汉字字汇上说,GB18030在GB13000.1的20902个汉字的基础上增加了CJK扩展A的6582个汉字(Unicode码0x3400-0x4db5),一共收录了27484个汉字。 CJK就是中日韩的意思。Unicode为了节省码位,将中日韩三国语言中的文字统一编码。GB13000.1就是ISO/IEC 10646-1的中文版,相当于Unicode 1.1。 GB18030的编码采用单字节、双字节和4字节方案。其中单字节、双字节和GBK是完全兼容的。4字节编码的码位就是收录了CJK扩展A的6582个汉字。例如:UCS的0x3400在GB18030中的编码应该是8139EF30,UCS的0x3401在GB18030中的编码应该是8139EF31。 微软提供了GB18030的升级包,但这个升级包只是提供了一套支
本文实例讲述了PHP CURL实现模拟登陆并上传文件操作。分享给大家供大家参考,具体如下:
最近要上个项目,其实很简单的东西,就是拼接一个url,不过url中的参数需要UrlEncode编码的,其实对我来说,这个问题很好解决,C#用HttpUtility.UrlEncode来进行编码,asp用Server.UrlEncode来进行编码。 问题解决了吗?问题刚刚开始 因为这个公用转向文件,是针对所有分站的,分站代码有.net和asp两种,文件编码格式也不一样。 头大的事情开始了。asp站的文件编码是gb2312,虽然.net的文件格式也是gb2312,但因为webconfig里设置的reque
在用ASP.NET写网上支付的接口程序时,遇到一个奇怪问题,通过表单提交过去的中文全是乱码,英文正常。而用asp程序进行测试,可以正常提交中文,asp页面中有这样的HTML代码: <meta http-equiv="Content-Type" content="text/html; charset=gb2312"> 可是将这个代码加入到ASP.NET页面中,依然解决不了问题。分析了一下,问题应该是编码引起的,对方的程序只能处理GB2312编码的页面提交过来的中文数据。难道加了上面的代码,ASP.NET却
以下就是我们php中文网总结的各种php发送邮件类库,感兴趣的朋友们可以进入网站类库下载页面下载学习。
最近做邮件收发,不同的邮件系统间可能会出现编码问题,迫使我重新回来研究一下字符的编码问题,unicode,utf-8,gb2312这些编码格式都是我们熟知的,default 编码格式是哪一种呢?我们用实例来看看: string str = "china,中华人民共和国"; byte[] bufferutf8 = system.text.encoding.utf8.getbytes(str); printbyte("utf8:", bufferutf8);
试想你请求一个数据,却得到一堆乱码,丈二和尚摸不着头脑。有同事质疑你的数据是乱码,虽然你很确定传了 UTF-8 ,却也无法自证清白,更别说帮同事 debug 了。
领取专属 10元无门槛券
手把手带您无忧上云