xml schema での datetime の扱い
Time Zones
To specify a time zone, you can either enter a dateTime in UTC time by adding a "Z" behind the time - like this:
http://www.w3schools.com/Schema/schema_dtypes_date.asp
<startdate>2002-05-30T09:30:10Z</startdate>
soap でやり取りしてる datetime 型が、送信した時刻から9時間ずれて送信されるーー、という事象。
実はずれているのではなく、末尾に 'Z' が付与されている場合、GMT のタイムゾーンとして取り扱われているだけ。
特に難しい話ではなさそうなのだが、時にややこしい。
<birthday xsi:type="xsd:dateTime">1971-02-01T15:00:00.000Z</birthday>
この人は、JST では 2月2日が誕生日。だけど、datetime 型でそれを送信する場合、年月日情報に単純に時分秒を0で埋めて、
1971-02-01 00:00:00
を JST で設定すると、soap では、GMT(1971-02-01 15:00) で送信される場合がある。二つは同じ意味なので何の問題も無いのだが、timezone の認識が無いとハマる原因になる。
「誕生日」や「カード有効期限」なんかの時分秒までの精度が無い情報は文字列として最初から取り扱ったほうが安全そうだ。
で、疑問点。タイムゾーンの指定(Z とか、-9:00 とか)は optional のようだが、この指定をしない場合、そのデータは GMT として扱われるのだろうか?実装依存なのか、XML Schema で定められているのか、今のところ見つけられていない。
java で chmod とか使うための 6 つの方法
http://www.experts-exchange.com/articles/Programming/Languages/Java/File-permissions-with-Java.html
より、
システムコールを使う
String fileName = "/path/to/file", Process proc = Runtime.getRuntime().exec("chmod 755 " + fileName);
JNA を使う。
JDK1.4 以上であれば、上記の代替として JNA が使える。
import com.sun.jna.Library; import com.sun.jna.Native; public class ChmodTest { private static LinkedOSLibrary linkedLibrary = (LinkedOSLibrary ) Native.loadLibrary("c", LinkedOSLibrary.class); public static void main(String[] args) { linkedLibrary.chmod("/path/to/file", 0755); } } interface LinkedOSLibrary extends Library { public int chmod(String path, int mode); }
JTux を使う
Unix コマンドのラッパライブラリとして JTux(Java To UNix)というのがある。ほとんどの Unix コマンドをラップしている。
UFile.chmod("/path/to/file/", 0775);
java.io.File を使う。(ただし、Java6 以上)
Java6 以降であれば、java.io.File に setReadable、setWriteable、setExecutable の3つのメソッドが追加されている。ファイルの rwx だけは変更できるようになっている。これ以外のことは出来ないので、限定的な対応といえる。
失われたライブラリ(The lost library)を使う
Xenon Soft という会社が、Javaunix という JTux に似たライブラリを昔作っていたが、もはや手に入らない。
以上。詳細は上記記事を参照してくださいませ。
axis のレスポンスで、日本語文字列がUTF-16の数値文字参照に置き換わってしまう件。
なんでいまさら axis1 なんて?というのはおいといて、他にもいろいろ問題があり、axis 関連で丸々一週間持っていかれたので・・・。恨みをこめてここに記す。(もっとマシな解決方法あったら教えてください。ぜひ)
axis の組み立てるレスポンスが、UTF-8 ではなく、UTF-16 の、しかも数値文字参照(ሴ みたいな)に置き換わってしまう、という問題。要するに Java の内部文字表現がそのまま数値文字参照に置き換えられてるわけだ。
[AXIS-840] Character entities are escaped too aggressively - ASF JIRA
[AXIS-2342] Reopen issue: Character entities are escaped too aggressively - ASF JIRA
あたりが該当の issue。
1.4 で再現。けどたぶん、1.2、1.3 でも同じ問題が出そう。
これ、Java クライアントでは内部文字表現が UTF-16 なので、(偶然)問題が発覚しないのだが、PHP4 みたいな、Java 以外の言語だと文字化けとして発火する。
とりあえず、axis の、org.apache.axis.components.encoding.UTF8Encoder を上書きすることで解決した。修正内容は
if (character < 0x20) { throw new IllegalArgumentException(Messages.getMessage( "invalidXmlCharacter00", Integer.toHexString(character), xmlString.substring(0, i))); } else if (character > 0x7F) { writer.write("&#x"); writer.write(Integer.toHexString(character).toUpperCase()); writer.write(";"); } else { writer.write(character); }
の、 else if 部が諸悪の根源なので、ここをコメントアウトするだけ。全ソースを以下に貼り付けておく。
/* * Copyright 2001-2004 The Apache Software Foundation. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package org.apache.axis.components.encoding; import org.apache.axis.i18n.Messages; import java.io.IOException; import java.io.Writer; /** * UTF-8 Encoder. * * @author <a href="mailto:jens@void.fm">Jens Schumann</a> * @see <a href="http://encoding.org">encoding.org</a> * @see <a href="http://czyborra.com/utf/#UTF-8">UTF 8 explained</a> */ public class UTF8Encoder extends AbstractXMLEncoder { /** * gets the encoding supported by this encoder * * @return string */ public String getEncoding() { return XMLEncoderFactory.ENCODING_UTF_8; } /** * write the encoded version of a given string * * @param writer writer to write this string to * @param xmlString string to be encoded */ public void writeEncoded(Writer writer, String xmlString) throws IOException { if (xmlString == null) { return; } int length = xmlString.length(); char character; for (int i = 0; i < length; i++) { character = xmlString.charAt( i ); switch (character) { // we don't care about single quotes since axis will // use double quotes anyway case '&': writer.write(AMP); break; case '"': writer.write(QUOTE); break; case '<': writer.write(LESS); break; case '>': writer.write(GREATER); break; case '\n': writer.write(LF); break; case '\r': writer.write(CR); break; case '\t': writer.write(TAB); break; default: if (character < 0x20) { throw new IllegalArgumentException(Messages.getMessage( "invalidXmlCharacter00", Integer.toHexString(character), xmlString.substring(0, i))); // } else if (character > 0x7F) { // writer.write("&#x"); // writer.write(Integer.toHexString(character).toUpperCase()); // writer.write(";"); } else { writer.write(character); } break; } } } }
エンコーダーを別のもの指定するとか、なんかもうちょっと綺麗な対処方法がある気がするので、何かあればぜひご指摘くださいmm
vi で文字コードを指定してファイルを開きなおす
:e ++enc=euc-jp
やっぱCore2 すげーわって思った件
長年、Pentium4 のマシンを会社で開発で使用してきたが、あまりの遅さに耐えかねて、交換してもらった。
交換してもらったマシンは Pentium D である。なんでいまさら D だよって話なんだけど、まあ、今までよりはましだ。これで体感でも多少の改善があった。
しかし、同僚の使用している Core2 duo マシンは、桁の違う性能。主に Eclipse での体感になるが、数倍くらい違うように感じる。
私のマシンはメモリ 2GB 積んでて、同僚の Core2 duo は 1GB である。スワップ発生するような状況では私のマシンの方が快適かもしれないが、多少いじった程度ではそこまでメモリはシビアではないので、メモリの影響はあまり無かったのだろう。
いやー、やっぱすごいなと今更に思った。・・・っていうかね、交換マシンなら最新の CPU にしてよほんと・・・。