パスワードを忘れた? アカウント作成

XML誕生から20年」記事へのコメント

  • XMLとその関連技術は素晴らしすぎて、20年後の現在もかなり完成されているように見える。
    今はJSON好きが多いけれど、XMLより劣る点は多い。
    現在でもつかわれるプロトコルとして、SMTPとかのメール周りは改良点は多数あるし(参考 [srad.jp])、HTMLは実際手を入れられているが再設計するならかなり良くなるだろう。
    その点でXMLをより良くするなら、今の視点で設計するなら、というのはテーマとして面白いと思う。

    自分としては、

    • 属性を要素に展開する標準的な手法の規定(XAMLではある)。
    • 一般のバイナリを記述できるスキーマ
    • by Anonymous Coward on 2018年02月12日 17時58分 (#3360248)

      「charset が出現するまでは必ず ASCII コード」という規約が欲しい
      いや、BOM なし UTF-16 な XML なんて存在しないならどうでもいいのですが。

      # オレオレパーサを書くのが一番悪いってのはわかっているのですが

      • by Anonymous Coward

        いや、それマトモにテキストエディタで開けないから駄目だろ

        • by Anonymous Coward

          同じ理由で大きなバイナリを埋め込む仕組みとかの拡張も無理そう。
          PDFとか基本テキストベースのはずが読める気がしない。

        • by Anonymous Coward

          途中で文字コードが変わるテキストデータの話ではなく、文字コードの判別方法に関してです。

          BOM つき UTF-16→わかる
          7bit 領域は ASCII 互換→charset の結果でわかる(SJIS とか UTF-8 とか)
          BOM なし UTF-16→ビッグエンディアンの UTF-16 と判別して読み込む(が、どう判別する?)

          2 番目まで処理してパースに失敗したら 3 番目処理して、というのが現実的な解でしょうか?
          (これだけのために文字コード判別のライブラリとか組み込みたくないので)

          • BOMとか見るなら、頭2バイト見ればわかるんじゃないの?

            0x3c 0x3f ならASCII互換の「<?」なのでencoding指定まで読み進める
            0xFE 0xFF ならUTF-16のBig Endian
            0xFF 0xFE ならUTF-16またはUTF-32のLIttle Endian(UTF-16とUTF-32の確定ができないので4byte目まで読む必要がある)
            0x00 0x00 ならUTF-32のBig Endianの可能性が高い(4byte目まで見ないとBOMか確定はできない)
            0xEF 0xBB BOMありUTF-8(厳密には3byte目の0xBFまでがBOMだけど)
            0x00 0x3c ならUTF-16のBE(BOMなし)
            0x3c 0x00 ならUTF-16またはUTF-32のLE
            それ以外ならXMLではない

            という判定をすれば事足りるよねっていう?

      • by Anonymous Coward

        HTML 5.1ならば、文字コードはutf-8固定になるようですがね〜

犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー

処理中...