對於輸入字段應該在HTML表單上運行多長時間，是否有任何指導/建議？具體做法是：對HTML表單輸入字段長度（例如用戶名，電子郵件）的建議
可視長度可以短（20個字符），但這是否阻撓用戶稍長的e-mail地址？
對於所有字段，捕獲長度可以設置爲200個字符，但這是一個好的做法嗎？這會有什麼不利嗎？
，我正在盤算的共同領域是：
已知可能值（如年齡，電話號碼，國家，製造商）的字段都可以預先判斷，所以不是問題。
假設最終要存儲它們，可以使它們保持相同或略小於數據庫字段長度。
這真的是一個設計問題。用戶可以接受什麼樣的長度。 我可能會將允許的最大電子郵件長度設置爲最多50個字符（許多超過40），但我可能不希望在我的Web表單 – Techboy 2009-05-17 20:18:42
哪個答案您接受，請考慮您所服務的人羣類型。例如編程人羣的電子郵件，可能是這樣的：
，
而籃子編織者人羣可能是這樣的：
[email protected]ld.com.
我必須修改我的答案，因爲你編輯而不必水平滾動。即大小，而不是MAXLENGTH，所以我想答案還是有點相關的恐懼以下情形的發生：
alt text http://img190.imageshack.us/img190/5632/techboy.png
VS
alt text http://img199.imageshack.us/img199/6746/weavers.png
不應該有任何的可視差異/捕獲長度。至少我從來沒有聽說過這種方法，我覺得很奇怪。
某些文化中的名稱可能會非常不同，很容易出現幾百個字符。
登錄名可能在30個字符的限制內，這是Google的限制。
密碼應該被散列，並且不能直接存儲，哈希會產生40個字符。
電子郵件最長可達260個字符。如果考慮到非拉丁字符的可能性，這些字符的替代品將進一步擴展此長度。
電話號碼和郵政編碼遠不能預測，長度和格式因國家而異。
我的建議是在數據庫中使用不受限制的字段。如果你使用SQL Server，那麼使用nvarchar（max）。您可以在代碼中引入限制，但是當用戶向您抱怨由於您的限制而無法正確輸入他/她的信息時，請準備展開限制。
我傾向於讓他們很長 - 超過200個字符。在網站上顯示時，使值更易讀是次要的實際停止的人能夠把自己的電子郵件地址英寸
考慮您的後端數據庫最有可能有一個類型，允許串高達有一定的長度，但如果只存儲10個字符，則不會通過存儲200個字符來懲罰您，但我沒有看到這種方法存在任何缺陷。
我正在專門討論諸如電子郵件，姓名，地址，網站網址等字段，而不是諸如用戶名和密碼之類的東西，這些東西在您的應用需要與他們一起工作時需要有合理的限制。 IE，如果您要求用戶輸入屬於他們的數據，則不應該打印以下類型的驗證消息：
「對不起，您的姓名/電子郵件地址/我們需要的東西 - 你太長了，你不能進去。「
我居然發現了這個問題，同時尋找答案自己...首批通過看完之後，我有幾個建議：
如果您正在爲您的應用程序的數據，數據字段長度應該與可查看的大小相匹配;特別是像User-ID這樣的東西。這是你控制的東西。
密碼字段應該有一個很大的上限，因爲你願意容納。由於密碼本身不應該存儲（存儲散列），表單中的字段可以表示大約1.5倍至2.0倍的最小允許長度（畢竟，它將被*****掩蓋）
棘手的部分是人們已經建立的信息，如果大多數用戶來自單一管轄區，那麼您可以針對該情況進行優化，並且您可以爲其他地區的人提供「其他」選項，或者根據您的實施情況，只允許該字段爲空。
底線：使字段短，你可以，但仍然允許廣大目標受衆羣體，以填寫表格的;並且通過不收集任何您絕對不需要的信息來降低複雜性。
如果你有，你可以做一些現有的數據下面找到長度：
SELECT
column AS 'field contents',
LEN(column) AS 'length',
CUME_DIST() OVER (ORDER BY LEN(column)) -- Fraction with length less than this value's length
FROM table
（經測試，在SQL Server 2012;還應work with oracle）
你可以找到一些非常有用的答案，非常類似的問題在http://stackoverflow.com/questions/20958/list-of-standard-lengths-for-database-fields – DOK 2009-05-17 20:17:25