易栈网-膘叔

条形码这个东西，在实际中用的比较多，而且现在大多数的手机（带摄像头的）几乎都支持条形码拍摄识别了。

曾经想过为老头子的小店搞一个这样的程序，方便他统计货物，但后来想想，这么小的小店，数都数的过来就放弃了。其实还有一个原因，那就是，手持PDA太贵 了。

这是条形码的资料，先学习一下，说不定哪天老头子的小店能够做大呢？HOHO

内容如下：我是从博客园COPY而来的：http://www.cnblogs.com/gnielee/archive/2009/07/29/1533768.html

     在一些生产制造行业条形码是必不可少的。比如，打印工作单、原材料出入库、成品出库发货等都需要扫描条形码进行数据采集。最近发现公司打印出的工作单上出 现了条码，打印工单的程序是用PHP写的，于是乎看看源代码是怎么实现的。原来是通过一个生成Barcode的类将相应的数据转给该程序并生成JPG文 件。
     自己在网上搜了搜实现Barcode的其他方法，找到一个国外的开源程序专门用来生成“一维条形码”。首先，复习一下条形码的相关知识。

条形码分类

一、按码制分类
1. UPC码
1973年，美国率先在国内的商业系统中应用于UPC码之后加拿大也在商业系统中采用UPC码。 UPC码是一种长度固定的连续型数字式码制，其字符集为数字0~9。它采用四种元素宽度，每个条或空是1、2、3或4倍单位元素宽度。IPC码有两种类 型，即UPC-A码和UPC-E码。

2. EAN码
1977年，欧洲经济共同体各国按照UPC码的标准制定了欧洲物品编码EAN 码，与UPC码兼容，而且两者具有相同的符号体系。EAN码的字符编号结构与UPC码相同，也是长度固定的、连续型的数字式码制，其字符集是数字0~9。 它采用四种元素宽度，每个条或空是1、2、3或4倍单位元素宽度。EAN码有两种类型，即EAN-13码和EAN-8码。

3. 交叉25码
交叉25码是一种长度可变的连续型自校验数字式码制，其字符集为数字0~9。采用两种元素宽度，每个条和空是宽或窄元素。编码字符个数为偶数，所有奇数位置上的数据以条编码，偶数位置上的数据以空编码。如果为奇数个数据编码，则在数据前补一位0，以使数据为偶数个数位。

4. 39码
39 码是第一个字母数字式码制。1974年由Intermec公司推出。它是长度可比的离散型自校险字母数字式码制。其字符集为数字0—9，26个大写字母和 7特殊字符（-、。、Space、/、%、￥），共43个字符。每个字符由9个元素组成，其中有5个条（2个宽条，3个窄条）和4个空（1个宽空，3个窄 空），是一种离散码。

5. 库德巴码
库德巴码（Code Bar）出现于1972年，是一种长度可变的连续型自校验数字式码制。其字符集为数字0—9和6个特殊字符（-、：、/、。、+、￥），共16个字符。常用于仓库、血库和航空快递包裹中。

6. 128码
128 码出现于1981年，是一种长度可变的连续型自校验数字式码制。它采用四种元素宽度，每个字符由3个条和3个空，共11个单元元素宽度， 又称（11，3）码。它由106个不，同条形码字符，每个条形码字符有三种含义不同的字符集，分别为A、B、C。它使用这3个交替的字符集可将128个 ASCII码编码。

7. 93码
93码是一种长度可变的连续型字母数字式码制。其字符集成为数字。0-9，26个大写字母和7个特殊字符（-、。、Space、/、+、%、￥）以及4个控制字符。每个字符由3个条和3个罕，共9个元素宽度。

8. 49码
49 码是一种多行的连续型、长度可变的字母数字式码制。出现于1987年，主要用于小物品标签上的符号。采用多种元素宽度。其字符集为数字0-9，26个大写 字母和7个特殊字符（-、。、Space、%、/、+、%、￥）、3个功能键（F1、 陀、F3）和3个变换字符，共49个字符。

9. 其他码制
除上述码外，还有其他的码制，例如25码出现于1977年，主要用于电子元器件标签；矩阵25码是11码的变形；Nixdorf码已被EAN码所取代Plessey码出现于1971年5月主要用于图书馆等。

二、按维数分类
1. 普通的一维条码
普通的一维条码自本问世以来，很快得到了普及并广泛应用。但是由于一维条码的信息容量很小，如 商品上的条码仅能容13位的阿拉伯数字，更多的描述商品的信息只能依赖数据库的支持，离开了预先建立的数据库，这种条码就变成了无源之水，无本之木，因而 条码的应用范围受到了一定的限制。

2. 二维条码
除具有普通条码的优点外，二维条码还具有信息容量大、可靠性高、保密防伪性强、 易于制作、成本低等优点。<BR>美国Symbol公司于1991年正式推出名为PDF417的二维条码，简称为PDF417条码，即“便携 式数据文件”。FDF417条码是一种高密度、高信息含量的便携式数据文件，是实现证件及卡片等大容量、高可靠性信息自动存储、携带并可用机器自动识读的 理想手段。

3. 多维条码
进入20世纪80年代以来，人们围绕如何提高条形码符号的信息密度，进行了研究工作。多维条形码和集装 箱条形码成为研究、以展与应用的方向。<BR>信息密度是描述条形码符号的一个重要参数据，即单位长度中可能编写的字母个数，通常记作：字母 个数/cm。影响信息密度的主要因素是条、空结构和窄元系的宽度。<BR>128码和93码就是人们为提高密度而进行的成功的尝试。128码 城1981年被推荐应用；而93码于1982年投入使用。这两种码的符号密度均比39码高将近30%。<BR>随着条形码技术的发展和条形码 三制的种类不断增加，条形码的标准化显得愈来愈重要。为此，曾先后制定了军用标准1189；交叉25码、39码和Coda Bar码ANSI标准MH10.8M等。同时，一些行业也开始建立行业标准，以适应发展的需要。此后，戴维·阿利尔又研制出49码。这是一种非传统的条形 码符号，它比以往的条形码符号具有更高的密度。特德·威廉姆斯（Ted Williams）GFI988推出16K码，该码的结构类似于49码，是一种比较新型的码制，适用于激光系统。

条形码实例

1. Codabar   Manual Reference

• Supports: [0-9], [A-D], - $ : / . +
• Must start and end with a letter
• Contains an auto-checksum, no checksum number

2. Code 11   Manual Reference

• Supports: [0-9], -
• Rarely used
• Contains auto-checksum numbers

3. Code 39   Manual Reference

• Supports: [0-9], [A-Z], - . $ / + % [SPACE]
• Really used, many uses
• Contains a optional checksum
• Resulting barcode is pretty big

4. Code 39 Extended   Manual Reference

• Supports: [0-9], [A-Z], - . $ / + % [SPACE] + ASCII 0-127
• The extension of this barcode is optional. You must specify your reader that you read Code 39 Extended.

5. Code 93   Manual Reference

• Supports: [0-9], [A-Z], - . $ / + % [SPACE] + ASCII 0-127
• Similar to Code 39 but less used
• Supports ASCII 0-127 and is not optional like the Code 39
• Bigger density

6. Code 128   Manual Reference

• Supports: [0-9], [a-zA-Z], tous les characteres
• Contains 3 tables to better encode data
• Groups numbers by two for a better compression

7. EAN-8   Manual Reference

• Supports: [0-9]
• Encodes 7 numbers and a checksum number
• It is the EAN-13 short version
• You have to get a number with a license to use in the public

8. EAN-13   Manual Reference

• Supports: [0-9]
• Encodes 12 numbers with a checksum number
• It is the UPC-A extension which adds the country code
• You have to get a number with a license to use in the public

9. ISBN-10 / ISBN-13   Manual Reference

• Supports: [0-9]
• Based on EAN-13, used for books
• You have to get a number with a license to use in the public

10. Interleaved 2 of 5   Manual Reference

• Supports: [0-9]
• Based on Standard 2 of 5
• Optional checksum number

11. Standard 2 of 5   Manual Reference

• Supports: [0-9]
• Hard to read for readers because really low density
• Optional checksum number

12. MSI Plessey   Manual Reference

• Supports: [0-9]
• Formerly used for inventory
• Optional checksum number

13. UPC-A   Manual Reference

• Supports: [0-9]
• Encoded like EAN-13
• Encodes 11 numbers with a checksum number
• The numbers depends on what you sell
• You have to get a number with a license to use in the public

14. UPC-E   Manual Reference

• Supports: [0-9]
• Short version of UPC-A
• Encodes 7 numbers with a checksum number
• The numbers depends on what you sell
• You have to get a number with a license to use in the public

15. UPC Extension 2   Manual Reference

• Supports: [0-9]
• Contains 2 characters
• Indicates more information on the product
• Must be joined to a UPC or EAN symbol

16. UPC Extension 5   Manual Reference

• Supports: [0-9]
• Contains 5 characters
• Usually indicates the suggested price of the product
• Must be joined to a UPC or EAN symbol

17. PostNet   Manual Reference

• Supports: [0-9]
• Contains either 5, 9 or 11 numbers
• Used to encode envelopes in United States

18. Other   Manual Reference

• Create your own barcode
• Add the text you want

参考资料：http://www.barcodephp.com/1d/overview.php

APC其实是PHP5自带的东西，只需要把xxx.dll前的注释去掉就可以用了，不象其他的加速 ，还需要装软件，什么xCache啦，eacceraltor之类的，都需要额外编译好之后放到扩展目录下才行（当然我说的是windows下面的，linux下面就不太一样了）

既然是自带的，又这么好，总要有个介绍的吧？

原文：http://blog.goguoguo.com/html/y2009/311.html

作者：土 豆

先说说php程序的执行流程吧，说明了这个，才好开始我们的优化之旅。

客户端（譬如浏览器）
—》请求Get hello.php
—-》cgi服务器接（譬如apache）收到请求，根据配置寻找php的处理程序（譬如mod_php）
—-》apache加载php的处理程序，php的处理程序读取php.ini初始化php的解释环境
—-》mod_php定位寻找hell.php，将其载入到内存中来
—-》mod_php编译源代码成为opcode树
—-》mod_php执行opcode树
—-》生成结果给浏览器

在这个过程中我们有哪些地方可以优化呢：
1 将mod_php fast-cgi化，避免每次都要加载这个模块，这个模块还要每次都去初始化php的解释环境
2 缓存php文件的opcode码，这样话，避免每次都去编译。

缓存opcode码有很多软件，apc、以及zend提供的cache等。
转载一个apc的配置和使用：

Alternative PHP Cache（APC）是 PHP 的一个免费公开的优化代码缓存。它用来提供免费，公开并且强健的架构来缓存和优化 PHP 的中间代码。

在 Windows 下，APC 要求有 c:\tmp 目录，并且该目录要对 Web 服务器进程可写。

1. 安装:

以PHP extension 形式安装.

2. 配置
apc.enabled boolean
apc.optimization optimization
选项在脚本中可以改变

APC PHP.ini配置选项详解

[APC]
; Alternative PHP Cache 用于缓存和优化PHP中间代码

apc.cache_by_default = On
;SYS
; 是否默认对所有文件启用缓冲。
; 若设为Off并与以加号开头的apc.filters指令一起用，则文件仅在匹配过滤器时才被缓存。

apc.enable_cli = Off
;SYS
; 是否为CLI版本启用APC功能，仅用于测试和调试目的才打开此指令。

apc.enabled = On
; 是否启用APC，如果APC被静态编译进PHP又想禁用它，这是唯一的办法。

apc.file_update_protection = 2
;SYS
; 当你在一个运行中的服务器上修改文件时，你应当执行原子操作。
; 也就是先写进一个临时文件，然后将该文件重命名(mv)到最终的名字。
; 文本编辑器以及 cp, tar 等程序却并不是这样操作的，从而导致有可能缓冲了残缺的文件。
; 默认值 2 表示在访问文件时如果发现修改时间距离访问时间小于 2 秒则不做缓冲。
; 那个不幸的访问者可能得到残缺的内容，但是这种坏影响却不会通过缓存扩大化。
; 如果你能确保所有的更新操作都是原子操作，那么可以用 0 关闭此特性。
; 如果你的系统由于大量的IO操作导致更新缓慢，你就需要增大此值。

apc.filters =
;SYS
; 一个以逗号分隔的POSIX扩展正则表达式列表。
; 如果源文件名与任意一个模式匹配，则该文件不被缓存。
; 注意，用来匹配的文件名是传递给include/require的文件名，而不是绝对路径。
; 如果正则表达式的第一个字符是”+”则意味着任何匹配表达式的文件会被缓存，
; 如果第一个字符是”-”则任何匹配项都不会被缓存。”-”是默认值，可以省略掉。

apc.ttl = 0
;SYS
; 缓存条目在缓冲区中允许逗留的秒数。0 表示永不超时。建议值为7200~36000。
; 设为 0 意味着缓冲区有可能被旧的缓存条目填满，从而导致无法缓存新条目。

apc.user_ttl = 0
;SYS
; 类似于apc.ttl，只是针对每个用户而言，建议值为7200~36000。
; 设为 0 意味着缓冲区有可能被旧的缓存条目填满，从而导致无法缓存新条目。

apc.gc_ttl = 3600
;SYS
; 缓存条目在垃圾回收表中能够存在的秒数。
; 此值提供了一个安全措施，即使一个服务器进程在执行缓存的源文件时崩溃，
; 而且该源文件已经被修改，为旧版本分配的内存也不会被回收，直到达到此TTL值为止。
; 设为零将禁用此特性。

apc.include_once_override = Off
;SYS
; 关于该指令目前尚无说明文档，参见：http://pecl.php.net/bugs/bug.php?id=8754
; 请保持为Off，否则可能导致意想不到的结果。

apc.max_file_size = 1M
;SYS
; 禁止大于此尺寸的文件被缓存。

apc.mmap_file_mask =
;SYS
; 如果使用–enable-mmap(默认启用)为APC编译了MMAP支持，
; 这里的值就是传递给mmap模块的mktemp风格的文件掩码(建议值为”/tmp/apc.XXXXXX”)。
; 该掩码用于决定内存映射区域是否要被file-backed或者shared memory backed。
; 对于直接的file-backed内存映射，要设置成”/tmp/apc.XXXXXX”的样子(恰好6个X)。
; 要使用POSIX风格的shm_open/mmap就需要设置成”/apc.shm.XXXXXX”的样子。
; 你还可以设为”/dev/zero”来为匿名映射的内存使用内核的”/dev/zero”接口。
; 不定义此指令则表示强制使用匿名映射。

apc.num_files_hint = 1000
;SYS
; Web服务器上可能被包含或被请求的不同源文件的大致数量(建议值为1024~4096)。
; 如果你不能确定，则设为 0 ；此设定主要用于拥有数千个源文件的站点。

apc.optimization = 0
; 优化级别(建议值为 0 ) 。
; 正整数值表示启用优化器，值越高则使用越激进的优化。
; 更高的值可能有非常有限的速度提升，但目前尚在试验中。

apc.report_autofilter = Off
;SYS
; 是否记录所有由于early/late binding原因而自动未被缓存的脚本。

apc.shm_segments = 1
;SYS
; 为编译器缓冲区分配的共享内存块数量(建议值为1)。
; 如果APC耗尽了共享内存，并且已将apc.shm_size指令设为系统允许的最大值，
; 你可以尝试增大此值。

apc.shm_size = 30
;SYS
; 每个共享内存块的大小(以MB为单位，建议值为128~256)。
; 有些系统(包括大多数BSD变种)默认的共享内存块大小非常少。

apc.slam_defense = 0
;SYS(反对使用该指令，建议该用apc.write_lock指令)
; 在非常繁忙的服务器上，无论是启动服务还是修改文件，
; 都可能由于多个进程企图同时缓存一个文件而导致竞争条件。
; 这个指令用于设置进程在处理未被缓存的文件时跳过缓存步骤的百分率。
; 比如设为75表示在遇到未被缓存的文件时有75%的概率不进行缓存，从而减少碰撞几率。
; 鼓励设为 0 来禁用这个特性。

apc.stat = On
;SYS
; 是否启用脚本更新检查。
; 改变这个指令值要非常小心。
; 默认值 On 表示APC在每次请求脚本时都检查脚本是否被更新，
; 如果被更新则自动重新编译和缓存编译后的内容。但这样做对性能有不利影响。
; 如果设为 Off 则表示不进行检查，从而使性能得到大幅提高。
; 但是为了使更新的内容生效，你必须重启Web服务器。
; 这个指令对于include/require的文件同样有效。但是需要注意的是，
; 如果你使用的是相对路径，APC就必须在每一次include/require时都进行检查以定位文件。
; 而使用绝对路径则可以跳过检查，所以鼓励你使用绝对路径进行include/require操作。

apc.user_entries_hint = 100
;SYS
; 类似于num_files_hint指令，只是针对每个不同用户而言。
; 如果你不能确定，则设为 0 。

apc.write_lock = On
;SYS
; 是否启用写入锁。
; 在非常繁忙的服务器上，无论是启动服务还是修改文件，
; 都可能由于多个进程企图同时缓存一个文件而导致竞争条件。
; 启用该指令可以避免竞争条件的出现。

apc.rfc1867 = Off
;SYS
; 打开该指令后，对于每个恰好在file字段之前含有APC_UPLOAD_PROGRESS字段的上传文件，
; APC都将自动创建一个upload_的用户缓存条目(就是APC_UPLOAD_PROGRESS字段值)。

3. 函数:

apc_cache_info - Retrieves cached information (and meta-data) from APC’s data store
apc_clear_cache - Clears the APC cache
apc_define_constants - Defines a set of constants for later retrieval and mass-definition
apc_delete - Removes a stored variable from the cache
apc_fetch - Fetch a stored variable from the cache
apc_load_constants - Loads a set of constants from the cache
apc_sma_info - Retrieves APC’s Shared Memory Allocation information
apc_store - Cache a variable in the data store

apc的用法比较简单,只有几个函数,列举如下。
apc_cache_info () 返回缓存信息
apc_clear_cache() 清除apc缓存内容。
默认(无参数)时,只清除系统缓存,要清除用户缓存,需用‚user‘参数。
apc_define_constants ( string key, array constants [, bool case_sensitive] ) 将数组constants以常量加入缓存。
apc_load_constants (string Key)。
取出常量缓存。
apc_store ( string key, mixed var [, int ttl] )。
在缓存中保存数据。
apc_fetch ( string key )。
获得apc_store保存的缓存内容
apc_delete ( string key )。
删除apc_store保存的内容。

apc的管理：
到pecl.php.net下载apc源码包有个apc.php，copy到你的web server可以访问到的地方，浏览即可访问。
管理界面功能有：
1. Refresh Data
2. View Host Stats
3. System Cache Entries
4. User Cache Entries
5. Version Check

配置php.ini的时候一定要跟进编译选项来放置这些扩展的位置。
默认apc.so要放到php.ini同一个目录下，而不是传说中的extension目录。

风雪之隅的网站上大多是对PHP的底层进行关注的文章，如果对PHP的核心内容有兴趣不妨多翻阅一下他的网站。

本文的标题，其实是一个老问题了。
大家都知道，PHP对于没有引号的字符串，会当成常量来处理，如果该常量不存在，则直接输出该字符串。也就是多做了几步处理。
事实上，上面的这个知识点，很早就知道，但，不是我自己研究出来的。虽然自己写过代码进行测试过。

雪候鸟则直接从OPCODE上进行查看，给你一个直观印象。好，我们来看看原文吧
地址：http://www.laruence.com/2009/04/24/695.html
内容：
我看到过很多人操作数组的时候, 对于数组中的非数字键名不使用引号,

我可以理解有些人可能会觉得这样的代码很”整洁”, 并且也能正常执行.
更甚至,如果他很”幸运的”php配置的好:

他也许永远都沉浸在自己的”整洁”风格中, 看不到任何的NOTICE提示, 也不会意识到, 他这么做, 能损失多少的性能~

来, 我们一起来看看:

那么, 这些效率损失到哪里去了呢?

我们分别看下, 俩个文件生成的OPCODE序列:

good.php :

我们可以看出(其实,根据NOTICE的提示也知道), PHP会把没有引号引起来的键名当作是常量去获取, 当找不到的时候, 抛出一个NOTICE, 然后再根据”常量明”生成一个字符串, 然后再讲这个字符串做为键名继续~

聪明的你一定会想到, 可能会出现如下不可预期的错误:

我很赞同:”be lazy”, 但是, lazy也是应该有原则的.

最后, 好的代码,不应该通过关闭error_reporting来伪装.

附注, FETCH_CONSTANT OPCODE中找不到常量的相关逻辑:

——EOF——

膘叔最受不了的，就是discuz，特别是模版中的变量，全部是不含单引号的。写起来是方便啊。但是性能不敢恭维。所以common.inc.php的前面几句就是error_reporting了。。隐藏掉，看你怎么办，有本事你咬我呀。。

我还能怎么办？

架构这个东西，不能一味的盲目抄袭，因为每种新架构的出现往往都有其特定的历史背景，要么是数据访问量太大、要么（想写的一些内容因为存储关系丢失了，一下子又没有想起来，下面是重写的，但内容已经和原来想的不太一样了）

高春辉就在他的勃客里认为，主从数据库不行了，未来的数据存储走向应该不会再是主从，他这么说：

文末，他推荐了一篇InfoQ上的文章，在这里我也进行转载一下，是关于FriendFeed实现基于MySQL的无模式存储，不过他这种架构也不是能拿来就要用的，也需要根据目前的实际情况，只能进行参考。这是一篇翻译文章：

作者 Dave West译者 王丽娟 发布于 2009年4月4日 下午8时7分

对于迅速增长的网站所遇到的问题——“用灵活的模式存储数据、即时创建新的索引”，FriendFeed的Bret Taylor介绍了一种“无模式的解决方案” 。问题本身源自一些需求：需要不断增加新功能，不断更新底层的数据库结构和数据库中存储的数百万条已有记录，还要同时支持新旧功能。FriendFeed的办法是基于MySQL建立一个无模式的解决方案，而不是迁移到别的技术基础上去。Bret描述了基本问题：

尤其是有一两千万行数据的时候，每次修改模式、往数据库中添加索引都会数小时完全锁定数据库。删除旧索引也需要同样长的时间，但不删除又会影响性能，因为 数据库在每次执行INSERT操作时都会继续读写这些不用的块，而重要的块却没有足够的内存。经过一些复杂的操作过程可以克服以上困难（比如在从机上创建 新索引，然后调换从机和主机），但这些操作过程都很容易出错，也都是重量级的，因此会使我们因为害怕改变模式/索引而不敢增加新功能。由于我们的数据库都 是严重分片的，像JOIN这些MySQL的关系型功能对我们毫无用处，所以我们决定看看RDBMS之外的领域。

研究了几个可行的解决方案后，他们决定基于MySQL的自定义一种“无模式”持久化方案，而不是彻底改换门庭。

他们的解决方案是把主要数据和这些数据的索引分离开来。“我们的数据存储储存了无模式的属性包……我们在单独的MySQL表中存储索引，从而在这些实体中索引数据。”这是以容量来换效率。

结果我们比以前多了很多的表，但添加和删除索引却很容易。我们大力优化了填充新索引的进程（我们称之为“Cleaner”），以便该进程能快速填充新索引，而不会让站点中断。

分离数据和索引引起了一致性和原子性问题。他们没有建立严格的事务规则，而是把数据库表推到最简，索引只用来引用，发生实际的数据库读操作的时候才 施加数据过滤。他们改进了持续更新表的自动化进程，让这个“Cleaner”进程不停地对优先级高的被更新实体进行更新和索引修正。尽管可能出现不一致， 但消除不一致的时间平均不到两秒钟。

Bret用平均页面延迟这一指标描述了以下走向。

• 整体来说——尽管有增加的趋势，但还是有显著的减少。
• 过去二十四小时——即使在高峰时段也保持稳定。
• 前一周——明显减少。

Bret的帖子有很多回复。有一种观点认为“对于模式演变，现代的RDBMS不像MySQL局限那么大”，这种观点忽略了选择背后的成本问题。其它读者则回复了更多种不同的解决办法。

有意思的是，并没有人指出FriendFeed的解决方案与古老的ISAM技术（Indexed Sequential Access Method，索引顺序存取法）之间的相似性。ISAM用的是同样的基本架构——分离数据和索引，同时在数据发生变化时自动更新索引。

查看英文原文：FriendFeed Implements Schema-less Storage Atop MySQL

网上的资料，都是用svn update命令在post-commit里面进行同步，这里面很多人都忽略了讲最重要的一点，那就是在svn update之前，该目录必须要先用svn checkout一下，否则。update目录会直接忽略该目录。
这，几乎所有的教程里都没讲，我是试了半天啊。。。
后来，也找到了一篇类似教程。希望看到的人少走点弯路。

原文：http://www.unix-center.net/bbs/viewthread.php?tid=11607