アカウント名:
パスワード:
2文字なのは確定してるんだから、設定で変えられるようにしてテストしろよまさか、埋め込んでるの!?
新元号の文字コードが、よりによってShift_JISで0x5cを含むいわゆるShift_JISのダメ文字になってたりして。
そんな予想したらフラグ立ちそうで怖いよ~~~ホントやめてください。そんな事になったら、本当に死亡するSIer出てきそう。
その辺の話を政府に苦言なり進言なりあげられるロビイストは日本のIT業界にいないの?特定の文字コードによるトラブルなんてのは、流石に専門家の立場から進言しないと問題点が伝わらない例だと思うけど…。# 日本IT業界の黒い話を聞く限りじゃ、政府との窓口役は皆安請け合いのクズばかりというのも有りそうだけど…o…rz
第1・2水準から選ばれるなら次の34字。なんか平易な文字という縛りがあるみたいだから「圭」「構」「十」「申」「貼」「能」「表」「暴」「予」ぐらいか。あまり使えそうにないかな?
噂浬欺圭構蚕十申曾箪貼能表暴予禄兔喀媾彌拿杤歃濬畚秉綵臀藹觸軆鐔饅鷭
― ソ Ы Ⅸ 噂 浬 欺 圭 構 蚕 十 申 曾 箪 貼 能表 暴 予 禄 兔 喀 媾 彌 拿 杤 歃 濬 畚 秉 綵 臀藹 觸 軆 鐔 饅 鷭 纊 犾 偆 砡
どの文字のつもりで言いましたか?
テスト用のダミー元号を決めてIT業界内で統一しといて欲しい。
ケータイとかパソコンとかの時計を数年後に設定してバグ出し、とかやるときに、どのOS、どのサーバでやっても同じように表示されると分かりやすくて便利だし。うっかりそのまま修正を忘れて切り替えを迎えても、一目で切り替え漏れだと分かって楽だし。
# それがほんとの次の元号だと勘違いしちゃうやつらが一定数現れて混乱するのを指さして笑えるし
保気とか富賀とか羽下とかどうですか
カレンダーや手帳は設定では変えられないぞ。
アップデートで簡単に変えられるでしょ。
紙を?
電子ペーパーというものがあってだな・・・#何か違う。
元号の所を空白にして、決まったらシールを配るとか
# カレンダーはともかく、手帳は大変そうだな
ちゃんと開発できないやつは、よくこういうこと言うよね。テストの主旨がわかってないんだろうな。
問題なのは変える手間じゃなくて、ちゃんと変わるか予想外の問題が出てないか確認する手間なんだよ。「設定変えたので変わってるはず」で済むんだったら楽勝。
システムによっては外字作るか、Unicode に新しい文字を登録して、新しいフォント準備しなっくちゃならないとか、笑えるやつもあるし。
# 私は「OSの設定変えたので変わってるはず」で押し通すつもりだけど。
酷いシステムになると「文字列xが○○だったら~処理」みたいなのがハードコーディングされてたりして…# 何故可変のものを比較するのに固定値を埋め込んでしまうのか…
やっつけで対応したコードなんて、埋め込み山ほどあるでしょう。まぁ、昭和→平成問題で、和暦使わなくなったシステムも多い(特に民間)ので、「平成対応時の遺産」くらいじゃないのかなぁ。
SJISの$5Cに引っかかる元号になったら古いシステムで悲鳴が上がりそうだなw
> 2文字なのは確定 そう思わせといて3文字とかだったらマジで殺されますね。あと、「㍻」使ってる場合はやっぱり厳しいね。
元号は法律で漢字2文字と決まってるからそれはない。
確かに法律では決まってないね。決めたのは閣議報告。https://www.digital.archives.go.jp/das/contents/pdf/lossy/H11B00017200... [archives.go.jp]
葛城市の「葛城」(U+845B U+E0100 U+57CE)みたいにIVSを含んでいたりしたら大変です!漢字2文字と言いつつ、UCSで3文字、UTF-16で4ワード、UTF-8では10バイトもあります。2文字だから大丈夫なんて、甘い甘い。
10バイトだと何が困るのかさっぱりわからんのだが。むしろ10バイトだと対応できないような柔軟性のないコードで許される現場って、どんだけ甘いんだ。
すごい自信ですね。データベースのバイト長制限とか、帳票のレイアウトとか、文字コード変換とか、入力文字数のバリデーションとか、全文検索の異体字対応とか、思いつくことなんていくらでもあると思いますが・・・。そこまで十分に考えきっているシステムはほとんどないですね。同じUTF-8ですら、IVSのU+E0100を、いったんUTF-16のサロゲートペアにしてからUTF-8にして6バイトにしてしまう(それを正しいと定義している)処理系もありますからね。
まったく意味不明。挙げた例のすべてで年号変更が無関係。
データベースのバイト長制限 →もしかして、「平成」をUTF-8で表現すると10バイトになることを知らない人?帳票のレイアウト →表示が2文字のままで変わらないのだからレイアウトは影響ない文字コード変換 →意味不明。自分の言ってることわかってる?入力文字数のバリデーション →あなたのシステムは「平成」がバリデーションエラーになってたわけか全文検索の異体字対応 →文字単位の異体字対応なら年号無関係だし、そもそも極めて優先順位が低い
u5e73-ue0101とかだったらおもしろいな。そんなの見たことないけど。
バイトオーダーマークって1バイトでは無いよね…?NULLは入らないんじゃ無いかなUTF8ではBOMはそもそも必要ないけど
Pascal フォーマットで Length が32ビットなら10バイトになるかも。
UTF-8でPascalフォーマットでの保存ってシステムって見たことはないけど、世の中にはあるんだろうな。
そういう柔軟性の無いシステムの保守をやってるとか、改修をやってくれと泣きつかれたとか、そういうこともあるんですよあとOCRラインケチった旧システムを踏襲して元号コード無しの納付書とか・・・
君が実作業側で、発注者とか丸投げ上流ではないことを切に願います。切に願います。切 に 願 い ま す
>10バイトだと何が困るのかさっぱりわからんのだが。むしろ10バイトだと対応できないような柔軟性のないコードで許される現場って、どんだけ甘いんだ。自分で何も作ったことないのにドヤ顔でこういう頓珍漢なこと言うゆとり増えたよね
http://www.unicode.org/L2/L2017/17429-sc2-n4577-japan-new-era.pdf [unicode.org]UCSに新元号のコードポイントの予約要求してるけど、レガシーシステムをサポートするためだからBMPでないと困るとか言ってる。マジで北朝鮮の将軍様専用文字を笑えねーな。そこまでレガシーならシフトJISで使えなかったらどのみち困るんじゃねーの?
話は変わるけど、ISO/IECのJTC1/SC2も芝野がやめてからずいぶんと秘密主義に戻って、この文書も私企業連合であるUnicode Consortiumのほうがオープンに情報を出している始末というのもひどい
これはヒドい……
孝謙天皇「天平勝宝ですっ★」
改号に備えた提案をしても「ハードコーディングのほうが早くて安いならそっちで」というオーダーがあったという話を聞いてことはある。
過去には2文字を超える元号もあったよ。
過去は過去。今では元号を2文字にするというガイドラインがあるから
ルールは不変ではありませんよ
でもまだそれは予想であって確定じゃないから。直前になって3文字になった時点でアウト。それに対して文句を言ったところで、「想定してなかったお前らが悪い」って言われたらそれまで。
せめて漢字二文字にするって確約すればいいのに、なんでしないんだろうね。つまりは三文字以上にする余地を残しておきたいからでしょ。
#中にはこういうジョーク(?)も: https://www.j-cast.com/2018/01/17318824.html?p=all [j-cast.com]
本当にこれ。2000年問題から18年とか経って、改元時期も分かってるのに、盛り上がるかよりシステム屋の都合を優先しろとかどんだけ無能なんだとしか…。こんなもん最初のコンピューターが発明された時点ですら難しい問題ではないだろ。正気を疑うわ。
仮の元号を使用してテストができるシステム屋と、製造した後はアップデートが事実上不可能な印刷屋を一緒にするようなコメントはしちゃいけません。
ちなみに、お役所に提出する書類などは和暦必須のがあるようです。そういった書類にかかわるシステム屋さんは、逃げ道が減る分だけ大変かも。
#手帳・カレンダー業界をはじめとした各業界から混乱しないように早めの新元号公表を求められているにもかかわらずこの体たらくじゃ、「国民の生活に支障のないように」との今上陛下のお気持ちを完全に無視する所業ですな。#現政権は国民の声を無視することに慣れているので、今上陛下のお気持ちを無視するのも平気なんでしょうね。
お役所に提出する書類などは和暦必須のがあるようです。
そろそろ元号は伝統文化と割り切って仕事で使うのはボイコットしたい気分。
ひとまず大学の事務書類は全部西暦で提出するようにしてみようと思います。
皇紀でGO
ホルホルいらね
お役所の文書は全て和暦必須ですね。でも昭和64年の文書は出回ってたし平成元年が施行日の法律も再議決とかしなかったので、平成31年も改元後8ヵ月は有効かと。
必須っていうけど書き込み済みの元号を消して西暦で書いても受け取らなきゃいかんとか決まってなかったっけ何か通達とかあったような
本当は西暦拒否はダメなんだけど、実際には蹴られる。私の職場は大学だが、文部科学省に提出する前に大学の事務から書き直せと言われる。事務方と喧嘩してもロクなことがないから結局こっちが折れる。
なるほど…そういうの戦うのが好きな人に頑張ってもらわないとダメですね…
よし、小倉昌男さんを召喚しよう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
いやいや、馬鹿すぎだろ (スコア:0)
2文字なのは確定してるんだから、設定で変えられるようにしてテストしろよ
まさか、埋め込んでるの!?
Re:いやいや、馬鹿すぎだろ (スコア:2, 参考になる)
新元号の文字コードが、よりによってShift_JISで0x5cを含む
いわゆるShift_JISのダメ文字になってたりして。
Re: (スコア:0)
そんな予想したらフラグ立ちそうで怖いよ~~~
ホントやめてください。
そんな事になったら、本当に死亡するSIer出てきそう。
Re: (スコア:0)
その辺の話を政府に苦言なり進言なりあげられるロビイストは日本のIT業界にいないの?
特定の文字コードによるトラブルなんてのは、流石に専門家の立場から進言しないと問題点が伝わらない例だと思うけど…。
# 日本IT業界の黒い話を聞く限りじゃ、政府との窓口役は皆安請け合いのクズばかりというのも有りそうだけど…o…rz
Re: (スコア:0)
第1・2水準から選ばれるなら次の34字。
なんか平易な文字という縛りがあるみたいだから「圭」「構」「十」「申」「貼」「能」「表」「暴」「予」ぐらいか。あまり使えそうにないかな?
噂浬欺圭構蚕十申曾箪貼能表暴予禄兔喀媾彌拿杤歃濬畚秉綵臀藹觸軆鐔饅鷭
Re: (スコア:0)
― ソ Ы Ⅸ 噂 浬 欺 圭 構 蚕 十 申 曾 箪 貼 能
表 暴 予 禄 兔 喀 媾 彌 拿 杤 歃 濬 畚 秉 綵 臀
藹 觸 軆 鐔 饅 鷭 纊 犾 偆 砡
どの文字のつもりで言いましたか?
Re:いやいや、馬鹿すぎだろ (スコア:1)
テスト用のダミー元号を決めてIT業界内で統一しといて欲しい。
ケータイとかパソコンとかの時計を数年後に設定してバグ出し、とかやるときに、どのOS、どのサーバでやっても同じように表示されると分かりやすくて便利だし。うっかりそのまま修正を忘れて切り替えを迎えても、一目で切り替え漏れだと分かって楽だし。
# それがほんとの次の元号だと勘違いしちゃうやつらが一定数現れて混乱するのを指さして笑えるし
Re: (スコア:0)
保気とか富賀とか羽下とかどうですか
Re: (スコア:0)
カレンダーや手帳は設定では変えられないぞ。
Re:いやいや、馬鹿すぎだろ (スコア:1)
アップデートで簡単に変えられるでしょ。
Re: (スコア:0)
紙を?
Re: (スコア:0)
電子ペーパーというものがあってだな・・・
#何か違う。
Re: (スコア:0)
元号の所を空白にして、決まったらシールを配るとか
# カレンダーはともかく、手帳は大変そうだな
Re: (スコア:0)
ちゃんと開発できないやつは、よくこういうこと言うよね。
テストの主旨がわかってないんだろうな。
問題なのは変える手間じゃなくて、ちゃんと変わるか予想外の問題が出てないか
確認する手間なんだよ。「設定変えたので変わってるはず」で済むんだったら楽勝。
システムによっては外字作るか、Unicode に新しい文字を登録して、新しいフォント
準備しなっくちゃならないとか、笑えるやつもあるし。
# 私は「OSの設定変えたので変わってるはず」で押し通すつもりだけど。
Re:いやいや、馬鹿すぎだろ (スコア:1)
酷いシステムになると「文字列xが○○だったら~処理」みたいなのがハードコーディングされてたりして…
# 何故可変のものを比較するのに固定値を埋め込んでしまうのか…
Re: (スコア:0)
やっつけで対応したコードなんて、埋め込み山ほどあるでしょう。
まぁ、昭和→平成問題で、和暦使わなくなったシステムも多い(特に民間)ので、「平成対応時の遺産」くらいじゃないのかなぁ。
Re: (スコア:0)
SJISの$5Cに引っかかる元号になったら古いシステムで悲鳴が上がりそうだなw
Re: (スコア:0)
> 2文字なのは確定
そう思わせといて3文字とかだったらマジで殺されますね。
あと、「㍻」使ってる場合はやっぱり厳しいね。
Re: (スコア:0)
元号は法律で漢字2文字と決まってるから
それはない。
Re:いやいや、馬鹿すぎだろ (スコア:1)
確かに法律では決まってないね。決めたのは閣議報告。
https://www.digital.archives.go.jp/das/contents/pdf/lossy/H11B00017200... [archives.go.jp]
Re: (スコア:0)
葛城市の「葛城」(U+845B U+E0100 U+57CE)みたいにIVSを含んでいたりしたら大変です!
漢字2文字と言いつつ、UCSで3文字、UTF-16で4ワード、UTF-8では10バイトもあります。2文字だから大丈夫なんて、甘い甘い。
Re: (スコア:0)
10バイトだと何が困るのかさっぱりわからんのだが。むしろ10バイトだと対応できないような柔軟性のないコードで許される現場って、どんだけ甘いんだ。
Re: (スコア:0)
すごい自信ですね。データベースのバイト長制限とか、帳票のレイアウトとか、文字コード変換とか、入力文字数のバリデーションとか、全文検索の異体字対応とか、思いつくことなんていくらでもあると思いますが・・・。
そこまで十分に考えきっているシステムはほとんどないですね。同じUTF-8ですら、IVSのU+E0100を、いったんUTF-16のサロゲートペアにしてからUTF-8にして6バイトにしてしまう(それを正しいと定義している)処理系もありますからね。
Re: (スコア:0)
まったく意味不明。挙げた例のすべてで年号変更が無関係。
データベースのバイト長制限 →もしかして、「平成」をUTF-8で表現すると10バイトになることを知らない人?
帳票のレイアウト →表示が2文字のままで変わらないのだからレイアウトは影響ない
文字コード変換 →意味不明。自分の言ってることわかってる?
入力文字数のバリデーション →あなたのシステムは「平成」がバリデーションエラーになってたわけか
全文検索の異体字対応 →文字単位の異体字対応なら年号無関係だし、そもそも極めて優先順位が低い
Re:いやいや、馬鹿すぎだろ (スコア:1)
6バイトになると思っていたのですが、10バイトの場合には具体的にどのようなコードになるのでしょうか?
Re: (スコア:0)
u5e73-ue0101とかだったらおもしろいな。そんなの見たことないけど。
Re: (スコア:0)
Re: (スコア:0)
バイトオーダーマークって1バイトでは無いよね…?
NULLは入らないんじゃ無いかな
UTF8ではBOMはそもそも必要ないけど
Re: (スコア:0)
Pascal フォーマットで Length が32ビット
なら10バイトになるかも。
UTF-8でPascalフォーマットでの保存ってシステムって見たことはないけど、世の中にはあるんだろうな。
Re: (スコア:0)
そういう柔軟性の無いシステムの保守をやってるとか、改修をやってくれと泣きつかれたとか、そういうこともあるんですよ
あとOCRラインケチった旧システムを踏襲して元号コード無しの納付書とか・・・
Re: (スコア:0)
君が実作業側で、発注者とか丸投げ上流ではないことを切に願います。
切に願います。
切 に 願 い ま す
Re: (スコア:0)
>10バイトだと何が困るのかさっぱりわからんのだが。むしろ10バイトだと対応できないような柔軟性のないコードで許される現場って、どんだけ甘いんだ。
自分で何も作ったことないのにドヤ顔でこういう頓珍漢なこと言うゆとり増えたよね
Re: (スコア:0)
http://www.unicode.org/L2/L2017/17429-sc2-n4577-japan-new-era.pdf [unicode.org]
UCSに新元号のコードポイントの予約要求してるけど、レガシーシステムをサポートするためだからBMPでないと困るとか言ってる。
マジで北朝鮮の将軍様専用文字を笑えねーな。
そこまでレガシーならシフトJISで使えなかったらどのみち困るんじゃねーの?
話は変わるけど、ISO/IECのJTC1/SC2も芝野がやめてからずいぶんと秘密主義に戻って、この文書も私企業連合であるUnicode Consortiumのほうがオープンに情報を出している始末というのもひどい
Re: (スコア:0)
これはヒドい……
Re: (スコア:0)
孝謙天皇「天平勝宝ですっ★」
Re: (スコア:0)
改号に備えた提案をしても「ハードコーディングのほうが早くて安いならそっちで」というオーダーがあったという話を聞いてことはある。
Re: (スコア:0)
過去には2文字を超える元号もあったよ。
Re: (スコア:0)
過去は過去。今では元号を2文字にするというガイドラインがあるから
Re: (スコア:0)
ルールは不変ではありませんよ
ルールは破るためにある (スコア:0)
でもまだそれは予想であって確定じゃないから。
直前になって3文字になった時点でアウト。
それに対して文句を言ったところで、「想定してなかったお前らが悪い」って言われたらそれまで。
せめて漢字二文字にするって確約すればいいのに、なんでしないんだろうね。
つまりは三文字以上にする余地を残しておきたいからでしょ。
#中にはこういうジョーク(?)も: https://www.j-cast.com/2018/01/17318824.html?p=all [j-cast.com]
Re: (スコア:0)
本当にこれ。
2000年問題から18年とか経って、改元時期も分かってるのに、盛り上がるかよりシステム屋の都合を優先しろとかどんだけ無能なんだとしか…。
こんなもん最初のコンピューターが発明された時点ですら難しい問題ではないだろ。
正気を疑うわ。
Re: (スコア:0)
仮の元号を使用してテストができるシステム屋と、製造した後はアップデートが事実上不可能な印刷屋を一緒にするようなコメントはしちゃいけません。
ちなみに、お役所に提出する書類などは和暦必須のがあるようです。そういった書類にかかわるシステム屋さんは、逃げ道が減る分だけ大変かも。
#手帳・カレンダー業界をはじめとした各業界から混乱しないように早めの新元号公表を求められているにもかかわらずこの体たらくじゃ、「国民の生活に支障のないように」との今上陛下のお気持ちを完全に無視する所業ですな。
#現政権は国民の声を無視することに慣れているので、今上陛下のお気持ちを無視するのも平気なんでしょうね。
Re: (スコア:0)
そろそろ元号は伝統文化と割り切って仕事で使うのはボイコットしたい気分。
ひとまず大学の事務書類は全部西暦で提出するようにしてみようと思います。
Re: (スコア:0)
皇紀でGO
Re: (スコア:0)
ホルホルいらね
Re: (スコア:0)
お役所の文書は全て和暦必須ですね。
でも昭和64年の文書は出回ってたし平成元年が施行日の法律も再議決とかしなかったので、平成31年も改元後8ヵ月は有効かと。
Re:システム屋よりカレンダーや手帳の業界が死ぬね (スコア:2)
必須っていうけど書き込み済みの元号を消して西暦で書いても受け取らなきゃいかんとか決まってなかったっけ
何か通達とかあったような
Re: (スコア:0)
本当は西暦拒否はダメなんだけど、実際には蹴られる。
私の職場は大学だが、文部科学省に提出する前に大学の事務から書き直せと言われる。事務方と喧嘩してもロクなことがないから結局こっちが折れる。
Re:システム屋よりカレンダーや手帳の業界が死ぬね (スコア:2)
なるほど…
そういうの戦うのが好きな人に頑張ってもらわないとダメですね…
Re: (スコア:0)
よし、小倉昌男さんを召喚しよう。