php空行应该怎么写，怎样给视频添加中英文双语字幕？
下载地址: http://www.leawo.cn/ND_upload.php?do=info&id=6192 先给大家看看小编的制作效果，字幕的大小颜色位置等参数可自行设置： 点击上方链接内下载字幕制作工具。要等完全解压缩之后运行应用程序即可。注意，尽量不要将程序解压缩到带有中文名及特殊字符的文件夹中。然后我们需要一个准备工作，先将字幕内容输入到txt文档中保存好，以一行为一句字幕，中文下方接英文翻译，如下图格式。每句字幕内容尽量不要太长： 点击上方的“文件”按钮，选择“导入音视频文件”，选中视频文件点击打开即可导入，再次点击可替换导入的视频文件。然后我们先点击视频下方的播放按钮查看一下视频画面。确认无误后再次点击上方的“文件”按钮，选择“导入双语字幕文稿”： 点击预览效果按钮，此时显示界面如下图所示，若是导入的txt文档中，单数行是中文的话，此时显示的第一语言就是中文，即左侧中文，右侧英文；若是反了可以在界面上方设置双数行为第一语言。总之显示出左侧为中文右侧是英文即可。然后点击继续按钮： 这时可以看到字幕内容显示在界面右方。要边播放边加字幕的话，可以将视频的播放速度减慢一点，在视频画面右下方可以设置播放速度；点击步骤一处的按钮，鼠标指针上方会出现第一句字幕内容；在时间轴上大致划出每句字幕对应的时间段，字幕时间点不需要太准确，设置到大致的时间点即可： 这一步操作可能对于电脑小白比较难理解，下方是小编之前制作中文字幕时录制的操作方法，双语字幕的操作也是一样的。就是点击上图步骤一出的按钮后，可以边播放边划出字幕显示时间段，视频的播放与暂停可以通过键盘的空格键来控制： 当每句字幕都已经设置到画面下方的时间轴之后，字幕显示时间肯定不是很准确，这时我们鼠标右键点击时间轴上的字幕内容，选择“调整字幕时间”；在弹出来的调整时间小窗口中，左右滑动开始时间、结束时间的数值即可调整字幕显示的准确时间。也可以拖动时间轴上的字幕边缘处来设置显示时间： 时间调整好之后，我们会发现中文与英文字幕是重叠在一起的，我们要先将中英文字幕拆分到不同的字幕组，这样才可以对中英文字幕分别设置字体样式。点击界面上方的“功能”菜单，点击“将双语字幕切分为双轨道”，这样时间轴上就会出现中英文两个轨道的字幕了： 接着来设置一下字幕样式。在此之前，如果还处在字幕编辑状态，可以点击下图步骤一处的按钮切换回选择工具；然后点击下图步骤二处的A形状按钮；在显示的界面上方可以设置字幕显示是否‘自动淡入淡出’；注意字幕生成算法要保持默认的C：保持字幕块独立；然后双击Default字幕样式： 此处我们设置的是中文字幕的字体样式，自行设置字幕的字体、字号、描边、阴影、对齐位置、颜色，大家可能会问在哪里设置颜色，分别点击文字‘字体’‘描边’‘阴影’正下方的正方形方框即可修改颜色；然后修改‘垂直边距’，由于中文字幕在英文字幕上方，这里的垂直边距设置在50左右；点击“应用”： 接着我们来设置另一个字幕样式Default-Box，把这个字幕样式设置为英文字幕的字体样式。还是在下图所示界面，注意将字幕生成算法设置为C:保持字幕块独立，然后双击Default-Box进行编辑： 下图是Default-Box的样式编辑界面，同样的，自行设置字体、字号、描边、阴影等参数，如果不要字幕背景颜色，就将描边右侧的矩形边框去除勾选即可。这里主要设置垂直边距，由于这个样式是要设置到英文字幕中去的，英文字幕在中文的下方，所以这里的垂直边距设置小一些，大概设置为20左右即可： 将两个字幕样式设置完成后，接下来的操作就简单了。首先点击下图步骤一处的按钮；观察时间轴上的字幕分组颜色，默认中文是黄色，英文是粉色，相对应的就是组1和专用组A了；如下图步骤三处点击组1的设定样式，将样式选择为刚刚设置的Default；然后设置专用组A的设定样式为Default-Box： 此时画面不会显示字幕样式，我们点击下图步骤一处的眼睛形状按钮将实时字幕预览关闭。然后点击上方的“文件”—“保存工程并生成字幕”；此时会自动在原视频文件目录下创建一个工程及一个ass字幕文件，这时再播放就可以看到字幕效果了： 如果设置的字幕样式不合适，可以再次设置，但是设置好之后要敲键盘Ctrl+S键进行保存，或者再次点击“文件”—“保存工程并生成ASS字幕”进行保存。那么要如何导出带有字幕的视频文件呢？点击“文件”，选择“视频转码输出/压制”，然后点击开始转码即可： 这个如果视频文件太大的话就需要等待一段时间了，这个一般用来制作短视频加双语字幕，我们也可以保存成ass字幕文件，然后在狸窝视频转换器中将视频及字幕文件合并嵌入处理。 好啦，视频添加字幕的操作就完成了。这款工具是可视化视频加字幕工具，界面简洁好用，小编还是蛮喜欢用这款工具制作字幕的，当然啦，这款工具还有很多功能，小编下次给大家介绍嘞！ 笑话段子： 妻子：我饿了，咱俩去超市逛逛吧？丈夫：你先吃点东西咱再去。妻子：到那就买吃的了，饿不坏，走吧！丈夫：我不是怕饿坏你，我是怕你在饿的情况下到超市乱买东西！ 相关文章： 视频添加字幕 http://www.leawo.cn/space-5015878-do-thread-id-74934.html 视频加gif动态水印 http://www.leawo.cn/space-5015878-do-thread-id-74952.html 视频加垂直条纹闪动滤镜 http://www.leawo.cn/space-5015878-do-thread-id-74994.html ppt转swf保留动画效果 http://www.leawo.cn/space-5015878-do-thread-id-75023.html
企业类网站如何加速？
网站建设和设计者都会很关心一个问题，如何让网站的打开速度更快一些，文汇建站当主机位置和线路已经选择了之后，我们仍然可以在代码和网站的设置上进行一些优化，达到网站加速的效果
1、设置静态内容缓存时间
浏览器会用缓存来减少http请求数来加快页面加载的时间，如果你有权限的话，你可以通过修改IIS或.htaccess文件来实现，如果你的网站更新速度很快，那么首页的html、asp、php等网页文件可以不用设置缓存时间，而变化频率不高的css、图片、flash等文件等可以设置一个较长的时间，如24小时或几天时间。
2、网站启用Gzip压缩
几乎所有的浏览器都支持Gzip压缩，并且Gzip压缩的比例也很高，通常都可以压缩50%上下，有的甚至更高，这就可以大大缩短数据的传输量，不管是动态网页还是静态网页都可以启用Gzip，不管是Windows服务器还是Linux服务器都支持Gzip，它可以为你节省网页文件（html、asp、php等）和css文件的传输时间。
3、减少HTTP请求数
网页、css、图片、flash等等这些都会增加http请求数，减少这些元素的数量就能减少响应时间。
4、图片使用原始尺寸和容量
如果你想使用图片，请尽量先根据页面大小需求规划图片的尺寸，在页面调用图片时也最好不要缩放，而使用原始尺寸大小。
不管是jpg、gif、png图片，在不减少观看效果的情况下适当降低图片的质量。
5、清除无效的脚本
无效的代码块和隐性代码（没有正常显示的），以及减少注释文本量，清除不必要的空格、空行会为你节省意想不到的文件容量，这一工作包含所有的脚本：html、asp、php、css、js等。
6、减少外网站引用
减少从网站外部调用资源，可以加快网页的调用速度，除非从外部调用的资源既稳定有速度快，如从百度或google引用的代码。
7、把影响布局和表现的css放顶部
把css放在head之间，可以让浏览者能尽早的看到网站的完整样式，不至于错位和混乱。
8、把不影响表现的js等放底部
如果js没有对内容表现没有影响，如，统计类脚本，就可以放在底部。
以上是比较容易实现的，如果你是大型网站，资金充裕，可以考虑的就是cache、cdn加速了
wordpress后台提示Cookies因预料之外的输出被阻止？
找到functions.php，查看下代码，如果有<?PHP和?>中有多余的分号，逗号，句号，或者附近有空行都删除掉，大部分都是这个文件出问题引起的。仔细排查下，祝你早点解决问题。
如何才能写出高质量的代码？
作为一名java开发工程师，对于这个问题我算是比较有感触的，所以想说说我对java开发的一些看法，纯属个人意见，不喜轻喷！
什么样的代码算是高质量代码，或者说是高质量代码的特征？在我看来，主要就是在于可读性、易扩展两方面。
首先，我觉得最重要是要可读性高。为什么这么说呢？相信做过开发的朋友都知道，互联网公司的人员流动率还是比较高的，可能出现的情况是领导突然跟你说，你去交接一下某某某同事的工作，而交接的时候一般情况主要是业务流程、功能模块来交接，大概率不会一行一行的代码去读。如果项目正常运转，不出问题、也没有需求变更（大概率需求会变更），那就是你好我好大家好，如果出了问题或者需求变更，还是之前同事的那些模块，那就必须得去啃代码了。这个时候代码的易读性就显得非常重要了。你可以试想一下，通篇没有一句注释、一个方法几百行、if/else满天飞、方法之间参数传递全是map、sql语句各种嵌套子查询、关联查询7-8个表，当你看到这样的代码，估计心里顿时万马奔腾，怒火蹭蹭蹭的往头上涌去。所以我觉得可读性是第一要素。
其次，扩展性要好。这个也很好理解，现在是信息时代，流量为王，为了提高市场占有率，普遍需求变更频繁，2周一次发布都是正常频率。在这种频繁需求变更的情况下，如果代码的扩展性不高，每一次需求都需要大量改动代码，即耗费时间还容易出错，比如漏改某处地方而引起其他功能异常。所以开发过程中要注意代码扩展性，当然也不要去过分设计，让代码晦涩难懂。
高质量代码在开发中的意义？《计算机程序的构造和解释》一书提到代码是写给人看的，不是写给机器看的，只是顺便计算机可以执行而已。如果代码是写给机器看的，那完全可以使用汇编语言或者机器语言(二进制)，直接让机器执行。所以代码一定要让人容易理解。高质量代码的好处：
好的代码读起来令人赏心悦目，比如java里的spring、mybatis等框架，读源码时常常不自觉发出惊叹，代码原来还可以这么写！
质量高意味着维护成本低，运行稳定
质量高意味着扩展性强，方便业务开发
如何去写高质量代码？对于做java的来说，我建议去看一下《阿里巴巴Java开发手册》。
手册以 Java 开发者为中心视角，划分为编程规约、异常日志、单元测试、安全规约、MySQL 数据库、工程结构、设计规约七个维度，再根据内容特征，细分成若干二级子目录。根据约束力强弱及故障敏感性，规约依次分为强制、推荐、参考三大类。对于规约条目的延伸信息中，“说明”对规约做了适当扩展和解释；“正例”提倡什么样的编码和实现方式；“反例”说明需要提防的雷区，以及真实的错误案例。 摘自《阿里巴巴 Java 开发手册》最后推荐一下阿里巴巴代码规范扫描插件，以IDEA为例，安装如下
使用如下：
什么样的代码叫好代码？
送大家以下java学习资料
简介： 我们每天都与代码打交道，但当被问道什么是好的代码时，很多人可能会先愣一下，然后给出的回答要么比较空泛，要么比较散，没办法简单明了地概括出来。显然，这个问题并没有唯一的标准答案，谁都可以谈论自己的理解，今天谈谈我对于好代码的理解。
我们每天都与代码打交道，但当被问道什么是好的代码时，很多人可能会先愣一下，然后给出的回答要么比较空泛，要么比较散，没办法简单明了地概括出来。显然，这个问题并没有唯一的标准答案，谁都可以谈论自己的理解，今天谈谈我对于好代码的理解。
一句话概括衡量代码质量的唯一有效标准：WTF/min —— Robert C. Martin
Bob大叔对于好代码的理解非常有趣，对我也有很大的启发。我们编写的代码，除了用于机器执行产生我们预期的效果以外，更多的时候是给人读的，这个读代码的可能是后来的维护人员，更多时候是一段时间后的作者本人。
我敢打赌每个人都遇到过这样的情况：过几周或者几个月之后，再看到自己写的代码，感觉一团糟，不禁怀疑人生。
我们自己写的代码，一段时间后自己看尚且如此，更别提拿给别人看了。
任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。—— Martin Fowler
所以，谈到好代码，首先跳入自己脑子里的一个词就是：整洁。
好的代码一定是整洁的，给阅读的人一种如沐春风，赏心悦目的感觉。
整洁的代码如同优美的散文。—— Grady Booch
好代码的特性很难给好的代码下一个定义，相信很多人跟我一样不会认为整洁的代码就一定是好代码，但好代码一定是整洁的，整洁是好代码的必要条件。整洁的代码一定是高内聚低耦合的，也一定是可读性强、易维护的。
高内聚低耦合
高内聚低耦合几乎是每个程序员员都会挂在嘴边的，但这个词太过于宽泛，太过于正确，所以聪明的编程人员们提出了若干面向对象设计原则来衡量代码的优劣：
开闭原则 OCP (The Open-Close Principle)单一职责原则 SRP (Single Responsibility Principle)依赖倒置原则 DIP (Dependence Inversion Principle)最少知识原则 LKP (Least Knowledge Principle)) / 迪米特法则 (Law Of Demeter)
里氏替换原则 LSP (Liskov Substitution Principle)接口隔离原则 ISP (Interface Segregation Principle)组合/聚合复用原则 CARP (Composite/Aggregate Reuse Principle)这些原则想必大家都很熟悉了，是我们编写代码时的指导方针，按照这些原则开发的代码具有高内聚低耦合的特性。换句话说，我们可以用这些原则来衡量代码的优劣。
但这些原则并不是死板的教条，我们也经常会因为其他的权衡（例如可读性、复杂度等）违背或者放弃一些原则。比如子类拥有特性的方法时，我们很可能打破里氏替换原则。再比如，单一职责原则跟接口隔离原则有时候是冲突的，我们通常会舍弃接口隔离原则，保持单一职责。只要打破原则的理由足够充分，也并不见得是坏的代码。
可读性
代码只要具有了高内聚和低耦合就足够好了吗？并不见得，我认为代码还必须是易读的。好的代码无论是风格、结构还是设计上都应该是可读性很强的。可以从以下几个方面考虑整洁代码，提高可读性。
命名
大到项目名、包名、类名，小到方法名、变量名、参数名，甚至是一个临时变量的名称，其命名都是很严肃的事，好的名字需要斟酌。
► 名副其实
好的名称一定是名副其实的，不需要注释解释即可明白其含义的。
/** * 创建后的天数 **/ int d; int daysSinceCreation;
后者比前者的命名要好很多，阅读者一下子就明白了变量的意思。
► 容易区分
我们很容易就会写下非常相近的方法名，仅从名称无法区分两者到底有啥区别（eg. getAccount()与getAccountInfo()），这样在调用时也很难抉择要用哪个，需要去看实现的代码才能确定。
► 可读的
名称一定是可读的，易读的，最好不要用自创的缩写，或者中英文混写。
► 足够短
名称当然不是越长越好，应该在足够表达其含义的情况下越短越好。
格式
良好的代码格式也是提高可读性非常重要的一环，分为垂直格式和水平格式。
► 垂直格式
通常一行只写一个表达式或者子句。一组代码代表一个完整的思路，不同组的代码中间用空行间隔。
public class Demo { @Resource private List<Handler> handlerList; private Map<TypeEnum, Handler> handlerMap = new ConcurrentHashMap<>(); @PostConstruct private void init() { if (!CollectionUtils.isEmpty(handlerList)) { for (Handler handler : handlerList) { handlerMap.put(handler.getType(), handler); } } } publicResult<Map<String, Object>> query(Long id, TypeEnum typeEnum) { Handler handler = handlerMap.get(typeEnum); if (null == handler) { return Result.returnFailed(ErrorCode.CAN_NOT_HANDLE); } return handler.query(id); } }
如果去掉了空行，可读性大大降低。
public class Demo { @Resource private List<Handler> handlerList; private Map<TypeEnum, Handler> handlerMap = new ConcurrentHashMap<>(); @PostConstruct private void init() { if (!CollectionUtils.isEmpty(handlerList)) { for (Handler handler : handlerList) { handlerMap.put(handler.getType(), handler); } } } public Result<Map<String, Object>> query(Long id, TypeEnum typeEnum) { Handler handler = handlerMap.get(typeEnum); if (null == handler) { return Result.returnFailed(ErrorCode.CAN_NOT_HANDLE); } return handler.query(id); } }
类静态变量、实体变量应定义在类的顶部。类内方法定义顺序依次是：公有方法或保护方法 > 私有方法 > getter/setter 方法。
► 水平格式
要有适当的缩进和空格。
► 团队统一
通常，同一个团队的风格尽量保持一致。集团对于 Java 开发进行了非常详细的规范。（可点击下方阅读原文，了解更多内容）
类与函数
► 类和函数应短小，更短小
类和函数都不应该过长（集团要求函数长度最多不能超过 80 行），过长的函数可读性一定差，往往也包含了大量重复的代码。
► 函数只做一件事（同一层次的事）
同一个函数的每条执行语句应该是统一层次的抽象。例如，我们经常会写一个函数需要给某个 DTO 赋值，然后再调用接口，接着返回结果。那么这个函数应该包含三步：DTO 赋值，调用接口，处理结果。如果函数中还包含了 DTO 赋值的具体操作，那么说明此函数的执行语句并不是在同一层次的抽象。
► 参数越少越好
参数越多的函数，调用时越麻烦。尽量保持参数数量足够少，最好是没有。
注释
► 别给糟糕的代码加注释，重构他
注释不能美化糟糕的代码。当企图使用注释前，先考虑是否可以通过调整结构，命名等操作，消除写注释的必要，往往这样做之后注释就多余了。
► 好的注释提供信息、表达意图、阐释、警告
我们经常遇到这样的情况：注释写的代码执行逻辑与实际代码的逻辑并不符合。大多数时候都是因为代码变化了，而注释并没有跟进变化。所以，注释最好提供一些代码没有的额外信息，展示自己的设计意图，而不是写具体如何实现。
► 删除掉注释的代码
git等版本控制已经帮我们记录了代码的变更历史，没必要继续留着过时的代码，注释的代码也会对阅读等造成干扰。
错误处理
► 错误处理很重要，但他不能搞乱代码逻辑
错误处理应该集中在同一层处理，并且错误处理的函数最好不包含其他的业务逻辑代码，只需要处理错误信息即可。
► 抛出异常时提供足够多的环境和说明，方便排查问题
异常抛出时最好将执行的类名，关键数据，环境信息等均抛出，此时自定义的异常类就派上用场了，通过统一的一层处理异常，可以方便快速地定位到问题。
► 特例模型可消除异常控制或者 null 判断
大多数的异常都是来源于NPE，有时候这个可以通过 Null Object 来消除掉。
► 尽量不要返回 null ，不要传 null 参数
不返回 null 和不传 null 也是为了尽量降低 NPE 的可能性。
如何判断不是好的代码讨论了好代码的必要条件，我们再来看看好代码的否定条件：什么不是好的代码。Kent Beck 使用味道来形容重构的时机，我认为当代码有坏味道的时候，也代表了其并不是好的代码。
代码的坏味道
► 重复
重复可能是软件中一切邪恶的根源。—— Robert C.Martin
Martin Fowler 也认为坏味道中首当其冲的就是重复代码。
很多时候，当我们消除了重复代码之后，发现代码就已经比原来整洁多了。
► 函数过长、类过大、参数过长
过长的函数解释能力、共享能力、选择能力都较差，也不易维护。
过大的类代表了类做了很多事情，也常常有过多的重复代码。
参数过长，不易理解，调用时也容易出错。
► 发散式变化、霰弹式修改、依恋情结
如果一个类不是单一职责的，则不同的变化可能都需要修改这个类，说明存在发散式变化，应考虑将不同的变化分离开。
如果某个变化需要修改多个类的方法，则说明存在霰弹式修改，应考虑将这些需要修改的方法放入同一个类。
如果函数对于某个类的兴趣高于了自己所处的类，说明存在依恋情结，应考虑将函数转移到他应有的类中。
► 数据泥团
有时候会发现三四个相同的字段，在多个类和函数中均出现，这时候说明有必要给这一组字段建立一个类，将其封装起来。
► 过多的 if...else 或者使用 switch
过多的 if...else 或者 switch ，都应该考虑用多态来替换掉。甚至有些人认为除个别情况外，代码中就不应该存在 if...else 。
本文首先一句话概括了我认为的好代码的必要条件：整洁，接着具体分析了整洁代码的特点，又分析了好代码的否定条件：什么样的代码不是好的代码。仅是本人的一些见解，希望对各位以后的编程有些许的帮助。
我认为仅仅编写出可运行的代码是远远不够的，还要时刻注意代码的整洁度，留下一些漂亮的代码，希望写的代码都能保留并运行 102 年！
后续增加一些实际的例子来说明好的和坏的代码；分享下如何编写整洁代码——自己认为有用的一些编程技巧。