#
自从TGV东线开通之后，每天都有4班德国高铁的ICE列车往返于巴黎东站与德国法兰克福和斯图加特。Rene很少去那个角落，也就一直无缘目睹德国ICE的尊容。这次姐夫来法国出差，正好要从东站出发去Strasbourg。无意中发现了停在我们旁边的ICE，雪白的车身、流线型的车头还有车身上的ICE，以及德国高铁在车头的标志都显出了一种高贵。这点连旁边TGV Duplex的最新款都比不上。只可惜身边没有带相机，只能用手机凑合一下了……
ICE@Paris Gare de l'Est
Originally uploaded by Rene ZHU
星期五用了一天RTT，去了中国使馆拿到了新护照。这次换护照还算是顺利，无论是上个月22号去交材料，还是这次去取件。收了45€，还算是比较贵的，如果和在国内换的话。原来的护照有效期是5年，这次换了10年有效的。
想想5年前，办护照的时候，Rene还在上海，连出国的眉目还没有理清。5年后的今天，已经在巴黎工作了一年多了。那么10年之后呢？我会在哪里换护照？上海还是巴黎？仰或是其他某个城市。
接下来又要去Préfecture排队换居留了…… 
小时候刚开始学程序设计的时候就为了中文编码而头痛，尤其是做JSP的时候。不是页面显示不对，就是参数获取上有问题。记得经常和Vincent两个人很快把程序架构写好后，要为了字符编码问题忙上好久。
在第一次飞法国的飞机上就想过，终于可以不用为了编码而困扰了。工作后，公司的项目都是英、法、德三种语言，没有超越Latin1字符集。默认的工作环境也是ISO-8859-1编码集。一年多以来，倒也是相安无事。
最近，开始了一个新项目。不算很大的工作量，也没有什么陌生的技术，一开始进展很是顺利。但是在实际测试时发现了问题，就是表单数据的字符编码。这个项目有两个版本，罗马尼亚语和土耳其语。这两种语言都超越了西欧Latin1字符集，却又分属于ISO-8859-2和ISO-8859-9两个不同的编码集。
其实完全可以全部用UTF-8编码了事。但是公司的Tomcat和MySQL全局环境都显式配置为ISO-8859-1，而且在庞大的底层程序中有好几处都硬编码成Latin1。更改全局配置是不可能的，也不想冒极大的风险来修改底层类。
最后完全迷失于编码转换中……很神奇的是没有乱码出现。Latin1以外的字符被转换成HTML格式编码了。所以就用了很恶心的方法，把读入的表单数据从8859-1读入转换成UTF-8（HTML <-> UTF是很容易的）后再转成8859-2/9显示（由于客户方终端不支持UTF-8方案，不能直接用输出Unicode）。尽管8859-1编码集不支持Latin1字符集以外的字符，但是这层转换的内部处理还是通过Unicode，不存在信息丢失问题。说白了就是UTF-8 -> ISO。
不过数据库中的数据却始终无法正常存储。数据永远以乱码读出，而且无法转换。奇怪的是，如果把控制台编码换成8859-2/9的话，可以在数据库中看到正确的数据。但是运行
SELECT HEX(column) FROM table得到的结果却是错误的。获得的十六进制编码是信息经过
8859-1编码后的Unicode值。这个问题涉及到系统底层类，数据库配置等多个方面。Rene甚至不知道在数据库中贮存的到底是什么。
最后的理解是这样的，底层接口类把数据转换成8859-1编码存入数据库，同样也以8859-1读出。SQL请求以字节流返回，这也说明了在控制台下可以用8859-2/9编码看到正确结果。但是中间结果由于全局配置的关系，被编码成8859-1，所以显示的Unicode值不对。在程序中，由于数据取出后被强制转换成8859-1编码，所以造成了信息丢失。就再也找不回Latin1以外的字符了。
最终的解决方案，让Rene恶心到可以从Montparnasse上跳下来。由于数据在存入数据库前是正确的，其实在存入时也是正确的。所以打算在存入前，把信息转成十六进制编码。理论上应该是可行的，就是会很难看，非常非常难看。
天气开始转凉了，今年比去年冷得早些，还没到供暖的日子。巴黎的劳苦大众们就纷纷走上大街活动一下有些冻僵的身子。早上到火车站，老远看到月台上站满了人，心中就开始有些不安起来。没想到这么早就开始了……看到屏幕上一排Supprimé，终于确信SNCF开始罢工了。车不是很少，因为明天才正式开始。但是很挤，也很慢。从Val d’Argenteuil到巴黎原本20分钟的路程，大约用了快40分。到Paris St. Lazare那段几乎就是在挪动，因为车站没有地方停车:(没有赶上08h46的快车，只好坐后一班站站停的慢车。
窗外风景不错，早晨的太阳躲在铁塔后边，一缕缕晨曦洒在河水上。过了La Défence，就从Mont Valérien上走了，可以俯瞰整个市区，直到蒙马特高地上的圣心。整个巴黎大致是平的，铁塔高高矗立在那里，是个很不错的地标。熟悉方位的话，依稀可以辨别出凯旋门还有荣军院。当然，还有Monparnasse大楼，像座墓碑一般插在那里，大煞风景。
明天罢工继续，尽管这次只有3家工会参加，但是Rene的线路全部影响到。准备早些去公司，早些回家。一定要赶上18h43的那趟车，否则就会很惨了。SNCF之后会是哪个呢？估计RATP会很快响应的吧。希望这次不要像去年年底那样持续1个月就好了。坐St. Lazare这条线的人还真是苦，每次都会影响到~~
尽管欧洲央行决定维持原有的指导利率不变，但是法国政府依旧下调了A本储蓄（Livret A）的利率，由第二季度的1.75%下调至1.25%。各银行的其他短期金融产品利率也纷纷下降：
可持续发展储蓄（Livret de Développement Durable）：1.75% -> 1.25%
大众储蓄（Livret d’Epargne Populaire）：2.25% -> 1.75%
LCL的普通储蓄账户（Compte sur Livret）：1.25% -> 1%
ING的橙色储蓄账户（Livret Epargne Orange）：2.25% -> 2%
先要为马萨祝福，赶快康复。F1今年的规则变动太大，工作后也实在没有精力去仔细研究。慢慢地也就不看比赛了。但是心里还是关心着的。
晚上看新闻，在马萨缺席的这段时间，Shumi又要回来了。很诧异Ferrari的决策，按常理应该是选择Badoer。Shumi无论是年龄还是对车以及新规则的熟悉程度都不占优势。Rene对于赛季后段的成绩并没有大的期待。不过Shumi以40岁的年龄回归本身已经是奇迹了。
新加坡的夜战应该还是很有看头的，对于每个人都是新的环境、新的赛道。时间对于Shumi还是有利的，夏季休赛的三周正好可以用来恢复体能，熟悉新赛车的性能与调教。也许要放弃休假，德国人应该是能够做到的，幸好不是法国人J
8月23号欧洲站，西班牙瓦伦西亚赛道，又要开始看比赛了……
SimpleDateFormat是一个很好用的日期转换工具类。使用它，开发者可以很方便地按照预先定义的格式在字符串和Date对象间转换。Rene在工作中也经常用到它。平时遇到的日期格式大多为dd/MM/yyyy的欧洲标准短格式，没有什么太多好注意的地方。
但是有时也会遇到长格式（Mon, 07/26/2009 09:00:00 +0200），其实就是星期的中长度格式表达，中长度格式日期 时区。那么日期描述字符串就是EEE, dd/MM/yyyy HH:mm:ss Z。
说了那么多还没有进入重点。问题是运行时总是报解析错误异常。反复检查日期描述字符串，确认是正确的。突然想到是Locale的问题。由于在法国工作，Locale的默认设置当然是法语法国，问题就来了。在法语中星期一（Lundi）的短格式表达是Lun，用它来解析英语的Mon（Monday）当然是错误的。这个时候就需要在初始化SimpleDateFormat对象的时候，设置一下Locale值，对于Rene的情况，改成Locale.UK就可以了。不知道在中国会不会也有相同的情况呢？
平时还是短格式用的多些。突然遇上长格式一时会不注意，切记，切记~~
40年前，3个人在几千名同类的帮助下离开地球，成功登陆月球并安全返回。40年后的今天，人类依旧生活在地球上……
摘要: 隔了一天的9月19日，6点刚过出门，6点半就到préfecture开始排队，这次终于拿到票子了。当时情况挺紧急的，第一个CDD按原来居留时间签的，到10月底到期，RCPC只到12月。这样第二个CDD也只能到12月。老板的意思是希望我可以去重新换个期限长点的RCPC，这样就可以签个时限长些的CDD直至转身份结束。回答是Val de Marne（94）的Préfecture。春节那天是1月26号，休了一天RTT，又一次准时出现在了Préfecture门前的长龙队伍里。还问我要了工作许可做复印，觉得很奇怪，按理说Préfecture自己应该会收到一个副本的。一周后的2月27号，又去Préfecture交体检证明。回到Préfecture交了体检证明，又问我要了ANAEM盖章的格式合同复印，之后开始新一轮的等待。到了4月21号，一直都没有消息，RCPC再次临近过期，就又去了Préfecture排队。写了Salarié，电脑工程师，工作地点是整个法国本土。信上的日期是4月6号，不过Préfecture每月底寄一次通知，害我多等了将近一个月。
阅读全文