这篇文章，针对网站的移动开发，对刚刚开始进行开发时应该注意的事项进行了说明。
面向手机和面向PC的web页面的差异
作为能访问网络的移动设备，纵使全屏下访问且能有与PC上相似的操作感，作为手机主要被使用的网络连接方法iモード，EZWeb、SoftBank与PC上仍有相当多的部分不同。那些未知的地方，经常会出现碰到在手机上无法确认实际的画面的问题。
“手机的web站点开发和PC上web站点开发有哪些不同呢？”要回答这简短的问题，列举了与PC上的差异如下：
1，有无字符文字和字符编码
手机特有的文字表现方式。在应用字符文字时，SoftBank的手机必须和iモード／EZweb的手机分别对待。同样，PC上也是如此。因此，在使用iモード、EZweb时必须返回Shift-JIS字符编码，而使用SoftBank时如果不返回UTF-8字符编码。表格标签等图画文字的丢失容易发生，所以推荐使用UFT-8字符集。
2，不能使用Cookie
iモード等不能使用能保持登录状态的Cookie。因此面向移动的web应用服务开发的架构很难应付。在制作具有用户登录功能的站点时，一定要考虑到这个。
3，不能使用外部样式表
样式表是最近几种手机机型常使用的结构，但是，DOCOMO等不能读取外部CSS的情况需要注意。
4，访问站点时IP地址的改变
因为移动设备是通过网关访问web站点的，因此使用的是网关的IP地址。因为网关能给多个移动设备分配IP地址
所以，在多次访问中，可能会出现相同的设备分配了不一样的IP地址，或者相同的IP对对应着不同的移动设备。
5，不同机种的可视面积大小不同
手机的可视面积可能不一样，手机根据机种的不同所能表示的文字字数和画面大小是不一样的。
对于这个情况，出现了两种解决方法。按照可视面积小的机种调整文字显示数量和画面大小，或者根据不同机种决定现在画面大小。
6，邮箱地址的检测方法
对于移动设备，每个用户都能设定自己的邮箱地址，因此在用户输入中可能会出现并不被允许的格式或字符。
在定义了邮箱地址的RFC 2821文档中，“.”不能成为是邮箱地址用户名的第一个和最后一个字符，但是docomo和au等却允许使用。对于邮箱地址的描述检测，根据RFC标准检测，像上述所说的邮箱地址在出现时应该特别注意。
7，画面的表示
根据移动设备的不同，机种画面的表现格式和大小容量都有所不同。
现在大部分的载体使用机种都采用JPEG这种格式。
如果使用GIF格式，SoftBank的二代手机无法显示，请注意。
8，动画的表示
动画的表示，与画面对于的情况类似。目前为止任何情况都能用使用的格式还不存在。另一方面，是否能根据动画显示尺寸进行处理，根据机种的判断来转换是必要的。
9，SSL在非常规情况下不能利用
在移动设备使用SSL时，必须要导入正规的证书。
那些需要SSL证书的站点，即使能用PC迅速使用适当的SSL证书进行访问，在移动设备下经常会出现“证书不正确”的提示而无法访问站点。利用SSL时从验证服务器申请证书是必须的。设备的不同能够利用的证书也不同。VeriSign提供的针对移动设备使用的证书也根据不同的设备而大不相同。
利用框架轻松进行web开发
对于开发前应该进行的机型上，通用的框架和登录状态的维持相关进行讲解。（编者按）
开发前“要决定对于机型的范围啊！”
在前篇《移动设备web开发的九点注意事项》中，介绍了打算对于手机等移动设备进行web开发时应该注意的九点问题。这个篇章中，在决定了于开发所对应的机型后，对通用的框架和登录状态的维持相关进行讲解。
首先，从开发前所决定的机型出发，在制作手机对应的web站点时，首先必须要决定下来的，是采用何种机型和载体。
例如。为了对行2000年左右时的机型，图像的格式根据机型的判断应该使用PNG来表示……等等的设定是非常花费时间的。采用最初9年前的机型的用户还有多少呢？
而且，即使拥有3G的手机动画的容量还是有限制××，1M大小的动画在想要下载的时候，老的手机对于的情况必须要除外。假设要应对这种情况，必要要开发分割动画的系统，工期需要增加，而且为了要看一个动画在下载时需要下载几个文件，易用性也就没有了～
接下来在开发前研究验证方法
但是，只注意那几种手机的机型的话，用怎么的方法去检测（手机的机型各种意图检测出租房间服务）产生的费用谁来承担，或者，也许有不适合的条件，如果；忽视旧的机型，站点的规模和预算合计后，事先决定下来是很必要的。
移动站点的开发中对于载体、机型的操作变化了，用web应用程序替换表示等时候对于机型判断的能力和字符文字的转换是必要的。
机型信息放在UserAgent里面，UserAgent的格式有如下几种
iモード的时候
DoCoMo/1.0/机型名
DoCoMo/1.0/机型名/cache
DoCoMo/1.0/机型名/cache/识别情报
DoCoMo/2.0<SP>机型名(cache;识别情报)
DoCoMo/1.0/机型名/cache/状態code/识别情报
DoCoMo/2.0<SP>机型名(cache;状態code;识别情报)
DoCoMo/1.0/机型名/cache/状態code/游览器表示可能比特数/识别情报
DoCoMo/2.0<SP>机型名(cache;状態code;游览器表示可能比特数;识别情报)
iモード对应机型识别的帮助页面（HTTP_USER_AGENT）
EZweb的时候
SoftBank的时候
虽然基于UserAgent的信息判别载体和机型是必要的。但是这个判别程序的编写，字符文字变化的对应表自动生成，定期更新最新情报的工作，是非常费力的。
因为这个原因，推荐利用框架和和即插型和库
例如，如果使用Ruby on Rails是，使用jpmobile插件，
- 移动设备的载体判别
- 用户端位置信息的取得
- 用户端制造编号，合同号等的取得
- IP地址的验证（从载体公开IP地址访问域来的访问判定）
- sessionID
- 移动设备显示界面自动配置
- 显示信息（界面大小，浏览器大小，色彩信息）的取得
- 与GeoKit（http://geokit.rubyforge.org）的链接
- 文字CODE转换功能／字符文字不同载体间的转换
如上的功能可以利用
此外，如果使用Perl，2008年5月，采用DeNA的MobaSif公开，
- 移动设备的载体判别
- 机型的判定
- 用户端的认证
- 字符文字转换
- 3种载体对应的模板
以上的功能可以利用
机型判别和字符文字的表示等，无论站点发生不大的变化之前，定期的更新是必要的，所以，上述说的库的使用，版本更新推荐使用。
以上是移动web开发的基本事项。
总结下、
- PC和移动设备不同造成的困难需要注意
- 对应机型的验证方法事先定义
- 框架和库的使用后，机型的判别，字符文字的表示更容易的实施
如上3点。
移动web开发，今后IPhone和Google的Android的登场，被认为与PC上站点更加相似。但是仍然移动设备的原因特殊的处理是很必要的。
画面1 Silverlight 2 Beta 2代表的控制
登录功能的实现「不使用Cookie的前提下、IP地址分析……」
会员页面等登录功能的实施是必要的在上篇文章中已经讲述过了，但是iモード不能使用Cookie，而且，想要进行IP地址的判断，IP地址在每次访问时都会变化，不同用户终端使用同样的IP地址访问时，无法判断信息。
库对应的情况，无法对应的时候，作为解决方法，session信息固定URL持有方法，机型固有IP判别两种方法。
1. session情報固定持有URL的情况
这是像mixi等经常需要登录状态的站点浏览时必要的方法。
在登录时，向a标签的链接跳转的时候，通过经常的程序，这个用户的sessionID会作为URL后面的参数附加上去。
<pre>
<a href="/home?session_id=de431u78i4efdaeiq">ホームへ</a>
</pre>
因为完整的HTML的a标签的后面添加是很必要的，虽然稍微有些费事，这样做的sessionID的信息判断后，能够区别用户的登录情况。
这个时候，每次登陆时随机的字符串方式的sessionID的分配是必须的，请注意。
如果sessionID像1，2，3……的形式增加的话，下个sessionID能够被轻易地推测出，可能会受到恶意攻击。
2.机型有固定ID的判别
这种方法，只在用户评论的发表时信息的判别能够识别时使用。
登录用户的终端制造编号在作为事先的会员信息记录下，然后访问时终端制造编号确认一致后用户的登录被确认。
终端制造编号，当是DoCoMo时，可以从a标签和form标签等中，utn属性中取得。
<pre>
<A href="URL" utn>
<FORM method="メソッド" action="URL" utn>
</pre>
这时，确认画面会出现在用户面前。
用户同意把终端制造编号发送过来的情况，在UserAgent能够包含信息，所以可以使用库的功能和正则表达式等。
另外，在PC端访问的时候，通过一些工具使用用特定的UserAgent访问请注意判别。
首次访问的IP地址在不能判断是DoCoMo的iモード使用的IP地址时，能够通过UserAgent的伪装，进行欺骗。
1700
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
