Använd accesskey 'n' för att hoppa till de interna navigationslänkarna i dokumentet. Hoppa till början av innehållet.
Detta dokument är en översättning av ett engelskt orginal. Om det finns tveksamheter eller fel i detta dokument, så är senaste version av det engelska orginalet den auktoritativa versionen. Copyright tillhör W3C, enligt nedan.
Översättare: Olle Olsson, SICS
Avsedd läsarkrets: XHTML/HTML-kodare (med editorer eller skripts), skriptutvecklare (PHP, JSP, etc.), projektledare för webbprojekt, och alla som vill veta hur man bör hantera internationella datumformat.
Hur förbereder jag mina webbsidor för att visa datum i olika internationella datumformat?
Webbplatsbesökare som kommer från olika lokaler kan förvirras av hur datum beskrivs. (Översättarens anmärkning: det svenska termen lokal används här som översättning av den engelska locale.) En lokal definierar användarens preferenser för användning av språk, datum, tid, valutor, mått, sortering, etc.) Formatet MM/DD/YY är specifikt för USA. I största delen av Europa används DD/MM/YY. I Japan används YY/MM/DD. De skiljetecken som används kan vara snedstreck, bindestreck eller punkt. I några lokaler används inledande nolla, i andra gör man inte så. Om en användare som kommer från Japan ser en amerikansk engelskspråkig webbsida, som hämtats från en webbplats i Tyskland, och som visar datum 03/04/02, hur tolkar då användaren detta datum?
Din första tanke kan vara att detta problem tas om hand genom lokalisering av webbsidan – dvs att översättaren ser till att det blir rätt. Motstå denna frestelse. Vill du verkligen hantera olika kopior av dokumentet för USA och för Storbritannien, som bara skiljer sig åt vad gäller datumformat? Du måste ändå kunna hantera flerspråkiga användare, som illustrerades i vårt exempel ovan.
Du har tre alternativ att välja mellan, där var och en har såväl fördelar som nackdelar:
ISO 8601 specificerar formatet YYYY-MM-DD. 2003-04-02 är tydligare än 03/04/02. (Vissa föredrar att anpassa ISO 8601 genom att använda en förkortning av månadsnamnet så att månaden blir tydligare, t.ex. 2003-Apr-02, men då är det inte längre lokalneutralt.)
Fördelar:
Nackdelar:
För att uppnå detta så kan du använda månadens namn (förkortat eller ej), och använda fyra siffror för alla Gregorianska årtal. Exempelvis, 2 april 2003.
Fördelar:
Nackdelar:
HTTP-huvudet "Accept-Language" anger egentligen bara användarens preferenser för språk, men används ofta för att bestämma lokalpreferenser.
Denna metod fungerar bra för dynamiskt skapade webbdokument, där datum hämtas från någon serverdatabas och läggs in i en webbsida, så länge som användarens förväntningar om datumformat är tydliga. Om det är lämpligt eller ej beror snarare på det språkliga kontextet än på inställningarna i användarens webbläsare. Till exempel:
Hur detta kan åstadkommas beror på din utvecklingsmiljö. Här är några pekare för vanliga utvecklingsmiljöer.
Anropa metoden
getLocale
i objekten
ServletRequest
eller
HttpServletRequest.
Använd det resulterande objektet
Locale
för att anropa
DateFormat.
Observera att formatet
SHORT
enbart använder siffror.
Om du vill ha ett otvetydigt format, använd då formatet
LONG.
I några lokaler ger även formatet
LONG
enbart siffror.
Se även ICU4J eftersom den innehåller mer aktualiserad data (och mer funktionalitet) än JDK-rutinerna.
Använd
Request.ServerVariables('HTTP_ACCEPT_LANGUAGE')
för att få tag på användarens preferenser.
Parsa den första lokalen i listan av acceptabla lokaler.
Du måste själv hantera
avbildningen från alfabetisk
lokalkod till numerisk lokalidentifierare
("Locale Identifier").
Sätt
Session.LCID
till det returnerade värdet.
Anropa
FormatDateTime
för att formatera datum.
Använd vbLongDate för att undvika tvetydighet.
Använd
$ENV{'HTTP_ACCEPT_LANGUAGE'}
för att få tag på det språk som användaren föredrar.
Använd
POSIX:strftime
för att formatera datumvärdet.
Du måste själv hantera
avbildningen av koden för
språk till formatsträng för datum.
Det finns ingen perfekt lösning för detta problem. Utvärdera alternativen och välj det som bäst svarar mot dina preferenser och aktuellt sammanhang.
Om det är möjligt att användaren kan bli tveksam om hur visade datum skall förstås, så är det vanligen bäst att använda explicit månadsnamn och fyrsiffriga årtal för gregorianska datum, eller ange åtminstone i sidan hur datum skall förstås.
Datum kan omformateras med dynamiska metoder för att passa till sidans språkliga sammanhang.
Några har förespråkat att man ska skapa en <date>-tagg, som skulle visa datum i enlighet med den lokal som är angiven i webbläsaren. Detta skulle ge samma svårigheter som beskrevs för dynamiskt genererade datum med det japanska exemplet ovan. Det mest lämpliga formatet beror vanligen på sidans språkliga sammanhang, och inte på det verktyg som användaren använder.
Tala om för oss vad du tycker (på engelska).
Prenumerera på en RSS-kanal.
Twitter (Nyheter på hemsidan)
Översatt från engelskt innehåll skapat/ändrat 2007-07-04. Översättningen senast ändrad 2011-06-26 19:19 GMT
Information om ändringar i orginaldokumentet kan fås genom att söka efter qa-date-format i i18n-bloggen.
Copyright © 2003-2011 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.
Nya resurser
@webi18n