解决angular发布到apache后单页面应用的路径错误问题

在htdocs目录上增加.htaccess文件,内容如下:

RewriteEngine On
# 如果请求的是现有资源,则按原样执行
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -f [OR]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -d
RewriteRule ^ – [L]
# 如果请求的资源不存在,则使用index.html
RewriteRule ^ /index.html

发表在 计算机技术 | 留下评论

Ubuntu 18.04下如何开机自动运行程序

参考:https://blog.csdn.net/qq_14824885/article/details/81587774sudo

  1. vi /lib/systemd/system/rc.local.service
    在文件尾部增加:
    [Install]
    WantedBy=multi-user.target
    Alias=rc-local.service
  2. sudo ln -s /lib/systemd/system/rc.local.service /etc/systemd/system/
  3. sudo vim /etc/rc.local
    #!/bin/bash
    echo “this is a test” > /tmp/rc.local.log
    exit 0
发表在 计算机技术 | 留下评论

关于儒略历与格里历的一个简要说明(2)

格里历

儒略历比回归年365.2422日长0.0078日,则约每128年累积出一天的误差。由于实际使用过程中累积的误差随着时间越来越大,1582年教皇格里高利十三世颁布、推行了以儒略历为基础改善而来的格里历,即沿用至今的公历。1582年3月1日,格里高利颁发了改历命令,内容是:

一、1582年10月4日后的一天是10月15日,而不是10月5日,但星期序号仍然连续计算:10月4日是星期四,第二天10月15日是星期五。这样,就把从公元325年以来积累的老账一笔勾销了。

二、为避免以后再发生春分飘离的现象,改闰年方法为: 凡公元年数能被4整除的是闰年,但当公元年数后边是带两个“0”的“世纪年”时,必须能被400整除的年才是闰年。

格里历的历年平均长度为365.2425日,比回归年长26秒。虽然照此计算,过3000年左右仍存在1天的误差,但这样的精确度已经相当了不起了。至于为了修正这个误差而提出一些方案,如对数值很大的年份能否整除3200年来判断是否闰年,则因并无权威规定,且距今尚远,故不与考虑。

格里历很快在罗马天主教势力范围被普遍接受,但是在英国却引起了一片喧嚣的反对声,英国人仍然坚持儒略历法,拒绝“抹掉10 天”。直到1752年,英国人才想通,理性终于占了上风,不过从1582年到那时,历法又多出了1天,所以英国议会在1752年作出决定,抹掉11天,即1752年9月3日至13日,至此才接受了格里历的改革。

世界各国将儒略历切换为格里历的时间不尽相同,罗马天主教势力范围内如意大利、西班牙等从1582年10月4日之后就切换为格里历,英国以及从英国殖民地独立出来的美国、加拿大等国从1752年9月2日之后才切换为格里历,更晚的如俄国,1918年1月26日,苏俄政府宣布停止使用旧历(儒略历),采用新历(即公历,格里历),所以俄国十月革命发生在格里历1917年11月7日,但是当时俄国使用的是儒略历仍为10月,史称十月革命。最晚的是土耳其,在1926年。下面是各国切换时间:

AL Albania        1912-11-30      IT Italy          1582-10-04

AT Austria        1583-10-05      JP Japan          1918-12-18

AU Australia      1752-09-02      LI Lithuania      1918-02-01

BE Belgium        1582-12-14      LN Latin          9999-05-31

BG Bulgaria       1916-03-18      LU Luxembourg     1582-12-14

CA Canada         1752-09-02      LV Latvia         1918-02-01

CH Switzerland    1655-02-28      NL Netherlands    1582-12-14

*CN China          1911-12-18      NO Norway         1700-02-18

CZ Czech Republic 1584-01-06      PL Poland         1582-10-04

DE Germany        1700-02-18      PT Portugal       1582-10-04

DK Denmark        1700-02-18      RO Romania        1919-03-31

ES Spain          1582-10-04      RU Russia         1918-01-31

FI Finland        1753-02-17      SI Slovenia       1919-03-04

FR France         1582-12-09      SW Sweden         1753-02-17

GB United Kingdom 1752-09-02      TR Turkey         1926-12-18

GR Greece         1924-03-09      US United States  1752-09-02

HU Hungary        1587-10-21      YU Yugoslavia     1919-03-04

IS Iceland        1700-11-16

 

1582年10月15日之前发生的事件日期仍应以当时采用的儒略历日期表示,而不应“溯及既往”转换成外推格里历等值。

公历在公元1582年处的分界,还带来另外一个问题:由于全世界各国并非都在公元1582年就开始使用格里历,许多国家几十年甚至几百年后才接受格里历,所以在1582年至20世纪初(那时世界各国才普遍使用格里历)这三百多年间,许多历史事件就会有两个日期——比如例如,牛顿的生日就有1642年12月25日(儒略历)和1643年1月4日(格里历)两种表达,乔治·华盛顿出生于儒略历1732年2月11日,合格里历1732年2月22日,“十月革命”则有1917年10月25日(儒略历)和1917年11月7日(格里历)两个日期。

这两个日期应该采用哪个,也不是轻易就能有一言九鼎的结论的。通常人们都使用儒略历的那个,那是因为英国直到1752年、俄国直到1918年才使用格里历,在牛顿出生、“十月革命”爆发时,事件发生的国家都还在使用儒略历。或者为避免争议,应注明是哪一种历法的日期。

最后说一下中国的对公历的采用情况。公元1912年1月1日,中华民国建立,采用国号纪年、西历纪月日的时期。1912年为民国元年。这时候直接采用的就是格里历。1949年中华人民共和国成立,为与国际接轨,直接采用西元作为官方历法。为了记录早于1912年的事件,只能倒推历法,一般采用在1582年10月15日以后采用格里历,而1582年10月5日之前,包括公元前46年以前,使用儒略历。比如武王伐纣的牧野之战发生于公元前1044年1月9日,或孔子诞生于公元前552年10月9日。

但是由于计算机最早由美国发明的,而美国与英国一样,于1752年9月14日之后采用格里历,1752年9月2日之前采用儒略历,所以计算机系统中,缺省情况下一般以英国方案为两种历法的切换时间。

发表在 未分类 | 留下评论

关于儒略历与格里历的一个简要说明(1)

回归年(Tropical year):平太阳连续两次通过春分点的时间间隔,即太阳中心自西向东沿黄道从春分点到春分点所经历的时间,又称为太阳年。回归年是四季周期同恒星年一样也是地球公转周期,他们之所以时间不同是因为采用的时间体系不同,地球差异旋转缩短了回归年的时间。根据公元1980年——公元2100年每回归年的时间长度计算1回归年 = 365.2422日,即365天5小时48分46秒。这是根据121个回归年的平均值计算的结果。每个回归年的时间长短并不相等。

儒略历

儒略历(Julian calendar)是由罗马共和国独裁官儒略·恺撒(即盖乌斯·尤里乌斯·凯撒)采纳数学家兼天文学家索西琴尼的计算后,于公元前45年1月1日起执行的取代旧罗马历法的一种历法。儒略历中,一年被划分为12个月,大小月交替;四年一闰,平年365日,闰年366日为在当年二月底增加一闰日,儒略历的年平均长度为365.25日。

儒略历实施早期是比较混乱的。首先是闰年的设置。因当时僧侣错误理解“隔三年设置一闰年”,以致每三年设置了一个闰年。故前45年、前42年、前39年、前36年、前33年、前30年、前27年、前24年、前21年、前18年、前15年、前12年、前9年是闰年,与儒略历实际日期误差有3天。奥古斯都为了纠正以上闰年过多的错误,故取消前5年、前1年、4年3年的闰年,拟补累积误差的天数。此后按儒略历原来的设计每四年有一次闰年。

其次是每个月的天数。

古罗马历法,一年从March到February,前11个月以数字命名,最后一个月(February)是腊月。后来改历,January成为第一个月,各月名逐渐改用俗名或以神命名。

一月 January 名字来自古罗马神话的双面神雅努斯。

二月 February 名字来自古罗马的节日Februa。

三月 March名字来自古罗马神话的战神玛尔斯。

四月 April 名字来自古罗马的词aperire,意思为“开始”,意味着春天开始。

五月 May 名字来自古罗马神话的花神玛亚。

六月 June 名字来自古罗马共和国的创始人Junius。

七月 原名Quintilis,后改July。古罗马历只有10个月,这是第五月,原名是“第五”的意思,因为恺撒是这月出生的,经元老院一致通过,将此月改为恺撒的名字“儒略”。

八月 原名Sextilis 后改August。原名是“第六”的意思,因为后来独裁者屋大维是生于此月(或说为了纪念他,屋大维实际出生在九月),元老院将此月改为他的称号“奥古斯都”。

九月 September 拉丁语“第七”的意思。

十月 October 拉丁语“第八”的意思。

十一月 November 拉丁语“第九”的意思。

十二月 December 拉丁语“第十”的意思。

由于儒略历是太阳历,所以其中的月的长度只是人为设置,与月亮的周期变化无关。恺撒决定凡有特别宗教意义的月份31天,不重要的月份30天。因此,取名门神的1 月,以战神为名的3月,为表示尊敬恺撒大帝而取名的7月,都有31天。因为2月是处死犯人的月份,属不吉的时间,所以只有29天。

恺撒大帝的继任人屋大维(奥古斯都)以自己的名字命名8月。为了和恺撒等同起来,他要求把8月也加成31天。为了要使8月有31天,他便从2月再借来一天,把2月减少到28天。又为避免3 个大月的月份连在一起,又规定9月及11月各有30天,把10月及12月加长到31天。

为简化起见,我们不考虑上述这些混乱情况,而是直接以后来的历法倒推这段短暂混乱时期的记年。也就是一般自公元前45年1月1日起就采用和后来的闰年算法与月份长度一致的算法。为了某些目的,历法能向启用前的日期延伸而制作外推历法,但应谨慎使用。为了一般目的,公元前46年以前因为历法过于混乱,一般以外推儒略历记录。

发表在 未分类 | 留下评论

字符编码简史

  • 很久以前,计算机只能处理英文。那时候一个字符就是一个字节,广泛采用的编码是ASCII。ASCII使用一个字节表示一个英文、数字或常用标点符号,其中字节高位为0,故共有128个字符。
  • 后来,西方各非英语国家/地区为了处理俄语字母、希腊字母等,扩展了ASCII编码,方案是仍然使用一个字节表示一个字符,但是字节高位为1,以便与ASCII区分。从128 到255这一页的字符集被称“扩展字符集”。
  • 1980年,我国公布了GB2312-1980这个国家标准,包含6763个汉字,其中一级汉字(常用字)3755个,二级汉字(次常用字)3008个;同时,GB2312收录了包括拉丁字母、希腊字母、日文平假名及片假名字母、俄语西里尔字母在内的682个全角字符。对于人名、古汉语等方面出现的罕用字,GB 2312不能处理。为了与ASCII相区别,GB2312采用双字节方案,一个字符两个字节,每个字节的高位均为1。当然这样是与“扩展字符集”冲突的。
  • 在亚洲很多国家的语言中,广泛使用着大量的汉字,如日文、韩文等,我国港澳台地区使用繁体汉字,所以各国和地区都制定了自己的字符标准,方案一般也是采用双字节表示一个字符,且两个字节的高位至少有一个是1,以便与ASCII区分。不幸的是,这些字符编码,包括我国的GB2312-1980,彼此是冲突的,同一个编码在不同的字符集中代表不同的字符。
  • 为了解决冲突,1991年开始,国际标准化组织(ISO)和一个叫Unicode的组织联合制定新的“通用字符集”。 通用字符集(Universal Character Set, UCS)是由ISO制定的ISO 10646(或称ISO/IEC 10646)标准所定义的标准字符集。UCS-2用两个字节编码,理论上能存储6万多个字符(2^16个),UCS-4用4个字节编码,理论上能存储21亿多个字符(2^31个,因为高位bit要求为0)。UCS-4与UCS-2是兼容的,即UCS-4中高位2个字节为0的部分,省略掉高2字节,即为UCS-2。我国在1993年制定国家标准GB13000.1-1993与UCS-2兼容,现已被GB/T 13000-2010取代。
  • UCS/Unicode是“通用字符集”,但是各国人民都不愿意直接使用它。原因是:
    1. UCS-4太长了,四个字节,且大部分常用字符的高2字节都是0,直接使用就大量浪费空间存一堆0。
    2. 常用字符主要集中在UCS-2能表达的范围中(即UCS-4中高2字节为0的部分,这部分又叫做基本多文本平面,BMP),所以很多情况下大家只使用UCS-2。可是UCS-2并不够用,现在已经整理进入Unicode的汉字有七万多个了,UCS-2只有6万多的字符空间。
    3. 西方国家的人不爱用UCS-2。本来一个英文字符只需要一个字节,现在UCS-2中一个英文字符也要两个字节,高字节为0,那么一篇英文文章的大小就扩大了一倍,且扩大出来的全是0。
    4. 东亚地区的国家和地区的人民也不爱用UCS-2,因为虽然在UCS-2中,一个汉字仍然是2个字节,但是与本国的标准不一致啊,例如在我国,在UCS-2中和在GB2312-1980中,同一个汉字有不同的编码,同一个编码对应不同的汉字。

现在情况就很尴尬了,通用字符集出来了,但是由于效率和兼容的考虑,大家都不愿意直接用字符集中字符的编号。所以对UCS编码要进行转换,大家才能接受使用。现在我们就要区分开两个概念了,一个是字符集(character set),另一个是字符编码(encoding)。字符集就是我们能表达的字符的集合,而字符编码是如何把字符集中的字符进行编码。UCS/Unicode就是大家共同使用的字符集,但是对同一个字符集,可以给出不同的字符编码方案。以下是我们现在广泛使用的几种字符编码:

  • GB18030-2005。这是我国目前使用的强制国家标准,是对UCS/Unicode的一种字符编码方案。它的特点的是采用单、双和四字节的变长编码方案,单字节兼容ASCII码,双字节兼容GB2312-1980和GBK中汉字编码,而四字节部分处理罕用汉字和部分少数民族文字。
  • UTF-16。它采用双字节/四字节编码方案,Unicode中的BMP字符直接对应双字节部分,而超出BMP的字符则采用代理对的方式,用四字节表示一个字符。在计算机底层系统中,很多采用UTF-16字符编码方案的,如Java虚拟机中和Windows内核中(Windows 2000以后)。
  • UTF-8。这是互联网中使用最广泛的字符编码方案,也是事实标准。它采用1-4字节的变长编码方案。英文采用单字节编码,与ASCII兼容,西欧其他语言的字符一般采用2字节编码,常用汉字采用3字节方案编码,罕用字符采用4字节编码。UTF-8的优点:
    1. 对ASCII极佳的兼容性,英文仍然是单字节;
    2. 没有字节序和讨厌的BOM问题;
    3. 可以编码自纠错;
      UTF-8对中文使用者来讲的缺点,是常用汉字采用3字节编码,与GB18030-2005中常用汉字采用2字节编码相比,常用汉字的占的空间扩大了50%。
  • UTF-32。就是UCS-4。

字符集与字符编码的关系,打个比方,比如一个学校有10万学生,这10万学生就是字符集,那么怎么能唯一的找到一个学生呢?有很多种编码方案,比如,用身份证号可以定位一个学生,也可以用全校唯一的学号,也可以用班号+班内小号。所以现在汉字字符集和字符编码的关系,就是这个关系,一个字符集(Unicode),多种编码方案(GB18030-2005,UTF-16,UTF-8,UTF-32等等)

发表在 计算机技术 | 标签为 , , , , , , | 留下评论

“基于Angular的Web开发课程建设”项目获批

根据2016年10月22日《教育部高等教育司关于公布有关企业支持的产学合作协同育人项目申报指南(2016年第二批)的函(教高司函[2016]48号)》,我们申报了其中的“2016年秋季学期Google支持教育部产学合作专业综合项目”,申报方向为“教学内容和课程体系改革”,申报题目为“基于Angular的Web开发课程建设”。

Google公司共收到了45所高校的53份有效申报。经过评选,共有4个课程教学内容和课程体系改革项目和5个师资培育区域联盟项目入选本轮资助名单。最终我们的申报获得了批准。

发表在 未分类 | 留下评论

欢迎加入项目开发小组

Java 开发
1、熟悉Java语言,具备面向对象程序设计思想,了解设计模式。
2、熟悉数据结构、数据库等相关基础
3、熟悉并使用spring、hibernate/mybatis等技术,熟悉tomcat。

前端开发:
1、熟悉精通HTML、CSS、JavaScript,熟悉JQuery
2、了解Angular/react/vue.js等前端框架,了解JavaScript设计模式
3、了解node.js

如果你对上述二个方向其中一个有一定的经验,欢迎加入到项目开发组中,有实际开发项目的机会。如果只有兴趣没有经验,可以加入进来先进行学习储备技术。

有兴趣的同学可以邮件联系我:ligang{at}tju.edu.cn

发表在 未分类 | 留下评论