アカウント名:
パスワード:
＞文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ...
この件がどうかは知りませんが、自治体の案件では人名とか地名を扱うことが多いので、 JISの第２水準までに含まれないような文字が使用できるように求められることがよくあります。 今は Unicode系を使えばなんとかなるのですが、
包摂して実用上問題ないものでも、 利用部門が (場合によっては門外漢のお偉いさんが)「これと同じ形で見えなきゃダメだ」の一点張りだったりします。
Unicode以前は各ベンダーから独自に自治体対応に拡張したコード系が提供されていたので、そんなのを使用して実装していたようです。
というか、業務を知りもしないで「Unicode にすれば大丈夫です！」みたいな嘘八百の提案書を役所の上の人に見せるのはやめてくれ > 某外資系コンサル # ほかにも XML とか SOAP とかオープンシステムとかオープンソースとかクライアント・サーバとかシンクライアントとか、 彼らがどこかで聞いてきただけの単語を並べるだけの提案が色々……
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:1, 興味深い)
＞文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ...
って…、まっとうなソフト会社じゃなくて素人さんに発注してしまったんじゃないのん？Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:0)
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:2, 興味深い)
今は Unicode系を使えばなんとかなるのですが、Unicode以前は各ベンダーから独自に自治体対応に拡張したコード系が提供されていたので、そんなのを使用して実装していたようです。
で、そうゆう事情を知らずにシステムを内部を 普通にただのEUC(シフトJISでも)に依存した方式で実装してしまうと、JIS外の文字が化けるという不具合になります。
あ、ひょっとして、Windowsに変えるってのは、Unicodeの使用が関係するのかな？
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:2, すばらしい洞察)
包摂して実用上問題ないものでも、 利用部門が (場合によっては門外漢のお偉いさんが)「これと同じ形で見えなきゃダメだ」の一点張りだったりします。
オープンシステムに移行しても、 他のレガシーな業務システムとの連携の都合で JEF コード等をベースにすることはあります。外字に独自にコードを割り当て (自治体や業務によって包摂基準が変わるので共通化すらできません)、 フォントを作成し、 情報交換用の変換テーブルを作成するのです。
というか、業務を知りもしないで「Unicode にすれば大丈夫です！」みたいな嘘八百の提案書を役所の上の人に見せるのはやめてくれ > 某外資系コンサル
# ほかにも XML とか SOAP とかオープンシステムとかオープンソースとかクライアント・サーバとかシンクライアントとか、 彼らがどこかで聞いてきただけの単語を並べるだけの提案が色々……
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:1)
法律で、公務所等で行う電子化する事務ではJIS(日本工業規格)の情報交換用*文字符号に含まれる文字だけの使用に強制にすべき時期と思います。必要ならば第5? 水準とかも制定する前提で。いい加減ローカルなJISで標準的な文字表現を可能にしないと、特殊仕様のコストやらがかさんでIT化に因る種々のご利益を国民が享受できなくなります。
# でなきゃ、JISの存在価値無し。
## 可能性0に近いでせうが将来Unicodeに入れる(てもらう)為にも、ローカル規格の使用実績が不可欠でせう。
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:1)
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:1, 参考になる)
実装する言語も１種類だとかなら楽勝案件にしか見えませんが、
公共系の帳票印刷というのは、DB格納も画面表示も極めて特殊です。
インターネットでは半角カナは推奨されていないから、入力を許さないとか、
このコード体系にはこの文字が無いとか、技術的正論は通用しない上に、
それをオープン系で行うとなると更にアプリ間の連携でつまづいてしまう、
受注した側は例えばMySQLの開発をするつもりは無かったわけだから、
当初の契約金額と見合わない作業が発生してしまうので予算追加を依頼する。
そのような想定外のトラブルを当然のように見込んでいて、解決するほうが特例的でしょう。
たとえばMSのように人的リソースが潤沢で、公共系の受注実績を維持したい所なら
サクッと対処してくれるけど（但しMS製品の置き換えプレッシャー込みで）。
なんで出来ないのか、と簡単に思うほうが素人さんです。
発注側の市には、当然そうした知識が無いからアカデミーあおもりが中間に入ったんでしょうが。
データ移行部分は、タタというインドの会社に依頼したとか上のほうのソースにあったけど、
タタは契約期間が来たからって事で離脱しちゃったみたいね。
タタに振った仕事が単純で、それを完璧にこなしていたから許可したのだろうか。
個人的には、韓国企業やインド企業に日本語のデータを扱わせるのは、
かならず後で問題が発生する経験ばかりなんだけど、どうだったのだろうか。
OECの見通し・予備調査・技術力が甘かったというのも確かだけど、
技術的対策のための追加予算が出なかったり、パートナー企業が途中離脱したり、
プロジェクトとして空中分解しないほうがおかしい要因に満ち溢れていた。
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:0)
公共の仕事に手を出す以上、「想定外のトラブル」ではなく想定してない方がアホです。
特例でもなんでもない。